Random Technology Musings
Yep. It does. Awesome. A taster:
HAI IM IN UR BUCKETS MAKING UP FORMATS GIMME UPLOADS FROM ROBERT SCOBLE I CAN HAS PHOTO RACKSPACE CTO IN NASA BRIG ITZ AT http://www.flickr.com/photos/scobleizer/4931518474/ INVISIBLE METADATA LOL KTHX.I IS BORED KTHXBYE.
See more here.
PS Only a true geek could be jazzed at this. I ain’t apologising for that. 🙂
Update: Here’s the related screencast episode.
As you may have noticed in the last episode (episode4), writing the Feed Reader has got to the stage where we require UserID’s.
Given the delicate nature of login credentials and the security precautions required, its much easier to hand off the details to Google Federated Login, or even Windows Live ID. These services simply give us a return token indicating who has logged in.
The previous version of the feed reader used Windows Live ID. Its a very simple implementation. It consists of a single MVC controller, and a small iFrame containing the login button. It’s elegantly simple. Since its MVC, there are no issue running it on Windows Azure. The reason why I picked it the last time, was a) its simplicity and b) its part of the Windows Azure ecosystem.
The alternative is to use Google Federated Login. This is a combination of OpenID and OAuth. The implementation is certainly much more involved, with a lot of back and forth with Google’s Servers.
![OpenIdDiagram[1]](https://blog.robertobonini.com/wp-content/uploads/2010/08/openiddiagram1.png "OpenIdDiagram[1]")
As you can see, an involved process.
There is a C# library available called dontnetopenauth, and I’ll be investigating the integration of this into MVC and its use in the Feed Reader.
There is one advantage of using Google Accounts, and that’s the fact that the Google Base Data API lets us import Google Reader Subscriptions.
It may well be possible to allow the use of dual login systems. Certainly, sites like stackoverflow.com use this to great effect.
Why is choosing an external login system important?
Well, firstly its one less username and password combination that has to be remembered.
Secondly, security considerations are onus of the authentication provider.
If we were to go with multiple authentication providers, I’d add a third reason: Not having an account with the chosen authentication provider is a source of frustration for users.
So, the question is, dear readers, which option would you choose?
As you’ve no doubt surmised from the title, this weeks episode deals almost entirely with the OPML reader and fitting it in with the rest of our code base.
If you remember, last week I showed a brand new version of the OPML reader code using LINQ and Extension Methods. This week, we begin by testing said code. Given that its never been been tested before, bugs are virtually guaranteed. Hence we debug the code, make the appropriate changes and fold the changes back into our code base.
We then go on to creating an Upload page to upload the OPML file. We store the OPML file in a Blob and drop a message in a special queue for this OPML file to be uploaded. We make the changes to WorkerRole.cs to pull that message off the queue and process the file correctly, retrieve the feeds and store them. If you’ve been following along, none of this code will be earth shattering to you either.
The fact is that a) making the show any longer would bust my Vimeo Basic upload limit and b) I couldn’t think of anything else to do that could be completed in ~10 minutes.
The good thing is that we’re back to our 45 minute-ish show time, after last weeks aberration.
Don’t forget, you can head over to Vimeo to see the show in all its HD glory: http://www.vimeo.com/14510034
After last weeks harsh lessons in web-casting, file backup and the difference between 480p and 720p when displaying code, this weeks show should go perfectly well.
Enjoy.
Remember, the code lives at http://windowsazurefeeds.codeplex.com
PS. Some occasional interference in the sound. I’m wondering if the subwoofer is causing it while I’m recording it. Apologies.
Sorry for the lateness of this posting. Real life keeps getting in the way.
This weeks episode is a bit of a departure from the previous two episodes. The original recording I did on Friday had absolutely no sound. So, instead of re-doing everything. I give you a deep walkthrough of the code. Be as that may, I did condense an hours worth of coding into a 20 minute segment – which is probably a good thing.
As I mentioned last week, this week we get our code to actually do stuff – like downloading, parsing and displaying a feed in the MVCFrontEnd.
We get some housekeeping done as well – I re-wrote the OPML reader using LINQ and Extension Methods. We’ll test this next week.
The final 20 minutes, or so is a fine demonstration of voodoo troubleshooting ( i.e. Hit run and see what breaks) but we get Scott Hanselmans feed parsed and displayed. The View needs a bit of touching up to display the feed better, but be as that may, it works.
Since we get a lot done this week, its rather longer – 1 hour and 9 minutes. I could probably edit out all the pregnant pauses. 🙂
Here’s the show:
Success! My 2nd HD attempt uploaded last night. Click here to see the HD on vimeo.com. Enjoy.
Remember, the code lives at http://windowsazurefeeds.codeplex.com
The term “money quote” best describes this paragraph:
There are no guiltless parties with white hats in this little drama. This skirmish isn’t much about patents or principles or programming languages. The suit is far more about ego, money and power.
The rest of James’ post is worth a read.
A few days late (meant to have this up on Tuesday). Sorry. But here is part 2 of my Series on building a Feed Reader for the windows Azure platform.
If you remember, last week we covered the basics and we ended by saying that this week’s episode would be working with Windows Azure proper.
Well this week we cover the following:
Now, I did do some unplanned stuff this week. I abstracted away all the storage logic into its own worker class. I originally planned to have this in Fetchfeed itself. This actually makes more sense than my original plan.
I’ve added Name services classes for Containers and Queues as well, just so each class lives in its own file.
Like last weeks, this episode is warts and all. I’m slowly getting the hang of this screencasting thing, so I’ll be getting better as time goes on I’m sure. Its forcing me to think things through a little more thoroughly as well.
Enjoy:
Next week we’ll start looking at the MVC project and hopefully get it to display a few feeds for us. We might even try get the OPML reader up to scratch as well.
PS. This weeks show is higher res than the last time. let me know if its better.
The rumours are:
I just left this reply to this post on the GeekTonic blog discussing the AppleTv rumors that will not die.
Well… 1080i or p is only really viable if you have cable internet… and its a really small market. So 720p is pretty much a good bet as the default res.
I don’t care what anybody says – I ain’t streaming movies. Not with a 15gb fair use download cap. I’m getting a local copy of everything. Download once re-use all over the house. However, a 16Gb capacity is barely enough for the photos I have on the Apple Tv. Currently I play all my TV shows off the server rather than sync them. So while not being able to cache much content locally on the device, as long as i can download a copy to the server, I’m happy.
An App Store would be great – though I would assume it wouldn’t be backwards compatible with older AppleTvs – since it would require apps to be recompiled ( or even re-written) for the older hardware/CPUs.
The $99 price point is also awesome. It does open up the market. Its under the psychological $100 barrier – so people will be more likely to buy it.
The form factor is a persistent rumour – however I don’t see the logic of it. Given the clutter in the TV closet, there’s a real chance of me loosing it. However it will be a boon to those who already have too many set-top boxes in their Tv closets – look out for Steve to mention this prominently in any event. I still think its possible that Apple may keep the current form factor in some way.
However, unless the new Apple Tv ( or as you say, iTV) launches with some really awesome apps that will be worth the outlay of $99, I can’t see myself rushing out to buy one. Since we got satellite Tv installed with the accompanying HD-PVR a few weeks back, the use of the AppleTv has declined a lot – like 2 or 3 times a week as opposed to every day. Purchases sinc3e can be counted on one hand.
So a bit of a mixed reaction to this.
LINQ is the gift that keeps on giving. Literally. Its unbelievable the stuff I’ve seen LINQ do.
Ian Griffiths over at IanG on Tap has been doing a blog post series on LINQ and N-ary Cartesian Products.
He’s got a few posts left to publish.
I’ve rather enjoyed reading this over my tea in the mornings.
Enjoy.
As I announced last month, I’ll be screen casting my efforts on the Windows Azure Feed reader.
Well, a couple of weeks ago, I just went ahead and did the first episode. The delay between recording it and posting is due to a weeks holiday and a further week and a half spent offline due to my ISP.
I’ve open sourced the code to http://windowsazurefeeds.codeplex.com.
In this episode I cover:
I’ve tried not only to explain what I’m doing, but also why I’ve done things this way – with a view to how it will affect things down the road.
So here is the screencast:
Next time we’ll begin integrating things with our worker and web roles. We’ll be working with blobs and queues. And we’ll start chewing through some live data.
I’ll try keeping to a weekly schedule, but my schedule of late is anything but regular and predictable.
Enjoy.
Just pushed out a new version of the application. I added the live feeds from the Ocean Intervention II and Viking Poseidon.
So there are a total of 12 feeds available forming 6 panels:
As usual you can add and remove panels as you wish:
This is an alpha release, so it still needs work.
You can download it from here: http://oilslickfeeds.codeplex.com/releases/view/48477
I’ll let you know when a more polished build is done.
Random Musings 
You must be logged in to post a comment.