Lufthansa stattet Piloten mit Surface Pro 3 aus 21.11.2014

Werner Franz
Werner Franz, Vorstand

Nun ist es offiziell:

Die Lufthansa Piloten werden das neue Electronic Flight Bag EFB auf Surface Pro 3 nutzen.

Ein toller Erfolg für Microsoft – und für SDX: Unsere eXperts haben als .NET Spezialisten an der Entwicklung des EFB mitgewirkt.

Weitere Informationen finden Sie in der Microsoft Presseerklärung und im Microsoft Surface Blog.

Lufthansa-Cockpit

Share |

Top 10 Fehler: Wrap-Up–Jetzt aber!

Alexander Jung
Alexander Jung, Chief eXpert

Dies ist Teil 15 der letzte Teil der kleinen Serie, die ich als Kommentar zum Blog-Beitrag Top 10 Mistakes that C# Programmers Make begonnen habe.

Und jetzt reicht’s dann auch Zwinkerndes Smiley.

 

Die ursprünglichen Common Mistakes von Patrick will ich hier nicht wiederholen, hier sind meine Ergänzungen:

  1. Neglecting FxCop/Static Code Analysis
  2. Naiver Einsatz von Reflection
  3. Missbrauch von String-Operationen

Es ist nicht so, dass man die Liste nicht fortsetzen könnte, im Gegenteil. Aber an irgendeiner Stelle muss man schließlich aufhören, und hier hat es sich angeboten.

Dinge die ansonsten bei meinen Reviews immer wieder hochkommen drehen sich dann aber auch immer weniger um die Sprache und Nutzung der BCL. Vielmehr geht es dann zunehmend um Codequalität, Wartbarkeit und Robustheit, um Einsatz von Patterns, konzeptionelle Dinge wie Fehlerhandling und Testbarkeit, Grundlagen wie Objektorientierung und Abstraktion, Architekturfragen, und so weiter.

Das würde den Rahmen hier etwas sprengen Zwinkerndes Smiley. Daher…

[ENDE!]

Share |

FAZ Spezial: Die beliebtesten Arbeitgeber im Rhein-Main Gebiet 18.11.2014

Svenja Henß
Svenja Henß, Senior Assistant

Endlich draußen:

Die aktuelle Spezialausgabe der FAZ, der Frankfurter Neuen Presse, der Frankfurter Rundschau sowie den jeweiligen lokalen Zeitungen zum Thema “Beliebteste Arbeitgeber im Rhein Main Gebiet” ist am 12. November 2014 erschienen.

Wir freuen uns mit dabei zu sein und hoffen, den ein oder anderen neuen Flurfunk Leser oder sogar neuen Mitarbeiter begrüßen zu können.

sdx_FAZ-Beilage

Share |

LINQ Coding Guidelines #2–Kein Mischen der Syntax 14.11.2014

Alexander Jung
Alexander Jung, Chief eXpert

Nach der Strafandrohung vom letzten Mal haben die folgenden Guidelines eher den Charakter von – mehr oder weniger strengen – Empfehlungen.

Empfehlung:
Das Mischen von Query-Syntax und Method-Syntax sollte vermieden werden.

 

Um’s nochmal deutlich zu machen: Wir reden von Query-Syntax…

   1: int[] numbers = { 5, 10, 8, 3, 6, 12};
   2: var numQuery1 = from num in numbers
   3:     where num % 2 == 0
   4:     orderby num
   5:     select num;

versus Method-Syntax…

   1: int[] numbers = { 5, 10, 8, 3, 6, 12};
   2: var numQuery2 = numbers
   3:     .Where(num => num % 2 == 0)
   4:     .OrderBy(n => n);

In diesem einfachen Beispiel macht das keinen großen Unterschied. Tatsächlich neigen viele Entwickler zur Query-Syntax, weil sie näher an SQL liegt und nicht zuletzt, weil Microsoft sie in seinen Beispielen bevorzugt.

Dummerweise ist die Query-Syntax aber auf einen festen Satz an Schlüsselwörtern beschränkt; selbst Aggregatfunktionen – obwohl Teil von SQL – sind darin schon nicht mehr enthalten. Und auch bei vorhandenen Schlüsselwörtern erlauben diese nicht alle Optionen, die mit der Method-Syntax möglich sind, etwa ein OrderBy mit Comparer. Von zusätzliche Funktionalitäten aus eigenem Code oder Bibliotheken ganz zu schweigen.

In diesen Fällen muss man auf die Method-Syntax ausweichen. Leider legt Microsoft hier mit Vermischung der beiden Varianten vor (1, 2):

   1: string[] digits = { "zero", "one", "two", "three", "four", "five", "six", "seven", "eight", "nine" }; 
   2: var reversedIDigits = ( 
   3:     from d in digits 
   4:     where d[1] == 'i' 
   5:     select d) 
   6:     .Reverse(); 
   1: List<Customer> customers = GetCustomerList(); 
   2: var first3WAOrders = ( 
   3:     from c in customers 
   4:     from o in c.Orders 
   5:     where c.Region == "WA" 
   6:     select new { c.CustomerID, o.OrderID, o.OrderDate }) 
   7:     .Take(3); 

Und so weiter.

Der Raytracer als pathologisches Beispiel mischt das ebenfalls, was nur bei genauem Hinsehen erkennbar ist.

Hier ist ein Beispiel aus produktivem Code:

   1: static string GetOSVersion()
   2: {
   3:     var name = (from x in new ManagementObjectSearcher("SELECT * FROM Win32_OperatingSystem").Get().OfType<ManagementObject>() select x.GetPropertyValue("Caption")).First();
   4:     return name != null ? name.ToString() : "Unknown";
   5: }

Den LINQ-Ausdruck in einer Zeile zu packen macht’s nicht eben besser lesbar, aber Umbrüche helfen auch nicht wirklich:

   1: static string GetOSVersion()
   2: {
   3:     var name = (from x
   4:                     in new ManagementObjectSearcher("SELECT * FROM Win32_OperatingSystem")
   5:                     .Get()
   6:                     .OfType<ManagementObject>()
   7:                 select x.GetPropertyValue("Caption"))
   8:                     .First();
   9:     return name != null ? name.ToString() : "Unknown";
  10: }

 

Problem dabei: Durch die Mischung fällt es beim Lesen schwerer, die Logik zu erfassen. Gleiche Dinge werden unterschiedlich dargestellt, konzeptionelle Unterschiede und Gemeinsamkeiten werden verwischt.

Wenn man den ganzen Ausdruck hingegen konsequent in Method-Syntax hinschreibt, wird die Logik auf einmal sehr offensichtlich und einfach nachvollziehbar. Das letzte Beispiel in Method-Syntax:

   1: static string GetOSVersion2()
   2: {
   3:     var name = new ManagementObjectSearcher("SELECT * FROM Win32_OperatingSystem")
   4:         .Get()
   5:         .OfType<ManagementObject>()
   6:         .Select(x => x.GetPropertyValue("Caption"))
   7:         .First();
   8:     return name != null ? name.ToString() : "Unknown";
   9: }

Wie ich finde ein ausreichender Grund, um – zumindest in den beschriebenen Fällen – auf eine Mischung – und damit letztlich auf die Query-Syntax – zu verzichten. Womit die Empfehlung begründet ist.

 

Um aber einen Schritt weiter zu gehen…

Einfache Ausdrücke kann man nach wie vor mit der Query-Syntax schreiben – ohne die Empfehlung zu verletzen. Allerdings habe ich die Erfahrung gemacht, dass einfache Ausdrücke nicht immer so einfach bleiben. Sie später umzuschreiben ist mindestens nervig.

Ich persönlich – und ich bin da nicht der Einzige – habe mir daher die Query-Syntax mittlerweile völlig abgewöhnt und nutze grundsätzlich die Method-Syntax.

Das mag Geschmackssache sein; wer das in seine Coding Guidelines aufnehmen will, kann zumindest Konsistenz über verschiedene Ausdrücke hinweg als Argument anführen.

Share |

Frankfurter SDX TC: SQL Server 2012/2014 – Mehr als nur Migration 11.11.2014

Simone Franz
Simone Franz, Marketing Manager

Herzlich lade ich Sie zum SDX Technical Council “SQL Server 2012/2014 – Mehr als nur Migration” im Frankfurter Westhafen ein:

Termin: Donnerstag, der 20. November 2014 ab 17:00 Uhr in Frankfurt Zielgruppe: BI/SQL-Entwickler, Architekten, Projektleiter
Dresscode: Business Casual

Agenda:

17:00 Uhr: Begrüßungskaffee
17:30-19:30 Uhr:

Daten schneller, besser, flexibler mit SQL Server 2012/2014
- Hochverfügbare, performante und sichere Datenbanken
- Columnstore Index
- SQL Server InMemory
- Resource Governor
- Buffer Pool Extensions
- SQL Erweiterungen
- SQL Server Migration

19:30 Uhr: Fingerfood

clip_image002_thumb1

Das Ende des (extended) Supports des SQL Servers 2005, neue/konsolidierte Hardware oder Innovation – das sind potentielle Treiber für eine Migration der SQL Server Infrastruktur.Dabei entstehen nicht nur Kosten und Risiken, sondern eine Migration liefert ebenfalls Mehrwert, z.B. die Konsolidierung von Umgebungen, weniger Hardware- und Supportaufwand, performantere Umgebung sowie die Nutzung neuer Features.

In unserem Technical Council – mit Fokus auf Datenbank-Infrastruktur und
-Entwicklung – zeigen wir Ihnen die Vorteile auf, die eine nicht nur technische Migration von SQL Server 2005/2008 auf 2012/2014 mit sich bringt. In mehreren Live-Demos gehen wir dabei auf typische Anwendungsszenarien ein.

Zum Abschluss geben wir Ihnen eine kurze Empfehlung bzgl. eines Vorgehens bei einer anstehenden Migration und informieren Sie, mit welchen Quick Wins Sie am schnellsten innerhalb Ihres Unternehmens und gegen­über dem Management punkten können.

Beim abschließenden Abendessen können Sie sich dann in lockerer Atmosphäre mit den Teilnehmern und den SDX eXperts zu Features und Einsatzszenarien austauschen.

Das SDX-Team freut sich auf Ihren Besuch.

Auf Wiedersehen im SDX Büro am 20. November 2014 im Westhafenhaus, Speicherstraße 1 in Frankfurt.

Die komplette Einladung bzw. die Teilnahmebedingungen für Frankfurt erhalten Sie hier.

Share |

Codehunt – Stellt eure Coding Skills auf die Probe 03.11.2014

Max Jäger
Max Jäger, Senior eXpert
Neulich ist mir eine nette Seite im Rahmen des Imagine Cups über den Weg gelaufen: Codehunt
Es geht darum, einen vorgegebenen Codeabschnitt zu vervollständigen, um einen bestimmten Output zu erzeugen. Wer schafft das am schnellsten und mit dem kürzesten Code?

Der Output wird als Tabelle mit Ein- und Ausgabedaten angegeben. Was einfach klingt, kann auch ganz schön kompliziert werden.

Auf der Seite können Übungsaufgaben gelöst werden. Hier ein Beispiel, wie solch eine Aufgabe aussehen kann. Auf der linken Seite ist der anzupassende Code, auf der rechte die Tabelle mit den Ein- und Ausgangsdaten.

Codehunt

Im Rahmen des Imagine Cups gibt es immer wieder Wettbewerbe für einen begrenzten Zeitraum, bei denen man sich mit anderen messen und Preise gewinnen kann.

Viel Spass beim coden :-)

Share |

Office Day Oktober 27.10.2014

Svenja Henß
Svenja Henß, Senior Assistant

Wie immer startete letzte Woche Freitag der monatliche Office Day mit Werners Business Update.

Danach ging es mit folgenden Break-Out Sessions weiter:

- Angular JS
- Schlanke Softwarearchitekturen mit Web API
- SSIS Unittesting
- Testing mit CodesUI

IMG_7809IMG_7813IMG_7814IMG_7816IMG_7817IMG_7819IMG_7825IMG_7823

Share |

SDX TC: SQL Server 2012/2014 – Mehr als nur Migration 23.10.2014

Simone Franz
Simone Franz, Marketing Manager

Herzlich lade ich Sie zum SDX Technical Council “SQL Server 2012/2014 – Mehr als nur Migration” ein:

Termin: Donnerstag, der 13. November 2014 ab 17:00 Uhr in München
Zielgruppe: BI/SQL-Entwickler, Architekten, Projektleiter
Dresscode: Business Casual

Agenda:

17:00 Uhr: Begrüßungskaffee
17:30-19:30 Uhr:

Daten schneller, besser, flexibler mit SQL Server 2012/2014
- Hochverfügbare, performante und sichere Datenbanken
- Columnstore Index
- SQL Server InMemory
- Resource Governor
- Buffer Pool Extensions
- SQL Erweiterungen
- SQL Server Migration

19:30 Uhr: Fingerfood

clip_image002

Das Ende des (extended) Supports des SQL Servers 2005, neue/konsolidierte Hardware oder Innovation – das sind potentielle Treiber für eine Migration der SQL Server Infrastruktur.Dabei entstehen nicht nur Kosten und Risiken, sondern eine Migration liefert ebenfalls Mehrwert, z.B. die Konsolidierung von Umgebungen, weniger Hardware- und Supportaufwand, performantere Umgebung sowie die Nutzung neuer Features.

In unserem Technical Council – mit Fokus auf Datenbank-Infrastruktur und
-Entwicklung – zeigen wir Ihnen die Vorteile auf, die eine nicht nur technische Migration von SQL Server 2005/2008 auf 2012/2014 mit sich bringt. In mehreren Live-Demos gehen wir dabei auf typische Anwendungsszenarien ein.

Zum Abschluss geben wir Ihnen eine kurze Empfehlung bzgl. eines Vorgehens bei einer anstehenden Migration und informieren Sie, mit welchen Quick Wins Sie am schnellsten innerhalb Ihres Unternehmens und gegen­über dem Management punkten können.

Beim abschließenden Abendessen können Sie sich dann in lockerer Atmosphäre mit den Teilnehmern und den SDX eXperts zu Features und Einsatzszenarien austauschen.

Das SDX-Team freut sich auf Ihren Besuch.
Auf Wiedersehen im SDX Büro am 13. November 2014 in der Landwehrstraße 61 in München.

Die komplette Einladung bzw. die Teilnahmebedingungen für München erhalten Sie hier.

Share |

LINQ Coding Guidelines #1–Null-Werte für Enumerationen

Alexander Jung
Alexander Jung, Chief eXpert

Das Problem ist beschrieben, die theoretischen Grundlagen sind aus den Füßen, kommen wir also zur ersten Empfehlung bzgl. des Schreibens von LINQ-Ausdrücken…

Empfehlung Artikel 1 des Grundgesetzes zur LINQ-Programmierung:
”null” ist kein zulässiger Wert für Enumerationen! Zuwiderhandlungen werden mit Exceptions in Produktion bestraft.

 

Die null hat im Universum funktionaler Programmierung schlicht und einfach keinen Platz.

“Code written in the functional style is often safer and easier to reason about. For example, functional languages avoid using the null value.” (“F# and Functional Programming”)

“The null value is not normally used in F# for values or variables.” (Null Values (F#))

“I think the succinct summary of why null is undesirable is that meaningless states should not be representable.” (“Best explanation for languages without null”)

Unter anderem ist diese Garantie die Grundlage dafür, dass eine Verkettung von Aufrufen, wie sie zu LINQ gehören, überhaupt erst valide ist:

   1: IEnumerable<int> numQuery2 = numbers.Where(num => num % 2 == 0).OrderBy(n => n);

Ohne diese Garantie müsste der defensive Entwickler jeden Aufruf in dieser Kette einzeln machen und auf null prüfen:

   1: IEnumerable<int> numQuery2 = numbers.Where(num => num % 2 == 0);
   2: if (numQuery2 != null)
   3:     numQuery2 = numQuery2 .OrderBy(n => n);

Das würde dem Ganzen etwas die Eleganz nehmen…

 

Meistens bekommt man Enumerationen und verarbeitet diese weiter. In diesem Fall profitiert man einfach nur und muss das schon mutwillig kaputt machen. Manchmal muss man jedoch die Enumeration initial produzieren, z.B.:

   1: public IEnumerable<Orderbook> GetAll()
   2: {
   3:     IEnumerable<Orderbook> result = null;
   4:     if (User.IsAdmin(user))
   5:         result = _context.OrderbookSet;
   6:     // [...]
   7:     return result;
   8: }

Genau hier fällt das Kind in den Brunnen wenn die Berechtigungen nicht passen. Ein einfacher Aufruf wie…

   1: var candidates= Orderbook.GetAll().Where(ob => ob.Location == "Frankfurt");

… ist damit nicht mehr machbar.

 

Korrekt wäre hingegen:

   1: public IEnumerable<Orderbook> GetAll()
   2: {
   3:     IEnumerable<Orderbook> result = Enumerable.Empty<Orderbook>();
   4:     if (User.IsAdmin(user))
   5:         result = _context.OrderbookSet;
   6:     // [...]
   7:     return result;
   8: }

Wenn der Aufrufer keine Berechtigung hat die Daten zu sehen, bekommt er immer noch eine Enumeration, nur enthält diese eben keine Elemente.

Etwas umständlicher wird das, wenn man mit dem Entity Framework gegen IQueryable arbeitet, denn Queryable bietet keine Pendant zu Empty() an. Wohl aber eine Methode AsQueryable(), die ich verwenden kann, um ein IEnumerable zu “casten”:

   1: public IQueryable<Orderbook> GetAll(string userName)
   2: {
   3:     IQueryable<Orderbook> result = Enumerable.Empty<Orderbook>().AsQueryable();
   4:     if (User.IsAdmin(user))
   5:         result = _context.OrderbookSet;
   6:     // [...]
   7: }

Es ist also nicht notwendig, extra eine Collection anzulegen, wie ich das auch schon gesehen habe:

   1: IQueryable<Orderbook> result = new List<Orderbook>().AsQueryable();

 

Da der C#-Compiler nicht wissen kann, dass eine Methode funktionalen Erfordernissen Rechnung tragen muss, kann er den Entwickler hier leider nicht unterstützen.
Daher liegt diese Anforderung nur in Form einer Konvention vor, die der Entwickler selbst einzuhalten hat – unter Androhung von Strafe. ;-)

Share |

.NET ist dein kleines Einmaleins? Jetzt eXpert werden! 20.10.2014

Svenja Henß
Svenja Henß, Senior Assistant

Dein Herz schlägt für gute Software auf Basis der Microsoft Application Plattform? Für dich gehören zu Business Apps mehr als nur schöne Frontends?

Dann solltest du dir unser Jobangebot näher anschauen:

DEV-Stellenanzeige

Wir suchen Verstärkung für unsere Teams in Frankfurt oder München. Offene Positionen vom Junior bis zum Chief Level.

Unsere Projekte sind regional begrenzt, das heißt du kannst den Feierabend mit Familie und Freunden verbringen und schläfst abends zu Hause im eigenen Bett und nicht im Hotel. Smiley

Ich freue mich auf eure Bewerbungen. Bitte direkt an Svenja.Henss@sdx-ag.de.

Share |