Ich würde noch einen anderen Aspekt andeuten: Release Zyklen.

* 2011 hat Amazon alle 11.6 Sekunden einen Teil ihrer komplexen Software Lösung deployed. kA wieviel es im Moment sind. Sicher noch mehr.

* Bei einem Office gibt es alle 1-2 Jahre eine neue Version.

Das wird die Entscheidungen auch maßgeblich beeinflussen.

@LaTino: Nein ich meinte, dass ich Agile/Lean wenn möglich immer verwenden würde.

Ich grenze das Folgende mal auf Software ein, die von Menschen bedient wird.

Der Kunde ist nicht unbedingt der Nutzer,. Das heißt irgendein Manager oder Projektleiter trifft Entscheidungen und ein Sachbearbeiter nutzt das Ding dann. Oder ein Endkunde für eine SaaS Projekt oder auch nur einfach ein Besucher einer Webseite. Und hier gibt es eine riesige Lücke, weil der Projektleiter einfach nicht wissen kann, was die beste Alternative ist. Soll der Button jetzt grün oder blau sein? Hat uU. einen großen Effekt auf die Conversion. Da hilft Erfahrung auch nicht viel weiter.

Diese Wissenslücke kann der Projektleiter zum Beispiel schließen indem er vor dem eigentlichen Projekt Prototypen baut und sie an Nutzer testet. Aber die besten Tests sind am richtigen Produkt. Agile Entwicklung sorgt für kontinuierliches Feedback durch den Kunden und Lean Development schließt die Feedback Lücke zum Endnutzer. Um die langfristige Zufriedenheit des Kunden zu garantieren, sehe ich keine Alternative.

Mich würde mal interessieren, wie ihr ein Projekt als "erfolgreich" bewertet. Aus IT Sicht mag es ja ausreichen, wenn der Auftraggeber zufrieden ist, aber das heißt ja erstmal gar nichts.

Ich sehe nämlich nicht, dass irgendeine Expertenkommission in der Lage wäre Anforderungen richtig abzuschätzen. Wie soll man als Abteilungsleiter beim Arbeitsamt wissen, wie Daten am besten einzupflegen sind, wenn man das selbst kaum noch selber machen muss? Man kann auch nicht von sich auf andere Benutzer schließen, obwohl dass viele Manager leider versuchen. Das heißt ohne ein Prozess mit kontinuierlichen Experimenten ist die Gefahr einfach extrem groß, dass man in die falsche Richtung rennt (oder das neue Produkt einfach nicht so gut wird wie erwartet).

ich verstehe einfach nicht, wie man NICHT Agile/Lean arbeiten will.

Ich schließe jetzt mal Software für den Eurofighter oder technische Integrationsprojekte hier aus, da mag vll. Agile wirklich nicht so gut funktionieren, habe aber auch noch keine SW für den Eurofighter geschrieben (ist wahrscheinlich besser so).

Ich ziehe den Begriff MessageBus zurück 😉.

Ich brauche in manchen Fällen eine Entkopplung und asynchrone Kommunikation. z.B. mit RabbitMq oder Kafka oder Azure Service Bus. In dieser asynchronen Kommunikation können auch Menschen beteiligt sein, weil sich manche Buchungsschritte und Fehlerbehandlungen (noch) nicht automatisieren lassen.

Das heißt im Kern habe ich eine Art ProcessManager der auf Events reagiert und daraufhin Events auslöst. Diese Events müssen jetzt von verschiedenen Services behandelt werden.

Ein Teil der Events sind im Prinzip an einem bestimmten Empfänger gerichtet, der auch mal Offline sein kann, z.B. Amadeus-Flug-Buchungssystem, andere Events werden z.B. von mehreren Services konsumiert. Beispielsweise wird wenn eine Buchung abeschlossen wird, eine Email versendet, eine Rechnung verschickt, ein Report aktualisiert und die Information an das Accounting System geschickt.

Ich könnte z.B. einfach Kafka oder EventStore für die asynchrone Kommunikation verwenden, müsste dann aber für die synchrone Kommunikation auch noch mit gRPC arbeiten. Die Frage ist, ob ich das auch irgendwie abstrahieren kann, bspw.

1. Ich kann natürlich ein Art Adapter schreiben, der beide Kommunikationsprotokolle für die Microservices kapselt. Wenn alle Services mit der gleichen Sprache arbeiten, kann ich das ja einfach als NuGet zur Verfügung stellen.

2. Ich könnte auch nur auf asynchrone Kommunikation setzen. Request / Reply ist aber nicht so einfach. Evtl. muss ich dann mit temporären Queues arbeiten, Timeouts werden schwieriger usw.

Ich liebe Aussagen ohne Begründung, das erinnert mich immer an Religionen 😄

Ich finde gRpc auch super und die Proto Files sind klasse, aber wie kann damit asynchrone Kommunikation machen? Ich meinte nicht Async I/O (Async Task usw.) sondern im Prinzip Messaging mit Queues / MessageBus usw.

Hallo,

wir planen testweise ein neues Buchungssystem auf der Basis von Microservices. Das wird erstmal ein Spiel und Testprojekt und es ist unklar, ob es jemals zum Einsatz kommen wird. Unser System muss Hotelbuchungen, Flüge, Mietwagen und Zusatzprodukte bedienen können. Außerdem natürlich noch mehrere Payment Provider usw.

Ein großes Problem unseres aktuellen Systems ist, dass es synchron arbeitet, d.h. der Benutzer klickt "Jetzt buchen" und dann kommt ein Spinner und wir haben 1 Minute alles abzuschließen. Das ist erstmal relativ wenig Zeit, wenn viele Produkte im Warenkorb sind. Außerdem gibt es immer mal wieder Fehler und Produkte können auch ausverkauft sein. Deshalb soll es in Zukunft asynchron arbeiten. Das heißt der Benutzer bekommt sofort eine Antwort "Buchung wird bearbeitet" und dann später eine Email, wenn alles abgeschlossen wird. Dadurch können wir auch manuell eingreifen und Alternativen anbieten, z.B. ein besseres Zimmer, falls das die Provision erlaubt.

Ein Teil der Kommunikation zwischen Services ist synchron (= Request/Response), z.B:

* Zahlung beginnen (generiert vll. nur einen Deeplink zu Paypal etc.)
* Produkt validieren (sind die Eingaben gültig etc.)

Ein Teil der Kommunikation auch asynchron (= Messaging):

* Bezahlung durchführen
* Produkt buchen
* Produkt stornieren

Für beide Probleme gibt es viele tolle Lösungen:

Synchron

* REST mit JSON
* gRPC
...

Asynchron

* Kafka
* RabbitMq
...

Jetzt wäre es super, wenn man das Kommunikationsprotokoll relativ kompakt halten könnte. Habt ihr Erfahrung mit irgendwelchen Alternativen die im Prinzip beide Kommunikationsmuster abdecken? z.B. Akka.NET, Orleans. Was sind da eure Erfahrungen?

Du musst dir aber dann überlegen, ob du Commands asynchron verarbeiten kannst - auch im Client - und wie dann (hast du ja erwähnt) Antworten verarbeitet werden. Was ist z.B. wenn Commands abgelehnt werden, weil die Validierung fehlschlägt? z.B. Uniqueness Constraints?

Das ist dann aber vom Client her motiviert und nicht vom Server.

Aus der Perspektive des Servers geht es bei den Queues v.a. um die sequentielle Verarbeitung. Wenn dein Client auf das die Bearbeitung des Commands wartet hat er ja auch eine Erwartung an die Verarbeitungsgeschwindigkeit, dann kannst du alte Commands auch einfach wegwerfen, egal ob dein Server crasht oder nicht.

Kurz: Ich würde mir genau überlegen ob du synchrone oder asynchrone Command-Verarbeitung willst.

Falls ihr noch keine Aggregate Roots habt, ist es wirklich das wichtigste diese Konsistenz Grenzen zu definieren und dann hat man auch fast schon die Aggregate Roots.

Du brauchst aber keine Queue pro Aggregate Root, das wäre eine krasse Partitionierung. Die Queue verringert in erster Linie die Anforderungen an transaktionale Änderungen der Datenbank (und natürlich ein bisschen Last). Falls du das ganze Aggregate Root transaktional speichern kanns, kannst du es auch einfach mit einem Retry versuchen.

Das hängt auch damit zusammen was ihr noch innerhalb eines Commands macht. Falls z.B. noch mit Externen Systemen kommuniziert wird geht es fast nicht ohne Queues (auch in CQRS würde man das oft sequentiell verarbeiten, aber eher dann in den Event Handlern oder Process Managern).

Commands sequentiell zu verarbeiten ist absolut normal und auch durchaus notwendig. Immerhin ist CQRS ja gerade ein Pattern für Collaboration.

Wichtig ist es v.a. Aggregate Roots gut zu wählen. Die wichtigste Bedingung ist Konsistenz: Choosing Aggregate Boundaries – Consistency. In einem Buchungssystem können z.B. Buchungen für ein Hotel nicht Parallel verarbeitet werden. Das heißt du machst aus einem Hotel ein Aggregate Root und verarbeitest die Commands für dieses Hotel sequentiell.

Ich würde bloß nicht locken sondern eher über Queues nachdenken und dann überlegen, wie du partitionierst. Am besten über AggregateId % NumPartitions oder pro Stadt in dem sich das Hotel befindet. Das funktioniert aber nur auf Aggregate Ebene, falls deine Operationen übergreifend sind würde ich das über einen ProcessManager abbilden (=Saga) und dann die EventHandler partitionieren.

Btw: Genau dafür gibt es ja auch den CommandBus, es ist einfach das Dispatching zu ändern.

Markdown? Ist nicht so mächtig wie Html, was natürlich auch ein großer Vorteil ist. Gibt bestimmt auch Parser für Android.

Und natürlich auch Editoren: https://simplemde.com/

Bist du sicher, dass dein äußeres Grid die volle Höhe hat?

Werfe mal noch anonymous types in den Raum 😉

new 
{
	name = "Suttgart",
	country = "de",
	nested = new
	{
		name = "Suttgart",
		country = "de",
		nested = new
		{
			name = "Suttgart",
			country = "de"
		}
	}
}

Du musst die Grid austauschen:

var temp = grid;
grid = newgrid;
newgrid = temp;

Wäre auch einfacher zu verstehen, wenn du ein paar konstanten einführen würdest:

also

const int FieldWidth = 4;
const int FieldHeight = 4;

grid = new int[FieldWidth , FieldHeight ];
newgrid = new int[FieldWidth , FieldHeight ];

[...]

for (int y= 0; y< FieldHeight ; y++)
{
       for (int x= 0; x< FieldWidth ; x++)
       {
       }
}

Klar, kann man. Aber danach habe ich gar nicht gefragt. Google benutzen kriege ich schon einigermaßen hin 😉. Vielleicht habe ich mich aber auch ein bisschen unklar ausgedrückt.

Ich hatte auf Erfahrungsberichte gehofft, z.B.

1. Habt ihr OData mit einem Data Provider verwendet, der kein Linq unterstützt? Wie groß ist dabei der Aufwand?
2. Habt ihr OData mit einem dynamischen Model verwendet und wie ist eure Erfahrung?
3. Wie groß ist die Adaption von OData? Wie außerhalb des MS Umfelds?
4. Wie stark musstet ihr OData einschränken?
5. Hattet ihr schon mal Probleme im Produktionsbetrieb weil Abfragen zu lange gedauert haben?
6. ...

Mir sind die Implikationen von OData noch nicht ganz klar. Und der Aufwand und Komplexität um einen guten Abstraktionsgrad zu erreichen scheinen mir doch relativ groß zu sein. Die Spezifikation ist ja auch so umfangreich, dass Implementierungen schon sehr unterscheidlich sein können.

Ich habe noch nicht mit OData gearbeitet und auch noch kein Service direkt verwendet, der OData unterstützt (also wahrscheinlich indirekt mit irgendwelchen Azure Client Libraries), bin aber daran interessiert, wie ihr das mit dem $filter handelt.

Bisher hatte ich Service Methoden, dich ich 100% kontrollieren konnte. Das heißt ich kenne die verschiedenen Optionen und kann den kompletten Kontrollfluss kontrollieren. Zum Beispiel Datenbankabfragen optimieren. Mit OData kommt viel Flexibilität ins Spiel und damit auch die Gefahr, dass sehr langsame Abfragen abgesetzt werden müssen.

Grenzt Ihr die Filter Möglichkeiten so ein, dass ihr nur Abfragen ermöglicht, die unproblematisch sind oder lebt ihr einfach mit dem Risiko?

Wie löst ihr das Mapping auf die Datenbank? In diesem Thread scheint es auch keine richtig gute Antwort zu geben: oData und die 3-Schichten-Architektur

@LaTino

Ich habe im Grund genommen die gleiche Aussage bzgl. TDD gemacht. Kleinere Module in Projekten helfen auch enorm bei TDD. Lange Build Zeiten kann man einfach nicht immer verhindern.

Ich finde die Build Zeit sehr wichtig - gerade für TDD - und würde dafür auch einige Kompromisse eingehen.

Wenn man seine Anwendung modularisiert, geht es auch immer darum, kleine Hürden aufzubauen, diese Modularisierung nicht zu umgehen. Diese werden aber zumindest in großen Projekten sehr häufig umgangen, zum Beispiel mit Aufrufen auf die Datenbank. Ich persönlich finde die Hürden bei mehreren Projekten aber so niedrig, dass man auch darauf verzichten kann. (Da sind mehrere Solutions und Micro Services besser geeignet wie ich finde).

Für mich sind Projekte aber vor allem eine Möglichkeit mich auf ein Problem zu fokussieren. Pro Projekt würde ich auch ein Projekt für die Tests anlegen und hat dann beides sehr nahe beieinander. Das reduziert die Build Zeit für die Tests drastisch und zur Not kann man ja auch alle anderen Projekte in Visual Studio vorübergehend deaktiveren.

Außerdem werden größere Refaktorisierungs leichter. Hierbei hat man bei wenigen Projekten oftmals das Problem dass für einige Stunden erstmal gar nichts mehr funktioniert. Das Projekt buildet nicht mehr und Tests kann ich auch nicht laufen lassen. Habe ich viele Projekte angelegt, kann ich mich von unten nach oben durcharbeiten und Etappenweise das Refactoring implementieren.

Hi zusammen,

ich hatte vor einigen Jahren ein OpenSource Project für Silverlight und Windows Phone (http://imagetools.codeplex.com/). Das hat sehr viel Spaß gemacht und ich hätte mal wieder Lust was zu bauen.

Ich hoffe sehr, das ASP.NET Core Erfolg hat. Insbesondere die einfache Runtime und Cross Plattform ist vielversprechend und vielleicht wird es ja auch vermehrt für kleinere Seiten eingesetzt. Daher liegt es für mich nahe, was in diese Richtung zu bauen. Ich hätte 2 Ideen und hätte gerne Feedback.

Die Zielgruppe sind jeweils kleinere und mittelgroße Projekte

1. Backend Tools

In meiner alten Position haben wir viele Module selber gebaut, wie zum Beispiel Caching oder bestehende Module integriert, wie zum Beispiel ASP.NET Identity. Das Problem war dabei, dass wir selten eine Oberfläche dafür hatten und es auch kein System gab, dass man einfach integrieren konnten. Deshalb haben wir ein Mini MVC Framework auf Basis von Microsoft Owin gebaut, dass einfach in bestehende Anwendungen integriert werden kann. Dies UI Module sind im Prinzip kleine Angular Apps. Die Inspiration dazu hat http://hangfire.io/ geliefert.

Hier mal ein Beispiel, wie das konfiguriert wird:

public void Configuration(IAppBuilder app)
{
	app.UseBackendAdministration(options => {
		options.ManageCaching(cache);
		options.ManageUsers(userManager);
		options.ManageBackgroundWorker(userManager);
	});
}

Vorteile:
* Sehr leicht in Windows Service, API und Frontends einsetzbar
* Wenig Abhängigkeiten (nur Owin und JSON.NET)
* Man muss nicht das ganze Packet verwenden, sondern nur was man braucht

Nachteile:
* Bei Microservices gibt es evtl. viele Stellen, bei denen man Sachen verwalten muss

Ich habe ein Screenshot eines Administrations Modules mal angehängt. Die aktuelle Implementierung hat auch einige Probleme. Basis Auth nervt zum Beispiel ein bisschen. Trotzdem war das System sehr hilfreich für uns weil wir einige Microservices gebaut haben, die dann mit wenig Aufwand ihre eigenen Administrations Tools spendiert bekommen haben. Bei einer neuen Implementierung würde ich evtl. die Daten von mehreren Services aggregieren wollen und Systeme bauen, mit denen ein Service als Provider für andere Services dienen kann. Beispiel: Je nach Szenario sollen die Texte für API und Web Frontend getrennt sein oder zusammen verwalten werden. Da jedes Module eh API's zur Administration zur Verfügung stellen muss, kann ServiceA auch für ServiceB Texte bereitstellen.

2. Headless CMS

Meine ASP.NET/Core Anwendungen haben natürlich sehr viel Domain spezifischen Code, für den es kein fertiges Modul gibt. Allerdings bin ich es Leid dauernd irgendwelchen banalen CRUD Lösungen zu bauen. Die Idee ist ein ASP.NET Core Modul zu bauen, dass ein Headless CMS bereitstellt (analog zu: https://www.contentful.com/features/). Ich möchte keinen App Builder bauen, sondern eine Lösung liefern, um ein Teil der Anwendung zu realisieren. z.B. Blog Posts, Content Element, Übersetzungen usw.

Um diese Module zu realisieren braucht man nicht Einstein sein, trotzdem ist es zeitaufwendig all die Repositories und Services zu entwickeln. Außerdem muss eine UI gebaut werden und all die kleinen Features, die in der Summe dann doch kostspielig sind.

Im Prinzip könnte man beide Projekte in ein gemeinsames Projekt integrieren. Allerdings ist meine Zeit natürlich begrenzt.

Ich hätte gerne Feedback zu beiden Ideen. Würdet ihr sowas einsetzen? Falls nicht, warum? Habt ihr vielleicht andere Ideen?

Nee, Palladin, sorry.

Wie sehen denn deine Business Objekte typischerweise aus? Mir ist das Setup nicht ganz klar. "Business Layer" kann ja alles mögliche bedeuten.

Was soll eine Db Sicht sein? Für eine DB ist eher wichtig, dass der Primary Key nicht null sein darf, dass es nicht mehr als X Columns gibt usw. Alles andere sind Business Regeln, die (aus gutem Grund) auch in der Datenbank durchgesetzt werden.

Für mich persönlich funktioniert es übrigens besser, wenn ich richtige Business Objekte in das Repository packe. Da ist der Aufwand aber wirklich deutlich höher, weil diese nicht immer 1:1 auf die DB gemappt werden können.

Lies das mit den Tuples nochmal nach 😉 ...

Klar, wenn du Typen hast die du in deinem ganzen Modul oder sogar Anwendung verwenden willst, ist das eine super Sache. Beispielsweise Vectoren in einem Game (man könnte ja auch float[3] verwenden 😉

Aber um 200 Zeilen Code zu verbessern, sind 400 Zeilen für Datentypen (inkl. Equals, HashCode, operatoren, ToString usw. ) vielleicht ein bisschen unverhältnismäßig.

Keep it simple stupid

Dann mach doch einfach Factory Methods

class Blubber
{
     private Blubber(string foo, ..., sting flip, ... ) { }

     public static Blubber CreateFooBar(string foo, string bar)
     {
         return new Blubber(foo, bar, null, null);
     }
}

Ist ein altes Thema ich weiß, aber woran leitest du das ab, @Abt?

Es gibt so viele Dinge die mich im Moment an Angular2 nerven. Deshalb würde ich gerne wissen, ob es sich lohnt, sich mal Aurelia genauer anzuschauen.

Hätte ich vll. besser lesen sollen.

So wie ich das sehe, brauchst du globale Konfliktfreie Sortierregeln (Also nicht sowas wie "a" vor "b" und "b" vor "a"). Falls sowohl die Listen selbst, als auch die Einträge innerhalb der Listen vorsortiert sind, kannst du das vorgeschlagene OrderDictionary<char, char> verwenden.

Implementiere doch einfach nen IComparer<char> und dann kannst du sowas machen:

var uniqueValues = new HashSet<char>();

foreach (var list in lists) {
    foreach (var value in list) {
         uniqueValues.Add(list);
    }
}

var orderedUnique = uniqueValues.OrderBy(x => x, new MyComparer()).ToList();

Hier dazu ein paar Referenzen:

1. https://msdn.microsoft.com/en-us/library/bb549422(v=vs.100).aspx (OrderBy)
2. http://www.mycsharp.de/wbb2/addreply.php?threadid=117402 (IComparer Interface)

Eine andere Möglichkeit ist ein Topologische Sortierung: http://stackoverflow.com/questions/21189222/topological-sort-with-support-for-cyclic-dependencies

Das kann man z.B. verwenden, wenn man in requirejs und co Abhängigkeiten zwischen Javascript Module definiert. Dann ist die Frage, in welcher Reihenfolge man diese im Browser und Node.JS laden muss. In jeder Liste ist dann einfach jedes Element von seinen Nachfolgern abhängig. Wenn du alle Elemente in eine solche Struktur bringt, kannst du es durch eine Topologische Sortierung jagen:

z.B. so

class ItemWithDependencies {
  public char Item {get;set;}
  public HashSet<char> Dependencies {get;set;}
}

Dictionary<char, ItemWithDependencies> items = ...;

foreach (var list of lists)
{
     for (int i = 0; i < list.Count; i++)
     {
         var item = list[i];
         ItemWithDependencies itemWithDependencies = null;

         if (!items.TryGetValue(item out itemWithDependencies)) {
              itemWithDependencies  = new ItemWithDependencies { Item = item };

              items.Add(item, itemWithDependencies);
         }
          
          for (int j = i + 1; j < list.Count; j++) {
              itemWithDependencies.Dependencies.Add(list[j]);
          }
     }
}

SortByTopology(items);

Ich meinte eher, dass die Reihenfolge nicht erhalten bleibt. Zumindest wenn es über ein internes Array realisiert wird. OrderedDictionary sollte die Reihenfolge erhalten, SortedDictionary sortiert nach dem Key (bzw. dem Comparer).

HashSet ist nicht sortiert.

Aus der Doku

A HashSet<T> collection is not sorted and cannot contain duplicate elements. If order or element duplication is more important than performance for your application, consider using the List<T> class together with the Sort method.

Ordered dictionary dürfte funktionieren.

https://msdn.microsoft.com/en-us/library/system.collections.specialized.ordereddictionary(v=vs.110).aspx

Ich benutze nur Klassen und kaum Interfaces 😉

Das Problem ist, dass Interfaces nur ein Typescript Konzept sind um Typsicherheit zu verbessern. Im erzeugten Javascript existieren die aber nicht mehr. Wenn du also Typemoq nur ein Interface übergeben würdest, hätte es keine Informationen mehr über die zu mockenden Funktionen.

Deshalb kann man in Angular2 auch Interfaces nicht direkt im Service Container über provide registrieren und darüber Abhängigkeiten auflösen.

Allerdings braucht man Interfaces auch weniger. Du kannst nämlich eine Klasse als Mockup verwenden. TypeMoq tauscht dann einfach die Methoden aus. Das geht sehr leicht, es sei denn du hast einen komplexen Constructor mit Dependencies. Dann müsstest du TypeMoq alle Parameter übergeben. Was du dann zum Beispiel machen kannst ist:

class Foo { }

class Bar implements Foo {}

Damit kannst du dir eine neue Klasse erstellen, die nichts macht, die du aber dann Typemoq übergeben kannst. wenn du es brauchst.

Wenn es nur dazu da ist um Feedback zu sammeln funktioniert vll. irgendein Download Tool wie : http://www.httrack.com/

Gibt bestimmt noch schickere / bessere 😉

Batch habe ich leider noch nicht anschauen können. Bei Azure ändert sich so schnell so viel, dass man leider kaum hinterherkommt als kleinere Firma.

Was man bei Azure und der Kalkulation natürlich auch nicht vergessen darf sind so Themen wie Loadbalancing, DDOS Protection, Replication usw. für die man teilweise nochmal einiges zusätzlich zahlen muss bei einem Hoster.

Ich kann bisher nur aus unserem Use Case berichten, dass Azure trotz gutem Willen leider nicht funktioniert hat (bisher!?). Microsoft hat uns auch m Rahmen des Bizspark Plus Programms nach München eingeladen und wir haben selbst mit 2 Azure Experten von MS keine Konfiguration gefunden, die Sinn gemacht hätte 😉

Vielleicht hat jemand (außer Abt) auch gegenteilige Erfahrung gemacht, es wäre nett an einem konkreten Fall das zu diskutieren.

Was heißt "stumpf". Der Punkt ist, dass man bei so kleinen Deployments einfach kein Einsparpotential hat in Azure. Ich kann nix groß runterfahren und habe eh kaum Administrationsaufwand, den ich einsparen kann (man kämpft in der Cloud wieder mit ganz anderen Dingen, die Zeit erfordern). Mittlerweile gibts ja auch Mongo DB als Service bei Azure. Auch wieder extrem teuer, wenn man eine taugliche Konfiguration möchte.

Weiteres Beispiel: Wir machen Batch Verarbeitung von ein paar Daten (aus Azure Tables) und brauchen dabei leider ca. 50 GB RAM. Das ist leider nicht streambar, weil wir die Daten in ein neues Format überführen. Der Prozess dauert ca. 12h. Wieder extrem teuer in Azure. Auch weil ich ohne Mehraufwand die Deployments nicht über das Azure Portal auf 0 runterfahren kann (geht mit Powershell, ich weiß).

Weiteres Beispiel: Als wir angefangen haben gabs nur SQL Server in furchtbaren Konfigurationen und Azure Tables. Azure Tables sind einfach super langsam und man braucht wahrscheinlich extremst viele Daten, bis es sich lohnt Azure Tables einzusetzen, weil die afaik gut skalieren.

Wenn ich als Startup extrem schnell wachse und ein paar Mio. von Investoren gesammelt habe, ist die Cloud natürlich wieder super, weil ich nicht 1-4 Wochen auf neue Server warten muss. Das sind aber nur wenige Startups (auch wenns über Portale wie techcrunch vll. anderst wirkt). Ich finde die Startup-Story ist aber nicht die Beste, wenn man die Cloud verkaufen möchte.

Ich möchte aber nicht die Cloud allgemein schlecht reden. Ich finde das Konzept sehr gut und vielversprechend.

Das ist ech Mies. Project.json war viel besser. Endlich mal ein Projekt System, dass man verstanden hat und ohne viel Tooling verwenden konnte.

Die hatten wohl nicht die Eier, einen Cut zu machen. Schade.

Hallo,

ich würde gerne nochmal auf die Kosten eingehen, vll. ist das interessant. Ich habe nämlich selber vor 3 Jahren ein Startup (www.busliniensuche.de) gestartet und wir haben ein hin und her mit Azure erlebt. Das hat vor allem damit zu tun, dass wir diverse Unterstützung von Microsoft bekommen haben, wie zum Beispiel Bizspark+ und immer wieder mit Azure experimentiert haben.

Leider kann ich für unser kleines Startup nicht direkt bestätigen, dass die Kosten geringer sind. Das hängt aber bestimmt auch mit den Anforderungen zusammen und im Laufe der Zeit hat sich auch in Azure viel getan. Redis, DocumentDB und MongoDB waren zu der Zeit einfach nicht vorhanden.

Um beispielsweise MongoDB ausfallsicher einzurichten, brauche ich 3-4 Server. Das ist leider die Minimalvorraussetzung und ich wollte da auch nicht unbedingt das Risiko eingehen, nachts auf einem Server zu laufen nur um morgens Sync-Probleme zu bekommen. Für 450 € bekomme ich bei einem Hoster 3 Server mit 32GB RAM und SDD Raid. Der gleiche Preis bei Azure: ca. 1000 €. Administrationsaufwand: Ungefähr gleich.

Es gibt natürlich auch Konfigurationen, bei denen ich mit Azure günstiger bin und ich bin sehr davon überzeugt, dass es spätestens ab dem zweiten Administrator, den ich in Szenarien mit vielen Servern anstellen muss, deutlich günstiger wird. Wenn man aber nicht gerade ein extrem skalierendes Startup ist, gehe ich nicht davon aus, dass man mit Azure einen großen Preisvorteil hat. Nicht jeder ist Pinterest 😉

Außerdem muss man natürlich berückstigen, dass Azure gerade wenn man nicht direkt in die breite skalieren will, sehr teuer ist. Stackexchange hat ja bspw. eine Architektur, die sehr viel RAM benötigt.

Nichtsdestotrotz: Ich bin ein großer Fan der Cloud und wir haben dank Dependency Injection auch immer noch eine lauffähige Cloud Konfiguration für unsere Services, aber die Bilder, die teilweise vermittelt werden, werden noch nicht realisiert, wie ich finde.

Baue es doch einfach in Expression Blend mit irgendeiner XAML Technologie (WPF, Win10 Apps ...)

Dann kannst du mit Storyboards und Animationen deine Lightshows erstellen.

Ich glaube bei Steam wirst du so nicht weiterkommen. XAML und Winforms lässt sich nur sehr schwer in DirectX / OpenGL Awendungen integrieren und die praktisch jede Game Engine hat ihr eigenes System um Steuerelemente darzustellen. Ich nehme an, dass Steam deshalb auch eine Eigenentwicklung verwendet, die sowohl im Spiel selbst, als auch auf im Desktop Modus verwendet wird. Also nix mit Handles.

Ich würde mal vorraussetzen, dass wir ein einfaches Response-Request Modell haben. Entweder über ene API oder direkt per Methoden Aufrufe. Mit Events und evtl. CQRS könnte das wieder anderst aussehen. Außerdem sehe ich nicht, warum das ViewModel nicht das Model kennen soll, das ist halt eine weitere Kapselung, die man sich gut überlegen sollte.

Es gibt dann einfach mehrere Fälle wie deine API aussehen kann, z.B.

var teamMember = userFactory.Create("Max");
teamMember.Save();

var teamLeader = userRepository.Find(id);
teamLeader.AddMember(teamMember);
teamLeader.Save();

Und das kann dann noch gekapselt werden, durch ein Application Layer, Services, API...spielt keine große Rolle.

Dein Szenario würde ich so implementieren.

1. CreateUserViewModel befüllen und Validieren
2. Mit dem CreateUserViewModel Anfrage erstellen
3. User(Model) zurück erhalten (je nach Kapselung) und daraus UserViewModel erzeugen
4. UserViewModel zur Liste hinzufügen.

Dazwischen hängen vll. noch irgendwelche DTO's, aber das ist ja egal

Ich stimme dir in allen Punkten zu, fluxy, aber ich sehe nicht, wo du einen neuen Punkt in die Diskussion einbringst. Ich habe das ja oben auch so formuliert ... 😉

Schau dir mal ng-repeat-start in der Doku an: https://docs.angularjs.org/api/ng/directive/ngRepeat

Und poste dann deine Lösung hier, bitte 😉

Ich finde auch, dass das von REST nicht so richtig beantwortet wird.

Du hast ja mehrere Möglichkeiten:

1. Eigenes Verb, wäre eigentlich die sauberste Lösung, man bekommt aber mit den Clients und tlw. auch den Web Servern bisschen Stress.

2. PUT oder BATCH mit Urls wie du es vorgeschlagen hast: Nutze ich auch, finde ich aber ein bisschen hässlich, weil die URLs ja eher resourcen beschreiben...also user/1/licenses/123

3. Komplexere Bodies. Man könnte ja beschreiben, was du bearbeiten willst. Wird leider von WebAPI nicht direkt unterstützt und wäre auch bisschen komplexer was die Deserialisierung betrifft.

Ich würde einfach Attribute Routing verwenden, wenn du auch die Reihenfolge achtest, hast du eigentlich kein Problem mit Mehrdeutigkeiten. Außerdem kann man parameter ja noch weiter eingrenzen:

users/{id:number}/

Gibt mehrere Artikel dazu, wie man sowas (mit Editierfunktion) baut:

http://www.codeproject.com/Articles/24681/WPF-Diagram-Designer-Part
http://www.codeproject.com/Articles/484616/MVVM-Diagram-Designer

Falls du ein Budget hast, kauf dir einfach die Telerik Controls http://www.telerik.com/products/wpf/overview.aspx

Da ist sowas dabei: http://www.telerik.com/products/wpf/diagrams.aspx

Das klingt erstmal teuer, aber das amortisiert sich schnell.

Da hat deine Kollege meiner Meinung nach Recht. Es kommt aber auch viel auf die Formulierung an:

Beispiel 1:

"Einführung eines Modules X im Rahmen von ... " hat überhaupt keinen wissenschaftlichen Mehrwert, was kann ich davon als Leser erwarten, hat es das Potential mich in meinem Thema weiterzubringen?

Beispiel 2:

"Untersuchung von typischen Problemen bei Einführung von XYZ" ... hier habe ich einen Mehrwert, du hast wahrscheinlich mehr als einen Fall, teilweise sind die Probleme praktisch nochmal nachvollzogen oder gelöst und es hat eine gewisse Allgemeingültigkeit.

Der Kern einer wissenschaftlichen Arbeit ist meiner Meinung nach, dass es verwertbares Wissen generiert und das machst du halt nicht mit einer Implementierung.

Also oben in dem Beispiel stimmt was nicht mit dem async und await.

was für mich funktioniert hat:

public sealed class NodeIconBitmapConverter : IValueConverter
    {
        public object Convert(object value, Type targetType, object parameter, string language)
        {
            INodeIcon icon = (INodeIcon)value;

            BitmapImage bitmapImage = new BitmapImage();

            icon.OpenAsStreamAsync().ContinueWith(stream =>
            {
                if (stream.Result != null)
                {
                    CoreApplication.MainView.CoreWindow.Dispatcher.RunAsync(
                        CoreDispatcherPriority.Normal,
                        () =>
                        {
                            bitmapImage.SetSourceAsync(stream.Result.AsRandomAccessStream()).Forget();
                        }).Forget();
                }
            });

            return bitmapImage;
        }

        public object ConvertBack(object value, Type targetType, object parameter, string language)
        {
            throw new NotSupportedException();
        }
    }

Da du den Stream ja freigibst sollte das doch eigentlich passen. Falls du dir unsicher bist, kannst du die Datei ja in einen MemoryStream schreiben und das mal testen.

Deshalb das Grid außen rum 😉

Ich würde auf jeden Fall nicht mit dem Canvas arbeiten, sondern mit dem Grid und dem StackPanel für deine Regalböden. 😉

Dein Template könnte z.B. so aussehen.

<Grid>
	<ItemsControl x:Name="PART_Floors">
		<ItemsControl.ItemTemplate>
			<Grid>
				<Rectangle Fill="Brown" Height="{TemplateBinding FloorThickness}" />
				
				<!-- Margin kann hier nicht direkt ohne Converter gebindet werden, deshalb der Trick ;). -->
				<Rectangle Height="{TemplateBinding FloorHeight}" />
			</Grid>
		</ItemsControl>
	</ItemsControl>
</Grid>

public class Regal
{
    protected override OnApplyTemplate() 
	{
	    this.floors = GetTemplateChild("PART_Floors") as ItemsControl;
		
		UpdateFloors();
	}
	
	private void OnFloorCountChanged()
	{
		UpdateFloors();
	}
	
	private void UpdateFloors()
	{
	    if (floors != null)
		{
		    // Dummy Array
			floors.ItemsSource = new int[FloorCount];
		}
	}
}

Die Frage ist ja wie dein Control von außen konzipiert sein soll, was z.B. die API betrifft. Wenn du nur die Anzahl übergeben willst, kannst du intern natürlich mit dem ItemsControl arbeitet.

Du kannst die Liste der Regelbretter natürlich auch einfach über das ViewModel managen und in deiner View mit dem ItemsControl arbeiten.

Ich würde ein CustomControl erstellen und da wirst du dann einfach auf Änderungen in den Dependency Properties reagieren müssen.

Dann kannst du die Regelböden einfach per Code erzeugen. Anklicken kann man ja jedes Control und mit Trigger solltest man auch das Styling gut hinbekommen könnem.

Es ist leider extrem schwierig, Open Source Entwickler zu finden 😦