HoloLens talk at DotNetNorth Manchester

Last night was the December meeting of DotNetNorth in Manchester at which the excellent Mike Taulty gave us a developers’ first look at the HoloLens. It was an eagerly anticipated meeting and we had just over 50 people in the room.

There’s some seriously powerful stuff going on inside the headgear and it was great to see people getting really excited about what HoloLens can deliver.

The group has been running in this format for just over a year and this was one of the best attended ones we’ve had – thanks to our sponsors and the team of fellow organisers.

DotNetNorth is a community group for techies in Manchester who are interested in Microsoft products. I’ll post more about the group over the next months, but if you’re local to the area and want to join us then head over to https://www.meetup.com/DotNetNorth/ and join the group.

 

 

Data science certificate – take care if linking to a Microsoft account

One tip  – when you have to sign up to edX to do the courses you will be presented with an option to ‘connect with Microsoft account’ along with options to connect with Facebook and Google too. I normally shy away from explicitly connecting accounts like this but decided, this once, to use the MS connect facility to connect to my hotmail account. This does NOT work (well not for hotmail accounts). Worse, it appeared to work for 24 hours before it stopped and causing much confusion and gnashing of teeth. Apparently, it will work for Office365 type accounts but not ‘consumer’ grade Microsoft ones.

Wish I’d followed my usual advice when faced with another new web registration – a deep breath to calm the rising frustration, open Enpass and add another login.

Beginning a journey to “data scientist”

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.

 

Conversation id’s are not carried between service broker instances

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.