.NET Blog   ·   .NET Casts   ·   .NET GUI Foren   ·   .NET BlogBook   ·   WPF Blogger   ·   visual studio one   ·   ASP.NET professional

  • ACHTUNG - NEUES BLOG

    Ab sofort steht unter http://devtyr.norberteder.com mein neues Blog zur Verfügung. Dieses Blog wird nicht weiter betreut, bleibt aber erhalten. Neue Eintr%auml;ge erfolgen nur mehr im neuen Blog. Kommentare werden ebenfalls nicht mehr behandelt. Wer weiterhin meinen Einträgen und Aktivitäten folgen möchte, möge bitte RSS-Feeds, Verlinkungen etc. an die neue Location anpassen.
Download .NET Essentials Installer
Trickkiste

Rude Q&A - Die etwas andere FAQ

26.06.07 - Entwicklung, Diskussionen, Qualitätsmgmt.
Beitrag von Norbert Eder
 Frequently Asked Questions (FAQ) sind hinreichend bekannt. Was aber hat es mit dem Begriff Rude Q&A auf sich? Sehr einfach erklärt.

Zu jedem Projekt (Software oder nicht) können tonnenweise Fragen gestellt werden. Manche sind für alle von Interesse (typischer Fall für eine FAQ), manche sind unangenehm und würden am liebsten nicht beantwortet werden bzw. sind ohnehin nicht für die Allgemeinheit bestimmt (sinnvoll für eine Rude Q&A). Zusammenfassend: Eine Rude Q&A enthält alle unangenehmen Fragen zu einem Produkt, Unternehmen etc.

Was bringt das nun? Fragen sind da, um sich mit ihnen zu beschäftigen, und sie auch zu beantworten. Vor allem unangenehme Fragen werden oft nicht beantwortet, sei es aus eigener Angst heraus oder bedingt durch andere Gründe. Fakt ist jedoch, dass man auf alle Fragen eine Antwort parat haben sollte. Durch die Beschäftigung mit einer Frage wird also eine Vorbereitung betrieben, die sich im Falle des Falles auf jeden Fall auszahlt. Zudem empfiehlt es sich, die notierten Fragen von Zeit zu Zeit zu überarbeiten, denn schlechte Antworten sind oft schlimmer, als gar keine.

via Scott Berkun

  Kommentar hinzufügen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


Microsoft's neue Produkte und des Entwicklers Zukunft ...

19.06.07 - Entwicklung, Diskussionen
Beitrag von Norbert Eder
 Grundlegend sind mir die aktuellen Versionen und kommenden Anwendungen von Microsoft bekannt. Kein Wunder. Schließlich liest man ja überall darüber. Wenn man nun aber an einem Tag mit so ziemlich allen neuen Produkten aus dem Hause Microsoft konfrontiert wird, bekommt man so wirklich mit, was denn nun auf uns Entwickler (und Designer) zukommt.

Ja. Das ist nicht wenig und im Grunde muss man sich schon sehr gut überlegen in welche Richtung man persönlich gehen möchte. Zahlreiche Möglichkeiten tun sich auf, aber kaum jemand wird es schaffen, sich tatsächlich mit allem zu beschäftigen.

Für mich stellt sich nun weiters die Frage, wohin dies führen soll. Viele neue Produkte, viele neue Möglichkeiten. Prinzipiell gut. Aber irgendwann ist es einfach zuviel. Derzeit will Microsoft wohl den gesamten Markt aufrollen und das noch mit aller Gewalt. Ich persönlich glaube aber nicht, dass sehr viele auf den Zug aufspringen werden.

Firmen, die gerade erst auf Visual Studio 2005 aktualisiert haben werden wohl wenig Interesse haben bald eine neue Version zu kaufen. Feature hin, Feature her. Anstatt der neuen Möglichkeiten durch die neuen Frameworks wäre es sehr sinnvoll Visual Studio selbst entsprechend zu erweitern. Man sehe sich hier einmal Eclipse an. Hier werden sehr viele Funktionen mehr quasi kostenlos angeboten. Immerhin kann unter Orcas nun die .NET Zielversion gewählt werden. Funktioniert jedoch auch erst ab 2.0.

Im Grunde sollten sämtliche Neuerungen gemacht werden, um dem Entwickler (oder Architekten) sein Leben zu erleichtern. Aktuell passiert genau das Gegenteil. Anstatt wirkliche Neuerungen einzuführen finden alte 'Technologien' ein Revival. Zuerst Ajax (gut, das wächst nicht auf den Mist von Microsoft) und im gleichen Atemzug XAML. Deklarative Sprachen hatten wir doch auch schon. Wurden aber dann doch lieber wieder verworfen. Heute sind sie wieder modern. Bahnt sich hier ein neues Paradigma an? Oder liegt es vielleicht daran, dass wirklich gute Ansätze fehlen? Ganz ehrlich? Ich glaube Letzteres.

Es ist gut, Dinge ändern zu können ohne Änderungen am Source vorzunehmen. Aber es dreht sich alles im Kreis. Injections (beispielsweise durch den Policy Injection Block) sind eine nette Sache. Wird uns allerdings durch AOP auch schon längere Zeit vermittelt. Was also kann man tun, um die Softwareentwicklung wirklich weiter zu bringen. Komponenten spielen hier sicherlich eine große Rolle. Ebenfalls SOA. Anwendungen müssen soweit sein (oder generell Frameworks), dass sich jeder seine Komponenten selbst zusammenfügen kann. Eigentlich sind wir davon nicht mehr weit entfernt. Aber wie wird das Problem mit der UI gelöst? XAML wird hier nicht die Lösung sein. Etwas Mächtigeres und vor allem einfacheres muss hier her. Wie das auszusehen hat kann ich auch nicht sagen. Aber es muss sich etwas tun.

  2 Kommentare - 583 mal angesehen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


Rekursive Methoden mit Hilfe eines Stacks abbilden

15.06.07 - Entwicklung, Diskussionen, .NET, Grundlagen
Beitrag von Norbert Eder
 Rekursionen werden recht gerne für unterschiedlichste Zwecke eingesetzt. Beispielsweise um ein bestimmtes Steuerelement auf einem Formular (oder darunterliegenden Containern) zu finden. Allerdings muss eine Rekursion nicht immer sein. Der Nachteil einer Rekursion besteht im zahlreichen Aufruf derselben Methode. Methodenaufrufe sind kostspielig und und sollten daher nicht übertrieben werden. In einigen Fällen der Rekursion läßt sich das vermeiden.

Im nachfolgenden Beispiel wird eine vorhandene Rekursion mit Hilfe eines Stacks ersetzt. Die Stack-Variante ist recht einfach umgesetzt und zudem auch noch performanter als die rekursive.

Um ein bestimmtes Steuerelement auf einem Formular zu finden, würde uns folgender rekursiver Ansatz zum Ziel bringen:
private Control FindRecursively(Control c, string strControlName)
{
    if (c.Name == strControlName)
        return c;

    foreach (Control cf in c.Controls)
    {
        Control cTemp = FindRecursively(cf, strControlName);
        if (cTemp != null)
            return cTemp;
    }
    return null;
}

Recht schnell erklärt: Das jeweils übergebene Control wird auf den Namen hin überprüft. Entspricht dieser nicht dem gewünschten, wird die Controls-Auflistung durchlaufen und dieselbe Methode wieder aufgerufen. Dies wird so lange gemacht bis entweder das gewünschte Steuerelement gefunden wurde, oder alle durchlaufen wurden. Das nachfolgende Beispiel zeigt, wie dies nicht-rekursiv, mit Hilfe eines Stacks gelöst werden kann:
private Control FindNotRecursively(Control c, string strControlName)
{
    if (c.Name == strControlName)
        return c;

    Stack stack = new Stack();
    stack.Push(c);

    while (stack.Count > 0)
    {
        Control cTemp = stack.Pop();
        if (cTemp.Name == strControlName)
            return cTemp;

        foreach (Control cf in cTemp.Controls)
            stack.Push(cf);
    }
    return null;
}

Auch diese Variante ist schnell erklärt: Das übergebene Steuerelement wird auf den Stack gelegt. Die darauffolgende Schleife durchläuft den Stack solange, solange sich Elemente darauf befinden. Per Pop wird immer ein Steuerelement vom Stack genommen und die Eigenschaft Name überprüft. Danach werden alle Steuerelemente aus der Controls-Auflistung auf den Stapel gelegt und ebenfalls durchlaufen. Dies geschieht ebenfalls so lange bis das gewünschte Steuerelement gefunden wurde, oder sich keine weiteren Elemente mehr auf dem Stapel befinden.

Ein kleiner Testfall wurde durch ein dynamisches Anlegen von Steuerlementen geschaffen:
Panel currentPanel = new Panel();
this.Controls.Add(currentPanel);

for (int i = 0; i < 40; i++)
{
    Panel p = new Panel();
    for (int i2 = 0; i2 < 80; i2++)
    {
        Label l = new Label();
        p.Controls.Add(l);
    }
    currentPanel.Controls.Add(p);
    currentPanel = p;
}

Button btn1 = new Button();
btn1.Name = "button1";
currentPanel.Controls.Add(btn1);

Danach wurden die unterschiedlichen Varianten mittels Stopwatch gemessen. Hier das Ergebnis:
// Zahlen in Millisekunden
// Erster Durchlauf
Recursively: 4
!Recursively: 1
// Folgende Durchläufe
Recursively: 1
!Recursively: 0

Die zahlen wirken auf den ersten Blick nicht sehr spektakulär. Zu beachten ist jedoch, dass die Beispielrekursion recht klein ist und wenig Aufwand verursacht. In der Realität sind viele Rekursionen meist aufwändiger, wodurch sich der Geschwindigkeitsunterschied verdeutlicht.

  2 Kommentare - 753 mal angesehen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


Über die Motivation zum Bloggen ...

21.05.07 - Blog-Intern, Entwicklung, Diskussionen, .NET, Allerlei
Beitrag von Norbert Eder
 ... wurden sicherlich schon zahlreiche Beiträge verfasst, auch wenn ich mir persönlich noch keinen dieser Beiträge gegeben habe (sei es aus Faulheit, oder einfach dadurch bedingt, dass ich derartige Artikel noch nicht gefunden habe).

Gerade eben habe ich jedoch eine Email erhalten, in der ich gefragt werde, wie ich denn die Motivation am Leben erhalte, mein Blog mit eben diesem zu befüllen. Ansich eine gute Frage, weiß ich doch selbst darauf keine Antwort. Das Bloggen ist so eine Sache. Einmal entspringen einem Ideen und Beiträge, dass es anderen ganz schwarz um den Augen wird, manchmal verbringt man Wochen darüber nachzudenken, was man denn (sinnloses) verbreiten könnte.

Tatsächlich ist die Motiviation selbst von einigen Faktoren abhängig:
- berufliche Situation
- private Situation
- Stress
- Zeit zum Testen/Spielen
- etc.

Je nachdem finden sich mehr oder weniger potentielle Beiträge. Ich persönlich kenne kaum einen Blogger, der mit jedem Beitrag den Nagel auf den Kopf trifft und permanent den richtigen Artikel zur richtigen Zeit bringt. Intuition und die richtigen Probleme zur richtigen Zeit sind ein gutes Mittel um gute Blog-Beiträge zu schreiben.

Anders verhält es sich natürlich bie den zahlreichen News-Bloggern oder denjenigen, die zu diversen Artikeln ihren Senf abgeben (das Bildblog fäll mir hier ein). Diese haben es wahrlich leichter, als dass sie lediglich auf bestimmte Ereignisse reagieren müssen. Ein Blog zu fachspezifischen Themen bietet an dieser Stelle nicht diese Vielfalt. Gilt es doch bestimmten Themenbereich einzuhalten. Und gerade dabei (und auch den nicht so zahlreichen Hits) spielt Motivation eine große Rolle.

Jedes seriöse Blog kann Stammleser vorweisen - so auch ich. Dennoch liest jeder das, wovon er sich am meisten verspricht. Dadurch werden Blogs auch schnell vergessen und gegen andere ausgetauscht, vor allem, wenn sich über einige Tage oder gar Wochen keine neuen Beiträge auffinden lassen. Aber gerade die blog-treue macht den Reiz der Blogs aus. Kaum ein Blog kann ohne Rückmeldungen leben. Schließlich möchten die meisten lernen und dies geschieht nur durch Kommunikation. Kay spricht es schon richtig an: gefragt ist auch eine Blogger-Ethik. Ohne diese können keine Blogs überleben und werden somit uninteressant. Leider gibt es immer wieder Personen, die einen persönlichen Vorteil daraus ziehen wollen und somit negative Beispiele abliefern.

Jedes Blog, welches sich ernsthaft mit eingegrenzten Bereichen auseinander setzt, verdient Aufmerksamkeit. In welchem Masse diese dem Blog "zugemutet" wird, findet sich wohl an der Qualität der Beiträge wider. Dennoch, die meisten Blogschreiber wenden sehr viel Freizeit auf, um detaillierte Beiträge zu verfassen. Eventuell sollte es an dieser Stelle entsprechende Richtlinien geben, um diese Arbeit zu honorieren, in welcher Richtung auch immer.

Nehmen wir ein x-beliebiges Blog, in dem weniger Einträge erscheinen als gewohnt: Es häufen sich Emails, warum denn auf einmal keine Beiträge mehr erscheinen. Anfangs recht nett, kristallisiert sich bald die "Elite" mit negativen Einträgen á la "hat es sich wohl nicht ausgezahlt" heraus. Unabhängig der dahinterliegenden Problematik (Stress, Krankheit etc.). Es wird also viel erwartet, wenn es aber darum geht, Antworten auf Fragen zu erhalten, dann stellt sich die "Community" taub.

Ja, jetzt wandere ich von einem Thema zum anderen. Aber warum auch nicht. Vor allem die .NET Community lag mir eigentlich bis dato ziemlich am Herzen. In der letzten Zeit musste ich aber feststellen, dass sich immer weniger innerhalb dieser Community tut - zumindest im deutschsprachigen Raum. Foren werden stillgelegt (oder erscheinen zumindest so), zu Projekten kann man kaum jemanden bewegen, kaum Rückmeldungen auf diverse Projekte und teilweise Grüppchenbildung. Ja, vor allem diese Grüppchenbildung entspricht zwar der typischen Verhaltensweise des Menschen, bringt aber eine Community nicht wirklich voran. Kaum ein Zusammenhalt in der .NET Community. Kaum tiegsinnige Diskussionen. Kleine Gruppen, die von sich behaupten, sie wären die besten, die einzigen. Ja, selbsternannte Heros.

Möglicherweise klingen die letzten Absätze nach Resignation. Das möchte ich in dieser Form nicht übermitteln. Vielmehr sollte an der Community wieder stärker gearbeitet werden, um vor allen "Neuankömmlingen" besseren Halt zu bieten. Meine eigenen Mittel in diese Richtung sind beschränkt. Ich kann lediglich auf Mißstände hinweisen und meine Mithilfe anbieten. Tatsächlich müssen alle mitwirken, um dieser Geschichte zu einem erfolgreichen Ende zu verhelfen.

  Kommentar hinzufügen - 27 mal angesehen   |  2 Trackbacks   |  Permalink  |  Trackback-URL


Jobangebote in der IT - Eine Weiterentwicklung ist notwendig

26.03.07 - Entwicklung, Diskussionen
Beitrag von Norbert Eder
 Im Beitrag Jobangebote vs Jobforderungen hatte ich bereits über den - aus meiner Sicht gesehenen - Missstand von Jobangeboten der IT-Branche berichtet. Nun, diese Gedanken wurden weiterentwickelt und mit konkreten Vorschlägen untermauert.

Bisheriger Stand
Wer sich per Zufall ein Jobangebot aussucht, der findet darin hauptsächlich Forderungen, jedoch nahezu keine Anreize, sich auch tatsächlich zu bewerben. Gesucht wird ein Allrounder, ein Wunderwuzzi.

Umdenken ist notwendig
Fakt ist, dass Unternehmen Mitarbeiter suchen. Diese müssen natürlich entsprechende Kenntnisse mitbringen um ihre Arbeit zuverlässig ausführen zu können. Sind dafür jedoch alle angegebenen Anforderungen notwendig? Durchleuchten wir doch einige dieser Punkte:

Hochschulabschluss
Ein akademischer Titel suggeriert Lernfähigkeit, Lernwille, Selbstdisziplin, Genauigkeit und noch vieles mehr. Ein abgeschlossenes Studium bedeutet jedoch nicht, dass alle diese EIgenschaften auch tatsächlich erfüllt werden. Auch wird durch den Studienplan festgelegt, welche Fähigkeiten der Absolvent besitzen sollte. Das erfolgreiche Ablegen der Diplomprüfung bedeutet in der Realität aber nicht, dass dem so ist.
In der Arbeitswelt tummeln sich jede Menge Nicht-Akademiker, die zwar möglicherweise kein so breitgefächertes (oberflächliches) Wissen besitzen wie Akademiker, dafür jedoch in vielen Fällen eine höhere fachliche Kompetenz aufweisen.
Durch die Notwendigkeit eines Hochschulabschlusses, wird jedoch von Beginn an den Nicht-Akademikern die Chance auf diesen Job genommen. Es gibt auf beiden Seiten gute, als auch schlechte potentielle Mitarbeiter. So sollte nicht die Anforderung nach einem Hochschulabschluss gegeben sein, sondern vielmehr, die tatsächlichen Anforderungen bzw. die mögliche Weiterentwicklung im Unternehmen. Dadurch kristallisiert sich sehr schnell heraus, ob nun doch ein akademischer Grad notwendig ist oder nicht. Besitzt jemand ohne akademischen Grad diese Fähigkeiten bekommt er jedoch die Möglichkeit, sich zu bewerben (bzw. wird seine Bewerbung ernst genommen).
Ausschlaggebend sollten dementsprechend die tatsächlichen Fähigkeiten sein und der Grad der Übereinstimmung zu den gemachten Anforderungen.

Ich will, ich will - Angaben der Anforderungen
Hier gilt nach der Größe des Unternehmens zu unterscheiden. Kleine Softwareschmieden vereinen mehrere Aufgabengebiete in einer Person. Hintergrund: Es kann sich nicht für jedes Aufgabengebiet einen eigenen Mitarbeiter (oder gar ein ganzes Team) leisten. Hier ist es unumgänglich, dass ein Softwareentwickler auch Datenbank-Administrator ist, oder sich ebenfalls mit Netzwerken auskennen muss. Diese Tatsache kann nicht umgangen werden, sollte jedoch in einem Jobprofil angegeben werden - nämlich als Hinweis zur Unternehmensgröße und des tatsächlichen Aufgabengebietes.
Bei größeren Unternehmen gestaltet sich dieser Punkt einfacher. Hier gibt es oftmals eigene Datenbank-Administratoren, Entwickler-Teams in unterschiedlichen Ausprägungen etc.
Nichts desto trotz sollten ganz klare Verhältnisse geschaffen werden. Es gilt sich zu überlegen, welche Anforderungen wirklich notwendig sind (keine utopischen Angaben) und welche optional für das Unternehmen hilfreich wären. Kaum wird es jemanden geben, der alle Anforderungen erfüllen kann, jedoch sollten diese klar (der Realität entsprechend) definiert werden.
Das wichtigste an dieser Stelle ist jedoch anzugeben, was der potentielle Mitarbeiter als Gegenleistung erhält. Natürlich steht das Gehalt im Vordergrund. Dieses ist - da ein bestimmter Betrag - klar bewertbar. Es stellt jedoch nur einen Teil der Gegenleistung dar. Was kann denn das Unternehmen noch bieten?
Vor allem Softwareentwicklern wird oft nachgesagt, dass sie meist nur über eine geringe soziale Ausprägung verfügen, introvertiert sind, nur in ihrer eigenen Gedankenwelt leben. Dies ist schon lange nicht mehr so. Für wenig Geld kann also jedes Unternehmen soziale Rahmenprogramme anbieten (gemeinsame Ausflüge, Sport, Besuch von Freizeit-Veranstaltungen). Welcher Entwickler freut sich beispielsweise nicht darüber, hin und wieder auf eine Fachmesse zu dürfen?
Diese Angebote sind zwar nicht leicht zu bewerten (da nicht Bestandteil des Gehaltes), sorgen aber für eine besondere Grundlage für eine gute Zusammenarbeit und genau das sollte es sein.

Sind allgemeine Angaben gute Angaben?
Besonders allgemein gehaltene Angaben können von einem potentiellen Bewerber nicht bewertet werden. Ein Beispiel:

Hervorragende C# Kenntnisse

Wie sind hervorragende Kenntnisse zu beurteilen? Kann man sich selbst als hervorragend einschätzen? Ja, kann man. Entspricht aber meist nicht den Tatsachen. Vielmehr bietet es sich an, klar zu beshreiben, was tatsächlich gewünscht wird. Anstatt der obigen Angabe könnte dies so formuliert werden:

C# (Reflection, Threading, Generics)

Und schon ist klar, was gewünscht wird. Ohne Missverständnisse. Genauso sollte dies bei allen angeführten Forderungen passieren. Nochmals zur Erinnerung: Nur Punkte definieren, die auch tatsächlich benötigt werden, keine utopischen Angaben.

  8 Kommentare - 1220 mal angesehen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


Von der Steinzeit direkt in die Zukunft

07.03.07 - Entwicklung, Diskussionen
Beitrag von Norbert Eder
 Gestern hatte ich das Vergnügen, einem Vortrag von Dipl.-Ing. Dr.techn. Univ.-Doz. Klaus Schmaranz zuhören zu dürfen. Thema: Eine kleine Geschichte der Softwareentwicklung.

Es war sehr interessant, wieder einmal vor Augen gehalten zu haben, warum sich sehr viele Menschen mit der IT wirklich schwer tun und so gänzlich überfordert sind. Und das betrifft nun nicht nur Anwender. Nein, auch der Softwareentwickler selbst ist überfordert. Aber warum? Eigentlich ist es doch gar nicht so schwer ein guter Softwareentwickler zu sein, oder etwa doch?

Ein Großteil des menschlichen Wissens wurde über Jahrtausende hinweg generiert. Sei es die Mathematik, Astronomie oder die Medizin. Ehemalige Berufsbilder haben sich bis in die heutige Zeit nicht verändert (man denke an Bauern, Priester, Ärzte). Nun stelle man dies der Softwareentwicklung gegenüber. Anstatt 100.000 Jahre zu benötigen um von der Steinzeit in die Neuzeit zu gelangen, hat es die Softwareentwicklung in einigen Jahrzehnten geschafft diesen Sprung zu tun. Permanente Paradigmenwechsel, ständige Berufsbild-Änderungen prägen unsere Branche. Wissen, das vor 10 Jahren gültig war, ist es heute zu großen Teilen nicht mehr. Neue Programmiersprache, ständig wechselnde Technologien, kurze Lebensdauern von APIs usw. Kein Wunder dass der Entwicklung kaum zu folgen ist.

Und nun die alles entscheidende Frage: Wo soll das hinführen? Und hier, genau hier, möchte ich den Faden von Dr. Schmaranz noch weiterführen. Der Softwareentwicklung (oder der IT generell) wird nachgesagt, Arbeitsplätze zu zerstören. Durch Automatisierung und vereinfachte Prozesse werden Berufsbilder zerstört, an Arbeitskräften kann eingespart werden. ABER! Der für mich ersichtliche Punkt ist folgender: Rationalisiert sich ein Softwareentwickler nicht selbst ins Nirvana? Software, die es erlaubt, sich seine eigene Anwendung selbst zusammen zu stellen. Durch den Einsatz von Komponenten heute schon sehr vereinfacht. Zahlreiche Projekte zeigen: Der "Entwickler" von morgen ist der Anwender selbst. Zukünftig wird der Anwender seine Anwendung selbst zusammenklicken, ein wenig konfigurieren und er hat das was er möchte. Die Bausteine wurden entwickelt, durch ein wenig künstlicher Intelligenz kann die Software bestimmte Bereiche selbst erlernen und/oder optimieren. Der Softwareentwickler wird zum Konfigurator. Dieses Spiel kann man soweit spinnen, bis wir (die Softwareentwickler) komplett überflüssig sind. Doch was kommt danach? Das kann ich auch nicht beantworten. Aber keine Sorge. Irgendeine Schweinerei wird uns sicherlich einfallen ...

  1 Kommentar - 700 mal angesehen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


Jobangebote vs Jobforderungen

05.03.07 - Blog-Intern, Entwicklung, Diskussionen
Beitrag von Norbert Eder
 Wieder einmal bin ich über einige Jobangebote für C#-Entwickler gestoßen und muss hier einfach einmal meine Meinung kund tun, auch wenn diese nicht bei allen Gehör oder Einsicht findet.

Was wird gefordert?

- .NET / C# Kenntnisse
- ASP.NET Kenntnisse
- Objektorientierte Programmierung
- Software Architekturen (UML)
- Beherrschung mehrerer DBMSs
- Soft Skills nicht zu vergessen
- Abgeschlossenes Studium

Was wird geboten?

Hier wird es nun schwierig. In den meisten Jobangeboten wird von einem angenehmen Arbeitsklima gesprochen, von leistungsbezogenem Gehalt. Das war es dann auch wieder. Auf der Waage liegen also viele Forderungen und selten ein wirklich gutes Angebot.

Betrachtet man nun die offenen Stellen und die dafür wirklich in Frage kommenden Personen (man beachte, dass in Frage kommende Personen möglichst alle geforderten Punkte wirklich erfüllen) kann gut erkannt werden, dass bei weitem nicht alle offenen Jobs besetzt werden können.

Alleine aus dieser Tatsache heraus ist es unverständlich, warum Jobangebote auch heute noch so formuliert werden, wie es vor 20 Jahren üblich war. Vielmehr sollte um die wirklich guten Entwickler geworben werden. Denn nur durch ein Jobangebot, das man auch so nennen kann, fühlen sich die guten Leute angesprochen und melden sich. Zusätzlich will der Bewerber bzw. spätere Mitarbeiter im Unternehmen gehalten werden. Nur durch Forderungen ist dies nicht erreichbar. Vielmehr sollten die Unternehmen auch anführen, was sie bereit sind zu geben.

Bitte mich nicht falsch zu verstehen. Das Gehalt ist eine wichtige Komponente - ganz klar - aber sicherlich nicht das ausschlaggebende Faktum. Unternehmen haben wesentlich mehr zu bieten. Seien es fördernde Maßnahmen (Schulungen, Erweiterung der Soft Skills) oder entspannende Angebote (alle 2 Wochen 20 Minuten Masseur für die verspannte Rückenmuskulatur) bis hin zu anderweitigen Unterstützungen. Wie gesagt, Unternehmen haben vieles zu bieten. Es sollte nur hervorgehoben werden.

Ich will, ich will, ich will ist sicherlich der falsche Weg, um gute und motivierte Entwickler in sein Team zu holen. Wer nehmen will muss auch geben. Wie das Geben aussieht ist Verhandlungssache, sollte aber von vornherein vom Unternehmen angeboten bzw. in Aussicht gestellt werden.

  3 Kommentare - 876 mal angesehen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


Serviceorientierte Architekturen Grundlagen

03.03.07 - Entwicklung, Diskussionen, .NET, Grundlagen
Beitrag von Norbert Eder
 Serviceorientierte Architektur (SOA) ist wohl ein häufig gebrauchter Terminus in der heutigen Zeit. Wer sich beispielsweise näher mit der Windows Communication Foundation (WCF) beschäftigen möchte, sollte sich zuvor in die Grundlagen der SOA einarbeiten.

Wie die Bezeichnung vermuten läßt, besteht SOA aus lose gekoppelten Diensten, die jeweils bestimmte Aufgaben kapseln und unabhängig voneinander bezogen werden können. Ein Dienst wird von einem Service Provider angeboten, der Client nennt sich Service Consumer.

Ein einzelner Dienst stellt unterschiedliche Funktionen (Operationen) zur Verfügung, die von einem Consumer aufgerufen werden können. Dabei wird ein Service über eine Schnittstelle (Contract) definiert. Die Schnittstelle beschreibt also, welche Funktionalitäten und Nachrichten angeboten werden. Hierbei ist zusätzlich darauf zu achten, dass der Client die Implementierung der Funktionalität nicht kennt, da diese vom Service gekapselt wird. Dadurch ist es sehr einfach möglich, die Funktionalität selbst zu ändern, ohne Änderungen am Client (und ein damit verbundenes Rollout) vornehmen zu müssen.

Nun stellt sich die Frage, über welches Protokoll kommuniziert wird. Dies wird in sogenannten Policies festgelegt.

Wie erfolgt nun der Ablauf der Kommunikation?

Die Kommunikation erfolgt prinzipiell durch das Versenden und Empfangen von Nachrichten. Diese enthalten Daten und keine Objekte. Der Austausch erfolgt über sogenannte Endpoints die vom jeweiligen Service bereitgestellt werden. Ein Endpoint besteht aus drei Teilen:

- Adresse
- Binding
- Kontrakt

Die Adresse definiert, wo der Endpoint zu finden ist. Das Binding beschreibt, wie der Endpoint aufgerufen wird und der Kontrakt (wie bereits weiter oben beschrieben) definiert welche Operationen angeboten werden.

Weitere Informationen zu diesem Thema können unter folgenden Links gefunden werden:

SOA - Wikipedia
Service Oriented Architecture - Microsoft

  Kommentar hinzufügen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


Aspect Oriented Programming

08.02.07 - Entwicklung, Diskussionen
Beitrag von Norbert Eder
 Ein heißes Thema und für viele sicherlich interessant. Und ein Blick über den Tellerrand schadet sowieso nie. Daher ein paar gute Links dazu:

Aspect oriented programming in C# :- Part I
Aspect oriented programming in C# :- Part II
Using AOP in C#
AOP (Aspect Oriented Programming) in C#
Aspect Oriented Programming using .NET - AOP in C#
AOP Support for C# (PDF)

  2 Kommentare - 2385 mal angesehen   |  1 Trackbacks   |  Permalink  |  Trackback-URL


Kostenlose Code Coverage Tools

27.01.07 - Entwicklung, Diskussionen, Software Testing
Beitrag von Norbert Eder
 Was ist Code Coverage?

Die Code Coverage Analyse wird zusammen mit Unit Tests eingesetzt. Durch sie wird überprüft, welcher Anteil des Sourcecodes durch Tests abgedeckt wird. Dadurch kann weiters festgestellt werden, welche Bereiche nicht abgedeckt sind und hat so die Möglichkeit, dafür entsprechende Unit Tests zu bilden. Insgesamt wird durch den Einsatz der Code Coverage Analyse die Qualität der Unit Tests verbessert.

Kostenlose Code Coverage Tools für .NET?

Kommerzielle Produkte zu diesem Thema gibt es einige, jedoch auch kostenlose Tools sind verfügbar.

NCover ist eines dieser kostenlosen Tools und steht aktuell in der Version 1.5.5 beta zur Verfügung, welche jedoch nur mit dem .NET Framework 2.0 zusammenarbeitet und nicht abwärtskompatibel ist. Dazu muss zu einer älteren Version gegriffen werden. Für eine komfortablere Auswertung der Berichte bietet sich der kostenlose NCoverExplorer an.

Eine weitere Variante stellt PartCover dar. PartCover unterscheidet sich in einigen Bereichen von NCover, leistet jedoch auch gute Dienste.

Lohnt sich der Einsatz?

Egal ob nun ein kostenloses Code Coverage Tool oder ein kommerzielles eingesetzt wird, insgesamt wird die Qualität der Unit Tests und somit der gesamten Software erhöht. Daher: Sehr empfehlenswert.

  1 Kommentar - 241 mal angesehen   |  0 Trackbacks   |  Permalink  |  Trackback-URL



Zurück Weiter