Tuesday, 17 October 2017

After Ignite–Bots and Brains Meetup–Part 1

What is a Community Meetup at Ignite

This year, in September I attended Microsoft Ignite in Orlando Florida for the first time in many years (since the days of TechEd actually) and for the first ever as a speaker.  I was deeply honoured to be selected as a speaker and even more so that I was selected for what is a relatively new format, the Community Meetup format.

I took my role seriously and spent a good amount of time preparing for this unusual presentation format.  Typically at these sorts of events the presenter gets up at the front of the room with a projector, some PowerPoint slides and perhaps a copy of Visual Studio to show some code.  At a community meetup presentation the participation shifts a bit to the attendees.  To get the most out of the session, attendees have to find the subject interesting, have some opinions and be willing to share those opinions.

As the community meetup host my role was to present the ideas and concepts to the attendees backed with my expertise and experience in the field and hopefully my comfort in facilitating discussion.  Our session (for it was both my and the attendees session) was BRK2388 “Bots and Brains: The Microsoft Bot Framework and Cognitive Services, better together”.  The idea was to discuss the difficulties with making a chat bot application that was responsive to the needs of people using it.  This included three main topics, frustration, inclusive design and deciding if a chat bot was even the best delivery mechanism for the application.

Our room held only 85 people and I’m happy to say we filled the room.  However, I do regret that perhaps hundreds were turned away at the door as our room and format dictated a much smaller attendance than were registered for the session.  I will continue to work with Microsoft to improve the format as I feel that the format presented a number of valuable benefits to attendees that they might not get in other more traditional passive sessions.  I believe that attending a well run community meetup should offer a great chance to network with other people interested in the same topic.  It offers the chance to come up with some possible solutions or considerations to problems that many of us face on a regular basis and perhaps just as importantly give a chance to be actively involved in the Ignite conference as opposed to the typical passive nature of attending presentations.

This is the room I spoke in.  Seats 85 people.  350 showed up.










Getting Started

So… what did we do?  We had a room of 85 enthusiastic attendees that came ready to participate.  We had ten tables of 6 people each with additional chairs around the perimeter.  We began by getting everybody to introduce themselves at their particular table.  My plan was to get each table to work together as a team.

Next we introduced everybody to a shared OneNote notebook that would provide all the attendees a place to take notes that we would make available after the conference.  Each table would hopefully record notes of discussions and ideas right in the shared OneNote notebook (It turns out that they did… enthusiastically, more on that content in Part 2)

Now it came down to me where I introduced the topic we wished to discuss and more specifically what questions we would be addressing as a community.  I began by introducing my background in the Microsoft Bot Framework and Cognitive Services, my expertise in application development and some examples of  Bot/AI projects I have worked on.  Then we got to the meat of the meeting.  In a chat bot, how do you deal with Bot Frustration?  How do you make a chat bot that includes everybody and lastly how do you decide if a chat bot is the right solution in the first place.

When we got started with the first topic I was surprised to see everybody at each table actively participating in the table discussion and even more surprised that those sitting along the walls formed ad-hoc discussion groups without a table and began working on ideas.  There did not seem to be anybody I noticed that was left out of the discussion.  That made me feel pretty good.

What Could have been Better

I wish, in some ways that the session had been recorded for others to enjoy some of the feedback but it might not have presented well as a recording as there were 5-8 minute gaps of discussion where nothing obvious was happening to a recorded session.   I also wish that we could have accommodated the many people who were not permitted entry to the session due to seating availability. 

The difficult balance was between a community feel where everybody could participate and having so many people in the room that it becomes difficult to let everyone’s voice be heard.  We could easily have had a much bigger room available to a lot more people, but at what cost?  This is one of the challenges we will need to address for next year.  The fact that the meetup sessions were so popular was gratifying, concerning and encouraging, all at the same time.

I wonder if the elevated stage was more of a barrier to the presenter, me.  I spent a lot of time walking among the tables, listening to the discussions, offering some suggestions and advice and eliciting feedback from various tables and having to climb up to a podium separated me from the groups perhaps too much.

What Worked

The table discussion format actually exceeded my expectations.  Before the session I really didn’t know if what I had planned would work, would be fun and would provide valuable information to the attendees.  I thought it would (else why would I do it?) but it was satisfying to see that it worked out even better than expected.

We ended up with a whole bunch of information collected in the OneNote notebook on all three topics.  Some tables came up with some interesting names for their “team” (Revolving Table, Wall, Table Unique, etc…) and people seemed to have fun.  At the end of each 8 minute period of discussion we had two or three tables present their ideas using hand-help microphones we had available.  There were some great ideas (Part 2).

The size of the room was great for discussion purposes and Microsoft really spent quite a bit of time thinking of how this session format would work to reflect the community meetup feel.  We were, I think, the only room that had it’s own permanent snack station for attendees.  We had a Microsoft Surface Hub provided for which I used it to host the OneNote notebook so we could see progress being made and we had great technical support in the room at all times.

Part 2 –  The Results

After Ignite–Bots and Brains Meetup–Part 2, the Results

So, we have discussed what exactly a Community Meetup session at Microsoft Ignite is in Part 1.  Please feel free to have a read through to see what we did and how we did it.  This entry is to discuss the results of that session at Ignite.  During the session multiple groups of people came up with some great talking points on the three main topics covered concerning the Microsoft Bot Framework and Cognitive Services.  We discussed what I thought were three of the main points in creating bots using the Microsoft Bot Framework.  The three topics were, for the most part, focused around how Microsoft Cognitive Services could help.  We discussed user frustration when using bots, what were and were not problems that could be solved with a bot application and lastly how to make bots more inclusive to all people.

We had 10 tables of 6 people and, at least for the first topic, we had recorded responses from twelve distinct teams including one of my favorites “the Wall” team which consisted of people who were sitting in chairs along the wall that banded together to make a discussion group.  Some people along the wall chose to join existing tables for discussion.  It was great!

Most of the information below is not necessarily my opinion but that of people attending the Microsoft Ignite Community Meetup BRK2388, Bots and Brains.

Bot Frustration

The premise of this section was threefold.  How do I prevent frustration?  How do I detect frustration? and how do I resolve frustration?  All three points should be important considerations when creating a chat bot interface to an application.  Before arriving in Orlando I had some pre-conceived notions of how to detect frustration.  It was interesting how many different options the group came up with that I had not thought of.

With regards to detecting frustration there were plenty of suggestions.  Microsoft Cognitive Services provides a service called the Text Analytics API that lets you detect in a range of 0 to 100% very negative or very positive sentiment.  Another team suggested using the Language Understanding Intelligent Service or LUIS to detect curse words indicating frustration.  Outside of sentiment and curse words, suggestions were made to look for repeated questions and entities (parameters) indicating frustration at not getting a correct answer.  Overall if we consider the three main ideas above I believe we can be fairly competent at detecting most forms of frustration.

Before frustration ever happens, there are things we can do to prevent it from starting.  One group suggested using training data based on past feedback to ask leading questions to help get more accurate answers.  Some of the suggestions were beautiful in their simplicity.  For example provide the option to see a tutorial as we did for a project I worked on called the Accessibility Sport Hub or ASH.  The tutorial nicely sets expectations and suggestions on getting the most out of the bot.  It also outlines what the bot can, and just as importantly cannot do.  One of the responses seems to apply to this category as well as what to do to resolve frustration after it has occurred.  Hand the conversation off to a real person.  In the case of prevention, as soon as the bot can detect that it may not be able to resolve the inquiry, have a method of handing off the inquiry to a real person.  The bot can be the method of collecting information and a real person is used to resolve the problem that might not be addressable by the bot.

Lastly what do we do when things go badly and we have a frustrated or even angry person using our bot.  The most often repeated solution here is recognizing when human intervention is required and hand off the bot to a qualified individual for resolution.  Another suggestion by one of the “Wall” groups was to provide additional options or help when frustration is encountered.  Perhaps they don’t know what the bot is capable of and providing them the option of learning what is available might help.  Improving the feedback to the user was also suggested and this can also fall under the heading of prevention. 

Humour is something else that can be introduced.  Giving the bot a bit of a personality can help build a friendly relationship and perhaps reduce stress levels.  One caveat to consider is sometimes humour is not universal and one should be cautious that you don’t introduce more problems than you create.  One of the most popular suggestions was to use the “panic button” method of providing a way to ask for help while in the middle of the conversation.  If you provide an escape or some way to get back to the start and/or get help it might alleviate some of the frustration being created.

Bot Solutions

What makes a good bot solution?  It’s a question that isn’t asked often enough in development.  “What is the best way to do this” rather than “I know how I can do this”.  So we asked the community meetup what they thought.  It was interesting what considerations they came up with when trying to decide what sorts of applications would be best as chat bots.

One of the more interesting considerations is the target age group of the app.  As strange as it may seem different generations of people approach how they communicate in different ways.  The other one that was interesting was globalization and how bots might be better at dealing with multiple languages than many other solutions. 

Once we got past demographics there were suggestions that a solution that might require a more specific answer faster than searching Bing or Google might find a directed bot conversation more useful.  Also the ability to handle difficulties interactively would be helpful.  A bot would be useful at connecting people to internal data repositories like information on employment, HR and general inquiries would be ideal for a bot. 

Under the “not so useful” category, several tables/groups suggested that an “advice” type application might not be so useful as pure chat bots.  For example, providing legal or medical advice might have moral and legal barriers where the repercussions of providing improper or incorrect information are significant.  For example, we probably don’t want bots handling 911 calls at this time. Although, a hybrid solution where a bot collects basic information and then hands off the session to a human might be reasonable in some cases.

Lots of groups felt that bots are not very helpful for very complex needs.  For bots to work, somebody has to write code for the responses and depending on whether or not the path people using the bot need to follow has many branches or not could affect the effectiveness of the bot.

Inclusive Bots

This category turned out to be a bit more difficult than the others.  In many ways people feel it’s difficult to relate to the issues at hand.  However, once you consider that building an inclusive bot is not about building a bot for specific people but, instead, for all people, you can start to see ways to help in that area.  Including everybody does not mean just disabilities but also, culture, language, gender and a whole host of other variables that make people unique.

One of the items that came up is voice.  Microsoft nicely announced at Build 2017 the ability for a bot to be available as a Cortana skill basically enabling speech to text and text to speech handling so your bot doesn’t require keyboard or mouse input.  That’s a huge leap forward in usability and inclusivity.  Other items discussed were using Cognitive Services like the Computer Vision API to discern the age of a user. 

Also using images in providing information might help work around language barriers (although the Bot Framework does support many language, it might not cover all of them).  Addressing gender differences were also mentioned and here vision can help too by detecting gender using the Computer Vision API.

To Wrap it Up

Privacy was not mentioned and I think we always need to be aware of people’s privacy.  When we use various Cognitive Services we should always make sure we have permission where necessary to provide people with the choice.

Overall, it was quite remarkable how many different opinions and ideas came out of our room of just 85 people.  Everybody stayed right to the end to make sure they got their voice heard.  The OneNote notebook is available to those that attended my session and you can view it too if you wish.  Also, join the conversation at at the Microsoft Tech Community!

I hope that everybody got something out the session.  Maybe met a like minded person, found some information from myself or others in the room that might help in decision making over bots and AI or just generally enjoyed the break from the traditional session.  I thank all the attendees and hope that I have the opportunity to do it again next year.

Wednesday, 19 October 2016

Talking about Bots – Setting it up

Have you thought about using the Microsoft Bot Framework?  I have!  If you’ve ever wondered, I’m going to try and give you a hand up by pointing you in the right direction.  Maybe give you a few tips along the way and help clarify a few things along the path.

Getting Started

connector-getstarted-create-projectYour first step is to install the Bot Framework Template into your Visual Studio (I’m assuming you have Visual Studio installed already).  I guess the first step is to decide what language you are going to build in.  Because I am a Windows Platform sort of guy, I’m going to use C#, if you are too then it will make this a lot easier to follow along.  You can find the “Getting Started” page with the links at https://docs.botframework.com/en-us/csharp/builder/sdkreference/gettingstarted.html but you can directly download the template from here.  When you look at the getting started document, it does give you most of what you need to get going but ultimately you are going to have to connect a few dots and turn on a few lightbulbs on to get to where you want to go.  Once you have downloaded the template and created your first project, come back here for next steps (not in the above doc)

Creating Your Bot App

Your next step requires you to create a Bot in the Bot Framework.  You are going to have to modify a couple of things in your just created Bot Framework app in Visual Studio based on what you do here.  First, go to http://dev.botframework.com.  You will need to have a Microsoft Id to successful complete this next task.  Click on “Register a bot” to get started.  Don’t worry if you don’t know everything, you can fake it a little bit until you do some other stuff later.  You need to know your bot name and bot handle.  You can makeup stuff here.  You will need to create a BotWebConfigMicrosoft App ID and password, but they nicely give you a button you can press to do that.  Make a note of the App ID and password because you’ll need those in the Web.config file of your bot application.  For the publisher profile, you can fill in most of the URLs with placeholders, but you will need to provide those before going live in any way.  In your Web.config, put the id and password as you see in this picture.  There are security issues with putting ids and passwords in your Web.config but for just playing around locally on your system, its not a problem and security is not part of this post.

Testing Your Bot Locally

Bot EmulatorYou need to install the Microsoft Bot Framework Channel Emulator.  It won’t look as pretty but it will let you see what is going on.  Once you have installed this little emulator, go ahead and start the app in Visual Studio.  This should launch a browser (you can choose which one), make note of the port # in the URL that is loaded.  Now open the emulator and change the “Bot Url” to match the port number above.  Don’t change anything else.  Lastly, paste in the App Id and App Password and you should be good to go.
In Visual Studio, open the “MessagesController.cs” file and put a breakpoint on line 22 (inside the “Post” method.  Now go back to the emulator and Type “Hello” into the message space and hit enter.  You can now step through how the bot responds to the question (it just parrots back what you said with a char count).  Now you can start seriously thinking about what smarts you want to add to your bot using whatever AI you can think of.

Ready for More?

Now that you have a (somewhat) stupid bot, what do you do?  Well, you’ll need to deploy it to an Azure App Service or some other web site if you want the public to get access to it.  You’ll also need to add some brains to it.  Like what happens when somebody says hello.  You know, add a little personality to the game.  More on that in future blogs.

Monday, 17 October 2016

Developer Life Saving 101: Survival Training with Visual Studio Team Service

As discussed in a previous post, disaster can strike at anytime.  Most companies think about things such as protecting documents, insurance for property, fire safety procedures, and other physical protections.  But what do you do about software assets.  Does your company create software?  Even non-software companies often create software.  In-house IT departments will often have utilities and other little bits of code that are really useful in keeping a company operating smoothly and most employees and executives of the company may not even know its being used. 

When Disaster Strikes

My company develops software for ourselves (Windows Store) and for our customers.  Microsoft’s partner program is flexible enough for not only larger Fortune 500 companies to partner with them but also small software consulting firms like ours and everybody can win.  One of the great features of the partner program for us is our Microsoft Action Pack Subscription that provides us countless benefits but the one I want to focus on today is the Visual Studio Team Services (VSTS) account.

Let me go back a bit in time to October 2013 when a fire broke out in the same city block as our office.  The fire was devastating, wiping out half of a city block with buildings dating back as far as 1909.  I was told by some of the firefighters that the temperature at the heart of the blaze was almost 2,700 degrees (does it really matter if it’s Celsius or Fahrenheit?) and steel light poles across the street were melted. Our building, housing our primary offices, were just one building and a good strong wind away from being destroyed.  There was nothing we could do about it at the time… There was, however, something we could do in advance and we did it, have you?

Peace of Mind and Better Software

GitFirst and foremost, as stated previously, was the fact that our vast investment in software development was 100% protected in VSTS, either in Git or Team Foundation Version Control.  A lot of our legacy software was developed using Visual SourceSafe (VSS) which was migrated to Team Foundation Server (TFS) (on-premise) and then up into the cloud with Team Foundation Version Control (TFVC). If you have any combination of Source Control that uses VSS or TFS then migration is pretty painless.  We did it in a day (for four developers).  However, newer product development is now taking advantage of Microsoft’s implementation of Git source control.  Did you know you can run both simultaneously? Git provides a robust team environment for development, when implemented properly and with reasonable processes adhered to by developers. 

Of course, just storing your source code in the cloud isn’t going to get you better software.  It might save your existing software or allow your development team to work remotely should inconveniences occur like a power outage at the office or hardware failure for some reason, but you need tools to help with your process to really make gains in quality that go beyond just hiring great developers.

In my opinion the two best features that improved our software quality and the speed of software delivery are the integrated Testing Tools and Continuous Integration.  Of course, there are lots of other great features including Agile Tools, integrated DevOps and lots more. 

Test, Test and Test Again

testQuality starts at the beginning and begins with the developer.  However, how do you know that your software is solid.  One of the things we teach is to develop unit and UX testing at the same time as the actual software development.  No commits without at least a corresponding unit test being included, which sometimes takes quite a bit of willpower.  That’s great for the developer testing his stuff but how do you know the quality of a commit into your system.  Easy, with VSTS I setup my commit process to force a rerun of all tests when a commit is made on a branch before a Pull Request can be created to merge that branch into the parent.  This essentially puts a double check in place that the code created was of high quality.  Of course, this is dependent on the developers creating the tests in the first place, so test creating must become part of your culture of development.  If I’m creating websites, I can also implement load testing.  Having those tests run in VSTS is just one part of Continuous Integration (CI) that you really want to investigate thoroughly.

Round and Round We Go

VSTSContinuous Integration is part of combination of a whole host of tools available to the developer and to the process of software delivery.  You can have build agents in the cloud automatically build your application with new commits.  Results are provided in an extensive report that tells you if anything went wrong, what work items are included and any code changes and test results you may have.

I had the opportunity to work with some students on a team project.  The Continuous Integration allowed the team to commit bug fixes and new features without worrying about breaking the master build.  No Pull Requests into the dev or master branch were permitted without a new build being completed successfully.  CI did the work automatically.  Nobody had to “remember” to get it done.  On top of the build, CI also executed and reported on all the tests in the software so full regression testing of every committed bit of code was done.

Once all the tests were passed and a Pull Request was completed into the dev branch, CI automatically published the app for our dev team to try out and then when it was rolled to the “staging” branch it rolled out to our customer for review, again automatically, providing very fast turnaround for updates.

We have a pulse

This has all been a great benefit of our partnership with Microsoft.  We are able to deliver higher quality software with less work.  Continuous Integration along with writing and adding tests to our solutions as we go has created an environment where we can deliver great software.  Moreover, with cloud based source control all integrated together we are relatively well inoculated against disaster or just annoying inconvenience.

Tuesday, 11 October 2016

Pick a Platform, any Platform – The Prestige

The last stage of any magic trick is “The Prestige”.  In illusionist terms it means we make the rabbit reappear after making it disappear, or the tiger or the lovely assistant.  In our case we are going to take use Visual Studio to do more than just create an app or application for the Windows Platform.  We are going to do so much more.  We will take an existing Windows Phone 8.0 Silverlight app and convert it into a Xamarin App allowing us to publish not only a UWP app but also an Android one and an iOS app.  I must admit I don’t know where I’ll go with this as I have not tried this before.  What follows is what I did, how I did it, and where I messed up (fingers crossed).

Part 1: The Pledge

Part 2: The Turn

Create a new Application

SquarePegWP80Rather than take my existing project and try to change it, it made a lot more sense to start with a brand new Xamarin App and layer in the code.  To do this, I opened the old WP8.0 app in Visual Studio then opened a new instance of Visual Studio for my masterpiece.  To make my life simpler and to reduce the amount of the learning curve I’m going to start with a Xamarin Forms app.  This relieves me of the need to learn pretty much anything about Android and Apple UX development.  You may need to install the Xamarin Development AddXamarinToVS2015Tools (They are typically not installed by default in VS2015).  If you use Windows 10, right click on the Start button and select “Programs and Features”.  Find Visual Studio 2015 and click “Change”.  Scroll down until you find “Cross Platform Mobile Development” and check the “C#/.NET Xamarin” one and click “Next”.  This will get you the tools you need.  You need a bit of disk space to make it happen and it will take a bit of time to install but it’s very easy to do.

To create a new Xamarin Forms application

  1. NewProjectopen Visual Studio 2015
  2. click “New Project” in the start page
  3. Expand Templates/Visual C# and Click “Cross-Platform”
  4. Select “Blank App (Xamarin.Forms Shared)” and Click OK

If you choose to create the UI part of your app in Native, simply select the (Native Portable/Shared) project templates.  For our purposes though we want to keep it as generic as possible with a single UI across all platforms so we will used Portable.

Making Our App

I’m not going to go too deep into this part of the process at this time.  There are some basic things you need to know about Xamarin Forms though.  First, always remember that Xamarin Forms are NOT UWP XAML in the traditional sense.  You need to substitute the new Xamarin Forms control for something you might use in UWP XAML.  For example instead of <TextBlock/> you might use <Label/>.  The properties will be subtly different too.  Instead of a Foreground property in Label you need to use the TextColor.

These small changes could be frustrating in the beginning but most things you do in XAML you can do in Xamarin Forms and the big win is that when the app is compiled for the various platforms the Xamarin Forms controls will be compiled into their equivalent native controls for that format.  So, you end up with native apps for all the platforms but only had to create one UI.  This is a big win in my mind.

To get in-depth knowledge on Xamarin Forms controls and just about everything else you can think of to do with Xamarin.Forms, download a free copy of Charles Petzold’s book “Creating Mobile Apps with Xamarin.Forms”.

SetImageAnother gotcha I encountered was with images.  When binding or trying to reference images, you have to be very conscious of the different platforms and resolutions.  Furthermore, you need to put the images you will be using in each of the platform projects rather than the shared/portable project included.  Each platform has it’s idiosyncrasies and you need to account for those.  The Xamarin web site for developers very nicely describes the issues with images.   The code is fairly simple once you know.

One other item that I missed was that Radio Buttons are not a “thing” on all platforms.  You need to think of something else if you truly want this to be cross platform.  You COULD do it but then would not look “native” on at least one of the platforms.  I used a <Picker/> for my home page.  Below is what it looks like in UWP.  Please refrain from design commentary.  I didn’t do much of that here.  This is strictly a move from plain Windows Phone 8.0 to Xamarin UWP/iOS/Android and it turned out ok.

homepage

More to come

While this concludes the magic trick, it by no means is the end.  I plan on completing this app and testing on iOS and Android.  To this point, everything I’ve done works on all three major platforms.  I still have to build the game play and the “Help” pages.  I now know that it’s not as simple as copy and paste but far easier than a complete rewrite.  I, at least, have the framework of what and where everything should go.  I know which controls work and which do not.  I know what WP80 control translates to what Xamarin.Forms control.  The rest is a walk in the park.

Tuesday, 4 October 2016

Pick a Platform, any Platform – The Turn

Continuing on from our initial foray into creating an analogy between magic and development as outlined in our previous blog on “The Pledge”, in this post we want to cover the first part of the real magic.  We’ve already established (I hope) that Visual Studio is a great, maybe even the best, tool for developers.  We know we can write code fairly easily and create software of all different shapes and sizes for the Windows Platform.  But what about the magic?  For those of us old school developers who started in Visual Basic before it was even part of Visual Studio or even newer developers that see “Visual Studio” and only think “Software for Microsoft Windows” today’s post is for you.  We want to roll up our sleeves, show you that we have nothing under there and describe a little magic with Visual Studio.

Part 1 – The Pledge

Part 3 – The Prestige

The Turn

So, if you will watch my hands (at no time will my fingers leave my hands) you will see that using just Visual Studio I can now create, deploy and debug apps on Windows (no surprise there) and Android.  With a little help I can now create, deploy and debug apps on iOS and macOS as well.  With just a few magic words (written in the mystical language of C#) you can do it too!

Xamarin

The magic wand is Xamarin.  It is the tool that allows us to create multi-platform apps all with Visual Studio on a Windows device.  You aren’t creating some sort of HTML app that runs on all the platform, you are creating native apps with native user interfaces for all the platforms.  You have lots of ways you can create the magic too so the show should never get boring.  For the most part there is little to nothing else you need except in the case of iOS.  For that you need to have a macOS device of some sort (MacBook or MacMini will work) to do the compile.  However, it’s important to note that although the Mac is sitting there doing it’s job you are still writing the software, testing and debugging right on your Windows device, even for iOS…
The first thing you need to do is make sure you have Visual Studio 2015 installed.  Any edition will do.  The next step is to install Xamarin.  Another great thing is you can get started on this for nothing.  You can combine Visual Studio community edition with Xamarin and they are both free.

Platforms

With Xamarin you develop in multiple ways depending on your preference and needs.  A good majority of any code you might write is re-usable across all the platforms.  And you can write it all in C#.  In fact, in most instances you will find that doing the code in C# is easier than Objective-C, Swift and Java.  Things like Asynchronous programming are just easier with C#’s built in language level support.  Inside Visual Studio you can do your code behind using C# but still creating your UI using storyboards for iOS and XML for your Java and of course XAML for Windows.  Or, you can use Xamarin Forms and really bump up your re-usable code.  I attended a workshop a short while ago where we built an app in the space of a couple of hours using Xamarin Forms with a little help from James Montemagno, Principal Program Manger at Xamarin/Microsoft. Xamarin Forms uses XAML to design the UX but when you build the app for the different platform Xamarin translates all that work into native controls and apps so you don’t have a layered common generic app but rather an actual Native app with access to Native APIs.

My Breakthrough

I have written a lot of apps for the Windows Platform.  At last count it was over 80 apps.  But I have never written an iOS or Android app.  Being a .NET developer I just didn’t have the time to get up to speed on those platforms and still maintain my edge in .NET.  Xamarin destroys that wall and lets me look at my existing apps in a new light.  There is now no need for me to make that decision.  I can take existing apps and with a minimal amount of work prepare them for distribution on iOS and Android.  To me that is the real magic.  I have played around with XCode and Objective-C but to get the quality I expected was just not easy.  This removes that barrier and lets me move forward. 

Next Up – The Prestige

Now that we have shown Visual Studio to be both “normal” and magical I need to make the assistance re-appear, the Rabbit to disappear.  I need to conclude the magic trick.  To do that I’m going to take one of my existing apps written for Windows Phone 8.1 and move it to UWP/iOS/Android and document the experience.  Hold tight for the Prestige.  I’ll try to keep the language not too offensive and will hopefully help you experience the magic too!

Friday, 30 September 2016

Pick a Platform, any Platform – The Pledge

I am unashamedly a fan of the magicians Penn and Teller.  I most especially love the fact that I will laugh out loud during their performance and I end up just feeling great afterwards.  Today’s topic is sort of like one of their magic tricks.  Bare with me, while the analogy might be a bit loose I think it holds a wee bit of truth at least.

The build up to the big trick is sometimes long, takes a bit of explaining, usually involves some sort of peril for one of the participants and has a great payoff in the end that makes you happy and the audience will cheer.  So the following the analogy means that in creating an app, any app requires a bit of time for prep and planning.  You sometimes don’t know if you will be successful (the peril bit) and when you ship; it just feels good.  In some instances you might laugh (or cry I suppose) and the audience (users) will hopefully cheer.  I should add that the magic trick takes hours and hours of practice with the result being failure a whole bunch of times, so don’t give up, keep working on it and your audience will thank you.

Christopher Priest wrote a book called “The Prestige” which was made into a movie in 2006 about a couple of 19th century illusionists.  In the book he described the three parts of a magic trick, the pledge, the turn and finally the payoff, the prestige.  We are going to try really hard to relate development to these steps (in a slightly twisted analogy).

The first part, “The Pledge” is where the magician shows something ordinary: a deck of cards, a bird, etc.  The magician then gets the audience to inspect that ordinary thing, unaltered and real in all aspects.  The second part called “The Turn” is where the magician takes that ordinary object and makes it do something extraordinary.  You, the audience, are looking for the secret but you won’t find it.  Mostly, you won’t find it because you don’t really want to know.  You want to be fooled or in our case amazed. The last stage is “The Prestige” because just making something disappear is not enough, you have to bring it back too.  (paraphrased from “The Prestige” by Christopher Priest)

In these blog posts I hope to cover all three stages as they apply to app development beginning with “The Pledge”.

Part 2 – The Turn

Part 3 – The Prestige

The Pledge

The first part of our trick today is to show you something ordinary.  In a trick it might be a deck of cards or a bird or something like that.  In our tale it’s going to be Visual Studio 2015.  You can look at it all you like and of course it looks quite ordinary.  It’s probably not, but it seems so.

I have a big affinity for Visual Studio (VS).  I have used other tools from command line text editors (you vi fans know who you are) to notepad to open source tools like Eclipse.  None, absolutely none have performed for me the way that VS has.  Each new iteration has brought new productivity gains.  Each new thing I learn makes me a better developer.  Is it perfect?  Of course not, but then we wouldn’t need new versions every couple of years adding the features we sometimes didn’t even know we needed then wonder how we lived without.  Visual Studio “15” Preview 4 is out as of this writing and it looks pretty cool to me. 

Back to Visual Studio and showing off “The Pledge”.  You would think it looks like just an ordinary IDE used to build great Windows Software for the Enterprise, the Windows Store, your mom or just something to make your own life easier and it is.

Here are a couple of features of Visual Studio I find very compelling.  There are dozens more but I had to start somewhere.

Git

changesvscommitsI have “discovered” Visual Studio’s integration with Git source control.  I must admit that I was not a big fan of git in the beginning but I’m completely sold now.  I like a command line as much as the next geek but only a command line got to me.  With the git integration in VS I can do most of what I want inside the IDE now.  Branch management, commits, synchronization, pulls, pushes and even pull requests can all be done inside the team explorer that was once reserved for Team Foundation Services (TFS).  Working solo or in a team is now so much better.  This would be a good time to mention that Visual Studio Team Services (VSTS) will support TFS and Git source control.  Look for more info on VSTS in coming posts with regards to DevOps, Continuous Integration (CI), automated testing and publishing.

CodeLens

CodeLens1CodeLens was around in earlier version of Visual Studio but only for the Ultimate Edition.  Visual Studio 2015 brought it to the common man, aka most developers.  It offers developers a quick glimpse into not only the usage of a particular method or property but also its history.  Should you work in a team, it also provides a way of seeing who last modified the bit of code you are working on.  This is so unbelievably helpful, I love it.

CodeLens2To view references, or places where this method is called, click on the first section of the information just above the method name.  It will provide you with a list where this method is called.  Hover over the lines and it will display some context around the call.  Double click on the line of code and you will be taken to that code where you can edit it as necessary.  This feature is great on it’s own but combine with the other 2 sections (should you be using source control).

CodeLens3The second part of the CodeLens gives you a bit of a history lesson showing changes committed over time.  You can see who made changes, when they made them and get a feel for how dynamic this particular method is.  In the sample here we can see that no changes were made for more than a year then it was updated.  It’s useful information that provides a time perspective.

CodeLens4The last section gives you a more exact list of changes and gives you a way of seeing exactly what changed, when it changed and who did the change.  Tap the “Show all file changes” and see a complete history of this particular method.  Double tap any of the lines shown and a “Compare” is shown of that particular commit against the current code.  I can’t tell you how many times I use this feature, especially the first one while actively coding.  If there are 0 references it also gives you a quick idea of what methods or properties are probably deprecated and no longer used.

Next Up – The Turn

Clearly Visual Studio is more than just the simple object dictated by “The Pledge” but we hope you see that it’s not magical (wink wink) in the sense of how we are applying the analogy today.  VS is a great tool for creating Windows/Web applications.

My next post will demonstrate “The Turn” or a bit of magic if you like.  How we can use Visual Studio to do more than you expect.