Friday, November 13, 2015

Launching my first mobile app - Kwan

I've spent the majority of my "coding free time" this past year working on an app for the Microsoft App to Cert Program. This week, I was finally able to finish it up and deploy it to the Windows Store! Huzzah!

The app is called Kwan (thank you, Rod Tidwell); it's a simple budget management tool for a household or small projects. There are more details about it on the Windows Store page if you're interested; I also created a project site for the app as well. It's still a bit rough around the edges I suppose, but I'm pretty happy with it as a first release. I have it submitted for review to the App to Cert program (which was really the impetus for creating the app in the first place), and hope to hear back about that in the not too distant future.

I also want to add that, even as a first-timer, I found the whole process of getting my app through the review and approval stages and into the store to be very quick and straightforward. I wasn't quite sure what to expect in terms of time or hurdles when I was preparing to submit; I've heard anecdotally from others or been involved in projects with other app stores where this part of the process became a real pain. However, the Windows Store was great to work with. Once you have a Developer account (it's only $19 for a personal account), you can push the app to the store right from Visual Studio with just a few clicks. The approval process for me took less than 24 hours from there. Kudos to the Windows Store team on that! I'm sure I'll get a chance to work with the Store again as post updates for Kwan, and hope I'll get the chance to build another app for the Windows Store in the not-too-distant-future.


It means love, respect, community... and the dollars too. The package. The kwan. - Rod Tidwell

Monday, September 28, 2015

Easily expose metadata information from Web API

A client recently asked me for something in their Web API project that I'd never done before - they needed a way to expose metadata information about a few specific response objects that were being returned by the API. It sounded like it would be an easy task, but after spending a couple of hours at the Googler, I really didn't find any examples on that specific topic using the description above.

I was fortunate to eventually stumble across a good start to the solution nested within this article on OData basics while investigating a completely unrelated topic. Seeing as it was kind of challenging for me to find, I thought I'd take the time to document it. Before I launch into the solution though, I just want to clarify one point - I did not want to build OData routes in the API for this project. I simply want to expose metadata information for some of the existing response objects it was already providing.

With that being said, here's what I came up with to meet the request:

Part 1 - Modify the WebApiConfig.cs file to include "routes" for each object for which you want to expose metadata information.

This actually turned out to be easier than I had anticipated ... once I'd found a solution in the above article. It only required adding about half a dozen lines of code to the WebApiConfig.cs file to create an EDMX model builder function and define which objects to pass through it:

Simple as that; metadata routes are now available. So now that I had the routes I needed, how could I let requesters know that metadata information about the response objects is available, and where they could go to find it? Why, add the new metadata URLs to the response objects, of course!

Part 2 - Create a Controller to represent the metadata routes and use Hyprlinkr to expose them.

Create a new Controller in your project, and name it using whatever URI you used in the WebApiConfig declarations you added in Step 1 (in my case, this would be "EntitiesController"). It is very important that you keep the name the same here. You do not need to modify this file at all; it's simply an anchor for the dynamic links we're going to be creating with Hyprlinkr.

As stated on the Hyprlinkr project's GitHub page, "... it creates URIs according to the application's route configuration in a type-safe manner.". This little guy is great for dynamically discovering URIs that can be sent back as string properties of the response objects. This means regardless of which environment or location you deploy to (dev, prod, test, cloud, etc.), the metadata URIs will always be correct - HyprLinkr will discover them for you automatically.

There are two remaining steps to complete for each of your response objects:

  1. Add a property to your response object to store the metadata URI. I went literal and called mine "metadataUri", but feel free to name it however you see fit.
  2. Add code wherever you're building your response objects to populate the new field. Hyprlinkr makes this easy; it's just one extra line:
    SomeClass.metadataUri = (
    this.Url.GetLink(x => x.Get()).ToString() + "/SomeClass/$metadata"
    );

Not a very straightforward solution, but I'm really happy with the result, and will definitely be able to reuse the idea for future API projects. I think it's a nice & simple addition to the documentation for any public-facing API.

Friday, May 8, 2015

Exploring TypeScript and what makes it sweet

I've been watching the TypeScript project for a little over a year now, since the 1.0 release. The concept really interested me, but as is the case with many new language conventions, I wasn't sure whether or not it would catch on. However, the recent announcement that Typescript would be used to build AngularJS 2.0 gave me confidence that TypeScript was legit and here to stay. I decided it was time to start a little sample project (posted below) and explore.

While building said project and preparing to write this post, I came across quite a few "Introduction to TypeScript" articles. This is not intended to be one of those articles. They have their place, to be sure, and I used a number of them to get started on my journey. However, I want to take a different angle - I want to pose back to you, and answer, the same questions that were in my head when I started watching the TypeScript project:

  • Why should you use TypeScript in your next web or mobile project?
  • What makes TypeScript sweet - meaning how will it make your job easier and your project better?
  • Essentially, how does it put the sugar in your java[script]? (sorry, I had to)

Here's what I liked about TypeScript:

TypeScript creates better JavaScript than I do.

I'm not ashamed to admit it. I didn't have to do much with JavaScript early on in my career during the Web 1.0 days, and eventually started working with it through jQuery. TypeScript similarly helps to bridge that gap; you still need to know how to write and work with JavaScript, but the "compiler" handles the heavy lifting, especially when it comes to converting classes into nested functions and methods into prototypes. At some point, I'd like to learn how to do that myself; for now though, I'm happy to have the help. I can write objects and classes as I would in other languages I'm more familiar with, and still get pristine JavaScript.

On that point, I'd also argue that TypeScript code is cleaner and more maintainable than raw JavaScript. Download my .ts file below, compile it, and take a look at the two files side-by-side. Which one would you rather maintain? The JavaScript version is very clean, but still - TypeScript for me, please.

TypeScript is excellent at helping you organize your code.

I think the best way to describe the state of the JavaScript code in just about every large-scale web application I've inherited or consulted on is "hodge-podge". Some of it's in the page files. Some of it's in .js files. There's duplicate code all over the place. In general, it's because the code was poorly organized, and is thus a pain to work with.

TypeScript offers the ability to create modules that really help in this area:

  • Modules work like namespaces in C#. They help to group like objects together, as well as avoid name collisions with other objects and over-saturation of the global namespace.
  • The export keyword restricts access to code outside the module, clearly defining what's intended for public consumption and what isn't. Law of Demeter, anyone?
  • Classes within a module can be split across multiple files for simplified maintenance, readability and reuse (more on that in a moment).
You may notice that I didn't split my code into separate files. I decided not to simply because I wanted to post a single Gist file for all of it. If it as part of a bigger project, I'd probably have a separate file for each class.

TypeScript helps you share & reuse your code.

This is the result of points #1 & #2. At the risk of stating the obvious, if you have high quality code that's well organized, it's easy to share or reuse it in multiple projects. For example, if you were to split up my code below so that each class was in a separate .ts file, it would be easy to maintain the classes as part of a common library, but also to select only the pieces you want for a specific application. Maybe you don't need to make API calls, but you need a Timer or a ResultLog? The structure and conventions of TypeScript make this easy.

When I mentioned to a colleague that I was working on this article, one of his first questions to me was, "So how does it work with something like Angular"? To ask it another way, how do you share and reuse your existing JavaScript code with new TypeScript code? The answer - a d.ts file, or library declaration file. This allows TypeScript to understand and interact with an existing JavaScript library through interfaces. In the case of Angular, you can download the library declaration from the Definitely Typed Git repository or NuGet; d.ts files for most of the major JS libs are available here as well. For your own JavaScript libraries, you'll need to create your own declaration, or rewrite the library using TypeScript directly (as they're going to do with Angular).

* * * * *

TypeScript certainly offers other benefits as well, but these really struck home with me. I really liked working with it, and definitely intend to incorporate it in future projects. In fact, I'd go so far as to say that I don't think I'd want to attempt building a JavaScript-heavy project without using TypeScript for at least a portion of it. As JavaScript is now commonplace in all kinds of different software projects, you must be able to write high-quality, reusable JavaScript, and TypeScript will definitely help you do that.


Here's my sample project - it's an API testing module modeled after a PowerShell script I wrote a few months back. The TypeScript module code is below; there's also a sample HTML page that shows how to execute it:

Wednesday, May 6, 2015

Recap - Building Windows Apps with JavaScript is even easier

I had the privilege of representing SPR Consulting at Microsoft Ignite yesterday. It was my first experience attending a really big industry conference, which was cool in and of itself. Along with that came the opportunity to catch a session by Michael Palermo IV titled "Building Windows Apps with JavaScript is even easier". I thought it was a good high-level overview of some new app development features that are coming down the pipe with Windows 10, and wanted to share my notes on a few of Michael's topics that were of particular interest to me:

Hosted Web Apps

As Michael explained it, this is a web application that runs within the context of an app. Have an existing web site you want to have a corresponding app for? Just start a new Universal Windows app project, edit the config file to reference your site, and Build the Project.

Boom, it's an app.

This demo really impressed me. Not only does this mean you can create an app from an existing web application without many changes, but any changes you make on the web are instantly available within the mobile app without the need to redeploy. As Michael mentioned though, this is really only going to work well for web applications that utilize responsive design.

Lastly, and almost as cool, you will also be able to access Windows APIs from this app. This means the website you just turned into an app can also access device features like Notifications, Camera, Calendar - even Cortana!


Manifold.js

"Create hosted apps across platforms and devices". Basically, you point this tool at an existing website, and it will read the meta-data of the site and generate a Hosted Web App for you! You can run the utility either through the Manifest.js site, or locally after installing the corresponding node.js module. Besides Windows, this tool can also generate Hosted Web Apps for iOS and Android (using Apache Cordova).

Essentially, it's going to become much easier to take an existing web application and package it up as a Universal Windows Store app. I've recently been dabbling with building Windows apps using JavaScript in pursuit of an MCP certification, so anything Apps + JS is of particular interest for me right now. I'm looking forward to trying out these tools & techniques in the coming months once Windows 10 is released.

NOTE: Building Universal Windows apps requires Windows 10 configured for development + Visual Studio 2015.

Friday, April 24, 2015

Happy 40th anniversary, Microsoft!

Earlier this month, the Microsoft Corporation celebrated its 40th anniversary. Co-founder Bill Gates recently sent out an email to the company to mark the occasion. Reading his message sparked me to think about how Microsoft has impacted my life on a personal level:

My parents brought home our first Windows PC in 1995. It had all the awesome software of the day: Windows 95, Office 95, Doom, and AOL(!) blazing through our 28.8k dial-up modem. It was both amazing and super-slow.

A few years later when I graduated from high school, I started to become curious about computers as a career path, and used almost all of my graduation money for my own machine - a black Compaq tower running Windows 98 with a Pentium II processor and a gigantic 17" monitor. She was a beauty; envy of all the other nerds I knew. It was top-of-the-line ... for a few months; then the Pentium III came out. So I resold the machine to my parents to replace that original from '95. I used the money to buy some parts and built my own machine, then installed Windows 2000 from scratch. Now I was hooked.

I began studying for my A+ Certification, and took a couple of programming classes using Visual Basic 5. Not long after, I started my first professional job at a small manufacturing company doing data entry and help desk support for their Windows workstations. After a few months, the one programmer on staff who was in charge of building ERP system add-ons using VB 6 and MS Access resigned.

Guess who was offered the position? 13 years later, I'm still coding away and can honestly count myself as one of the fortunate few who has a great job I really enjoy.

If you've been involved in IT for a good part of the past 20+ years, I surmise you have a similar story to share. Technology workers as a group have been regularly critical of Microsoft during that time, often for good reason. However, many of us have well-paying jobs we really like based heavily on being experts in Microsoft's technologies. I don't think we stopped often enough, myself included, and said a "thank you" for all the good things they've done. This quote from Harvey Mackay says it better than I can:

"None of us got to where we are alone. Whether the assistance we received was obvious or subtle, acknowledging someone's help is a big part of understanding the importance of saying thank you."

So happy anniversary, Microsoft. Thanks for the life-changing innovations of the past 40 years, and the opportunities of the future. I can't wait to see where the next 40 years will take us.

Thursday, February 19, 2015

Worksheet for an Agile retrospective using XMind

I've been running Agile retrospectives for years now, usually with just a whiteboard and some sticky notes, and that works great for facilitating the ceremony and discussions. However, there's one major drawback - it's a real pain to try and collect all that information and digitize it.

I've wanted a single sheet I could post in the team's workspace that represented our discussion and goals. I've wanted to be able to review notes from past retros without having to flip through a bunch of photos and try to make out people's chicken-scratch handwriting on stickys or the whiteboard. I've wanted to be able to easily share the meeting experience with remote team members. I didn't want to take all of the information collected during the meeting and re-key it into some other document to accomplish this (nor did I usually have the time to do that). I also didn't want to run the ceremony using a spreadsheet so I could fill it out as people were talking; how boring would that be!

I recently found a tool that finally fulfilled all the items on my wish list. A colleague on my last project introduced me to XMind, a free and easy-to-learn mind mapping tool. After watching him use it during a couple of design meetings, it struck me that this could be a great tool for retrospectives as well. So I set to creating my own retrospective worksheet, which you can download from the XMind Library.

If you're familiar with the basic Agile retrospective meeting format, it pretty much follows that same flow, with a couple of nuances:

What went well? - You'll notice I have an extra layer in here. I encourage the team to tie their positives to one of the four foundational components of Agile; each of these maps to a value statement in the Manifesto. You could also replace these items with team-defined values if that's how you roll. Either way, I think it's important to have some key values that your team can claim positive gains against.

Goals - I'm kind of a stickler when it comes to the Goals portion of the meeting. If we identified a problem at the last meeting, and set a goal to improve or correct it, I definitely want to review progress and/or results at the next meeting. The nice thing about the mind map format is that you can drag & drop items to different parents. So when it's time for a retro, you can just boot up the sheet from your last one, drag the "Goals - Next Sprint" subtopics to the "Goals - Past Sprint" topic box, and you're all set.

I hope you'll give my worksheet a try at a future retro, and that it solves some of the same problems for you that it has for me.

Thursday, January 15, 2015

Personal Retrospective - 2014

I'm going to start my retrospective this year with a quote that I think pretty much sums up what happened between my last retrospective post and this one:

Life is what happens to you while you're busy making other plans.
-- John Lennon

Now, I don't usually find myself agreeing with most of John's philosophies on life, but this thought really hits home for me when looking back on 2014. At the beginning of the year, I laid out what I thought were some pretty ambitious goals, but I felt like I could accomplish all of them if I made a conscious effort to regularly spend time on each of one.

And then life happened. I had two major and somewhat unexpected events occur that took up most of this time I thought I had at the start of the year:

  1. I got a new job. It shifted me from a management role to a consulting role, which requires much more travel than I was accustomed to.
  2. My wife and I welcomed our second child (a daughter) into the family.

Both have been excellent changes for me and for my family. However, in the scope of this post, they were not so good for my goals that I had set. I still got through 2 of the 4 books I wanted to read. The job change put me back behind the keyboard on a daily basis, so I was also able to spend significant time building things (primarily Web API / mobile projects), but I didn't even consider starting either of the side projects I had mentioned, nor did I spend much time on my existing project. I also didn't really get a chance to do much in the way of coaching after the first few months of the year, although I do feel good about what I was able to accomplish in that short amount of time with the teams I did work with in this capacity.

I gave myself grades on all my goals last year, but I don't think I'm going to do that this year, or going forward. In retrospect (*wink*) I don't think it was a good idea to do it last year either. In essence, you either met a goal or you didn't. Not meeting it is not necessarily failing though; things just didn't work out according to your original plan. There could be a number of contributing factors as to *why* you didn't meet the goal, which is usually where you can learn something and make an improvement.

So having not met most of my goals from last year, what's my takeaway for doing things differently this year? Well, I learned a lot can happen in a year, so I'm going to set fewer goals that are smaller and more defined. Here's what I'd like to accomplish in 2015:

  1. Continue reading. 2 more professional books; 1 business, 1 craft. This is the amount of reading I was able to accomplish last year, and it feels like a good amount again this year. Last year, it was Conscious Agility and Clean Code. This year, I'd like to do Joy, Inc. for sure. For the other, I think I'd like to learn a new programming language. I'm thinking either something in the functional domain (Haskell / Scala / F#) or something in the mobile domain (XCode / Java).
  2. Make 10 blog posts. I really enjoy writing, and didn't get a chance to do much of it last year. I did 10 in 2013, and I think I can do the same this year, only because I'm seeing more topics and content coming along through new experiences in my new job.

I'm optimistic, but we'll see where the year takes me. As always, thanks for reading and best of luck in achieving your personal goals this coming year, even as life happens around you.