A new course: Day to day software design for .Net Programmers

Just over a year ago, I unveiled our Parallel and Async C# 5 course. It was immediately popular, and I’ve been enjoying teaching it at a number of locations. Today, I’m happy to announce another addition to our .Net offerings – and it’s something a little different to any of our courses so far.

Our existing .Net courses have focused on the C# language, a particular theme (such as TDD or parallelism/asynchorny), or a particular framework (such ASP.NET MVC or WPF). However, there is much more to being an effective developer than knowing tools, frameworks, and languages.

In our day to day development, we have to make all kinds of choices and trade-offs. While the decisions we make may each be fairly small, together they have a large impact on the quality of the software we produce. Large systems stay maintainable mostly through boundaries and abstractions being respected – but this respect is only possible when we can trust what lies beneath an abstraction. And that trust is gained through the code behind an abstraction making all of the little choices correctly, delivering consistent and predictable behavior.

Making good design choices is challenging. Let’s start at the bottom of the stack and work our way up to see some of the reasons why.

  • Modern hardware is complicated, and has non-obvious performance behavior both in terms of instruction execution and memory access
  • The CLR is not a simple, naive executor of bytecode. For one, the JIT compiler does some potentially surprising things. But more importantly, garbage collection is neither free nor magical, and there are ways it can bite you – not only in hot-path algorithmic code, but also in typical server applications.
  • Everyone knows List<T> – but is it always the best choice? When is LinkedList<T>, Queue<T>, Stack<T>, BitArray, or even just a plain old Array, a better choice? How do we use dictionaries well? What are trees and graphs good for? What do those O(…) things in the MSDN actually mean? There’s plenty to know about picking good data structures.
  • C# supports object-oriented programming. But much OO code written in C# sucks: it’s full of Manager or Service classes, the only pretense at encapsulation is the use of properties rather than fields, and attempts to test it mostly seem to result in wasting a lot of time updating tests on every refactor. This is not how OO should be, but to do better needs us to re-consider what OO even is. Spoiler: it’s not really about objects!
  • We hear plenty about “mutable” and “immutable” – but deciding between them can be tricky. Heck, how do we even apply the ideas of immutable data when we know things in the real world change?
  • We often hear that “extensible” or “composable” designs are desirable – but rarely discuss what the two words might mean. When do we pick inheritance, interface implementation, or take a Linq-esque monoid-y approach?
  • Time comes into a lot of business domains, but time is gnarly. Humans are wonderfully imprecise about dates and times in almost all their day to day interactions on the subject, relying on context to resolve the ambiguities. Computers lack that context – and sadly the .Net DateTime classes don’t do a great job of making that clear.

Our new Day to day design for .Net programmers course takes on all of these issues – and more. It aims to fill in a bunch of common knowledge gaps and shed some light on a number of areas that are typically under-discussed – thereby helping developers produce better-considered software.

As for prerequisites for this course, we believe anyone who has handled our Intermediate C# course (or has equivalent skills) will be in a good place to take it. Mostly, our requirement is that participants have a good working knowledge of modern C# (that is, including generics, lambdas, and Linq) – since the point of the course is not about learning the C# language, but rather about designing good programs that take C# and the CLR into account. This choice of prerequisite also indicates that we don’t consider this a hugely advanced course; senior developers with a good computer science background and a bunch of years experience may only find so much new. As always, please take the time to read the topic outline, to decide if the course is right for you.

I’ll be sharing the teaching of this course with other Edumenters, who have contributed in various ways to its development. We look forward to getting this new course “on the road!”

Here’s the abstract and how to book the course; as usual, there will be classroom sessions or you can have it at your company.

//jnthn

omg-jnthn

April 2, 2015 at 5:36 pm Leave a comment

Är servicedesken död?

Det har under ganska lång tid diskuterats hur servicedesken och
övrig support måste lämna sitt traditionella koncept för att leverera
det användarna behöver och vill ha just nu var de än befinner sig, support
just-in-time. Det är det som kommer göra skillnad nu när allt går snabbare
och snabbare och användarna blir mer och mer mobila och hela tiden
“uppkopplad”. Ida gär det många företag, där verksamheten ställer om och
erbjuder en virtuell arbetsplats, jobba där du är, reser mer och inte minst
är vana vid att kunna få det de behöver just nu, inte sen i denna globala
digitaliserade värld.
Om nu “kulturen” öppnar upp för Bring Your Own Device (BYOD), Bring Your
Own Services, Bring your own technology osv, molntjänster hit och dit blir
det en tuff om inte en omöjlig uppgift om inte supporten inklusive
servicedesken blir en lika virtuell organisation och levererar en snabb
effektiv support när användaren behöver det?
Servicedesk och support är många gånger något nödvändigt ont och ett
“kostnadsställe” och i takt med att allt fler hellre söker efter hjälp på
Google, eller frågar en kollega än att ringa servicedesken handlar det
kanske om ställa om eller förvinna.
Malcolm Fry en Servicedesk guru pratar om “real value” och att nyckeln är
att “stoppa telefonsamtalen” som är ett ineffektivt sätt att supportera och
istället med hjälp av self-service, användarportal, interna effektiva
söksystem (likt Google) möjligheten att chatta nu och få hjälp direkt
istället för att logga en ticket som sen ska eskaleras genom olika nivåer.
Det är inte så att behovet av support kommer att försvinna utan i takt med
att fler har allt fler enheter, tekniken blir billigare och billigare
kommer det driva behovet av support. Men vi måste tänka om.
T.ex. så måste supporten vara en “plats” att gå till varsomhelst och
närsomhelst likt t.ex. Facebook, inte en fysisk centraliserad plats.
Utmaningarna ligger i hur informationssäkerheten ska hanteras och
kontrolleras. Någon pratar om en “avreglering” likt elindustrin där
användaren väljer sin egen support, Bring Your Own Support, som är
“personlig”.
Det de flesta är överens om är att hur vi en hanterar det så måste det vara
en Single Point Of Contact, dit jag vänder mig där förväntar jag mig att
den personen/funktionen tar ansvar och ger mig den support jag behöver hela
vägen tills jag som användare är nöjd.
Sist ett litet tips från mig för att få en snabb effektiv support och
samtidigt bygga upp en bra kunskapsdatabas. Bygg in inte bara möjligheten
till chat utan också ett Twitter-flöde i portalen och i kommunikationen
mellan servicedesken och användarna där vem som helst kan ställa en fråga
och där den som bäst kan svara svarar just-in-time och med hjälp av
hash-taggar bygga en kunskapsbank och för sökmöjligheter.
Hälsningar från Las Vegas
johan@edument.se

February 18, 2015 at 7:14 pm Leave a comment

House of Cards or missing in action

pink2015
Nu har äntligen Pink Elephants årliga konferens Pink15 dragit igång. Jag har i ett år väntat på att få möjligheten att återvända till denna fantastiska konferens inom IT Service Management i lika fantastiska Vegas. Det är 160+ föreläsningar, workshops, paneldebatter att välja mellan. Läs mera här http://www.pinkelephant.com/pink15/
Om nu DevOps och The Phoenix Project var de heta ämnena under Pink14 så är det definitivt Governance och Cobit som är det i år. Vad är Governance? eller styrning som vi säger. Det är precis som det låter, det handlar om hur vi styr vår IT medans Management (ITSM) så som ITIL handlar om hur vi hanterar vår IT.
Nu handlar det om att vara “Aligned with the business” känner ni igen? Fast nu är det på en ännu högre nivå. Brett och högt :) Att hitta en bra balans mellan 1. Vilka fördelar har vi om vi gör så? 2. Vilka risker medför det och 3. Hur påverkas resurserna? Vilka behov har våra intressenter och ur kan vi skapa värde. Låter det bekant?
Här handlar det om hur verksamheten ska styra IT utifrån en Enterprise & verksamheten på hög nivå, strategiskt och långsiktigt.
Experterna påstår att nyckeln till framgång eller rättare sagt inte riskera att IT ska bli outsourced ligger i en bra styrmodell där vi kontinuerligt utvärderar, styr och monitorerar vad vi gör utifrån verksamhetens behov och framgång.
Vad hjälper oss en bra IT-Governance med?
  • Det ger en tydlig riktning för att säkerställa att IT-investeringar stödjer verksamheten
  • Det är ett effektivt sätt att hantera förändringar
  • Det skapar värde för verksamheten i linje med företagets mål
  • Och det adresserar hela livscykeln för IT-investeringar
Det känns som om vi drunknar i olika best practice, standarder, ramverk mm som IS020000, 27000, 9001, ITIL, CMMI, SIX SiGMA, och inte hinner vi ställa om IT med hjälp av ett ramverk som ITIL innan vi får nästa på halsen dvs IT Governance och standarden ISO38500 och ramverket Cobit (iofs inte något nytt). Det har gjorts undersökningar som ställer frågor som, har ni någon styrmodell? Är verksamheten involverad o.s.v.och här får vi samma svar som när det gäller tidigare undersökningar bland företagen om de har någon IT strategi, arbetar efter best practice (ITIL) eller om IT-chefen/CIO sitter i ledningsgruppen och gissa vad vi får för svar?
50% av all tillfrågade har någon form av IT Governance och hälften av de har verksamheten med alltså 75% av alla tillfrågade har inte någon koll på vad de gör eller tror sig veta vad verksamheten behöver och jag tror att vi bara bygger på vårt korthus med fler best practice och processer innan vi byggt klart föregående och att det blir ett hus som är ganska instabilt med stora hål eftersom vi hela tiden tror att bara vi gör så och följer t.ex. Cobit och ITIL så blir det bra…Nyckeln här tror jag är att när det gäller IT Governance så ska det komma uppifrån och ner som ett intiativ från verksamheten med stöd av IT och när det gäller management så ska det ske nerifrån och upp och så ska de två mötas och förenas i evighet där IT-styrningen blir ett filter mellan verksamheten och kontrollerar, följer upp, vidtar åtgärder eller på resn svenska Evaluate, Direct and Monitor det som IT hanterar annars kommer verksamheten att på sikt “döda” IT verksamheten.
Fortsättning följer från ett soligt Las Vegas
johan@edument.se

February 17, 2015 at 7:57 pm Leave a comment

Two days of Event Store

Event Store 

What is an Event Store?

It is a database for supporting the concept of Event Sourcing. Event Store stores your data as a series of immutable events over time, making it easy to build event-sourced applications.
Projections allow you to react to events as they are written, and to create new events when interesting combinations occur. You can use the same model for writing temporal correlation queries that run over historical data and on into the future.

Event Store Workshop

If you want to learn more about Event Store, we are hosting a workshop in Malmö 2-3 October. During this two-day workshop Greg Young will teach how to use the Event Store as a stream database, both by using the native Atom-based API and .NET client API.

You will also learn to use the built in projections library to do complex event processing and write temporal correlation queries using JavaScript.
To find booking and more information, see our event Event Store Workshop with Greg Young

August 28, 2014 at 3:06 pm Leave a comment

A few Edument C# Master Class updates

The C# Master Class has been one of our most popular and well-rated courses ever since its advent almost 3 years ago. In that time it has seen a number of tweaks in response to feedback, along with a more serious update when C# 5 was released.

 

C#

 

By now, I’ve done dozens of deliveries of the C# Master Class, and it has reached hundreds of developers. It’s been a great journey so far, and it has been especially rewarding to meet some course attendees a few months down the line and hear how the course helped. C# has grown into a larger and richer language than it once was. Some wonder if we really need all these features, but I strongly believe the sum of the features is greater than the features individually, and it’s been wonderful to have an opportunity to share that perspective with so many.

Equally, I’ve been growing and learning too. One of the nice things about working at Edument is that it’s simply OK to spend time learning new things. And after 3 years of the C# Master Class, I felt it was time to incorporate some of that learning back into it. Therefore, this summer, I’ve invested a bunch of time into improving the course. Of note, the OO coverage is now a lot deeper and richer, the parallelism section has been streamlined and refocused, and there’s an awesome new walk-through on implementing the event aggregator pattern from scratch by effectively fusing higher order programming, generic programming, and reflective programming.

There’s one other change I’d like to take a moment to mention. To date, I’ve been the only teacher for the C# Master Class. As our range of courses has grown, along with demand for consulting and mentoring, scheduling enough C# Master Class deliveries to meet demand has become challening. Happily, this summer the course has gained a second teacher. Edument’s Eric Lavesson has been working with me on the course updates, and will now also be teaching the class. Eric has great taste in code, and I know he’ll do a great job of teaching this course. All the same, I’m excited about the latest changes too, and look forward to my next chance to deliver a C# Master Class with them!

By the way, for those who took the C# Master Class and are looking to go further, don’t miss our Parallel and Asynchronous C# 5 course! I’ve had a lot of fun teaching it so far all over Sweden – from Malmö to Skellefteå – and we’ll be offering it some more times this autumn. It’s also available through our partner Glasspaper in Norway too – or anywhere in the world you want it, direct from Edument.

// Jonathan

Jnthn-Webben

August 19, 2014 at 10:51 am Leave a comment

JavaScript has taken over the world; long live TypeScript!

a picture of Darth Vader in front of some other toys

JavaScript has taught me this: if I were an evil overlord whose plans for world domination included getting everyone to download my programming language, I would put it in browsers.

Brendan Eich did just that, in 1995. He put this weird Java-Scheme-Self-HyperCard hybrid of his into browsers, and now all the king’s horses and all the king’s men can’t take it out again. I’m not saying Eich is an evil overlord; I’m saying if he were, this would have been a very clever move indeed on his part. Witness me clapping slowly.

JavaScript is here to stay

Let’s face it. We’re really, really stuck with JavaScript. In two ways, actually.

  • The first, that if you’re a web developer, you have to relate to JavaScript in some way. Because the web runs on JavaScript.
  • The second is Atwood’s Law: “any application that can be written in JavaScript, will eventually be written in JavaScript.”

(Someone may disagree with that last point… but only by failing to notice that nowadays people write office suitesIDEs3D first-person shootersemulators of mostly everything including JavaScript itself in JavaScript!)

Three stages of grief

Once we realize that JavaScript is here to stay, how do we choose to relate to it? We have a couple of options:

  1. Learn the language extremely well, so we can use it well.
  2. Improve the language step by step (without breaking anything).
  3. Wrap the language in a nicer language and use that instead.

Option 1 has become popular in the last few years. The two most earnest efforts I know about to teach JavaScript to the people are JavaScript: the good parts by Douglas Crockford and You Don’t Know JS by Kyle Simpson.

Option 2 is also underway, and seems to be picking up speed. Not only do we have a mostly-complete transition to EcmaScript 5 behind us, but EcmaScript 6 is looking good and more stable every day. Sometimes when the weather is just right, you even hear soft whispers of EcmaScript 7 in the wind. Evergreen browsers are becoming more common and help speed up adoption of newer features. All in all, given that we’re stuck with this language, it feels like we’re doing a very decent job of fixing it.

Option 3… now there’s a Cambrian explosion for you.

I can’t believe it’s not JavaScript

Seriously, check out the list of languages that compile to JavaScript. In that list, you are witnessing what happens when the reality of today’s web locks people into a de-facto development language: people find a way to compile from their own language to JavaScript. (True to form, half of those people geek out and neologize about “transpiling”, while the other half mumbles about kids today and nothing new under the sun, etc.)

On that list, you’ll find existing languages, original languages, languages with interesting ideas, and languages that won’t ever have 10 simultaneous users. There are behemoths like CoffeeScript and GWT on there. Even Perl 6 is on that list. It’s a long list.

Boilerplate

Summer Glau and a tear

Let’s be clear about why that list is so long: JavaScript may be the industry standard, but as a language, it’s clearly lacking in useful abstractions: classes, interfaces, modules. There’s no way to declare the type of a variable. There’s no built-in namespace mechanism, and no way for one JavaScript file to include another. JavaScript is not only unfit for its current role as Overlord language of the web, but laughably unfit. Or, let’s say, we’re almost sure the tears in our eyes are from laughter.

Everyone is helping. The people from option 1 have shown us, across the years, how to emulate classes and interfaces and modules, how to fake it without strong typing, and how to hack the DOM in various ways to emulate features. The result is a lot of so-called “boilerplate” code: a lot of code with a low oomph-per-character ratio. You’re not paid to like it, you’re paid to make it work across all browsers, kiddo.

The people from option 2 are busy putting classes and modules and other nice stuff into your JavaScript. You go, TC39! (You can even run ES6 today, in your browser. It’s pretty cool, but it has to be compiled down to ES5 for now.)

The people from option 3 are basically scouting ahead, seeing what options we have for making JavaScript nicer. That long list of languages is like an ongoing evolutionary experiment in working language designs. What will stick and what won’t.

TypeScript

It’s here that TypeScript comes in. It’s another language that compiles to JavaScript, but compared to the changes many languages on that list make, TypeScript’s are fairly modest, and the language sticks close to JavaScript. In short, TypeScript gives you optional typing and classes, interfaces, and modules/exporting — allowing you to write code with high-level abstractions, while the compiler translates it back to boilerplate.

A bit more in detail:

  • Syntactically, it’s a strict superset of JavaScript, so every JavaScript program is already a valid TypeScript program by definition.
  • It’s almost as if TypeScript’s mission is not to change JavaScript into something it isn’t, but to take what’s already there and describe it on its own terms, allowing us to talk about relations that were always present, implicit in our JavaScript code. I find that rather charming.
  • The boilerplate that comes out the far end of the compiler is described as “how you would have written responsible JavaScript anyway”.
  • What we put in as additional types and classes and interfaces to describe our code, we get back as static type-checking and term completion in our favorite IDE. That kind of safety and convenience is not possible with today’s dynamic-to-the-hilt JavaScript.
  • But what about all the JavaScript library code that’s already out there? Wouldn’t the TypeScript code you’re writing be like a tiny type-safe island in the middle of a vast ocean of untyped JavaScript library code? Yes, but… there’s a community project where people are adding TypeScript types to all the big JavaScript libraries out there, so we can TypeScript while we TypeScript! Gotta love open source.

These are some of the reasons I’m excited about TypeScript. I used to write mid-sized to big projects in pure JavaScript; nowadays, my first choice is TypeScript.

Try it now

You can play around with TypeScript code and the JavaScript it renders in your browser. Oh, and the project hit 1.0 a month ago, which is just what it sounds like: this is ready for production.

One last thing: Edument provides a JavaScript course, which we’re constantly keeping up-to-date to reflect the latest best practices in web development. If the topics in this blog post interest you, consider taking the course, which is two days’ worth of similar material.

 

 

//Carl

Carl Mäsak på Edument

June 24, 2014 at 12:47 pm Leave a comment

Video of my invokedynamic talk is online!

Several Edumenters attended Build Stuff 2013, and two of us gave talks. All of them were recorded by InfoQ, and they’re now starting to appear online! The first one to appear is my invokedynamic talk. The invokedynamic instruction was introduced in JDK7, and was aimed at helping compiler developers targeting the JVM to more efficiently implement a wide range of language features. While the name suggests a role mainly for the things we like to call dynamic languages, invokedynamic has in fact been used as part of implementing lambda expressions in Java 8.

My own application of invokedynamic was implementing JVM support for the Rakudo Perl 6 compiler. While the talk is not just about that – it covers invokedynamic in a much more general sense – I was able to draw on my concrete experiences of using it, which is something I always like to be able to do in a presentation. Also it was nice to do a talk on compiler-related things – an area I greatly enjoy working in.

Enjoy!

 

//Jonathan

Jnthn-Webben

 

 

 

 

 

Recorded at

May 23, 2014 at 11:33 am Leave a comment

Older Posts



Follow

Get every new post delivered to your Inbox.