Developer Christmas Is Early

In a widely shocking display unlike any that Microsoft has done before, they recently announced that the core of .Net will now be open source!

*Pause for raucous applause*

After years of working with .Net and loving it, I am looking forward to the move to open source. I feel that .Net has an incredible and rich development stack (aside from the presentation layer, I still love HTML/CSS there…) and it will only improve by allowing the massive .Net community to tinker, improve and evolve it.

The move was partially due to having to deal with a lot of issues between their platform and Mono, and partially to allow for development across all platforms. This isn’t Mono’s fault, of course, but when both teams are working to provide a great framework without collaboration, there is bound to be a few issues here and there. In fact, Microsoft reports that they are beginning a collaborative effort with the team at Mono to ensure that the core becomes cross platform.

What interests me in all of this, is just how much this will mean for Windows 10. Windows 10 is to become their next iteration of the pervasive OS that will ship for PC’s, phones, tablets, X-Boxes and apparently, embedded platforms. What better way to support embedded platforms than to make the foundation of your application stack open source!

Along the lines of cross platform and embedded devices, I just have to paraphrase a few of the comments that I have seen surrounding this news…does this mark the beginning of the end of Java? Will we see more and more applications built on a wide array of platforms and devices utilizing .NET? I can only hope, as from what I have seen, C# and .Net are easier to work with, build better user experiences and are built with quite a few newer technologies, practices and patterns in mind.

Furthermore, what will this mean for the web? ASP.NET has already been open sourced alongside the Entity Framework. How will this affect Python, PHP, Coldfusion or even Perl? Companies will soon have the capability to host their old .NET programs on affordable linux servers, where they can be served by ASP.NET over the web with a fresh new look. Who knows, maybe we’ll even see someone calling .NET application code from Python on a linux box. The possibilities are nearly endless! I already love Python, and to be able to use .NET for its strengths alongside Python and it strengths seems like a pretty amazing idea to me!

All in all, I am incredibly excited for this news. While the current core repo on Github is small and doesn’t contain all of .NET’s goodness, do not be alarmed! They are planning on continually moving their code over to the repo. This is the just another amazing step toward a wonderful, more open, more intriguing technological world.

P.S. Visual Studio is now free and fully featured. Huzzah!!!

Delicious and Affordable Cloud Hosting

So recently I spoke with a coworker about trying to find a decent webhost that I could use for various development projects. I have used VMs in the past to create my own servers that I could use for internal testing and hosting. The problem is that if I ever want any of those to be public, I have to jump through a bunch ISP and networking hoops. While I can jump through said hoops…I have no real desire to jump, hop or even skip in that direction.

On top of that, I wanted a host that would allow me to easily work with my servers as if they were my own. I didn’t want a complicated almost IIS-like control panel; I wanted something more akin to actually having my own box…but without the hassle of actually owning said box. I’ve grown accustomed to a certain development lifestyle, you see, and I want to continue living within it. I want hosting to be easy, fully-featured, and of course, I want it to be pretty.

And so it came to pass, that he suggested to me Digital Ocean, a beautiful, simple, and effective place where you can spin up a new server in almost no time. After about 5 minutes of reading their sales pitch, I was already hooked. I signed up and set up my first Ubuntu Docker server in no time. I knew that I had found my hosting paradise.

Here’s a quick rundown of why I love DO, and why you should at least review their site for yourself:

  • Great pricing, on your own dedicated virtual server
  • A full control panel with an amazing user experience
  • Server image backups and snapshots
  • A ridiculous amount of support information
  • A large and passionate community

If any of that sounds good to you, and you’d like a $10 credit for your own DO account, please click here.

Murmuring, Stuttering with Just a Pinch of Mumbling

There’s an awesome new standard for web developers that has been floating around the web for a short time that allows you to speak to your web apps and web sites. While the documentation is currently an evolving specification for the new standard, you can still dig in without too much trepidation and find yourself mesmerized by the sheer brilliance of modern technology…or find yourself potentially chucking your old $10 Logitech headset in favor of something with a better microphone.

I am, of course, writing to you today on Google’s fancy new Web Speech API.

What is this new API you ask? Well, for an extremely short description, it is a way for you to allow people to interact with your website or web app with simply their voice. It doesn’t end there, either, as it also allows your site to talk back through their Speech Synthesis. Sounds an awful lot like Siri, Cortana or Google Now, but of course it comes with no almost SI like understanding of what you want from it. No, this is just a means of interacting with the person on the outside of all of the 1’s and 0’s…and what a simple method of interaction it is!

I implemented it recently within an AngularJS project that I have been working on called Project Voxie (More posts on that topic soon). I utilized Angular’s awesome service model to abstract away a good chunk of the API workings away from the controller code:

Speech API Service

voxie.service('speechSVC', [
    '$window', 'speechMockSVC', function($window, speechMockSVC) {
    return function() {
        var speechRec, speechSVC;
        speechRec = $window.SpeechRecognition || $window.webkitSpeechRecognition || speechMockSVC;
        speechSVC = new speechRec();
        speechSVC.continuous = true;
        speechSVC.interimResults = true;
        speechSVC.onResultCallback = angular.noop;
        speechSVC.onresult = function(event) {
            if (speechSVC.onResultCallback) {
                return speechSVC.onResultCallback(event.results);
        speechSVC.onerror = function(event) {
            console.log(event.error + ": " + event.message);
            if (speechSVC.onResultCallback) {
                return speechSVC.onResultCallback("Unfortunately, speech recognition has failed.");
        return speechSVC;
voxie.service('speechMockSVC', [function() {
    return function() {
        var NOT_SUPPORTED, showError, speechMock;
        NOT_SUPPORTED = "Your browser does not support speech recognition. If you wish to use this application, please upgrade to a browser with speech recognition support.";
        showError = function() {
            return $window.alert(NOT_SUPPORTED);
        return speechMock = {
            start: function() {
                return showError();
            stop: function() {
                return showError();

I used the service to provide an extended public API to my controller where I could specify a callback to perform once I had some results from Google. I added in support for the non-prefixed API (Chrome utilizes the webkitSpeechRecognition, but the specs call it simply SpeechRecognition), which also gave me the ability to handle any browser that didn’t have any of the speech API’s loaded on the window.

As you can see, it’s fairly simple. You tell it whether or not it should continue recording for an extended period of time (continuous), whether or not it should send you any fuzzy results that haven’t been confidently matched yet (interimResults), and wire up your success and error events. Once complete, you can use it within your controller:

Speech API Controller Integration

$scope.listen = function() {
    var listener;
    listener = speechSVC();
    listener.onResultCallback = discernCommand;
    return listener.start();


Here, discernCommand is simply a callback that joins the results array into a single string in order to be displayed on the page. The $scope.listen function is wired to a button as it was incredibly difficult to get it to work automatically on page load alongside Angular’s digest cycle. I’m not saying it can’t be done…but I’m not entirely sure that the two can play nicely together either. So for now, it’s wired to a button. When pressed, your callback is hooked into your service, and it starts recording. Pretty easy.


What’s any write up of a new technology without a bit of a review at the end? The API is fairly easy to use once you decipher the specs. It integrates fairly well with the well known JS libraries (with a few idiosyncrasies like the aforementioned auto-listening and Angular’s digest cycle) and is…well…almost accurate. This is the most heart-breaking portion of it all. When I said “contest”, it sent back “Comcast”. Blegh. Insult on injury with that match up. But, I am hopeful, as Google Now seems to be fairly accurate, and who knows, it may be due to my $10 logitech headset. So, for now, I would stick to playing around with it until the results become more accurate and it becomes more widely accepted amongst browsers.

Greetings from the Code Lion!

Hello, and welcome to my humble blog page! I’ve had various iterations over the years, but I think I have finally landed on a platform that I can thoroughly enjoy. Here you can expect to find my various musings about code, food, gaming and any other (mostly) important aspects of my life. While this preliminary post is a bit short, do not be alarmed! You can find all sorts of wordy delicious goodness in my main protein-y meat-y posts. So sit back, read and if you would like, reblog or comment away! Who am I to judge?