A not-bad article on WinRT for .NET devs like me

Turning to the past to power Windows’ future: An in-depth look at WinRT

http://arstechnica.com/features/2012/10/windows-8-and-winrt-everything-old-is-new-again/

Advertisements
A not-bad article on WinRT for .NET devs like me

A tool to simplify and automate your SQL Azure database backup

So you have one or more SQL Azure databases that have data stored you treat really seriously and want to back them up on a regular basis like what you usually do for on-premises databases. However, the backup/restore story in Azure is different from on-premises. What you can do is to leverage the existing options provided by Azure platform. Following is a list of references you want to check out.

Business Continuity in SQL Azure
http://msdn.microsoft.com/en-us/library/windowsazure/hh852669.aspx

SQL Azure Backup and Restore Strategy
http://social.technet.microsoft.com/wiki/contents/articles/1792.sql-azure-backup-and-restore-strategy.aspx

How to Use Data-Tier Application Import and Export with SQL Azure
http://social.technet.microsoft.com/wiki/contents/articles/2639.aspx

Copying Databases in SQL Azure
http://msdn.microsoft.com/en-us/library/windowsazure/ff951624.aspx

However, if you really want to automate the backup operation and save some manual efforts, you then need to write some codes/scripts to orchestrate all these existing options and maximize the overall goodness that you can get from these options.

Now, here is the good news, a tool (SQL Azure Data Protector) is created for you just to do all these things. What you only need to do is:

  • Download and install the little tool on a machine that usually schedules Ops tasks for you
  • Create a profile (configurations like server names, credentials, locations, storage account, etc.)
  • Schedule a periodic task using, for example, Windows Task Scheduler

If you want to understand more details about how this tool works, you can read the documents. Of course, you can also check out the source codes directly, as well.

Till next time,

-Jack

A tool to simplify and automate your SQL Azure database backup

win 8 doesn’t like WEP Wi-Fi connection

My newly installed win 8 system failed to connect to my home Wi-Fi without any useful information provided. I tried many times, and it always failed. Then I tried to re-configure my router to change the security type to WPA2-Personal and used AES algorithm for the encryption type. And now win 8 can connect to my home Wi-Fi like a charm.

WEP is basically non-secure, so if you encountered the same issue as mine, you can try the same approach to see if it would be the rescue.

Till next time,

-Jack

win 8 doesn’t like WEP Wi-Fi connection

I like this statement: The 100% coverage practice is costly only when it forces substandard code to be well designed.

And it is from a post of Patrick Smacchia on simple-talk.

Patrick wrote an essay about writing unit testing code in c#, in which I personally found a lot of good points that I could not agree more. For example:

  • Not all classes need to be 100% covered by tests or even covered at all.
  • The 100% coverage practice is costly only when it forces substandard code to be well designed.

And especially for the second one, I think it is inspirational and encouraging. I faced situations from time to time that for some certain pieces of codes/logic, it was difficult to write a comprehensive test suite to cover all the branches. Honestly, most of time when I faced this, I will choose to leave the coverage not to 100% and accept the fact. But after reading this, from now on, I will try my best to achieve the 100% coverage by not only writing comprehensive test cases, but also refactoring the “difficult” logic to the best designed, intuitive, and enjoyable to read codes.

I like this statement: The 100% coverage practice is costly only when it forces substandard code to be well designed.

Be careful when you use both Windows Azure Diagnostics and auto cspack build

Recently, one application I work on encountered an interesting issue. We have configured WAD to forward the Windows event logs to a storage account. And it used to work very well. However, after a recent new deployment, all Windows event logs on the web role machines stopped to forward. Logs on worker role machines are still transferred, though.

We re-examined all the configurations, Entry Point codes to start WAD monitor, storage account connection string. Everything looks fine because we didn’t change them for the latest release.

Then what the heck happened to the web role machines? The application works fine, logging works fine. Only WAD doesn’t work? And I didn’t notice any WAD related errors.

I searched the Internet and came to this post which helped resolve the problem. I actually use another approach to resolve this particular issue. But the essential part of the approaches are the same.

So, the issue is due to we changed the auto build approach for the latest release. Originally prior to the new build method, we simply use the Publish target of Windows Azure MS Build extensions. However, for the latest release, since we enabled CodeSign to all our assemblies, we need to repack the Azure package to include the CodeSign-ed assemblies. And the original Publish target is not very convenient to be integrated into the TFS build system.

We updated the TFS build template to include a new activity which simply invoke the cspack to repack the Azure deployment package. And in the arguments of the cspack command, we missed the EntryPoint part of the /role parameter for the web role of our application.

After simply changing the TFS build template, now the new package restarts to initialize WAD and all the logs on the web role machines come to storage as expected.

Hope this helps,

-Jack

Be careful when you use both Windows Azure Diagnostics and auto cspack build