Joe Mayo

Windows 8 for Developers Online Camp

Joe Mayo — Mon, 20 May 2013 23:01:52 GMT

Originally posted on: http://geekswithblogs.net/WinAZ/archive/2013/05/20/windows-8-for-developers-online-camp.aspx

On May 21st, Ziff Davis is hosting an eSeminar, Windows 8 for Developers Online Camp. Speakers include Greg Levenhagen, @GregLevenhagen, and myself. Here’s the agenda:

- Building a Windows 8 App in 15 minutes or less.
- Where is Microsoft headed, how it differs from others (Apple/Google), and why it makes sense.
- Win8 Development versus Android, iOS, and Pre-Win8 Dev
- What’s Different in Building for Windows 8?
- Understanding the potential to Make Money With Windows 8
- What it takes to submit an app (It’s not that hard)
- What help is available? (There is some very good, free help and tools available)
- Next Steps / Getting Started

@JoeMayo

Webinar: Async Programming in C#

Joe Mayo — Tue, 07 May 2013 16:40:52 GMT

Originally posted on: http://geekswithblogs.net/WinAZ/archive/2013/05/07/webinar-async-programming-in-c.aspx

Tomorrow, I’m doing a live webinar with Learn Now on Async Programming in C#. More details here: http://bit.ly/17JT792.

@JoeMayo

Global Windows Azure Bootcamp–4/27/2013

Joe Mayo — Tue, 23 Apr 2013 18:32:36 GMT

Originally posted on: http://geekswithblogs.net/WinAZ/archive/2013/04/23/global-windows-azure-bootcampndash4272013.aspx

Denver Windows Azure Bootcamp

On April 27th, 2013, join us at a Windows Azure Bootcamp in Denver, just one of the 95+ locations hosting this massive event. This free one day deep dive class will get you up to speed on developing for Windows Azure. The class includes a trainer with deep real world experience with Windows Azure, as well as a series of labs so you can practice what you just learned.

Register for the event today at https://gwabdenver.eventday.com. There are only 100 seats available so act fast!

This free training event will be hosted at Microsoft - Denver Tech Center - 7595 Technology Way Suite 400. Want more information? Check out http://globalwindowsazure.azurewebsites.net
and follow hashtag #GlobalWindowsAzure.

Not enough reasons to sign up? How about awesome door prizes:

JetBrains	- ONE (1) winner at each event gets a license of one of their products. The winner may choose from ReSharper, dotTrace, dotCover, PhpStorm, PyCharm, IntelliJ IDEA, AppCode, WebStorm.
PluralSight	- ONE (1) winner at each event will get a 1 Year Annual Subscription. - ALL Attendees will get a 7 Day training pass via a unique code.
Telerik	- ONE (1) winner at each event will get a DevCraft Complete (all their products).
Cerebrata	- ALL Attendees will get a license to the new Azure Management Studio product. There will be an email address they can use to request it.
Blue Syntax	- ONE (1) winner at each event can win a Cloud Backup Advanced Edition license.
MyGet	- ONE (1) winner at each event can win a 1 year Starter Subscription - ALL Attendees will get a 1 month starter subscription redeemable via an online sign up form.
Cloud Berry	- FIVE (5) winners at each event can win a Cloud Berry Explorer License - FIVE (5) winners at each event can win a Cloud Berry Drive License
AzureWatch	- ALL Attendees will get a free 30 day unlimited license, redeemable via a unique code.
Inner Workings	- ALL Attendees will get 90 days Free Training, redeemable online.
Zudio	- ALL Attendees will get a 3 month free trial redeemable via a unique code. - ALL Organizers will get a 1 year subscription.

Bonus points to take part in an experiment to set a record for the largest "Shared Workload" run by a community in a public Cloud. The general idea is to launch a ready-to-go Windows Azure deployment package in every event location around the world. The workload is a video rendering farm which will render videos from a set of depth frame images - a very CPU intensive workload that takes a lot of time to process. Progress will be measured by country and location and each participant will be able to follow this progress.

You know you want in. Register today!

Twitter API v1.0 Deprecation and Blackout Schedule

Joe Mayo — Tue, 16 Apr 2013 19:55:14 GMT

Originally posted on: http://geekswithblogs.net/WinAZ/archive/2013/04/16/twitter-api-v1.0-deprecation-and-blackout-schedule.aspx

Twitter has officially announced API v1 Retirement: Final Dates. The final date will be May 7th 2013. So, if you still have code running on Twitter API v1.0, you’ll need to upgrade to Twitter API v1.1. LINQ to Twitter has supported Twitter API v1.1 for months and you can download it from codeplex.com or NuGet.

To help people understand the impact, Twitter will be having a blackout period starting at 4:00pm PDT today. This is an opportunity to verify that all of your endpoints have been re-written to use Twitter API v1.1. If you’re using the latest version of LINQ to Twitter, you shouldn’t have a problem. This will mostly affect folks who have written their own plumbing code or are working with an older library that only supports v1.0.

@JoeMayo

Released LINQ to Twitter v2.1.05

Joe Mayo — Mon, 08 Apr 2013 15:36:04 GMT

Originally posted on: http://geekswithblogs.net/WinAZ/archive/2013/04/08/released-linq-to-twitter-v2.1.05.aspx

Today, I released LINQ to Twitter v2.1.05, which is available via NuGet or the LINQ to Twitter Download page.

This was a critical release because Twitter changed their OAuth handling logic, as explained in the discussion, “oauth/access_token Stopped working today” on their developer site. In particular, this change requires all access_token endpoint calls to include the oauth_verifier for out-of-band, OOB, authorization. What this means is that any applications using PIN authorization with LINQ to Twitter will break or are already broken.

Impact-wise, I wasn’t seeing a problem with Console applications, but it did break Windows Phone apps. What this tells me is that the change isn’t fully implemented across the entire Twitter API, yet. However, if you’re using PIN authorization on any application type, you’ll want to upgrade to LINQ to Twitter v2.1.05 or later because this change is likely to eventually affect everyone using PIN authorization.

@JoeMayo

Truth, Equality, and the Meaning of Null

Joe Mayo — Thu, 28 Mar 2013 23:04:49 GMT

Originally posted on: http://geekswithblogs.net/WinAZ/archive/2013/03/28/truth-equality-and-the-meaning-of-null.aspx

There’s been some discussion recently about whether it’s proper for a language to support null values or not. My guess is that the people having these discussions are a whole lot smarter than myself, so it’s probably best to defer to their judgment on any matters that might conflict with whatever I have to say. That said, there might be semantic differences in what is being referred to when discussing null. Perhaps one discussion regards the logical operation or state of code, whereas my perspective in this post is on data.

There was a time when I was fascinated by subjects such as truth, equality, and the meaning of null. Especially when thinking about data, null is an interesting subject. In a relational context, null means the absence of a value. When writing code, the meaning of null is determined by your domain. You typically won’t have a specific requirement, use case, or story that tells you how to work with a null value when first writing the code and your logic is often inferred. It’s often when a bug appears in your code that a formal requirement might be specified, but I say “might” loosely because handling of null is a technical requirement and the bug would probably be stated as the functional requirement to satisfy. This is why null values are often so aggravating because they bubble up later in the application lifecycle where they’re more painful to deal with. This seemingly mundane topic of existence appears to be more important than one may think.

Today I encountered a null in the wild and all the related discussion compelled me to investigate. I was adding a new field to the LINQ to Twitter Status entity named FavoriteCount. This relates to the Twitter Tweets favorite_count field. What caught my eye is the definition of favorite_count identifies the field as Nullable. I know what Nullable means in relational and .NET parlance, but Twitter is a different world. So, I went to the Twitter developer’s site and asked, “What is the Meaning of null favorite_count?”. I’ll quote an important part of @episod’s answer:

The state of null is usually reached because it was not possible at the time of servicing the request to provide a value in that field -- an underlying system could have taken too long to respond, or a null value got cached at some other point in time when that happened.

One could say that this is the same thing as the “absence of a value” definition I mentioned earlier, but there’s an important nuance here in the context of the data source and nature of the application. The “absence of a value” comes from a relational ACID transaction perspective where you have what you’re going to get. However, Twitter is a massively scalable system that uses a NoSQL data source. From the answer and the scalable NoSQL perspective, the true value of favorite_count may not be null at the point in time that you’re looking at it, but you don’t know for sure. I believe the proper term for this phenomenon is Eventual Consistency. There’s some hair splitting that can be done here, but I’m speaking in general terms.

In my initial question about the favorite_count field, I wondered whether it was safe to assume that a null value meant 0. Making a blanket assumption like that could certainly cause some trouble and it would be unwise for me to make that assumption on behalf of the developers using LINQ to Twitter. e.g. What if an application would rather monitor a tweet for N minutes to see what the real favorite_count was after it initially appeared as null? There are variations of this theme, but it’s a situation where I would want to expose functionality that was meaningful and allowed the developer to know the true state of an entity.

To understand what null is and put it into context is an important endeavor, especially in keeping customers from hating you and reducing project lifecycle costs. However, you still need language support unless you regress to kludges of earlier platforms. In the first version of .NET you could encounter code that either treated a value as a string or used some other mechanism, such as an alternate value to represent null values. I can’t count the number of different representations of DateTime value system I encountered in those days and the headaches of accepting defaults of different databases with null values. Of course, ADO.NET has the DBNull type and there were 3rd party libraries that special types that allowed you to represent nullable value types. .NET 2.0 introduced the Nullable<T> type and added special language support to C#, where you could add a Nullable suffix, such as DateTime?. These days, it’s easy to represent null data in a consistent way with both .NET Framework and language support.

Null data is a reality. Old databases often have null values. These old databases also have applications with logic that relies on the null data. The cost/benefit of a re-write can result in leaving things as is. There are also current scenarios where null makes sense, such as when having Created and Modified fields on a record where it doesn’t make sense to provide a value for Modified because the record hasn’t changed since it’s initial value. One could argue that Modified should have the Created time and application logic would detect this fact or perhaps another design would be more appropriate, but the fact is that you’ll find people with differing opinions on what the data design should be in any given situation and sometimes the argument for null will win. I’m not one to fall on my sword for a null value when it’s possible to write code to deal with it. Another perspective, as mentioned earlier is the NoSQL world with eventually consistent data. Regardless of what arguments you have on that, the reality is that you will be working with APIs, public data, and situations where the need for scalability results in null data making sense or being the best choice to meet requirements.

So, I’m not trying to say that someone else’s opinion of null is wrong. However, it seems like there are nuances to consider before declaring that “Null is Evil!” Our industry is plagued with never-ending battles of who’s platform or language is best and the true answer can sometimes be found in-between. While Scientists debate What is Nothing, VB developers can relate and C# developers can say that’s equivalent to null. Or is nothing really something to care about?

@JoeMayo

IOException on WebRequest.Create in .NET 4.5

Joe Mayo — Thu, 28 Mar 2013 03:59:54 GMT

Originally posted on: http://geekswithblogs.net/WinAZ/archive/2013/03/27/ioexception-on-webrequest.create-in-.net-4.5.aspx

I was testing .NET 4.5 compatibility in LINQ to Twitter when I encountered an IOException with the message: “The specified registry key does not exist.” This occurred during a call to System.Net.WebRequest.Create().

This is something that happened after a Windows update, kb2745030. Since this is a security issue, you’ll want to read Microsoft’s article and make your own determination on what to do. Someone has already reported the issue on Connect with a work-around similar to the Microsoft Kb article, WebRequest.Create eats an IOException on the first call.

@JoeMayo

Exception Handling for LINQ to Twitter Streams

Joe Mayo — Sun, 24 Mar 2013 05:47:38 GMT

Originally posted on: http://geekswithblogs.net/WinAZ/archive/2013/03/23/exception-handling-for-linq-to-twitter-streams.aspx

Tonight, I checked-in changes to streaming in LINQ to Twitter. The primary refactoring was to remove the automatic error handling that had been in place since the beginning of stream support in LINQ to Twitter.

The primary problem with my previous approach is that a 3rd party library should not be performing exception handling on behalf of a developer. Originally, I thought it would be a great feature to do what I could to reduce the pain associated with HTTP exceptions that occur when communicating with Twitter. The basic functionality I’m referring to is the need to catch exceptions and retry with a back-off strategy that’s consistent with Twitter’s guidance for Connecting with a streaming endpoint. However, the issue is that the developer doesn’t really see what is happening unless they watch the log messages that LINQ to Twitter produces or perform their own debugging. The previous design reduces a developer’s ability to help themselves. Moving forward, anyone who needs to use streams should design their own approach, following Twitter’s guidelines.

If you are a current user of LINQ to Twitter’s streaming support, you’ll need to implement error handling if you upgrade to the next release, which will be v2.1.05. If you would like to get started early, the new source code is available for download.

@JoeMayo

Released LINQ to Twitter v2.1.04

Joe Mayo — Fri, 15 Mar 2013 14:40:16 GMT

Originally posted on: http://geekswithblogs.net/WinAZ/archive/2013/03/15/released-linq-to-twitter-v2.1.04.aspx

Today, I released the latest version of LINQ to Twitter, v2.1.04. Many of the modifications include new parameters for commands and queries, or new Entity properties. A few items were deprecated, so look for Obsolete warnings and minor changes to overloads. i.e. Since Twitter automatically wraps all links with t.co URLs, the WrapLinks parameter is deprecated.

Some notable changes occurred in the areas of authentication where there was a bug fix to WinRtAuthorizer, basic streams use OAuth, and I added a new ApplicationOnlyAuthorizer:

WinRtAuthorizer Bug Fix – There was a race condition with the async implementation of AuthorizeAsync on the WinRtAuthorizer. This is now fixed and, if you’re using WinRtAuthorizer, you’ll want to upgrade to upgrade your version of LINQ to Twitter if you’re using v2.1.03 or earlier.

OAuth in Basic Streams – User streams and Site streams already use OAuth, but the Basic streams such as Filter, Sample, and Firehose were originally implemented with username/password authentication. Twitter API v1.1 requires OAuth on all streams, so I removed the capability to perform username/password authentication and implemented OAuth. Since Twitter API v1.0 will be deprecated within weeks, you’ll want to upgrade to ensure your streams keep working.

ApplicationOnlyAuthorizer – This is a new authorizer in LINQ to Twitter. On Mar 11, Twitter announced Application-only authentication. Within hours, I had implemented and checked it into LINQ to Twitter. This authorizer, as it’s name implies, is intended for non-user scenarios. A user is someone who logs on, tweets, or performs some other action on their own behalf. However, an application can run in stand-alone mode on the server as a scheduled job, service, or worker-role, which would be a good choice for application-only authorization.

Finally, I want to give a shout-out to a few people who contributed code to this release: Greg Ennis and Ayo Adesugba. They both submitted pull requests. There were also people who submitted new issues that either describe a problem in detail with a recommended solution or provided the code to fix a problem, in the Issues area of the LINQ to Twitter site on codeplex.com.

Downloads:

LINQ to Twitter v2.1.04 via CodePlex.com

LINQ to Twitter v2.1.04 via NuGet

@JoeMayo

WinRtAuthorizer–A Better Way to do OAuth with LINQ to Twitter in Windows 8

Joe Mayo — Sat, 19 Jan 2013 21:07:09 GMT

Originally posted on: http://geekswithblogs.net/WinAZ/archive/2013/01/19/winrtauthorizerndasha-better-way-to-do-oauth-with-linq-to-twitter.aspx

Last July, I blogged about how to do OAuth in Windows 8 with LINQ to Twitter:

http://geekswithblogs.net/WinAZ/archive/2012/07/02/using-linq-to-twitter-oauth-with-windows-8.aspx

A the time, that worked well, but was still not an optimal solution. It required setting up a page to handle a WebBrowser control, navigating to that page, authorizing, and then asked the user to copy a PIN into a text box to complete the dance. You still have to do that with desktop and Windows Phone apps, but not with Windows 8 apps anymore.

LINQ to Twitter now has a new authorizer, called WinRtAuthorizer. It’s based on the WebAuthenticationBroker and allows a seamless integration of the OAuth workflow with your app. You don’t need PIN numbers anymore. This post shows how to use WinRtAuthorizer to perform OAuth authentication with LINQ to Twitter. There are essentially two steps: instantiate WinRtAuthorizer and Authorize.

Instantiating WinRtAuthorizer

WinRtAuthorizer is much like other authorizers with LINQ to Twitter. The main difference is that I’ve included various credential stores for managing credentials. Here’s an example that instantiates a new WinRtAuthorizer that stores credentials on your local machine.

            var auth = new WinRtAuthorizer
            {
                Credentials = new LocalDataCredentials
                {
                    ConsumerKey = "",
                    ConsumerSecret = ""
                },
                UseCompression = true,
                Callback = new Uri("http://linqtotwitter.codeplex.com/")
            };

The code above instantiates a WinRtAuthorizer, using object initialization syntax. I’ll discuss the Credentials property in a moment, but want to quickly point out that setting UseCompression to true will cause the underlying HTTP request to be sent to Twitter with GZip compression. The underlying authentication code expects a Callback Uri, which isn’t used in this case, but is still required. You can use the callback address that you specified as the Web callback when setting up your application and received credentials at the Twitter developer’s site.

This particular example uses LocalDataCredentials to store credentials in local data. LocalDataCredentials is just one way to store your credentials and you can create your own custom class to save credentials by implementing IOAuthCredentials, a LINQ to Twitter type, yourself. In particular, I’ve created the following hierarchy of IOAuthCredentials types to support Windows 8:

IOAuthCredentials
    WinRtCredentials
        LocalDataCredentials
        RoamingDataCredentials
        TemporaryDataCredentials

WinRtCredentials is a base class that supports a set of credential types unique to Windows 8. LocalDataCredentials stores credentials on the local machine, meaning that they persist for the authenticating user, but only on the machine where the authentication took place. RoamingDataCredentials uses the Windows 8 roaming data feature that persists credentials in the cloud, allowing the user to authenticate only one time and be authenticated on any other machine without needing to re-authenticate. TemporaryDataCredentials exist for at least the lifetime of the current session, but aren’t guaranteed to be available after that.

Authorizing

On the surface, performing the authorization part is dirt simple, but there are nuances that you might be curious about or eventually encounter in practice. The following code checks to see if the user is already authorized and, if not, performs the authorization:

            if (auth == null || !auth.IsAuthorized)
            {
                await auth.AuthorizeAsync();
            }

The first part of the code above checks the IsAuthorized property. Sometimes, this is a little confusing because the purpose of this is to verify whether the user’s authorization credentials are loaded into the IOAuthCredentials type instance of the authorizer. The four credentials are the ConsumerKey and ConsumerSecret that Twitter gives you as part of your application, and the OAuthToken and AccessToken that the Twitter API gives your code after the authentication process. If all four credential tokens are loaded, IsAuthorized returns true.

What IsAuthorized does *not* do is check with Twitter to verify if the credentials are valid. There’s an API call, VerifyCredentials, that’s specifically for that purpose. I could have embedded the VerifyCredentials call into the IsAuthorized, but there are a couple problems with that – it would have used more bandwidth and consumed rate limit – all without your knowledge. The current design gives you more flexibility.

This design also recognizes the fact that once Twitter gives you credentials for a user, those credentials don’t normally change. However, one scenario where the OAuth process can fail is if the user removes your application from their list of authorized applications via their Twitter settings page. If that happens, you’ll encounter an exception with an HTTP message of 401 Unauthorized the next time the user tries to use your application. In that case, you should delete existing credentials and make the user authorize your application again, using the process explained in this post.

This gives you the choice of either calling VerifyCredentials yourself or writing code to handle the exception, but LINQ to Twitter doesn’t take that design decision away from you.

If the user isn’t authorized, await the call to AuthorizeAsync. Through the magic of WebAuthenticationBroker, WinRtAuthorizer takes care of opening and closing the brower control and the user doesn’t need to copy a PIN number anymore. All you need to do is use the authorizer.

Using the new WinRtAuthorizer Instance

That’s all there is to it. Once you have a WinRtAuthorizer instance, just use LINQ to Twitter as normal. Here’s a quick example:

            var twitterCtx = new TwitterContext(auth);

            var searchResponse =
                (from search in twitterCtx.Search
                 where search.Type == SearchType.Search &&
                       search.Query == SearchTextBox.Text
                 select search)
                .SingleOrDefault();

            string message = 
                string.Format(
                    "Search returned {0} statuses", 
                    searchResponse.Statuses.Count);

            await new MessageDialog(message, "Search Complete").ShowAsync();

This is a normal LINQ to Twitter search. The only thing you need to do is instantiate TwitterContext with the new WinRtAuthorizer instance.

Summary

WinRtAuthorizer is the preferred way to perform OAuth with LINQ to Twitter. You do this by creating an instance of WinRtAuthorizer, selecting the credential store you want, and then awaiting a call to AuthorizeAsync.

@JoeMayo