Unity3D is certainly one of the most popular ways to make 3D games for mobile phones. There are thousands of games made with it, by students and large studios alike. I recently helped the team behind a Unity game called Drive Me Bananas, and I'd like to share three tips with you about how they succeeded.

1. Target Windows Phone. It’s natural to target iOS and Android with your game, and you wouldn’t be wrong to do so, but many developers find it hard to get their game noticed there. It’s so simple to also target Windows Phone with your Unity game, which lets you reach a whole new market. You’ve already done the hard work by making your game, and targeting one more platform is easy.
2. Target a global market. A lot of my readers are in the United States, and it would be natural for them to target the US market.  There’s nothing wrong with that, but keep in mind that it’s an enormous world and the US is just one part of it.  The Drive Me Bananas team put special attention on Latin America, and released a localized version called Changos Y Bananas. There were several reasons for this. Windows Phone sells quite well there, especially in countries where Nokia has been a household name. Also, because of Nokia’s long history in the region, there are more mobile operator billing arrangements there for Windows Phone than for iOS and Android. In markets where consumers can make purchases on their cell phone bill, they spend much more than in markets where they need credit cards or some other payment option.  Windows Phone is the leader in Latin America for this.
3. Merchandising. The Drive Me Bananas team not only created a fun game, but they’re working to drive awareness of their game through merchandising. They’re starting to make elements of the game available from a 3D printing store called Sandboxr.  Models are printed on demand, so they don’t have to spend a lot of money on inventory.

Here's Press Start Studios describing their experience:

Drive Me Bananas, or “DMB”, is an amazing mobile endless runner game with unique art and game mechanics in this genre. The game has been translated into five languages and reached a global audience after its launch in May 2014. This journey started three years ago while Luis Parra, Press Start's CEO, was in the middle of his Masters program at the Academy of Art University in San Francisco. Drive Me Bananas started as an inflection point from Facebook games to mobile games, and with the support of the Academy of Art and the studio R3dPixel, the game was initiated.

As Drive Me Bananas was being developed, it was also being used as the central project for several classes at the Academy of Art.  This helped both the students who were working on it to gain exposure in a published game, and also helped Luis Parra to transition from academia to his company, Press Start Studios. Working on a game from idea to working prototype proved to be a long and valuable learning experience, especially as this was the first game of such scope that Press Start Studios had developed. During the development of Drive Me Bananas, one of the Academy of Art professors, Pryce Jones, now head of the graduate program at the Academy of Art, was also able to bring an experienced perspective to the creative and production process. After two years of development, Press Start Studios took Drive Me Bananas live with great reviews and download metrics across the US and Latin American markets. In fact, Drive Me Bananas has been one of the top rated games in the top app charts in Latin America. With Drive Me Bananas, and its innovative art and game mechanics, Press Start established itself as a leading game development studio.

Shortly after being launched on iOS and Android, Drive Me Bananas was ported to Windows Phone.  This took less than a month’s time and the results were terrific. The Windows Phone Store provided great visibility to Drive Me Bananas, and Microsoft’s support has been valuable to Press Start Studios. Microsoft approved the game immediately upon submission, and Press Start found porting to Windows to be worthwhile as that version has achieved close to 50% of the game’s total downloads on all platforms. This was with zero marketing budget. The Spanish version, Changos Y Bananas, is also available in the Windows Phone Store, creating an opportunity to reach an ever widening global audience.

 

Start with the files you downloaded and used in part two. Visual Studio should have these files in the Solution Explorer view:

Select File -> Save All to save this as a solution. Test runners in Visual Studio seem to require that a *.sln file has been saved.

We need to add the Chutzpah test runner to Visual Studio. Go to Tools –> Extensions and Updates. On the left side of the dialog box, select Online. Then type chutzpah into the search field in the upper right corner. You’ll be shown two results:

Download and install the first one. You’ll have to then restart Visual Studio. Repeat this process with the second extension.

Chutzpah needs to know about the test file and all of its dependencies. Open calculator-tests.js, and add these lines to the top of the file:

/// <reference path="../js/vendor/mocha.js" />
/// <reference path="../js/vendor/expect.js" />
/// <reference path="../js/calculator.js" />

This tells Chutzpah that you’re using the Mocha test framework, and that you have a dependency on Expect. It also tells Chutzpah that the test file depends on calculator.js.

Right-click on calculator-tests.js, and you’ll now have a few options from Chutzpah. Select Run JS Tests:

Visual Studio will then display your unit tests and their results in Test Explorer:

You can also run your tests by selecting Test –> Run –> All Tests:

You could stop here and stick with just using Chutzpah to run your unit tests, but there are more features worth exploring. For example, you can use Chutzpah to tell you something about code coverage:

Select that, and you’ll see results like this:

The results for our own code look good, but there’s no reason to unit test a library such as Expect, unless of course you’re the author of Expect. We can tell Chutzpah to ignore Expect by creating a file called Chutzpah.json. Right-click the test folder and select Add –> Add New Item. Add a file called Chutzpah.json. Erase anything which Visual Studio might have put in that file, and put this:

{ 
    "CodeCoverageExcludes": [ "*\\expect.js" ] 
}

This tells Chutzpah to exclude Expect. Re-run Show Code Coverage, and the output will look better. Chutzpah now only looks at your own code.

To get even deeper with Chutzpah, check out the documentation on its GitHub repo. In particular, look at the documentation for Chutzpah.json.

Get Visual Studio

First of all, you need Visual Studio. If you don't have it already, you can download a free edition called Visual Studio 2013 Express for Web. If you're a student, check with your administrators to see if your college is enrolled in DreamSpark. If so, you'll have free access on the DreamSpark site to paid versions of Visual Studio such as the Professional edition. This gives you more features. If you're a startup, enroll in BizSpark to get a MSDN license for 3 years. This also gives you paid versions of Visual Studio such as Professional and Ultimate.

Create a web site and add unit tests

1. Download the following code sample: 5025.Calculator.zip. Right click on it, and choose Extract All.
2. In Visual Studio, go to File -> Open Web Site. Select the Calculator folder you unzipped in step 1.
3. Launch the website by choosing Debug -> Start Debugging. Or, you can just hit F5. This is the Mocha test runner and you'll see the output for a single unit test. It tests the add function on the Calculator object.
4. Close the browser window that just launched.
5. In Visual Studio, open index.html, js/calculator.js, and test/calculator-tests.js.
6. In index.html, you'll see the unit test framework Mocha referenced. You'll also see a reference to Expect. That's an assertion library. It then references the JavaScript being tested, calculator.js, and then the unit tests themselves, calculator-tests.js.
7. In calculator.js, you'll see a JavaScript IIFE which defines a Calculator constructor and the add function.
8. In calculator-tests.js you'll see 3 sections. The describe at the top defines the test suite. The beforeEach sets up any necessary state. Perhaps your unit test relies on things being set up a certain way. Do that in beforeEach. The remaining describe function describes the specification. It corresponds to a particular feature. The call to the it function defines what the test should do. Be as explicit as possible. Lastly, expect asserts what the result of the test should be.
9. Let's add a new test. In calculator-tests.js, copy this code for the subtract test and paste it below the add test:

describe("Subtract", function () {
    it("should return the difference of both operands", function () {
        expect(calculator.subtract(5, 3)).to.be(2);
    });
});

10. Hit F5 to run the tests, and it should fail. This is called TDD: Test-Driven Development. In TDD, you write your unit test first, run it to verify it fails, and only then implement the code you're testing. This prevents you from accidentally writing a unit test which always passes, giving you a false sense of safety.
11. In calculator.js, create this subtract function. Note that the function body is incorrect. That's on purpose:

Calculator.prototype.subtract = function (operand1, operand2) {
    return operand1 + operand2;
};

12. Run the tests again by hitting F5. This time you'll get a different error.
13. Change the subtract function in calculator.js to correctly implement subtraction:

Calculator.prototype.subtract = function (operand1, operand2) {
    return operand1 - operand2;
};

14. Run the tests a final time by hitting F5. This time both tests should pass. If you don't notice a difference, it could be because your web page is cached. Reload the page by hitting Control-R.

Commentary

Recall the principles of unit testing from part one in this series. How do the above unit tests stack up?

1. The unit tests are predictable. We pass in static arguments and everything is reproducible.
2. It's obvious when the unit tests pass or fail.
3. The tests are self-documenting. A quick look at the Add unit test tells us that "Add should return the sum of both operands". We know what that means without having to look anything up.
4. The unit tests have a single responsibility and only test one thing at a time.
5. When the tests fail, we get useful error messages.
6. They don't test multiple components, so they're not integration tests.

How about the excuses we listed in part one? Were these tests too hard to write, or too cumbersome? Once you learn how tests are written, they should be pretty simple especially when compared with debugging code without unit tests.

Want to learn more? Take a look at the Pluralsight course Front-end First: Testing and Prototyping JavaScript Apps by Elijah Manor. That's where this example is from.

In part three of this series, we'll see how to use the Chutzpah unit test runner in Visual Studio.

• JavaScript is one of the officially supported languages for Windows 8 and Windows Phone development
• Azure Mobile Services, a mobile backend-as-a-service, is written in Node.js
• Apps for Office are written in JavaScript

As a consequence, Visual Studio is an excellent tool for writing JavaScript, even if you're just writing a web app and not a Windows app. In my opinion, if you want to write reliable code in a dynamically typed language such as JavaScript, you really need to write unit tests. Part one of this blog series will offer some guiding principles for writing unit tests, and common excuses people give when they don't. In part two, we'll write a JavaScript unit test using Mocha. In part three, we'll use a Visual Studio extension called Chutzpah to run your tests.

What are unit tests?

Let's make sure we're all on the same page. A unit is a small section of code. Unit testing means you test that bit of code to make sure it functions properly. This increases confidence in your code.

Unit tests are important when many people work on the same codebase. If one engineer changes code in one part of the project, you want to ensure that the rest of the project still works.

Unit tests are especially important in dynamically typed languages such as JavaScript, since there is no compiler to catch common problems.

Guiding principles for unit tests

1. Predictable. If you have a certain input, you should always get the same output. Your input should always be static. For example, don't pass a random number or the current time as an input.
2. Pass or fail. It should be obvious if your test passed or failed.
3. Self documenting. Your code should describe what the test is meant to do. Another engineer looking at your test should immediately be able to understand it. It helps if you use testing and assertion frameworks which read like English.
4. Single responsibility. Unit tests should only test one single thing at a time. If you want to test more things, then write more unit tests.
5. Useful error messages. When a unit test fails, the error message should be useful.
6. Not integration tests. Unit tests don't test multiple components. Unit tests come first, then integration tests, then validation tests.

Common Excuses

1. Too busy. "I have too many other things to do." "There's plenty of time after development to catch bugs." When you fix a bug and it breaks something else, it's called a regression. Unit tests can prevent regressions.
2. Too hard. "It's too difficult to write unit tests." "It'll take too long because I'm not experienced."
3. Too confident. "I don't need unit tests. My code works." "Why waste time writing unit tests because my code works?"
4. Too lazy. "There are other things I'd rather be doing." "I just don't want to write unit tests."
5. Too cumbersome. "It takes too long to run the unit tests." "I keep forgetting to run the unit tests."

If you find yourself making one of the excuses above, do yourself a favor and work to get over it. Like anything, there's a bit of a learning curve. However, you'll save yourself countless frustrating hours down the road if you put in a little time now to learn this. It's not as burdensome as you might think.

In the next post in this series, we'll start writing JavaScript unit tests with Mocha.

Acknowledgments: This blog series is based on this excellent course on Pluralsight: Front-end First: Testing and Prototyping JavaScript Apps by Elijah Manor. Content reproduced with Pluralsight's permission.

• Backend services can now be written in .NET languages in addition to JavaScript
• Offline sync lets you handle scenarios where mobile phones lose cell service. It queues up database operations and synchronizes data when you get back in range.
• Enterprise apps using Active Directory authentication are now supported

Here's the first in a series of episodes I'm doing on DevRadio on the new features. In this episode, Yavor Georgiev talks about what's new, and then gives a deep dive into the new .NET backend.

1. Read and understand the hackathon’s official rules before the event. Ask questions if needed.
2. Understand the judging criteria. Devote attention to all judging criteria, not just one criterion in particular.
3. Don’t have AV problems. At the beginning of the event, ask how presentations will be made. If you’ll be presenting from your own laptop, test it out on the venue’s projector early on. Bring all necessary video converters. Don’t expect the venue to have what you need. If you’ll be presenting from a mobile phone, find out if you’ll use an overhead projector or a Miracast receiver. Test things before you get fully focused on building your entry.
4. Android presentations should not use the ARM emulator from Google. It’s too slow. Use Genymotion instead. Better yet, deploy right to your phone and present using a Miracast receiver. Bring your own receiver in case the venue’s does not work.
5. Don’t begin with a long PowerPoint presentation. Dive right in and show your app. I’ve seen too many presenters run out of time before actually showing their entry.
6. Consider using an opening line which clearly tells the judges and audience what your app does.  For example, “Contoso saves money on healthcare by making providers compete for your business.” Consider landing that point in a closing statement too.
7. A more advanced technique is to start telling a story to appeal to judges on an emotional level. Your story should lead to a problem, and then explain how your hackathon entry solves that problem. All too often this technique fails though, because many developers aren’t good storytellers and they run out of time to show their entry.
8. Make sure judges can summarize your app in one sentence. When deliberating, judges will remind each other about each entry. Don’t make a judge search through notes to remember your entry.
9. Clearly state who your intended user is. If the hackathon has an entrepreneurial feel to it, this will give judges an idea of your total addressable market.
10. Land your most important points early. Don’t wait until the end. You might forget, or run out of time.
11. Know who the judges are, and what’s important to them. If one judge is a designer, emphasize your entry’s beautiful design. Certainly don’t disparage something which is important to a judge if you want to win them over.
12. Don’t spend time explaining what you couldn’t accomplish. I’ve heard presenters list everything they attempted to do, but failed. Focus on what you built, not on what failed.
13. If you’re entering a specific category, such as Best Use of the Fabrikam API, make sure you explicitly state how you use their API. I’ve seen too many presentations which forget to mention how they use a particular technology.
14. When using a handheld microphone, keep it right in front of your mouth. Don’t hold it at chest level.  A rule of thumb, no pun intended, is to keep the microphone a distance of one thumb’s length away from your mouth.
15. Pretend that you’re only presenting to someone in the very back of the room. This ensures that you’re loud enough for all to hear.
16. If the hackathon rules state that only work accomplished during the event is eligible, don’t enter work you’ve previously done. I’ve seen people present apps they did absolutely no work on during the hackathon.
17. Don’t make JPEGs and pretend it’s a real app. I’ve seen this happen.
18. Don’t lie and say you used a particular technology when you didn’t. I’ve seen this happen.
19. Be prepared to answer any questions about the technologies you used. I’ve seen people present apps they did not build. When questioned about the simplest details, they could not answer.
20. Don’t waste time building features you intend for a version down the road. Have a singular focus on accomplishing what you intend to present.
21. In the days before the event, watch hackathon presentations on YouTube. You’ll get a feel of what a good presentation looks like.

Have tips of your own? Contact me if you want me to list them here, and I’ll attribute them to you.  Or, you can be anonymous if you like.

It’s smaller than you might think, and plugs into your TV with an HDMI cable. You then project to it from compatible devices using Miracast.  I’ll tell you how to determine if your hardware is compatible in a minute, but first let’s talk a little more about Miracast.

There really is a bewildering array of choices when it comes to connecting devices in your home, and you’ll be forgiven if you’ve just about given up trying to make things work.  There’s Miracast, DLNA, WiDi, AirPlay, Chromecast, and I think one more whose name I forget right now.  To cut to the chase, Miracast is the way to go if you want to project exactly what’s on your computer or phone's screen to your TV.

Two Miracast-certified devices connect over an ad hoc WiFi network called WiFi Direct, which is different from your home’s WiFi network.  By that I mean a second WiFi network is created just between your PC and the Miracast receiver, without a wireless router in between.  Advantages of this are:

• Devices don’t need the WiFi network’s password
• You can easily bring your Miracast receiver to another location without reconfiguring it
• Your home WiFi network is not saturated with traffic you’re trying to stream, since you’ll be using a separate WiFi Direct network

With Miracast, you can stream full HD at 1080p, and it also supports protected content.  You can even stream from compatible Windows Phone 8.1 and Android 4.2 phones.  Actiontec maintains a list of compatible devices. Windows Phone 8.1 is available for developers now, and once it's widely available for consumers I suspect Actiontec will update their list.

How to tell if your PC is compatible

Windows 8.1 supports Miracast, but your PC’s hardware must also support it.  Fourth generation Ultrabooks will work, but most consumers probably don’t know if that’s what they have.  The best way I’ve found to determine Miracast compatibility is to see if the Project panel contains an option to Add a wireless display.  Open the Devices charm, select Project (or just hit the Windows key and P), and you should see this:

Click the Add a wireless display link, select your Miracast receiver, and connect. A password will be displayed on your TV's screen, and you'll enter that password on your PC. After this initial setup, it just works and the receiver will be displayed in the list of available devices, just as ScreenBeam is above. You won't have to enter the password again. Support is built into Windows 8.1, and you don't need to install anything extra.

If the link is missing, as in the following picture, then your system doesn’t support Miracast:

Does your TV already support Miracast?

Maybe.  The technology behind Miracast is called different things by different manufacturers.  I wish I could say something definitive here, but I’m afraid this part of the Miracast story is still confusing.  Of course if your TV supports Miracast directly, you don’t need a separate receiver.

How does AirPlay compare?

AirPlay is a similar technology from Apple, and it’s only available on their devices.  You connect an AppleTV to your TV with an HDMI cable, and then you connect the AppleTV to your home network using WiFi or Ethernet.  This is different from Miracast, which creates a WiFi Direct network distinct from your home network.  You can project an iPhone or iPad’s screen to your TV using AirPlay, but as of right now you can’t project a Mac’s screen.  From a Mac you can project from apps like iPhoto to display pictures on your TV, but you can’t just display anything on your screen.  To bring your AppleTV to another location, you’ll need to reconfigure it to use the other location’s WiFi password if you want to use it wirelessly.

How does Chromecast compare?

The Chromecast device from Google is a little different from Miracast and AirPlay.  The Chromecast connects directly into your TV’s HDMI port, and then you use an app to connect the Chromecast to your home WiFi network.  As of right now, your options for projecting from a computer are limited.  The Chrome browser can project some content, but not all.  A Chromecast is more commonly used from apps which have been built to support it, such as YouTube.  You connect to a Chromecast from a mobile phone, and issue a command to do something like play a video.  The Chromecast then streams the video directly from YouTube.  You can turn your phone off at this point, and the video will continue to play.  However, if you’ll ever want to project from your computer instead, Miracast is more flexible.

What do I use it for?

My top use of Miracast is for hackathons.  I connect the ScreenBeam Pro to a projector, and then hackathon contestants can project straight from their compatible devices.  This cuts down on the time required to set up computers between each presentation.  Besides this, I also use it to rehearse talks and watch videos from Pluralsight, Build, and Channel 9.

Here's a tour of the TryFsharp.org website:

1. Enable Diagnostic Logging
2. Download the logs with a FTPS client such as FileZilla
3. Open the logs in a web browser or text editor
4. Fix the problem

I made this screencast to walk you through the process:

Troubleshooting Azure Web Sites from Matt Harrington on Vimeo.

This post describes how to host Django projects in Azure Web Sites, a Platform as a Service (PaaS) offering. As with other PaaS offerings, you the developer concentrate on writing your app and not on infrastructure issues. You deploy to Azure Web Sites, and Azure handles things such as scaling out when your traffic increases, operating system patches, backups, and redundantly storing your data to protect against disasters. PaaS allows developers to focus on their app, and leaves routine maintenance issues to the platform. This post assumes you’re on OSX or Linux, and also using git. If you’re on Windows, use the free Python Tools for Visual Studio.

Here's a screencast which quickly goes over the steps in this post and shows the end result:

1. Get a free Azure account

Three options come to mind for getting an Azure account. The best option for many is to enroll in BizSpark. This program from Microsoft gives $150 per month in Azure credits to startups to use as they like. In addition to this Azure benefit, BizSpark members also get MSDN Ultimate subscriptions. Eligible startups need to be in the software business, be privately held, be under 5 years old, and be making less than US$ 1M in revenue. You don’t need to be a legal entity such as a partnership or corporation. Apply at http://www.bizspark.com and the BizSpark team will look at your application. This could take a few days.

If you don’t qualify for BizSpark, you can apply for one year of $150 per month in Azure credits through a program designed for open source developers. Of course, both Python and Django are open source. This offer also gives you a MSDN Ultimate subscription. To apply for this program, email opensource@microsoft.com and tell us how you plan to use open source on Azure. The team is also on Twitter, @OpenAtMicrosoft.

Lastly, you can just use a regular Azure account. All Azure accounts come with 10 free Web Sites and 10 free Mobile Services. Currently the Azure landing page emphasizes the free trial offer of $200 in usage or 30 days, whichever comes first. The free trial applies to everything in Azure: virtual machines, the CDN, directory services, and everything else. However, even after your free trial expires you still get 10 free Azure Web Sites and 10 free Mobile Services. This might not be obvious on the current landing page. You need a credit card to sign up for an Azure account, but the card will not be charged unless you explicitly remove the spending limit.

Pro-tip: You'll be asked for a phone number which will be used to verify your account. This seems to fail when Google Voice numbers are used. Try using a regular phone number instead.

2. Run your Django project locally with SQLite

To proceed, you need to have a Django project running locally on your system. Have it working with a local SQLite database. You should be able to successfully run the app with python manage.py runserver. For this post, I’ll be using code from the Django tutorial which creates polls and keeps track of answers. Here’s what my directory structure looks like:

db.sqlite3
manage.py
polls/
tutorial/

3. Provision an empty Azure Web Site

Log onto the portal. Click the New button in the lower left corner. Select Compute –> Web Site –> Quick Create. Choose a host name, and make sure you create your site in a region close to you. I use West US.

4. Provision a ClearDB MySQL database

You have many options for databases on Azure. This post will use MySQL. Microsoft partners with ClearDB to offer MySQL as a service on Azure. ClearDB handles tasks such as backups and scaling. You get a 20 MB database for free. Create a MySQL database by clicking on Linked Resources. Complete the wizard, making sure you create the database in the same region as your website from step 3, and then click on your database’s name:

This brings you to a management site on http://www.cleardb.com. In the ClearDB portal, click on Endpoint Information and copy your Hostname, Username, and Password. Then click on Dashboard. Download these 3 SSL certificates: ClearDB CA Certificate, Client Certificate, and Client Private Key. You’ll likely need to right-click on the Download link and choose Save target (or link) as.

The Client Private Key contains an embedded password. However, we need this certificate in a format with that stripped out. Use openssl to make the conversion, and note that your filenames will be different:

openssl rsa –in client-key.pem –out client-key-nopass.pem

Save the 3 SSL certificates in your app's folder

5. Edit settings.py to switch to MySQL

To convert from SQLite to MySQL, edit your app’s settings.py file:

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': 'DATABASE_NAME_GOES_HERE',
        'USER': 'USERNAME_GOES_HERE',
        'PASSWORD': 'PASSWORD_GOES_HERE',
        'HOST': 'HOSTNAME_GOES_HERE',
        'PORT': '3306',
        'OPTIONS': {'ssl': {'ca':'tutorial/cleardb-ca.cer', 
            'cert':'tutorial/client-cert.cer', 
            'key':'tutorial/client-key-nopass.cer'},},
    }
}

I placed the 3 SSL certificates in the app’s folder. Make sure you use the certificate key which you processed with openssl in step 4 to remove the embedded password.

You also need to install the MySQL adapter on your system. A portion of the adapter is written in Python, and a portion is compiled for the specific platform you’re on. If you're on OSX, the easiest way forward is to use Homebrew to install MySQL with brew install mysql. You also need Xcode installed so you have a compiler and headers. If you're on Linux, just install MySQL and the development tools through your distribution's package repository. After you have MySQL and a development environment set up on either OSX or Linux, run pip install MySQL-python. Windows users should just install the adapter through WebPI.

Since you’ve switched from SQLite to MySQL, you need to run python manage.py syncdb. This creates your app’s tables on MySQL in Azure. Then, run your app locally and save some data. It will be saved in Azure.

6. Set up MySQL Workbench

This step is optional, but worth it. MySQL Workbench is a desktop client from Oracle which talks to any MySQL database, including your database in Azure. Download it from Oracle, and configure it with the hostname, database name, username, password, and SSL certificates you used in step 5. Connect to your database, and you should be able to see your app’s tables and data you entered after running your project in step 5.

7. Install django and other modules into a local site-packages directory

The Azure Web Sites platform already contains Python, but it does not contain Django or other modules since versions change so quickly. If you include Django and other modules you’ll need in your project, they’ll be available for you on Azure. Create a directory called site-packages in the same level as your app's folder, and install your modules there. For example:

mkdir site-packages
pip install --target site-packages django
pip install --target site-packages pytz

In a future release, you’ll be able to simply include requirements.txt, and Azure will install the modules you need.

In step 5, you installed MySQLdb on your system. Remember that it contains both Python and platform-specific code. Since Azure Web Sites run on Windows, you’ll need a Win32 version of MySQLdb. Installing this in the future will be smooth and will use requirements.txt, but here’s how to do it right now. If you don’t have a Windows PC handy, you can download a Win32 version from my OneDrive. After you manually copy those files into into site-packages, it should look like this:

django/
Django-1.6.3.dist-info/
MySQLdb/
pytz/
pytz-2014.2-py2.7.egg-info/
_mysql.pyd
_mysql_exceptions.py
_mysql_exceptions.pyc
_mysql_exceptions.pyo

Of course, yours will only contain pytz if your app requires it. Mine does. Here’s a good time to mention that you need to move a module out of a Python egg and put it in site-packages. You can’t just include the egg right now.

Be sure to add and commit site-packages to your git repo. When finished, my project looked like this:

db.sqlite3
manage.py
polls/
site-packages/
tutorial/

8. Configure your Azure Web Site

We’re almost done. You need to create 3 key/value pairs in the Azure Web Site environment where your app will run, and you also need to configure the wfastcgi handler. In the Azure portal, click on the Configure tab and scroll down to App Settings. Add these 3 key/value pairs:

DJANGO_SETTINGS_MODULE    tutorial.settings
PYTHONPATH                D:\home\site\wwwroot;D:\home\site\wwwroot\site-packages
WSGI_HANDLER              django.core.handlers.wsgi.WSGIHandler()

My starting app is called tutorial, so DJANGO_SETTINGS_MODULE is set to tutorial.settings. Your app name will of course will be different.

Scroll down a little further to Handler Mappings and add this:

EXTENSION                 *
SCRIPT PROCESSOR PATH     D:\python27\python.exe
ADDITIONAL ARGUMENTS      D:\python27\scripts\wfastcgi.py 

9. Deploy to Azure

We’ll use git to push your code to Azure. You can push directly from a local repo, GitHub, BitBucket, Dropbox, TFS, or another external repository. In the portal, go to your site's Dashboard and click Set up deployment from source control. In the wizard, select where your repo lives. It’s pretty straightforward. A cool thing about using BitBucket or GitHub is that when you push to a branch there, Azure will pick up your code and deploy it. After you’ve deployed to Azure, simply browse to your site. You’re done!

Next steps

If you upgrade your site from the free tier, you can do things such as autoscale to handle traffic bursts, use a custom domain name, and incorporate SSL. Of course your BizSpark credit can be used for this.

Take a look at the cross-platform command line interface to Azure. First install Node.js, then run npm install -g azure-cli. Then run azure account download to download your account's publishing settings. With the Azure CLI, you can create Web Sites, create deployment scripts, create Virtual Machines, start and stop services, and more. All of this can be scripted too.

If you need to see your log files, check out another post from me: Troubleshooting Azure Web Sites.

Conclusion

With a PaaS offering, you shouldn’t have to care about the underlying platform. Azure Web Sites run on IIS on Windows, but OSX or Linux users can use it without problem. If you think of any features you’d like added, or something you’d like changed, definitely get in touch with me. We’re always looking for ways to improve things and value customer feedback above everything else. Also, if you end up permanently hosting a Django project on Azure, please let me know. Email me, or hit me up on Twitter @mh415.