As you may know, I am one of the co-organisers of a Microsoft oriented community ‘user’ group in Manchester called DotNetNorth. We run a monthly meeting in Manchester city centre with one or two speakers plus pizza (that’s Manchester in the United Kingdom).
When the group started it was run by myself, Pete Vickers and Chris Hardy and was aimed at building a community of Windows Phone developers; we didn’t see many people at the meetings but we built a small core of regular attendees many of whom have become friends.
In 2014 we decided to pivot into a less specialised group and we’ve grown since then to have almost 1000 fans on our meetup group.
Chris has since gone off to work for Xamarin in the USA so Pete and I now have the help of Oli Newsham, Jason Holloway and Mike Irving to keep the group running. Having a team certainly makes the events easier to host and run – we’ve all got different strengths and we use that to our advantage each meeting and it means people can find an ‘organiser’ when they need one.
This last year has been a pretty incredible one for us – we secured a year long sponsorship with Evolution Recruitment which allowed us to stop worrying about how to pay for the pizza each month and they also promoted the meetup site by adding a link to the email signature of all their consultants working with Microsoft related technologies. The company has been commendably ‘hands-off’ about the arrangement with one of their guys, Scott Barker, coming along each month (sometimes with a colleague too) just to chat to anyone who is looking to move jobs.
The group continues to grow at pace and we will soon be looking for a bigger venue to host the meetings and more sponsors to cover the costs.
If you’re interested in coming along or speaking at one of our meetings then you can see the event diary and/or send us a message at http://www.meetup.com/DotNetNorth
For a long time I’ve been interested in data. My first development job was building a production tracking and reporting application in Microsoft Access (version 2.0 if you’re asking) and I’ve been in love with the idea and practice of storing data ever since. Many of my subsequent jobs were building applications to collect and show data, after my experience with Access (which was then, and still is, an incredible piece of software) I worked with VB4 through to VB6 and the transition to Windows Forms and C# and eventually to HTML and the web. But all that time, it was the *data* that interested and excited me. I did a few assignments building business intelligence solutions using the SQL Server BI stack and that was really good fun and challenging but I always seemed to end up back as a C# coder.
Having finished a recent contract building web apps in C# and Angular and all that webby stuff I found myself thinking that I’d change my focus and go back to the data. I had heard about the Microsoft Professional Program for Data Science, so I’ve enrolled in that with the aim of transitioning away from being a pure code monkey to something more deeply attached to the data.
I’ve finished a couple of the modules already, but I plan to blog a bit about my experience in making this change. At the end of the journey I hope to be able to call myself a Data Scientist, and more importantly get paid to be one.
Digging around today I have found something that, at first seemed odd, but probably isn’t. When a message gets transmitted between service broker instances, it has an associated conversation ID. One might expect that the ID would travel with the message(s) to the destination instance. After all, it’s the conversation ID that ties together all the messages that need to be treated as one dialogue.
At the destination, however, the conversation ID that the messages have is different to the one they are associated with at the sending end.
This seems odd.
All the messages in a conversation at the receiving end have the same conversation ID, it’s just a different GUID to the one that they have in the source database.
Apply a bit of brain juice and I surmise that what is going on here is either (or both) of (a) the system just not trusting the sender GUID, so causing a new one to be used, (b) an incrementing GUID is being used for the conversation ID, so that the destination has to assign a fresh value so as to maintain the sequence order of the ID.
I need to do a bit of testing to see if (b) is in fact what’s going on here.
P.S. I shall be presenting a talk on Service Broker of the SQL Server User Group in Manchester in June.