I wrote this today on Facebook as a way to help a number of friends who are freaking out over the 2016 US presidential election. Maybe you are one of them. Either way, enjoy. —

Regarding the reports of bigorty, racism, misogyny, and so on…it's important to remember that the perpetrators already held such views well before this election, and have likely held them through their entire lives. They now, of course, feel emboldened to outwardly express those views, which is no excuse whatsoever for hurting others.

At the same time, their expressions are revealing the stark truth about many people in our country, a truth that essentially been suppressed to the point of coming out explosively. Continued suppression was never going to help them change their views. But now that they're out in the open, it's possible to shine some light on them. Without that, there's really no hope of transformation; by having these things exposed it becomes clear what kind of work remains to be done, and the level of positive energy that must be expressed to counter the negatives.

It reminds of me of Gandhi saying that the purpose of civil resistance and non-violence is to *provoke* a response until your adversaries essentially wake up to what they're really doing. He also said that "it will hurt, as all fighting hurts." There will be pain. There will be trials and suffering. What he–and MLK–demonstrated, though, is fighting for the light and fighting for truth, rather than fighting to punish, which is what happens when you fight violence with violence or otherwise allow yourself to descend into bitterness and anger. It's vitally important, therefore, to choose always to contribute to the light, rather than the darkness.

If you're struggling with anger, get some help. Find a way to turn that anger into motivation. If nothing else, get the Gandhi movie http://amzn.to/2fVS7g8and watch it about five times. Or you can watch documentaries about Nelson Mandela. These things will give you courage.

As it's been well said, "there are no problems, only opportunities." This is your opportunity to choose whether you'll rise to a higher consciousness, or descend into the lower along with those you depise.

On that note, I'll share two pieces I wrote about an email battle that erupted at Microsoft over twenty years ago. The first is an article called "The Power of Thoughts and Words" , http://www.kraigbrockschmidt.com/the-power-of-thoughts-and…/. The second, which tells the story more fully, is Chaper 13 of my memoir, *Mystic Microsoft: A Journey of Transformation in the Halls of High Technology." The chapter is entitled, "A Flick of the Switch." http://www.kraigbrockschmidt.com/mm/Chapter13.htm.

May you also be transformed by what you choose to flow through you.


I just finished publishing a body of content on unit testing for JavaScript in the context of Apache Cordova, including both command-line and Visual Studio interfaces. I had a lot of fun learning about the subject and finding ways to communicate a number of concepts. I also found a direct example of a slight difference between JS runtimes that can bite you, but I'll leave that for the articles themselves.

You can find it all on http://taco.visualstudio.com/, the docs site for the Visual Studio Tools for Apache Cordova, under the "Test" node. Here are the individual topics:

There are two other topics in that node that I'll be revising and/or integrating into the stuff above: Test Apache Cordova apps with Karma and Jasmine and Test Apache Cordova apps with Chutzpah.

I'd love to know what you think, as this material is easily the basis for a video course with Microsoft Virtual Academy as well.

In January I'll start diving into UI testing for mobile–should be fun!


It's been a few years since I've taken the time to write a fuller essay for my site, but I'm delighted to offer a new one. Comments are welcome with this post as I don't have comments enabled for the articles themselves.

The California Drought: A Problem of Consciousness? – A defense of my claim that "all problems in the world are ultimately problems of consciousness." It's easy to see this truth in matters of human interactions, but is it also true with impersonal factors like the weather and other natural events? And it ths claim defensible without resorting to metaphysical explanations? It is, because what makes such things a problem in the first place is that humans happen to be in the way of such events, and that placement is subject to human choice and thus a matter of consciousness. The very act of classifying a natural event as a problem in the first place is also itself an act of consciousness, because we could just as well classify such things as opportunities. September 2015


One of the things we do in the Windows Ecosystem Scenario Adoption Team is work with top-tier software vendors to help them get key apps ready for things like launch events. Leading up to the General Availability (GA) of Windows 8 in late October, 2012, you can imagine that we were suitably busy (not to mention getting //Build 2012 together and, for myself, finishing up Programming Windows 8 Apps in HTML, CSS, and JavaScript!). Among those companies I worked with, one of them holds the record for the shortest time from first conceptualization to actually being available in the Store: two weeks! (I'm electing to not identify the app, simply because doing so in the context of this post can be interpreted a number of ways.) To be more specific, the first meeting I and a few of my teammates had with this company, its developers, and members of the agency that would be helping them with the app, was October 3rd, 2012. A working app was the available to the public from the Windows Store on October 17th, and we had time to make a few updates and improvements before the Windows 8 launch events a week later. How did we manage to pull this app together so quickly? In addition to the direct support provided by myself and my team, there are a number of factors that contributed to the speedy turnaround as I've written below. This list is also my answer to a question posed by one of my managers: "Why do some partners struggle when we have some who turn out an app very quickly?" What I've written here are then the guidelines of how to avoid struggling and get your productivity in high gear.

  • Complete commitment. These guys weren’t sitting on the fence or making passive agreements. They made a decision and then didn't let anything get in their way. Another way of saying this is that they just completely accepted the job and the platform as it is, and wanted to make the best experience within that reality. Another company I worked with early in 2012 for the first Windows 8 Consumer Preview, a travel app, took the same approach and got their first app done in 6 weeks, even with early tools and platform bugs. Conversely, some partners we've worked with seem to resist this level of commitment, making a big deal out of some small branding issue or turning other molehills into mountains, meaning that we seemed to slog through the process for month after month.
  • Prior experience: The company and their partner agency were also doing their Windows Phone 8 app at the same time. They knew their C# and XAML and didn’t need to struggle with the tools, language, and presentation layer. Other partners I worked with in Consumer Preview also ramped up quickly on the JavaScript side as their devs really knew their HTML/CSS/JS and just needed to learn the Windows platform specifics.
  • Knowing the Resources for a Quick Start: with the two-week project, the first thing I did, given that I'm deeply familiar with the Win8 platform, was to bang out an 8-page summary of what controls, APIs, and samples to use to implement what features in the design. I think this significantly shortened the amount of time they needed to do the job. Indeed, I highly recommend that developers really know the scope of the resources available in the samples, because you can then just grab code from a certain sample to solve a certain need–the Windows 8 samples in fact cover about 95% of the platform, so for most needs you're find code that you can quickly borrow and adapt. You can use my book as a reference for this, because I made note of every JS sample in the appropriate feature context, and by extension this also hits a significant number of C#/C++/XAML samples as well.
  • Properly scoped design: In short, don't try to do too much the first time out the door. Locking down the scope of an app early on and limiting design and development work to just that scope is super helpful. The app we did in two weeks was like this: we had a design in two days to which we only made minor modifications after thorough review. This meant that we could focus on developing just that, and not get sidetracked into other ideas. I’ve seen other partners, in contrast, go back and forth many times with many different ideas, which meant that the developers were having to rewrite stuff. Given that it's so easy to update apps in the Windows Store, you don't have to worry about getting it perfect the first time. Be sure to make it good enough to be useful and get good initial reviews, of course, but understand too that providing updates with more features later on will help to reengage customers.Another way of saying this is that because the development cycle for apps can be short (a matter of weeks instead of months or a year), then it seems to work better to have the designers and planners lock down a rev of the app and let the developers go at it, rather than have too much back-and-forth while the app is being developed, trying to add features, etc., as that just bogs down the dev team.
  • Clear, efficient, and appropriate methodologies: when a dev shop has clarity about who is doing what in their own teams, the process seems much smoother. The team on the two week app, for instance, had multiple teams or individuals working in parallel on app features that were easy to integrate together (my initial document also outlined what could be done in parallel). I've worked with other partners and agencies who had clear processes, as well; some partners, on the other hand, felt like they did everything by committee (too much methodology), as decisions were very slow in coming. Some partners, on the flip side, also end up being too chaotic (lack of methodologies).By the way, if you don't have a testing methodology, get one. Because the turnaround time for an app is not immediate like it is for the web, and because the customer reviews and ratings for your app stick across updates, you need to invest in up-front testing and not leave it to your customers to do that work for you!
  • Experience with tools: Having a solid familiarity with the tool stack ahead of time makes a big difference. With Visual Studio, I think newcomers are put off by the complexity of the whole thing, not knowing where to begin, exactly. For my book I made a 10-minute introduction to Visual Studio to address this, in which I show the core features you need to know about for writing and debugging code. This is Video 2-1 in the book's companion content; I've also posted to Channel 9 and YouTube.I also highly recommend learning to use Blend for Visual Studio Express, especially for CSS styling and probably for XAML, because the tool can make you highly productive. Blend very much helped the travel app developer last year—saved many hours, if not some says, when tracking down style issues. I show some of this tool in Video 2-2 of my book's companion content (I haven't posted it elsewhere).I can also recommend A deep dive into Expression Blend for designing Metro style apps using HTML (//Build 2011), Building Awesome HTML apps in Blend for Windows 8 (//Build 2012), and Designing awesome XAML apps in Visual Studio and Blend for Windows 8 and Windows Phone 8 (//Build 2012).And again, knowing where to find answers (docs, samples, forums–see http://dev.windows.com) is a kind of tool. Some devs just don’t know what’s available to them. Third party libraries, if you know how to use them (e.g. jQuery), can also help productivity.
  • Courage to ask questions: This has surprised me sometimes. Some devs are quick to reach out when they get stuck, whereas others seems to struggle along for a day or two before asking. I’ve made it a point to tell my partners that if they find themselves spending more than 30 minutes trying to find an answer, to just ask me. Otherwise you lose momentum and can get a little emotionally depressed (devs are not machines!) when you look too long for something, especially if you’re unsuccessful.Similarly, some devs are too fine-grained in their questions—asking how to solve something that doesn’t need solving if you step back and look at the larger issue at hand. I think the best results have come from devs who seek advice first on the general development approach, then ask good mid-level questions, then ask on specific details. This is again why the 8-pager I banged out for the two-week app was so effective.More generally, having good ongoing communication is helpful for a variety of reasons. I worry most about partners that don’t say anything for a while; having a regular sync call helps to keep the doors open. This is very necessary if you're working with an agency or have developers in different locales.
  • Making the right assumptions: Beyond core architecture decisions, I’ve seen devs make a design choice based on mistaken assumptions about how the platform works, and didn’t consult with us until they were a ways down that road and started to run into trouble (e.g. assuming that they could do more with an iframe or webview than is actually allowed). Of course, devs don’t always know that they’re making wrong assumptions, and if they didn't communicating well with us then we weren't able to provide timely feedback (hence again the utility of having regular sync calls).Checking one's assumptions is especially important for developers coming from other platforms like iOS and Android, because what works on those platforms might not work like you think on Windows.