dotnetsheff is a monthly user group focused on software development, particularly in the .NET ecosystem. We welcome people with interests in software development of all ages and levels of experience. Please get in touch via Twitter (@dotnetsheff) or email (organisers at if you or someone you know may be interested in speaking.

  • February's event will be split into two parts, Mark Thompson presenting on Building a private cloud on a shoestring using Ovh and the second half will be Robin Minto presenting #FAIL - Lessons from infosec incidents.

    Building a private cloud on a shoe string using Ovh

    We’ve all heard of AWS and Azure. Here’s a third option, the third biggest web host in the world according to Netcraft – Ovh. In this talk will discuss how you can build your own platform, from the hardware up, if desired, using Hyper-V and .NET to control and expand your cloud around the world. We will talk about using .NET to connect to the Ovh API as well as to manage Hyper-V, virtual machines and cloud infrastructure. Using C# we can quickly build applications to monitor and manage your firewall, load balancers and servers. Living the Dev Ops dream from C# or power shell for the cost of a half decent meal. Mark Thompson

    #FAIL - Lessons from infosec incidents

    Securing a web application is a challenge. The internet...

  • Messaging - RabbitMQ, Azure (Service Bus), Docker and Azure Functions

    Message queuing is becoming an essential part of modern architectures and essential for asynchronous architectures and microservices. In this session will be described the benefits of messaging systems, the software solutions that are available and typical messaging architectures. Examples will be made using Azure Storage Queues, Azure Service Bus and RabbitMQ. This talk is primarily about messaging, however as this session is for tech hipsters, the demos will be done giving an extensive introduction to Azure functions, Azure Resource Manager Templates, .Net Core and Docker.

    John Staveley is an organiser at LeedsSharp with 17 years programming experience and has been a heavy user of RabbitMQ and Azure in the past couple of years.

  • Life, Liberty and the Pursuit of APIness : The Secret to Happy Code

    We spend our lives working with systems created by other people. From the UI on our phones to the cloud infrastructure that runs so much of the modern internet, these interactions are fundamental to our experience of technology - as engineers, as developers, as users - and user experiences are viral. Great user experiences lead to happy, productive people; bad experiences lead to frustration, inefficiency and misery.

    Whether we realise it or not, when we create software, we are creating user experiences. People are going to interact with our code. Maybe those people are end users; maybe they're the other developers on your team. Maybe they're the mobile app team who are working with your API, or the engineers who are on call the night something goes wrong. These may be radically different use cases, but there's one powerful principle that works across all these scenarios and more - and it's called discoverability. In...

  • Following our continued success of the lightning talks, we are hosting another round! We will be having 5 speakers doing a 10-15 minute lightning talks, if you would like to get involved please message me on meetup or twitter.

    A lightning talk is a very short presentation lasting only a few minutes, given at a conference or similar forum. Several lightning talks will usually be delivered by different speakers in a single session, sometimes called a data blitz.



    Slot 1 - Zoltán Lehóczky (@zlehoczky ( - Hastlayer Talk

    Slot 2 - Andrew Gunn (@andrewgunn ( - Power BI

    Slot 3 - Elliot Chaim (@elliotchaim ( - TBA

    Slot 4 - Kiran Singh - No Estimates

    Slot 5 - Kevin Smith (@kev_bite ( - Error Monitoring with Raygun

  • "APIs are hard. They are pretty much ship now, regret later." -- Chet Haase.

    What do Greek philosophy, early video games, and Japanese bullet trains tell us about how we should design our APIs?

    Writing any old API is easy. Writing an API that can evolve to meet your needs over the coming months, years, and even decades; now that's hard. We'll look at some common practices and try to see where they go wrong, some misunderstood techniques and how to use them better, and some less common practices that might be useful.

    Let me give you some good advice that'll help you evolve your APIs, and some big ideas that might provoke some interesting thoughts.

    Gary is an agile provocateur, software nomad, and lean mercenary. His main hobby is to try and help companies to build better software in better ways. Sometimes this is by helping them with the messy human communication side of agile, and sometimes it's through teaching better software crafting practices - but it's usually at least so...

  • Details to follow.