Category Archives: Uncategorized

Partnership Vacuum

My role at Readify is pretty diverse. One day I can be up to my elbows in technical detail and other days I can be focusing on business relationships. I’m pretty sure that my technical background influences the way I look at business relationships.

I tend to look at relationships in terms of mutual benefits. The best partnerships are formed where both parties can put something into the relationship that the other really appreciates and can benefit from. Every so often I talk to organisations where the benefits don’t align to a great need on one or both sides of the relationship. In this situation the potential partners should agree to part ways and invest no further but keep the door open to future collaboration, but what can happen is a kind of “over politeness” where neither side are willing to admit that they see no benefit in a formal partnership. The result is the creation of a partnership with no activity at its centre, creating a kind of partnership vacuum.

Moving forward I’m going to try to be better at calling this out when I see it. The cost of not avoiding partnership vacuums is exertion of effort trying to create artificial value where no natural genesis exists.

 

 

OneNote vs. Evernote vs. Google Keep

Comparing OneNote and Evernote might be missing misreading Microsoft’s intent behind recent announcements.

OneNote has gotten lots of attention this week when Microsoft release OneNote for Mac. Microsoft also made OneNote free for Windows users and is opening up a cloud API for integration.

This recent activity has prompted many to compare OneNote to Evernote. Evernote is a popular third-party note taking tool with great support on most platforms.

While the effects of the announcement may impact Evernote, I suspect the real target is Google Keep. Google Keep is part of a much larger ecosystem of productivity tools by Google, including Google Drive.

All three products exist within an important category that I call “memory augmentation”. They are distinct from traditional productivity tools such as word processors and spreadsheets. They allow for the capture of unstructured (or lightly structured) detail.

I have been a OneNote user for years, and enjoy the pen input capabilities on Windows. But that power is useless without ubiquity of access, and that is what the OneNote announcement provides. Google needs to step up here and start providing access to their services on Windows Phone and Windows if they want to compete.

Writing Engaging Yammer Posts

The first sentence of Yammer posts should capture the essence of your topic to better engage your audience. If you don’t, summary representations of your post risk having their message hidden below the fold.

I work in an organisation that is taking advantage of Yammer. This tool can help lift the burden on e-mail volume and increase collaboration by being more open.

When I make an internal announcement I prefer to make it on Yammer because I can see feedback and dip in and out of the conversation.

Posts on Yammer lack a dedicated subject field. This might seem to be a critical flaw in the service, but I have come to appreciate it. When a Yammer post gets displayed in summary form only the first few chunks of text are visible. This is true of e-mail notifications and digests, mobile applications and the Yammer Inbox.

This means that posters to Yammer need to capture interest in the first sentence of their post. If you waffle you risk having the message missed in the stream of content on the enterprise social media tool.

I have found this constraint to be a blessing in disguise. My flowery writing style has begun to change as a result. This teaches me that constraints aren’t always negative. Sometimes they have positive consequences as the following articles can attest.

  1. Embrace Constraints in Getting Real by 37signals (now Basecamp)
  2. Why Innovators Love Constraints in HBR by Whitney Johnson
  3. Constraints Drive Innovation by Jim Highsmith

Recently one tool that has helped me deal with this constraint is Hemingway, a simple web-based app. Hemingway analyses text and reports what grade level you are writing and other characteristics. The following screenshot is an earlier version of the text in this article. You can see for yourself how the content has evolved.

hemingway-draft

Perhaps one of the lessons I need to relearn is brevity, and with that I will end my post.

Remotely Debugging Web Jobs on Windows Azure Websites

Yesterday I posted up some thoughts about how to streamline deployment of .NET-based Web Jobs along with your web-application. Continuing on with Web Jobs I thought it might be interesting to figure out how to debug them once they are deployed. With Windows Azure it is now possible to remotely debug a web application via Visual Studio when it is running in Windows Azure Websites.

Using the same mechanism it is also possible to attach to a running Web Job process which can help you dig into problems in Web Job execution during development (I wouldn’t recommend attaching a debugger on a production site). Unfortunately the process is a little kludgey right now so I’m not sure how effective this would be as a “normal-case” debugging scenario, but it’ll work in a pinch.

Before your start, to help you with the timing issue you might like to insert a Thread.Sleep(…) into your job just to give you enough time to attach to the process. Once you’ve got that updated Web Job code deployed start the debugger by attaching to the Windows Azure Website via the Attach Debugger menu option in Server Explorer.

AttachDebugger

Visual Studio will then spin away loading symbols etc. Once that is done go into the Windows Azure management console and start the web-job. At this point you need to work fast (depending on the value of the Thread.Sleep(…) that you put in.

Go into the “Debug | Attach to Process” menu item and select the web-site you are debugging from the Qualifier drop down (this is the remote debugging session that is currently supporting your web-app debugging). What you should see is your web-job executable in the list of available processes.

AttachToWorker

 

Once the debugger is attached any breakpoints that you have set within the web-job code will be hit and you can step through line by line.

BreakpointHit

 

Bingo! So now you know how to debug Web Jobs remotely via Visual Studio. I’d really like to see this process streamlined a bit so that when you attach a debugger to the web-site it automagically will hit breakpoints in the web-jobs that are part of the overall deployment.

 

Deploying .NET-based Web Jobs to Windows Azure

I was very excited when I learnt about the new Web Jobs preview feature on Windows Azure Websites. The ability to run separate background processing jobs alongside a web application is one of the critical features of any complex web application.

Amit Apple has a really good article covering the various deployment options for Web Jobs which I would recommend reading. If you are deploying a Node.js (or other script-based) application the convention based deployment model works very well but you might be wondering how you can streamline the deployment of a compiled binary along with your web application.

Managing Web Job Files

Let’s say that you have a .NET solution consisting of an ASP.NET web app and a simple console application. What we want to do is execute the console application as a Web Job, pretty straight forward.

ProjectStructure

In order to deploy a .NET-based Web Job you need to first compile your .NET code and then drop the executable or its dependencies into the App_Data/jobs directory structure. You could manually compile the files and then copy them into the directory but you are likely going to want to do this 100s of times as you build out the jobs, so you need something a little bit more productive.

One approach that you can take is to edit the *.csproj file for the web job console application itself. If you right mouse click on the console app and select Unload Project, then again to edit the file you can scroll down the bottom and update the AfterBuild build target as in the SimpleWebJob.csproj example below (contents removed to keep the file brief).

CsprojEdits

In the sample above I’m pushing the executable into the executable into the appropriate folder in the ASP.NET project. A more complete example might include copying configuration files and dependencies as well. You also need to make sure that you include the files that are being copied in the ASP.NET project itself so that they can get pushed up to the server.

Even though the web app isn’t directly referencing the console application, the console app is actually a dependency of a web-app, so you might want to do is right click on the web app project and select Build Dependencies | Project Dependencies to explicitly specify that SimpleWebApp (in my example) depends on SimpleWebJob.

ProjectDependencies

Once this is done you should be able to just publish your project from Visual Studio and the web jobs should automatically be created.

Room for Improvement

The Web Job feature is still in preview so I think it is fair to expect some further evolution in what you can do with Web Jobs. As a .NET developer I hope that the deployment process can be streamlined somewhat for .NET-based executables. Another thing that I would like to see is the ability to deploy a *.webjob file along with everything else in the directory which is used to provide additional metadata about the web job (such as being specific about what file is the entry point along with scheduling data).

Overall though I think it is a welcome improvement to Windows Azure Websites!

Death of the Start Screen Exagerated

It seems like the online media is foaming at the mouth about Windows 8.1 Update 1 supposedly making the move to boot by default to the desktop. The first article I came across was by Steven J. Vaughan-Nichols over at Computerworld followed by an article at Mary Jo Foley over at ZDNet (who gives the topic a much more balanced treatment).

Where Mary Jo Foley stops at reporting the news, Steven’s opinion piece is vitriolic which is typical of his previous articles. I mentioned to one of my co-workers the other day that I was disappointed in the state of tech journalism these days. Alas, there is only so much news to go around which means that content ends up being rehashed – so the only way to stand out is to write an opinion piece, the more bitter the better.

With that out-of-the-way, I have to acknowledge that where there is smoke, there is fire. So what about the rumour that Windows 8.1 Update 1 will boot straight to the desktop. If the rumour is true it is worth stepping back and thinking practically how this might work.

When Microsoft introduced Windows 8.x, the Start Screen didn’t replace the desktop. Rather the Start Screen replaced the Start Menu. The Desktop was always there in the background, it was just as if immediately after login that the Start button had been pressed and a full screen start menu was being displayed.

I suspect that Microsoft might ideally want to just boot to the desktop by default for devices that don’t have a touch first experience (desktop PCs and laptops) leaving touch first devices to boot to the Windows 8-style Start Screen. This would give users balance the best possible experience on their particular devices form-factor.

Some of the press has pointed out that if you boot to the desktop, then how will users know to launch metro-style apps? Well, remember that the Start Screen did not replace the Desktop, it replaced the Start Menu. So when a user presses the start button on the desktop (or on their keyboard) the Start Screen would still be displayed. If this continues to be the case then metro apps would still be discoverable in a desktop environment.

As Mary Jo Foley pointed out, leaked screenshots of the Windows 8.1 Update 1 UX reveal that users will be able pin metro-apps to the start menu. This means that users could quickly switch between legacy desktop apps and modern apps. I suspect that Microsoft has more plans for blending the metro and desktop environments.

I speculate that in a future release (not necessarily Windows 8.1 Update 1) we’ll see metro apps being able to run in floating windows on the desktop along with API support to make apps intelligently respond to this environmental change. Windows Runtime (or WinRT) is the underlying platform for modern metro applications, but that doesn’t mean that you can’t produce a UI in it that is more optimal for a mouse/keyboard user.

The second change we MIGHT see is a Start Menu / Start Screen hybrid. So far the best concept of how this might work I have seen is this start menu/screen transition video which was posted recently (and received great reviews).

What this video hints at is that the theme for phone, tablet and PC operating systems moving forward is convergence. Microsoft has pretty much confirmed this to be the case for Windows and Windows Phone, but I suspect this will also happen with OSX/iOS. Google is an interesting case because they have two quite different approaches to apps in Android and Chrome OS.

For Windows the key ingredient to convergence is Windows Runtime. Not only does Windows Runtime expose the UI building capabilities, but it also surfaces other OS features, file system, networking, sensors etc. WinRT modernizes key aspects of the existing Windows API (in Win32) in a way that is suitable for desktop, tablet and phone.

In summary, I don’t think that booting to the desktop on desktop-style devices spells the end for either metro, or the Windows 8-style start screen. Rather I think it’s just a continued fine-tuning of the user experience to support as broader range as users as possible. Indeed this kind of UX spread is a necessary feature of a single operating system running on a multitude of devices.

Code First Dynamics CRM?

A friend and former co-worker of mine, Jake Ginnivan forwarded a thread to me started by Darrell Tunnell to the DbUp mailing list. DbUp is a .NET API for building database migration tooling for applications by sequentially applying update scripts to a database, and keeping track of which scripts have been applied.

Darrell’s thread mentioned that he was working at a derivative work which could be used to apply changes to Dynamics CRM, he has called his tool CrmUp. For those of you who haven’t used Dynamics CRM before, out of the box it provides a way for businesses to manage sales, service and marketing processes.

Dynamics CRM is interesting from a development perspective because it is all built upon a customisable foundation where you can build your own custom business entities, relate them together and build processes that flow across the top of them complete with dashboarding and reporting. For some classes of problems it is a very productive development environment.

The product bundles customisations together into things called “Solutions” which contain the definition of all the customisations to be applied and this allows developers to ship grouped customisations to target environments. CrmUp is useful because it allows Dynamics CRM to be treated like an application dependency that can be upgraded to a baseline version.

Darrell’s work has got me thinking about what I would want from a developer orientated framework for managing customisations to Dynamics CRM. If we look at databases generally there are three broad approaches:

  1. Model/Tooling Driven Migrations (e.g. Database Projects in Visual Studio)
  2. Script Driven Migrations (e.g. *.sql scripts applied sequentially)
  3. Code Driven Migrations (e.g. EF CodeFirst)

Dynamics CRM doesn’t have a project type in CRM. The development environment is really CRM itself, from which you can export you customisations. It is these exported customisations (solution files) which are then fed into CrmUp.

Personally I am a huge fan of the way that Entity Framework Code-First migrations work. I love the fact that I can define my database entities in code, and add behaviour to them and then use the tooling to build a “migration” which takes me from one version of the database schema to the other. This leads me to wonder what a Code-First CRM framework would look like.

Dynamics CRM has various customisable elements:

  • Entities (create new, and extend existing)
  • Processes, Workflows & Workflow Activities
  • Reports
  • Dashboards
  • Views
  • Forms (for Entities)
  • Service Endpoints
  • … and many more.

This is perhaps what makes the CrmUp approach somewhat easier to get off the ground (because you are leveraging existing solution/customisation files). But in the long run a code-based way of defining the above would be incredibly useful.

For example, it would be great if I could define an entity in code:

[Entity(Name = "CustomEntity")]
public class CustomEntityDefinition: EntityDefinition
{
public override void Retrieve(RetrieveContext context)
{
// Do whatever.
}
}
Having this entity definition as part of a deployment would result in an entity being created, but a plug-in would also be generated which would route traffic to an Azure host (in the Dynamics Online scenario) to invoke the Retrieve method whenever that entity is retrieved.

There would be additional base classes and associated attributes to describe all aspects of a CRM solution in-code, and then you could do something similar to “Enable-Migrations” from Entity Framework to create the migration scaffolding. As the code is updated you could call “Add-Migrations” and it would generate a migration between the earlier migration and the current state. It would also take into consideration publisher details/signing and versioning.

I personally think that Dynamics CRM is an awesome product, and I’ve been working with it for years, but I would really love to have a more streamlined developer experience. Hat’s off to Darrell Tunnell for his contribution. I hope that the Dynamics team looks at what he has done and also looks at how the Entity Framework project has approached the challenge.