Meme Generator Powered by MMS

If you haven't heard yet, Twilio annouced MMS support today on all US and Canada phone numbers. I'm so stoked about this new feature and I knew exactly what I wanted to build with it.

Introducing the MMS Meme Generator

It is my belief that a mechanism for sending pictures cannot survive in the market if it does not generate memes. The internet demands the ability to express itself with images containing words. So, I am excited to bring you the first Twilio powered MMS meme generator.

How it works

All you need to do is send a properly formatted text message to (443)746-3637 -- that's (443)74-MEMES -- and you'll get back an MMS with your meme. Here are the supported memes in v1:

  • One does not simply ______
  • What if I told you ______
  • Brace yourselves ______
  • ______ but that's none of my business
  • ______ all the ______
  • ______ ain't nobody got time for that
  • ______ we're dealing with a badass over here
  • ______ aaaaand it's gone  (note: any number of a's will work on this one!)


Have fun with this!

Hope you have some fun with this. Share your funniest memes with me on Twitter @brentschooley! Future additions will allow you to send these memes to your friends by sending their phone number in the text. Also, stay tuned to the Twilio blog where in a few weeks I'll show you how this was built.

If you want to get started with Twilio MMS, my team has put together a great Getting Started post that covers Node, Python, C#, PHP, Java and Ruby. Show me what you build!

Ember.js Basics - What is Ember?


According to the creators of the framework, Ember.js is “a framework for creating ambitious web applications”. What exactly do they mean? Also, with the many (, many, many) JavaScript frameworks that we have to choose from these days, why might I choose Ember? In this post, I’ll introduce Ember.js and some of the core concepts that backed its development. In future posts, I’ll dig in and show you how to build applications with the framework. For now, let’s look at what the framework is made of.

Guiding principles

Before looking at the details of any framework, it helps to understand the core concepts that drove the feature decisions in the first place. Perhaps the biggest factor in the creation of Ember was the belief that what makes the web so unique is the ability to bookmark and share URLs. The team felt that many JavaScript frameworks treated the URL as an afterthought (mostly by treating the concept of a router as an optional add-on). The Ember team also wanted to create an MVC framework that was closer in line with the desktop MVC framework mentality rather than taking a server-side MVC approach (like ASP.NET MVC or Ruby on Rails). So, Ember combines the productivity of a native UI framework while supporting shareable URLs. The following key concepts are what make up the framework from a high-level overview standpoint.

Core concepts

Naming conventions

Ember was written with convention over configuration in mind. This means that much of the framework relies on things being named consistently and in the manner that the framework expects. The naming conventions are summarized nicely here.


Templates are what describe the user interface in Ember.js. Ember templates are written using the Handlebars templating language which allows for expressions to be added to standard HTML markup within double curly braces: {{}}. Each template is backed by a model and supports databinding such that the template will auto-update when the model changes. The following features are supported in Ember’s Handlebars templates:

  • Plain HTML
  • Expressions - Allow model values to be substituted into the HTML. For instance, {{price}} would substitue the value of the price property on the model into the template where specified
  • Outlets - An outlet (specified by {{outlet}}) is a placeholder for another template. As the user moves around the application, different templates can be loaded into the outlet by the router.
  • Components - Custom HTML elements (technically, custom Handlebars helpers) that help clean up repetitive templates by enabling the creation of reusable controls

Example template:


The router in Ember is what powers the shareable URLs that are so important to web applications. The router translates the URL of a request into a series of templates. For instance, when I visit /coffee within the application, Ember’s router will translate this to the CoffeeRoute which will set up the appropriate template backed by the appropriate model for that request. As the templates or models being shown to the user change, Ember’s router will automatically keep the URL in the browser up to date. This means that the user can share the URL at any point in the application lifecycle. Whenever someone clicks on this shared URL, they will see the same thing that the original user saw.

Example router:


A model object is used to store persistent state within an Ember application. These model objects are what back the templates and provide data to be displayed within the HTML. Many applications will load these models through a REST API using Ember Data which will store the data in a server database, but Ember doesn’t limit you to just this choice. There are many adapters for Ember Data that allow you to choose the backend that works best for your project. You can even roll your own syncing using the Basic Adapter.

Example model:


The controller is technically where the templates get their data from. Though optional, a controller will be created by Ember if not directly declared for a route. The controller “decorates” the model object. Properties specified on the controller can be accessed by a template as if they were declared on the model. Methods can be created within the controller that can be called using Handlebars helpers in the template. This enables things like button actions. In general, properties that do not need to be synced to the backend server but are necessary for template logic should be created in the controller. Ember supports the creation of ObjectControllers, which manages a single model object, and ArrayControllers which manage a list of model objects.

Example controller:


Components allow for the creation of reusable controls. The interface for the component is defined using Handlebars templates. The component also has a JavaScript class that is used to store state and handle user interaction. Components are placed into a template using a Handlebars helper with a name based off of the name of the component.

Example component:


Ember.js is a relatively young but growing framework. Though in the past it suffered from a lack of documentation and a difficult learning curve, that situation has improved dramatically. The Ember guides are very well-written and will help you get started with the framework in no time. I will also be posting more on how to develop with this framework over the coming weeks.


If you want to comment or reach out to me, the best place to do that is on Twitter @brentschooley. You can also contact me through the contact form at

Plantronics Voyager PRO UC v2 Review

Over the past few weeks, I've been trying out a Bluetooth headset from Plantronics called the Voyager PRO UC v2.  Plantronics bills this as a next-generation device which offers Smart Sensor technology, outstanding audio quality, and superior call management.  Another interesting feature of the device is the integration with Plantronics' Spokes SDK which allows you to access headset events and contextual usage data from within your applications.

The device

Just about anyone who has shopped around for Bluetooth headsets will be familiar with the design of the Voyager PRO UC.  It features an over-the-ear design with a rotating boom microphone that easily accommodates wearing on the right or left ear.  Volume buttons are conveniently located at the top of the device while the power button is on the back at the bottom.  Inside the box were 3 different sizes of earpieces and a leather carrying case.  The headset charges using a standard micro-USB port located on the bottom of the unit.  One other important thing included in the box is the small USB adapter that enables the headset to connect with your computer.  The adapter comes pre-paired with the headset so you don't need to fumble around with the Bluetooth settings on your computer to get up and running.  Once connected to the USB adapter, the headset will be able to relay information to the computer that can be leveraged using the Spokes SDK.


Audio quality

All of the technological advances in the world won't mean a thing for a Bluetooth headset if the audio quality isn't great.  Thankfully, the Voyager PRO UC v2 excels in this area.  Both incoming and outgoing audio from this device are stellar.  One person I called even said they had no idea I was using a headset.  Noise cancellation (referred to as AudioIQ2 noise canceling technology in Plantronics' literature) seems to be working great on this device as I tried a few calls in somewhat noisy environments and the person on the other end didn't complain about background noise.  The "WindSmart technology" is something I was very eager to try out since most headsets have major problems with wind.  I tried the Voyager PRO UC v2 on a few very windy days and again, the headset held up to the challenge.  It is definitely one of the best headsets I've tried in terms of audio quality.


The technological aspects of this device are where it really shines.  The Voyager PRO UC v2 has Smart Sensor™ technology that enables the headset to transmit contextual information to the computer.   While communicating with the USB adapter, the headset will report a variety of information such as proximity, battery level, and whether or not the device is being worn.  Since the device is able to detect whether it is on ear or not, it is capable of automatically transferring calls from your phone to the headset without needing to press a button.  When streaming audio over A2DP, removing the headset will smartly pause the music.  This all works out of the box without any need for additional programming.

However, the combination of sensors providing contextual data and the various amount of information available through the APIs in the Spokes SDK offers up a variety of potential application scenarios.  The information accessible through the Spokes SDK includes: wearing state, proximity, caller ID and call management, unique ID of the device, and device usage stats.   You can also send commands to the device using the Spokes SDK. The different types of applications that can potentially be developed using this SDK are described nicely in this post on the Plantronics' blogs.  A white paper for the Spokes SDK describes the benefits applications can gain by leveraging the contextual data provided by these smart devices.

I tried the SDK out for myself.  To get started, I needed to obtain the Spokes SDK from the Plantronics Developer Connection (PDC) which can be found at  The PDC contains a variety of resources including documentation, forums, blogs, as well as many samples.  A great place to get started once you have installed the Spokes SDK is the DevZone where you'll find a curated list of samples and documentation.

Since I've been mostly living in a Windows 8 world lately, I found the inclusion of a REST API accessible through Javascript to be very appealing.  I started with the "Hello Plantronics World!" example that I found on the developer portal.  This allows you to connect to your device and view event logs as well as send a few basic commands.  It looks like this:

Screenshot 12:17:12 5:00 PM.jpeg

My next challenge was getting the spokes.js file to work within the confines of WinJS.  After a bit of wrestling with jQuery and WinJS interaction, I was able to get some parts of the API to work.  I was not able to get event polling to work, but this is not a problem with the Spokes REST API, it's a problem in my port of spokes.js.  Given a bit more time, I'm certain I'll be able to get things fully functioning in WinJS.  For now, here's a screenshot to prove you can talk to the device in a Windows Store application!:



Overall, this is a great device.  Even without the SDK and smart sensors it is one of the best headsets I have tried.  The audio quality, noise cancellation, and wind protection are top-notch for this type of device.  Add to this all of the tech smarts and you have a device that is very unique in the field.  Plantronics has also recently released the Voyager Legend UC which promises to provide even better quality and more contextual information out of the box.

I would highly recommend developers check out these smart devices and the Spokes SDK.  The APIs exposed by the SDK will allow you to develop some really cool applications that take advantage of the data provided by the sensors in the headset.

Southwest Florida .NET Code Camp 2012 Recap


This past weekend I had the wonderful opportunity to attend and speak at the Southwest Florida .NET Code Camp 2012 in sunny Naples, FL.  It was a great event with over 80 attendees.  I was there as both a speaker and a sponsor and I also brought my father and brother to the event.  I'd like to thank John Dunagan again for putting on a fantastic event.  I presented 3 sessions at the code camp and I wanted to take some time to provide some additional resources for those that attended the sessions.

HTML5 and jQuery Fundamentals

Originally, my boss Jason Beres was supposed to be attending this event but he needed to attend TechEd Australia instead.  Since he was planning on presenting a session on HTML5 and jQuery I figured I would take that session slot and give it a try.  I'm still learning HTML5 and jQuery so I'm certainly not an expert.  However, I took Jason's content and made some slides of my own and gave it a shot as a high-level overview.  I thought the session went well and the attendees seemed engaged and appreciative.  I promised I'd share my slides and Jason's original material (including some content I didn't get to talk about).  Here are the links:

Windows 8 Design Fundamentals

The material in this session hasn't changed since previous events I've given the talk at.  You can find more details on those here and here.  However, one thing that is new is that I'm writing a book on the subject.  Please pre-order Designing for Windows 8 today and you'll get it when it's done in December!



Create iOS apps using C# with Monotouch

I added this session for a bit of fun after I noticed that there weren't any sessions at the code camp dealing with MonoTouch or Mono for Android.  I think these are very important technologies and I didn't want to let them go unrepresented.  The session was at the end of the day so I kept it lighthearted with no slides and a few "Hello World"-style demos.  I discussed the origins of MonoTouch and Xamarin and a little bit of the turmoil those have been through in the past.  Thankfully, those things are in the past and we can safely use MonoTouch to build iOS apps without worrying about Apple interjection.  I showed how to use MonoDevelop in tandem with Xcode to create a very basic application.  I then showed how to build the same application using just Xcode with Objective-C.

I didn't have slides for this session but I do have one follow-up piece of information from the session.  I mentioned a service that allows you to run MonoTouch in the cloud in case you don't feel like buying a Mac.  That service is called MacInCloud and it might be a good option for you.


I had a great time at this event.  I would highly recommend it to anyone next year.  The location is fantastic, the facilities were very accommodating, and the people were very friendly.  If you're looking for an excuse to take a trip to Florida, this would be a good one.

Windows 8 Style Apps?

Windows 8 Style Apps?

While watching the live video from the Microsoft Office Preview event, me and my colleagues all had the same reaction (almost simultaneously in different locations) and we posted it to Twitter at roughly the same time:

Microsoft all made us scratch our heads because I think we've all gotten used to the term "Metro style apps".  Originally this term seemed awkward (especially the use of the work 'style' in it), but we all got used to it.  We wrote posts about it.  We gave presentations about it.  The term maybe even grew on us a bit.  So now Microsoft seems like they're going to replace it with "Windows 8 Style Applications"?  Immediate reaction from my colleague @brianlagunas:

I think we've had some time to digest this (pun intended) and maybe it's time to revisit the term and whether or not Microsoft meant this as a replacement term because I have my doubts.  Here's my theory:

There is a lot of confusion in the software world regarding the Metro design language.  For starters, when it is applied to an immersive, full-screen Windows 8 application that is launched from the Start screen, we have been calling that a "Metro style app".  But what do you call a desktop application running on Windows 8 that has been styled using the Metro design language in an attempt to fit in with the system even though it is running in the classic desktop?  It is still technically "Metro style".  Is it possible that Microsoft was just referring to this scenario?  That's my theory at the moment but I'd really like some clarification from Microsoft on this soon.  It's hard to communicate these things to customers when there are competing terms floating around.

What are your thoughts?  I'd really be interested in hearing them, so comment on this post or find me on Twitter @brentschooley.