Learning about the latest & greatest at Techorama 2015 - Day 2 Recap

Just as promised in yesterday’s post of day 1, we are back with an overview of some of the sessions from the second day of Techorama.

Internet of things, success or failure by Stefan Daugaard Poulsen

Twitter: @cyberzeddk

One of the sessions to start off the second day of Techorama, was one about the internet of things, presented by Stefan. He made it clear from the very beginning, that this was not going to be a technical session about writing the code to run on devices, nor about the electronics themselves since Stefan, to put it in his own words, knows jack about it.

Companies are continuously attempting to invent new devices for all kinds of purposes, but are all of these devices actually useful? It’s not all about inventing shiny new devices that look good, but they should take some aspects into account:

• Does it solve a problem? Can it be used to actually make life easier or provide useful information.
• Is it consumer-friendly? In other words, can it be shipped without user-manual without raising questions.
• Does it repeat history? There is no use in re-creating devices that clearly failed in the past.

Off course, one could ask a whole bunch of other questions before starting the development or creating a kickstarter-project. But these questions above are vital in order to build a device, which might turn into a succes.

Although the Internet of Things is becoming widely popular and lots of companies are jumping onto the IoT-train, there are quite some challenges:

• Privacy: what happens with the data that is being collected by this device.
• Security: since most devices will be connected to a network, they may not become the culprit of security-leaks.
• Data processing: all of the sensors are generating a huge load of data, which needs to be processed in an orderly way.
• Data storage: all of this data that is being processed needs to be stored in a correct way. Do you actually need of the data? How long do you need to save it?
• Futuristic thinking: the devices should be an enhancement of the current world, but with some limitations. It is not always possible to change how everything is currently working, without expensive modifications.
• Battery-life: there is no use in creating a device that needs to be charged every couple of hours.

In overall, people or companies should think before creating the next new thing, as it needs to be useful, non-intrusive, reliable and enhancing.

Embellishing APIs with Code Analyzers by Justin Rusbatch

Twitter: @jrusbatch

Visual Studio 2015 ships with the long-awaited Roslyn compiler platform. I can’t remember when exactly Microsoft started talking about Compiler as a Service, but it’s been a couple of years at least. However, it was worth the wait!

As is more and more common within Microsoft, the development of this platform is all open on Github. This means the compiler is no longer a black box, but a fully featured set of APIs which can be used to analyze code, among many other things.

Justin did a small demo on how easy it was to create and debug an Analyzer using Visual Studio 2015 and the VS2015 SDK. It was a simple demo analyzer which would indicate that class names must be in upper case (I suggest not to use this in your actual code).

A code analyzer looks like this in Visual Studio: 

I can think of quite a few use cases already to use code analyzers for. If we think about BizTalk development alone, one can imagine quite a few rules to create, just for Pipeline Components.

• The pipeline component class must have a GuidAttribute and ComponentCategoryAttribute. (this prevents a few minutes of wondering why your pipeline component doesn’t show up in the Toolbox).
• Do in-depth code analysis to see if the Load&Save methods are implemented correctly.
• Create warnings for working with non-streaming classes.

Additionally, each integration project has business-specific rules and coding/naming guidelines. Perhaps your guidelines require you to do a LogStartMethod() & LogEndMethod() in each and every method. Now you can create an analyzer which can verify this, and optionally break your build. This way you can ensure that all your guidelines are enforced, and you have great Visual Studio tooling as an additional benefit. You can even create quick fixes so it’s just a matter of clicking the light bulb and the log statements are inserted without you typing a thing.

All in all, it’s something I will definitely look into in the coming weeks.

Teamwork – Playing Well With Others by Mike Wood

Twitter: @mikewo

Those who’ve read yesterdays post already know I’m a fan of Mike as a speaker but todays session was really really inspiring!

The focus of the talk was about how can you as an individual work well with others – The first step to achieve this is by stop thinking about yourself as an individual, but instead think the team. Together you are one and believe in one big picture – Your main objective. You need to get rid of your ego and work together as a team to achieve your goal and get across the hurdles that are holding your back from achieving it.

Here are some other interesting tips he gave us :

• When communicating in team, do it wisely – Don’t start pointing fingers at each other when things fail but work together to fix it as soon as possible. Talk in the we form when it’s possitive, otherwise talk in the I form, i.e. I broke the build because of this or that. Avoid the “Lottery”-effect where only one person has knowledge about a certain topic, losing him/her means losing a lot of knowledge.
• Great work can be rewarded with incentives but do it the right way – Reward the team instead of one individual. As an example don’t reward the salesman who sold the most, reward the team when they’ve reached a certain target. This will boot their team spirit instead of having internal competition.
• Understand failure and accept it – Nobody is perfect & everybody makes mistakes so accept this, it’s inevitable to make mistakes but make sure you learn from them.
• Leadership – Not everyone wants to be a leader so don’t push people to do this. A true leader knows how his team members work & feel so they can take that into account. Provide them with guidance & your vision to which you are striving. Also delegation is key to success but don’t assign them tasks you would not want to do on your own.
• Invest in your team members – Have trust in them and let them research things they’re interested in

These are just some of the examples Mike gave us that can really contribute in thinking as a team, working as a team & shipping great solutions as a team.

I’d like to end this blog post with a quote Mike mentioned during his talk.

“We will accomplish what we do together. We share our successes & we never let anyone of us fail alone.”
– USC Covenant 

This rounds up our 2 day adventure at Techorama, first of all we want to thank everybody for reading our two blog posts and off course a big thank you to the organization of Techorama for creating such an amazing event!! 

Thanks for reading,

Maxim, Sam & Tom