The Developers Road is a brand new podcast that I just launched and it has a single goal, to help developers find the next version of their careers. Why start a new podcast? How is it going to help your career? Great questions…

Over the last couple of decades, my career has had many twist and turns. Almost like a long winding road. (I know, subtle)

Having had the opportunity to meet and talk with countless developers over the years, I’ve found myself in conversations about careers more often than not. It’s an interesting conversation to have, because no two people seem to have the same journey. I started formulating the idea of a new show a while back that would focus and explore people’s different career paths.

Given the year and how full of uncertainty it has been, I decided that now seemed like a good time to start having this conversation in a public format. Thus, The Developers Road podcast was born.

While I have many plans for the types of content that the podcast will include, I wanted to launch with a series of interviews with some of the leaders in the industry. These interviews, while always talking the latest tech or reminiscing on days past, would focus on the guest’s careers.

I wanted to know what their journey was like…

What things worked for them and what things didn’t?

What things they were focusing on for the next phase of their careers?

What advice did they have for those in the industry?

To sum it up, the first phase of The Developers Road is it celebrate and highlight the vast array of opportunities that developers have in building their careers.

As of the time that I am writing this, I have recorded over a dozen episodes and the first batch are live. Over the interviews I’ve been blown away. These guests have been amazing and it’s incredible to listen to their stories and to learn from them.

Please head over to https://developersroad.com to get connected with the podcast. You can also find the podcast on all of the major platforms.

If you have any thoughts, ideas, or would want to be on the developers road, leave a comment below.

Until then… I’ll see you down the developers road…

I love Build. It’s a great conference that always has some great energy, amazing people, and a ton awesome conversations. This year I was given the opportunity to speak on Building UWP apps for Multiple Devices.

The talk was a lot of fun, with the notable exception of having to haul all of those devices around (exercise, we will call it exercise). I have some follow up content on the talk coming soon, but for now you can check out the demos for the talk at https://github.com/TonyChampion/MultiDeviceDemos

Thanks for everyone who came out to the talk and a special thanks for those you stuck around to chat after. That is always my favorite part of the any session.

Be back soon… Now, time to decompress…

It’s been a few years, but I have a new article published in this month’s MSDN Magazine. This article looks at using the Remote Systems API from Project Rome in UWP apps. If you haven’t looked into this piece of Project Rome / Graph, then this article will be a great introduction.

In addition to the article, I have a new app that will be launching soon as open source. Make sure you check back soon for more information on that.

Article

Universal Windows Platform – Building Connected Apps with UWP and Project Rome

So I took a look at the project, rolled up my sleeves, and prepared for the 4 or 5 hours it would take me to migrate the app. HA!

Here is how things went. I went thru the app making some notes and coming up with a few ideas of what I wanted to do a little different. My first thought was, hey, I bet WordPress has some sort of API that I can use to pull data from and I can eliminate the custom plug-in. As luck would have it, there was. Perfect! This is going easier than I thought…

I guess no one ever thought about writing a nice little portable library to wrap the WordPress API. No worries, we can make one. Now all we need is a nice little library that handles XMLRPC communication in a portable library. Hmm, there isn’t one of those either. So, guess who now decides he “needs” to create libraries to address both of these needs? Yep. Oh the rabbit holes you will go down as a developer sometimes.

You can find both of these projects on GitHub and Nuget:

XMLRPC for Universal Apps

A client library for accessing XMLRPC servers from UWP apps.
Nuget
Github

WordPress for Universal Apps

A client library for accessing WordPress site via XMLRPC from UWP apps.
Nuget
Github

Now that we got that out of the way, it’s time we got back to the original “simple” port I was going to do. Well, after learning about all of the cool things the WordPress API could do, the list of features in the Starter Kit kept growing. To add to that, I wanted to throw in some adaptive design so that app would run on Windows Phone as well as the desktop. That meant it was time to call it, and start from File > New.

The result is a new WordPress UWP Starter Kit which can be found here: https://github.com/TonyChampion/wordpress.uwp.starter.kit

Getting the Starter Kit up and running with your blog is a simple matter up updating App.xaml with your blog information. The WordPress API does require credentials for most operations, so you will need to supply a valid user account. The information you need is the url to your blog, username, password, and blog Id. In nearly all cases, your blog Id should be set to 1 unless you are running multiple blogs off of the same database.

The solution consists of 4 views: a home screen / dashboard, a category list, a list of posts filtered by category, and a post view page. Through the use of state triggers and adaptive design the app handles resizing fairly well. While this is definitely not a polished final project, if you are interested in building a WordPress app or just curious on how a data driven app could be built, go have a look at the Starter Kit on GitHub. I have a version for this blog that is being wrapped up and I will post here when it’s available.

If you do decide to build your own WordPress app, drop me a line. I’d love to see how the final product turns out!

It’s been a long couple of years for Windows developers. Most of the Windows developers that I know have hunkered (yep, I’m from Texas) down in their projects using existing techs like WPF to weather the storm. There was very little interest, if any really, in learning about WinRT apps in Windows 8 and Windows Phone 8. Enterprise interest? Forget about it. No one was really paying attention and the proof was everywhere. Long running popular blogs dried up over night, you were pretty much guaranteed to have the lowest session attendance at a conference if you gave a WinRT talk, and talks of WinRT projects practically didn’t exist. Heck the Windows 8 developer booth at TechED the year of the release was a ghost town (longest booth duty I’ve ever had to do).

Now to be honest, I liked Windows 8. I even liked the Start Screen. With live tiles, it gave me a great way to organize my apps and I never really saw why we needed a button on the screen when my Windows button on the keyboard worked perfectly well. To this day, my daughter won’t let me upgrade her computer because she likes the UI better the Windows 10. But maybe she get’s her stubbornness from her mother (not hardly, but this is my blog so we will pretend for the moment).

Here at the end of 2015, Windows 8 is now the past and Windows 10 is here. Since the insider program cranked up early this year I have been keeping a close eye on the OS and the development experience. Sure, there has been some growing pains along the way, which is probably a good reason not to run early bits on your daily machine (not that I know from experience or anything). Windows 10 is great. I think it blends the best of Windows 7 and Windows 8, and the performance has been there. That doesn’t even consider the monumental task of bringing all of Microsoft’s platforms under the same OS. On that feat alone, the team gets my admiration.

But my state of the union is not about the OS, it’s about Windows apps. Or UWP apps, or universal Windows apps, or any of the half of dozen names that have been thrown around over the last year. I’ve seen Microsoft’s official naming even change a couple of times. Regardless of the name, UWP apps are nothing more than the next generation of WinRT apps. In fact, most of the runtime errors you get from a UWP app still reference WinRT. However I digress, the question remains, are UWP apps worth looking into for your future projects…

The Good…

In spite of being fairly worn out, I’m in a good mood so let’s start with the good news first. UWP apps offer a lot for developers. For developers writing consumer apps, the store is a great way to get your app out there. Now the store experience isn’t perfect, but for indie developers to small shops to fortune 100 companies, you can’t beat the ease of deploying to your potential customers using the store.

Remember we are running on a single platform now (or will be over the next several months as other platforms roll out Windows 10)? That also means a single store. Now you are able to write a single app and deliver to users whether they are running on a desktop, tablet, phone, Xbox One, or even an IoT device. The potentials are limitless.

The language support is really solid. XAML dev? HTML/Javascript dev? IOS dev? You can use those skills to build native UWP apps to run across all of those same platforms discussed earlier.  Microsoft is making a solid effort to open up UWP apps to as many developers as possible.

If you have been around my blog long enough, you know that I am a Silverlight guy. And yes, there was a toast to Silverlight again this year at the Summit. One of the things that came over to UWP from Silverlight is concept of sand boxing. While it’s not always perfect, I like the security and control as a user that I have over apps installed on my system. I like not having to worry about a UWP app causing any trouble on my system. Each UWP exist in their own little world. They can’t start adding a ton of registry entries, install random DLLs in my Windows or System directory, and they for sure aren’t going to drop a trojan in some remote part of my file system. While sand boxing might not be perfect for every app, I would argue that it works for the large majority of apps out there.

The Bad…

I could probably nit pick this section to death, but the majority of items that would end up here all come from the same cause: UWP/WinRT is still young. When the team started on WinRT they had an interesting situation that doesn’t happen all that often. This was a brand new type of application and as such, there was no need for backwards compatibility. Now think about that. Even if you have never written an API or SDK, think about the projects you have written. In most cases, your apps have to always support existing functionality. Even if it would be better to start from scratch, you still have users who expect and demand that the way they have always done something still work with your latest and greatest code. This puts a lot of limitations on what developers are able to accomplish. When looking at that same demand from a SDK perspective, the constraints are magnified by an order of magnitude.

WinRT apps didn’t have those constraints. The WinRT team had a clean slate. This lead to things like a reorg of long existing namespaces, new methodologies like async calls, and removing legacy code that no longer made sense. However, this also meant that restructuring and rewriting of code was a ton of work and left a ton of decisions to be made about what was and wasn’t a necessity. Alas, there were a lot of things that were simply left off of the table. XAML features that were available in WPF and Silverlight were found missing in WinRT. .NET features like reflection were stripped down versions of their predecessors. There were just plenty of things that were missing whether intentionally or the team just didn’t get around to it.

Jump ahead to UWP and where are we at? Well, performance is the key difference between UWP and WinRT. Teams inside of Microsoft decided to eat their own dog food and started building UWP apps for Windows 10 and other products and thus there was a lot of pressure on the UWP team to make sure that the existing WinRT SDK worked well. Of course, this left little room for new features. Don’t get me wrong, there were some much needed additions to the platform, the introduction of new controls, and a decent job of merging the controls/code base for Windows Phone and Windows. It’s just with all of these requirements, you didn’t really see the maturity jump in the platform you would of expected in it’s second major release (or at least I didn’t). As with all things though, it comes down to a factor of time and money.

The Ugly…

Now, I’m going to try my best to not get on a soap box here, but there is one aspect of UWP apps that still rubs me the wrong way. The deployment story for UWP apps leaves a lot to be desired. True, it’s an improvement over the WinRT story, but so far I have been disappointed in the UWP deployment story. If you want to build an app, put it in the store, and let users install it on their machines, then it works just fine. Sure, from a store dashboard and reporting standpoint things could get better, but overall it works. What happens if you are in an enterprise? Well, if it’s large enough then you probably already have a MDM solution that you can use to manage apps. This is a great solution, especially for IT departments with a huge demand on their time and resources.

What if you are running a 15 man shop? MDM is overkill and is costly. In fact, WinRT was the first time in Windows history that it cost to install a Windows app (or application) onto a device. That had simply never been the case before. Thankfully, Windows 10 no longer has the side load licensing restrictions that Windows 8 had (I’d still love to hear why someone thought that was a good idea). However, sideloading apps onto a Windows 10 device is still more trouble than it is worth in a lot of cases. In my opinion, until this story changes, developers will always look at UWP through skeptical eyes.

The Future…

So where does that leave us? We aren’t where I thought we would be by now, but different priorities prevailed and the results were all positive gains, if just not where I would of liked them to be. But is it enough to warrant me to tell you to embrace UWP apps?

Well I can tell you that I made my way to Redmond a little skeptical this year. Then I sat through two days (wish it was four) of sessions from different members of different teams within Windows. And while I might still be a little skeptical, these are my impressions of the future…

Number one, the teams are listening. Every person that presented, every person that I met, all had the same goal, they wanted to hear our feedback and our thoughts and opinions on the present and the future. They cared, because they understand who their user base is. That is the developer out there trying to create amazing experiences for their users. With very little exceptions, they seem to have a good grasp on our pain points and the things we wished were improved.

Does this mean that UWP is going to be the most amazing platform tomorrow, next week, or next month? Not really. But I truly feel that it is on the right path. And while I’m sure things won’t move as fast as we all would like, they are moving in the right direction.

I’m excited to see what the various teams release over the next several updates to Windows 10. The next year should be interesting and I for one am starting to get more excited about UWP apps and their future.

State of the Union

So what is the state of Windows apps, from a developer who isn’t in any authority to give one?

Windows apps will be just fine. They are young and as such have the same pain points any young tech has. But there is a solid team behind the product that really cares about getting it right and are working hard to provide a platform that we developers will be proud of. Now that doesn’t mean we will ever stop complaining about things (do we even know how to do that?), but it does mean that there will be solid platform in which to build and deliver amazing apps.

So here is the million dollar question: how do I know? The answer to that is simple. I have known several of these people for many years now and I know their character. These are developers, leads, and PMs, that take pride in their work and many have come from the “outside” world that we live in. They want to make a platform that not only performs well, but let’s us build apps that work the way we need them to work.

To wrap it up, the state of Windows apps is good and I’m excited about what the future will bring. And what ever the future brings, I’m sure it will be an interesting ride…

This year I presented an introduction to Windows 10 and although the demo gods frowned on me by deciding VS needed to stop working, it was a lot of fun. I’m already looking forward to next year. You can get the slide deck for the talk here.

For those of you who weren’t there, UserGroup.tv was there to record it. You can find the recording at: http://usergroup.tv/videos/developing-for-windows-10.

Thanks again HTF. See you next year…

• Roaming Data Between Windows Store Apps and Windows Phone Store Apps
• Guidelines for roaming app data
• Quickstart: Roaming app data (XAML)

In the coming days I will be releasing a starter project using these libraries in an universal app. So make sure you stay tuned for that new project.

The Nuget projects can be found at:

XMLRPC.universal: https://www.nuget.org/packages/xmlrpc.universal/

WordPressAPI.universal https://www.nuget.org/packages/wordpressapi.universal/

Currently the project supports the following commands:

• GetPosts
• GetPost
• GetComments
• GetComment
• GetTaxonomies
• GetTaxonomy
• GetTerms
• GetTerm

These were need for the project that I was porting, but I will continue to flush out the full WordPress API to support other projects that we have in the pipeline. I look forward to your feedback.

The result is a new project on GitHub: xmlrpc.universal

The project is currently functional and supports everything that is needed for my WordPress API client, which I will post on shortly. There is still some improvements to be made, Nuget packages to build, and such. However, the initial release is out for you to check out.

Please feel free to let me know if you have any issues with the library or have any features that you want added.

The project can be found at : https://github.com/TonyChampion/xmlrpc.universal