The folks over at Code’n'Web produced these videos as a way to promote their “Texture Packer” software ($29.95). I find it quite brilliant actually and am going to give the software a try. Texture Packer packs those pesky sprites so you can get the most out of your sprite sheets.
GE is hosting a “Flight Quest” challenge and crowdsourcing the development community to come up with a new algorithm to more accurately determine flight arrival/departure times. Hence making flights more efficient.
You could win the $100,000 grand prize.
A blurb from the Flight Quest description…
Think you can change the future of flight?
Did you know airlines are constantly looking for ways to make flights more efficient? From gate conflicts to operational challenges to air traffic management, the dynamics of a flight can change quickly and lead to costly delays.
There is good news. Advancements in real-time big data analysis are changing the course of flight as we know it. Imagine if the pilot could augment their decision-making process with “real time business intelligence,”—information available in the cockpit that would allow them to make adjustments to their flight patterns.
Your challenge, should you decide to accept it:
Use the different data sets found on this page under Get the Data to develop a usable and scalable algorithm that delivers a real-time flight profile to the pilot, helping them make flights more efficient and reliably on time.
This seems like a really smart way for GE to tap into the internet community “hive mind” and expand their search for the perfect algorithm. I find it interesting that such a large company like GE is utilizing crowdsourcing vs paid employees within the GE ecosystem. A sign of the times.
As a personal challenge I’m going to pull down the data set and check it out. I urge you to do so as well. Anyone can sign up and who knows, you might win $100,000 or one of the many other cash prizes.
Flight Quest Website: http://www.gequest.com/c/flight
A great article has been posted to the Windows Azure MSDN blog about best practices for using push notifications, SMS and email in your iOS or Windows Phone apps as it relates to Azure Mobile Services.
Some interesting points…
- Mobile Services now fully supports Windows Store, Windows Phone 8 and iOS
- Configuring user auth in iOS is now a one liner.
- When to use Push vs Email vs SMS
- When using push notifications make sure you prune invalid or expired tokens from the DB
Overall a good read.
Windows Azure Mobile Dev Center: https://www.windowsazure.com/en-us/develop/mobile/
I use TFS for my source control, which makes it very nice when I want to add another computer to my arsenal. From a development standpoint TFS and relative references makes it very easy to get a machine up and running and ready to dev and since for the most part I can install Visual Studio Ultimate, Azure SDK and Windows Identity Foundation SDK and be up and running. One problem, I always forget to install SQL Server Express which is actually required by the Azure storage emulator. So what inevitably ends up happening is that I get everything ready working and compiling. Then I go to run my Dev fabric locally and it fails with the following error message…
Windows Azure Tools: Failed to initialize Windows Azure storage emulator. Unable to start Development Storage. Failed to start Storage Emulator: the SQL Server instance ‘localhostSQLExpress’ could not be found. Please configure the SQL Server instance for Storage Emulator using the ‘DSInit’ utility in the Windows Azure SDK.
You’d think I’d learn the first two times.
If you read the message it’s pretty self explanatory, simply install SQL Server Express and make sure you choose the default setting to use a named instance called “SQLExpress”. If you don’t have that named instance you will get the above error. I’m sure there’s some settings that can be changed to use dev storage against other named instances but for the sake of simplicity everything just works if you name the instance “SQLExpress”.
After you install SQLExpress all you have to do is try to run your application which will in turn fire up the dev fabric and automatically run an app called DSInit. DSInit will install the correct database schema into SQLExpress and everything from a dev fabric standpoint should be fine at this point.
Apparently, Microsoft assumes that everyone installs SQLExpress. Which I find kind of odd. I don’t use SQL and go NoSQL when I create something new therefore I run in to this typical problem because when I install Visual Studio I do a custom install and exclude many features of Visual Studio, which I don’t need.
Today I decided to set up my TFS in the Cloud Preview to use the newly activated Team Foundation Service Build Service. After setting up my build definitions, they kept failing with the following error:
The imported project “C:Program Files (x86)MSBuildMicrosoftVisualStudiov11.0Windows Azure Tools1.6Microsoft.WindowsAzure.targets” was not found.
After searching around on the InterWebs A.K.A. “A Series of Tubes” I found that the problem was more than likely related to the fact that beyond my better judgement I have the new Visual Studio 11 beta installed on my dev machine which currently doesn’t have support for ….wait for it…. WINDOWS AZURE projects.
Well isn’t that nifty!
To solve this problem you need to tell TFS that you want msbuild.exe to build using Visual Studio 2010 and not Visual Studio 11.
You can do this by adding the following MSBuild argument to the MSBuild Arguments field under the Process>Advanced section of the Build Definition edit window (see image below).
After setting the argument the build worked as expected. Good Luck and I vow to never install another beta again but more than likely I will because there’s nothing cooler than screwing up your dev environment just to get a glimpse at the future.
For the Cloudish application we are using the Windows Azure Access Control Service which works with the Windows Identity Foundation SDK to allow claims based federated authentication to our application.
In our development environment we wired everything up and after testing and tweaking we had authorization up and running and working perfect and as a result users are able to access Cloudish via federated authorization using their Google or Windows Live accounts.
So we finish our local development and decide to deploy to Azure and do some production environment testing. After deploying to Azure the status of the role starts looping in one of those awesome failure cycles where the status goes from Initializing to Busy to Stop and then repeats. Yippie! So the first thing we do is turn on intellitrace. For those of you who haven’t used intellitrace with regard to Azure, let me just say that it’s an invaluable tool in determining the inevitable scenario also known as “WTF is wrong with my deployment”. I’ll also say that 99.999999% of the time that we’ve had a problem with a role not starting in Azure it was because of a missing DLL that didn’t get correctly deployed to the cloud.
After some investigation using intellitrace we found that our problem was that the libraries required for the Windows Identity Foundation Runtime were missing. After hunting around we found that the missing libs were required to be installed to the GAC. Which poses the question, “How the hell do you get Windows Identity Foundation Runtime libraries installed into the GAC of an Azure role?”
After some further research we decided to run the installer for the WIF Runtime on deployment to Azure. This can be done using some nice features that the Azure team put in place for just such a scenario.
- The first thing that you need to do is download the windows update KB974405 .msu file and include it in the root of your Web Role or Worker Role project. Make sure that in the properties for the file that you have the BuildAction = “None” and Copy to Output Directory = “Copy Always”. This will include the file in the project output for the role.
- Next you’ll need to create a new .cmd file that we will use to script the installation of the .msu file. Create a text file and call it anything you want, we called it wifinstall.cmd. In the file add the following text, which when run in the cloud will install the WIF Runtime so that all the dll’s your app needs will be right where they are needed.
MS DOS123456789@echo offsc config wuauserv start= demandwusa.exe "%~dp0Windows6.0-KB974405-x64.msu" /quiet /norestartsc config wuauserv start= disabled
- Next you need to add your shiny new command file to the root of your Web or Worker role project with the same property settings you used for the .msu file in step #1.
- Next we need to tell Azure that we want to run this command file on deployment at startup. So we need to create a startup task in our Service Definition file. Open your ServiceDefinition.csdef file in your Azure Project. The following is a sample Service Definition file, note the Startup section and the child task that shows how to run the command with elevated permissions and as a simple task type.
- Finally, publish your project to Azure and your federated identity should be working. Or at least the dll’s should be there.
As you can see it was pretty simple to get this problem fixed and this solution shows that you can use startup tasks to initialize any prerequisites that your application might need up in the cloud.