Vortrag «Azure machine learning» am 10.2.2015

Die .NET Usergroup Bern startet mit zwei Vorträgen ins Jahr: «Azure machine learning» von Roland Krummenacher und «SQL Server 2014 Cardinality Estimator» von Klaus Aschenbrenner. Der Event findet am 10.2.2015 ab 18 Uhr im WISS in Bern statt.

Wäre es nicht toll, wenn wir die Zukunft voraussagen könnten? Wenn eine Leiterin der Notaufnahme eines Spitals wüsste, wieviele Patienten in der Nacht eingeliefert werden? Wenn die Marketing-Abteilung im Voraus wüsste, ob eine Werbe-Kampagne beim Publikum ankommt? Wenn ein Garagist wüsste, wann ein Alternator ersetzt werden muss, bevor es eine Panne gibt? Wenn die Polizei Verbrechen verhindern könnte, bevor sie begangen werden? Tatsächlich wird an solchen Vorhersagen schon seit Jahrzehnten geforscht und das mit einigem Erfolg. Die Berechnung solcher Modelle war jedoch bisher nur Experten mit Zugang zu entsprechenden Ressourcen vorbehalten.

Mit Azure Machine Learning, dem Hipster unter den Azure Diensten, können auch wir Normalsterbliche schnell, einfach und relativ günstig solche Vorhersage-Modelle entwickeln und via REST-Schnittstelle in unsere Software einbinden oder Dritten anbieten. Diese Session gibt einen schnellen Einstieg ins Thema und zeigt welche Möglichkeiten Azure ML eröffnet. Geeignet für Datenanalysten, die sich mit Azure auseinandersetzten wollen oder Entwickler, die vor dem Thema nicht zurückschrecken. Es sind keine Vorkennnisse notwendig.

Der zweite Vortrag konzentriert sich auf die Änderungen im Cardinality Estimator SQL Server 2014.

Anmeldung und weitere Informationen: http://www.dnug-bern.ch/events.aspx

Posted in .NET, Azure | Tagged | Leave a comment

Checkliste User Stories

Kennen Sie die Situation von unklaren User Stories an einem Sprint Planning Meeting oder zu Beginn eines Sprints? Oft sind Anforderungen nicht messbar definiert, nicht funktionale Anforderungen fehlen komplett, Stories sind riesig oder haben keinen Business Value (z.B. nur GUI erstellen als Story).

Eine Möglichkeit um solche Probleme zu minimieren ist eine „Definition of Ready“, welche das Team für sich definiert. Neben der Wichtigkeit, dass jedes Teammitglied den Inhalt der Stories kennt und es ein gemeinsames Verständnis dafür gibt, können Checklisten zusätzlich helfen.

Eine mögliche Checkliste könnte wie folgt aussehen:

Story Text

cb Ist klar wer der Akteur ist?
cb Ist klar auf welchem Dialog welche Aktion ausgeführt wird? Oder wenn das System etwas macht was der Auslöser ist?
cb Ist klar was die neue Funktion macht, wenn sie ausgeführt wird?
cb Ist ein Nutzen gegeben wieso die Funktion benötigt wird?
cb Ist die Story vertikal? -> sie muss vertikal sein
cb Sind alle Wörter klar definiert? (Wörter wie korrekt, wie vorher, etc. dürfen nicht vorkommen)
cb Können die Fragen „Wer? Wo? Was?“ beantwortet werden?
cb Gibt es keine Unklarheiten die noch abgeklärt werden müssen?
cb Gibt es Vorbedinungen oder andere Stories die erfüllt sein müssen, damit die Story umsetzbar ist?
cb Gibt es Annahmen für die Schätzung? Wenn ja welche?

Mögliches Template

Als [User/Rolle] möchte ich dass, die [Funktion] ausgeführt wird, wenn ich die [Aktion] auslöse, so dass [Grund] erfüllt wird.

Akzeptanz Kriterien

cb Ist das Kriterium messbar?
cb Könnte aus dem Kriterum ein Messbarer Test (Integration /Systemtest oder manueller Test) gemacht werden (Es muss möglich sein einen TestCase zu definieren)?
cb Sind Kriterien vorhanden, die ein User überprüfen kann (z.B. ist ein Wert im UI eingetragen, ist der Wert in der Datenbank? Ect.)
cb Betrifft das Kriterium einzig und allein die neue Funktion?
cb Gibt es allenfalls messbare Performance Anforderungen wenn ja welche?
cb Gibt es Security Anforderungen wenn ja welche?
cb Sind alle nicht funktionalen Anforderungen enthalten?
cb Können die Fragen Was? und Wie? Beantwortet werden?
cb Sind mehr als 7 Akzeptanz Kriterien vorhanden? Wenn ja könnte das ein Indiz sein, dass die Story zu gross ist.

Benutzer Rollen

Benutzerrollen sollten für ein Projekt spezifisch definiert werden. Dabei kann eine Eigenschaft mit einem Namen verknüpft werden. Ein Beispiel für eine Web Applikation, mit den Rollen: Admin, Moderator, Writer und Reader. Im Backend gibt’s die Rolle Administrator.

Benutzer

Beschreibung

Portal Walter

Web Portal Benutzer mit Schreibrechten (Walter -> für Write)

Portal Rudi

Web Portal Benutzer ohne Schreibrechte (Rudi -> für Read)

Portal Mike

Web Portal Benutzer mit Moderator Rechten (Mike -> Moderator)

Portal Albert

Web Portal Benutzer mit Admin Rechten (Albert -> Admin)

Backend Albert

Backend Benutzer mit Admin Rechten (Albert -> Admin)

User Story Texte können demnach wie folgt beginnen:

Als Portal Rudi möchte ich, dass … , Als Backend Albert möchte ich, dass …

INVEST und SMART

Weiter können beim Thema Stories und Tasks schreiben die Prinzipien von INVEST und SMART weiter helfen. (Quelle: http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/)

INVEST

I – Independent

N – Negotiable

V – Valuable

E – Estimable

S – Small

T – Testable

Independent

Stories are easiest to work with if they are independent. That is, we’d like them to not overlap in concept, and we’d like to be able to schedule and implement them in any order. We can’t always achieve this; once in a while we may say things like “3 points for the first report, then 1 point for each of the others.”

Negotiable… and Negotiated

A good story is negotiable. It is not an explicit contract for features; rather, details will be co-created by the customer and programmer during development. A good story captures the essence, not the details. Over time, the card may acquire notes, test ideas, and so on, but we don’t need these to prioritize or schedule stories.

Valuable

A story needs to be valuable. We don’t care about value to just anybody; it needs to be valuable to the customer. Developers may have (legitimate) concerns, but these framed in a way that makes the customer perceive them as important. This is especially an issue when splitting stories. Think of a whole story as a multi-layer cake, e.g., a network layer, a persistence layer, a logic layer, and a presentation layer. When we split a story, we’re serving up only part of that cake. We want to give the customer the essence of the whole cake, and the best way is to slice vertically through the layers. Developers often have an inclination to work on only one layer at a time (and get it “right”); but a full database layer (for example) has little value to the customer if there’s no presentation layer.

Making each slice valuable to the customer supports XP’s pay-as-you-go attitude toward infrastructure.

Estimable

A good story can be estimated. We don’t need an exact estimate, but just enough to help the customer rank and schedule the story’s implementation. Being estimable is partly a function of being negotiated, as it’s hard to estimate a story we don’t understand. It is also a function of size: bigger stories are harder to estimate. Finally, it’s a function of the team: what’s easy to estimate will vary depending on the team’s experience. (Sometimes a team may have to split a story into a (time-boxed) “spike” that will give the team enough information to make a decent estimate, and the rest of the story that will actually implement the desired feature.)

Small

Good stories tend to be small. Stories typically represent at most a few person-weeks worth of work. (Some teams restrict them to a few person-days of work.) Above this size, and it seems to be too hard to know what’s in the story’s scope. Saying, “it would take me more than a month” often implicitly adds, “as I don’t understand what-all it would entail.” Smaller stories tend to get more accurate estimates.

Story descriptions can be small too (and putting them on an index card helps make that happen). Alistair Cockburn described the cards as tokens promising a future conversation. Remember, the details can be elaborated through conversations with the customer.

Testable

A good story is testable. Writing a story card carries an implicit promise: “I understand what I want well enough that I could write a test for it.” Several teams have reported that by requiring customer tests before implementing a story, the team is more productive. “Testability” has always been a characteristic of good requirements; actually writing the tests early helps us know whether this goal is met.

If a customer doesn’t know how to test something, this may indicate that the story isn’t clear enough, or that it doesn’t reflect something valuable to them, or that the customer just needs help in testing.

SMART Tasks

There is an acronym for creating effective goals: “SMART” –

S – Specific

M – Measurable

A – Achievable

R – Relevant

T – Time-boxed

(There are a lot of variations in what the letters stand for.) These are good characteristics for tasks as well.

Specific

A task needs to be specific enough that everyone can understand what’s involved in it. This helps keep other tasks from overlapping, and helps people understand whether the tasks add up to the full story.

Measurable

The key measure is, “can we mark it as done?” The team needs to agree on what that means, but it should include “does what it is intended to,” “tests are included,” and “the code has been refactored.”

Achievable

The task owner should expect to be able to achieve a task. XP teams have a rule that anybody can ask for help whenever they need it; this certainly includes ensuring that task owners are up to the job.

Relevant

Every task should be relevant, contributing to the story at hand. Stories are broken into tasks for the benefit of developers, but a customer should still be able to expect that every task can be explained and justified.

Time-Boxed

A task should be time-boxed: limited to a specific duration. This doesn’t need to be a formal estimate in hours or days, but there should be an expectation so people know when they should seek help. If a task is harder than expected, the team needs to know it must split the task, change players, or do something to help the task (and story) get done.

Posted in Agile, Requirement, Scrum | Tagged , , | Leave a comment

Von 0 auf 100 mit der Microsoft Azure Cloud Plattform

Haben Sie sich immer schon mal gefragt, was genau Microsoft Azure ist? Haben Sie eine Ahnung von all den Diensten, die auf Azure zur Verfügung stehen und wie Sie diese nutzen können? Wollen Sie das in einer einfachen und praktischen Weise lernen?

Dann ist dieser Event genau das richtige für Sie, der am 11. Dezember bei Microsoft Schweiz in Wallisellen stattfindet. Egal ob Entwickler, IT Pro, Student oder Startup: Azure-Experte Roland Krummenacher von der bbv Software Services, unterstützt von Reto Rechsteiner, zeigt Ihnen das Wichtigste aus der Praxis, um mit Azure produktiv loszulegen.

Details zum Event und Anmeldung: «Von 0 auf 100 mit der Microsoft Azure Cloud Plattform»

Posted in Announcement, Azure, Events | Leave a comment

TDD in Embedded Software? – Und es geht doch!

Artikel von Silvan Wegmann; im Tagungsband des Embedded Software Engineering Kongresses (vom 1. – 5.12.2014 in Sindelfingen) publiziert.

Test Driven Development (TDD) ist eine Entwicklungsmethode, die durch den Test-First-Ansatz von Anfang an eine hohe Testabdeckung des entstehenden Codes sicherstellen soll. Vor allem aber wird der Entwickler gezwungen, sich vor der Implementierung Gedanken zu machen, welches Verhalten sein Modul haben soll, und dieses Verhalten in Form von Tests festzuhalten und damit zu formalisieren. Die Methode wird bereits in vielen Desktop-, Web- und Serverapplikationen erfolgreich eingesetzt. Bei Embedded Software stösst man aber immer wieder auf spezielle Situationen, die eine Entwicklung mit TDD scheinbar unmöglich machen. In diesem Beitrag werden verschiedene Strategien aufgezeigt, um mit diesen Herausforderungen umzugehen. Continue reading

Posted in Artikel, Embedded, Test Driven Development | Tagged | Leave a comment

Logbuch in der Cloud

Artikel von Roland Krummenacher im Windows.Developer (10/2014): pdf «Logbuch in der Cloud» als pdf lesen.

In dieser fünfteiligen Artikelserie beschäftigen wir uns mit der folgenden Frage: Wie können wir Azure-Dienste sinnvoll und sicher in Nicht-Cloud-Applikationen einsetzen? Ich zeige anhand von Beispielen aus meinem Projektalltag verschiedene Szenarien, in denen Cloud-Dienste eine Lösung für gängige Probleme lokaler Applikationen bieten. Im fünften und letzten Teil der Serie geht es um das clientseitige Logging und darum, wie wir die Azure-Infrastruktur hierfür nutzen können. Continue reading

Posted in Artikel, Azure, Cloud, Cloud Computing, Logging, Storage | Tagged , | Leave a comment

TechEd 2014 in Barcelona

I attended TechEd Barcelona with a coworker. The venue was just amazing. TechEd was hosted in the Fira Barcelona. The floor space in the fira is 400000 m2. You really have to walk from session to session. But I think that has very positive influence on the conference experience. Because usually when you are always at the same location you are getting more and more tired (mentally) after each session. With the “long” distance walks between the sessions you grab a coffee or tea on the way and head to the next hall (up to 10 minutes depending on your walking speed). This gives you time to think about what you’ve heard in the sessions and also time to “exercise” your body. Good contrast to the sitting only experience of the sessions.

This is an overview of the sessions I visited:

  • Day 1
    • The Keynote (Link)
    • Optimizing Your Datacenter with Windows Server, System Center, and Microsoft Azure (Link)
    • Microsoft IoT Platform: Architecture Overview (Link)
    • Introducing Microsoft Azure Machine Learning (Link)
    • Architecting Predictive Algorithms for Machine Learning (Link)
  • Day 2
    • The Next Generation of Microsoft .NET (Link)
    • TWC | A Game of Clouds: Black Belt Security for the Microsoft Cloud (Link)
    • Entity Framework Now and Later (Link)
    • Windows PowerShell Unplugged with Jeffrey Snover (Link)
    • Introduction to NoSQL in Azure (Link)
    • Architecting Secure Microsoft .NET Applications (Link)
    • Country Drinks Party ;)
  • Day 3
    • The Future of Microsoft .NET on the Server (Link)
    • Debugging Tips and Tricks in Visual Studio 2013 (Link)
    • Automating Microsoft Azure with the Management Libraries (Link)
    • Lessons from Scale with Mark Russinovich (Link)
  • Day 4
    • Building Real-Time Applications with ASP.NET SignalR (Link)
    • Entity Framework Model Partitioning in Domain-Driven Design Bounded Contexts (Link)
    • Telemetry and Data Flow at Hyper-Scale: Azure Event Hub (Link)

Continue reading

Posted in .NET, Announcement, Events | Tagged , | Leave a comment

Real World builds in .NET

How do you build your Visual Studio solution, verify your coding guidelines and execute tests?
What steps do you take when adding a new project to your Visual Studio solution?

Living in the past

Let me summarize my past experience. I have tried several different approaches, all of them involved build scripts, and Visual Studio Project Templates or manual editing of *.csproj files. I don’t like any of the approaches. Why? I will show you some drawbacks of this kind of build definitions.

Build scripts:

  • you have to learn a scripting language
  • you try to solve problems which you would solve in your preferred .NET language with less effort

Visual Studio Project Templates:

  • making up-to-date versions available to all team members is a PITA (pain in the ass butt)
  • update your templates and you still have to update all previously existing *.csproj files manually
  • if you change your build process (e.g. enable StyleCop) you have to release and distribute a new version of your templates

Manual editing:

  • enough said

Imagine the unimaginable

Continue reading

Posted in .NET, Clean Code, Visual Studio | Tagged , , , | Leave a comment

What you don’t see is what you don’t get

Or: Why missing visibility is hazardous to your tests

Some weeks ago, I was talking to a colleague about the merits of test driven development and its challenges in an embedded environment, such as limited memory resources and hardware dependencies. He was not happy at all about the way his team handled unit testing. Continue reading

Posted in C++, Embedded, Test Driven Development | Tagged , , | Leave a comment

Wie agile Methoden Innovationen in Unternehmen unterstützen

Artikel von Alain C. Boss und Oliver Gabor, publiziert im ObjektSpectrum online, pdf «Wie agile Methoden Innovationen in Unternehmen unterstützen» als pdf lesen

Innovationen sind der Antrieb für eine florierende Wirtschaft. Doch um langfristig erfolgreich zu sein, genügt es oft nicht, einen angestammten Markt zu bewirtschaften. Agile Methoden können dabei helfen, in fremde Märkte zu expandieren und die Zukunft des Unternehmens langfristig zu sichern. Der Artikel zeigt, wie agile Methoden Innovationen unterstützen und der Sprung in neue Märkte möglich wird. Continue reading

Posted in Agile, Artikel | Leave a comment

Wie Hund und Katze: Legacy Code und Agil

Artikel von Urs Enzler im Sybit Agil Nr. 14  pdf «Wie Hund und Katze: Legacy Code und Agil» als pdf lesen.

Legacy Code verdient viel Geld. Legacy Code steckt in vielen Systemen, die zwar in die Jahre gekommen, aber immer noch erfolgreich sind. Da können noch so viele Softwareentwickler fluchen und sich die Haare raufen, Legacy Code ist die Realität. Aber nicht das Ende… Continue reading

Posted in Agile, Artikel, Clean Code | Tagged , , , | Leave a comment