There it Goes – Google Reader Gone for Good

Icon by http://icontexto.blogspot.de/  via Creative Commons Attribution Non-commercial Share Alike (by-nc-sa)First headline in this morning’s news: Goggle stopps Google Reader (please bear in mind, this link won’t work anymore in the future). Google wants to power down the Google Reader among other APIs and services since the 2011 spring clean. Personally, I am affected the third time by Google’s cut downs after the Feedburner burnout last year.

While I was annoyed in the very first moment, I had to think through various perspectives, not just coming up with yet another rant post about Google’s attitudes.

The Business Point of View
Google is not doing anything wrong (I guess) from a business point of view. They simply cut down projects, teams or cost centers with no or little revenue. I have seen this several times during my time at Microsoft where teams or studios where shut down due to a revenue not meeting the expectations. Larry Page wanted to focus on core products and  less speculative projects which does make sense considering the shareholders beyond Google. Consequently, cutting down free services not being paid for, requiring manpower for development an maintenance and (not to underestimate) bare metal down in Google’s data centers is a plan to increase revenues, cut down losses and save not to spend money.

The User ‘s Point of View
As a user, you might rely on these services. Maybe you build up your website based on various Google APIs (as they have been free), you maintained you RSS feed in Google Reader and so on. Even with several weeks of notice, you need to change technologies, maybe rebuild or recode you page, and even worse to change habits. At some point in time, after this happened one, two or three times (depending on your very personal potential to suffer).

The Developer’s Point of View
There are quite many apps, tools and pages out there heavily depending or based on Google’s API including Google Reader. Not only their apps and tools stop working, also users who bought these products will be forced to stop using these tools. With feedly, there is timely an alternative Reader and with Normandy developers get an API they might use for their products. However, Nick Bradbury already announced to stop working on the Windows client FeedDemon which heavily depends on the Google API for synchronization.More will definitely follow…

The Consequences
As developer, I was affected once before, as user I am affected the second time by now. By cutting down both services I am left with Google Calendar. While Google might or might not continue this service in the future, one might rethink if using it is a good choice. Keep in mind, we do not pay for it as users and the Google App Sync meanwhile is only available for business users (probably paying for it). Google Calendar Sync was a great tool to sync between Outlook and Google Calendar. I fought my way through the setup using Windows 7 three years ago right after they stopped development for it.

There is already an petition for keeping Google Reader alive, supported by more than 35,000 users (nothing compared to he 10 Mio user susing G+ stated by Larry Page). Still chances that Google will continue the service are less than probably.

The Business Point of View Revisited
I wonder if Google thought of charging for these services. I wonder if one (e.g. I) would pay for such a service. It definitely would depend on the amount they would charge. A few bucks a year won’t hurt and with a few ten thousands of users they might pay the bills for this service one might think. On the other hand, a company like Google might not be interested in any service with less than ten million $$$ of revenue (please put in whatever amount you think is suitable) or a million of users…

Fixing ASP.NET MVC 4 Web API 404

For a Web Service providing some REST-style URIs to access the data, I decided to use the ASP.NET MVC 4 Web API. Once developed, tested and deployed I experienced a mysterious 404 on my production server.

ASP.NET Web API 404

The Web API started originally as WCF Web API at CodePlex and is finally fully integrated within the latest .NET framework:

“ASP.NET Web API represents the joint efforts of the WCF and ASP.NET teams to create an integrated web API framework. You can get the bits and find articles, tutorials, samples and videos on the new ASP.NET Web API home page. All you have to do is to..”

The tutorials and examples for the ASP.NET Web API are overall easy to understand and you probably get  access to the technology very quickly. After I set up my first Web API, which worked absolutely perfect on Windows 8, developed using Visual Studio 2012 and tested with the IIS Express, I was not able to get the bits executed on the deployment server. It’s a Windows Server 2008 R2, IIS 7.5 and a whole bunch of stuff installed using the Web Platform Installer.

Make sure the .NET Framework is installed, probably you missed to install the 4.5 framework on the deployment server. As IIS is set up already, once again it is necessary to register ASP.NET for the latest framework using

C:\Windows\Microsoft.NET\Framework\v4.0.30319>aspnet_regiis.exe -i

Even now, I got the 404. Eventually, I got the tip to check out how the routing of extensionless URLs work in ASP.NET. By adding

<system.webServer>
    <modules runAllManagedModulesForAllRequests="true" />
    ...
</system.webServer>

to the web.config file of my Web API  the routing seems to work fine now.

How to get the favicon.ico from any Page

Recently, I was in the need of retrieving the favicon.ico file from a website. As I had to process the file programmatically and render it on a website, it would have been quite a lot of manual work to get the .ico file and make sure the browser does render it in the correct way. After digging around, I learned about a secret URI probably provided once by Google’s social bookmarking service Google Shared Stuff. While Google Shared Stuff was launched in 2007,  it was already discontinued in 2009. However, this one URI seems to work perfectly maybe because it is still used within Google extensively.

The Secret

To get the favicon.ico file from any arbitrary page you simply have to use an URI using the following pattern:

http://www.google.com/s2/favicons?domain=www.example.org

Eventually, this URI will provide you the following image: Image retrieved using http://www.google.com/s2/favicons?domain=www.example.org

How it Works

Some More examples to see how it works:

  • Facebook
  • TechChrunch
  • aheil blog
  • Google
  • dotnetpro Magazine
  • heise.de
  • Google+

As most of the sites do keep their favicon.ico file right in the root of the web site, others like Google don’t. Actually, you might find Google’s plus icon located at

https://ssl.gstatic.com/s2/oz/images/faviconr2.ico

While this is probably not a problem retrieving the favicon.ico file using the standard URI at all, the secret URI provides one major advantage: you’ll get the icon as a nice 16×16 PNG file, ready to be rendered in any <img> tag right away.

The Risk

As every time building up on a Google service as I did before, it might disappear tomorrow without notice leaving your site with quite a bunch of 404s though. Even worse, as it seems there is no official support for this URI, there won’t be any notice or deprecation period until switched of as done for other services like Feedburner.

IEEE Data Breach

A few days ago, Radu Drăgușin discovered a data leak at the IEEE servers, enabling him to download about 100.000 plain text keywords (probably mine as well).

On the one hand it shows how critical it is to consider the security off your system, nevertheless if you are a small company or a worldwide organization such as the IEEE. On the other hand it showed that even large organizations you never thought of this might face such fatal security leaks.

However, Radu went ahead and (a) decided not to share the information he gained through this security leak with public (big kudos for this decision), (b) to prepare various statistics on ieeelog.com based on the information (which are indeed interesting without revealing traceable information about individuals) and (c) to inform IEEE about the leak (also kudos for this). As a result you can say, he was quite responsible with the data he received and at least e followed some of the principles, provided by the IEEE Computer Society Code of Ethics.

One result of his analysis is the fact, that about almost 300 users are using the password 123456, reminding me Mel Brooks epic Star Wars parody Spaceballs, Dark Helmet saying

“So the combination is… one, two, three, four, five? That’s the stupidest combination I’ve ever heard in my life! That’s the kind of thing an idiot would have on his luggage!”

As a result, I went straight to my IEEE account and changed the password. Luckily, it was a password not used for any other site beside the IEEE. Said that, if you have an IEEE account, it probably is a good thing to go there directly changing yours as well if not already done.

Most used IEEE passwords

And Radu, whenever you ever read this post, if have the chance please have a look into the log files and let me know if the user aheil is listed there as well.

Feddburner Burnout

It is officially, the Google Feedburner APIs have been deprecated and will be officially shut down in the near future after being bought for about $100 million in 2007.

“Important: The Google Feedburner APIs have been officially deprecated as of May 26, 2011 will be shut down on October 20, 2012.”

For all readers of this blog subscribed to the google Feedburner feed, it has not been available using the URI http://www.feedburner.com/aheil probably providing a 404 error code for the last few days. The Feed Stats dashboard already shows that the feed has subscribers anymore.

. Feedburner Stats

Therefore, everybody looking for a RSS feed of this blog should switch over to http://www.aheil.de/feed?rss2.

I used Feedburner even before acquired from Google. It was a great way to aggregate various sources of information on the web. Even with a deprecation time of three years, it is quite a loss as Feedburner provided a great way of mashing up data sources. Probably this service did not generate sufficient revenue for Google…

Cross-domain Mash-up using Google Feed API

If you want to retrieve cross-domain content via AJAX/JavaScript to build a mash-up client, browsers might restrict these calls upon security reasons.

Digging through the resources on the Web, you might figure out that there are various approaches. I decided against any server-side processing of the request as I did not want to make an extra call to the my server. Also any jQuery plugin related approach would not work at the moment due to recent unavailability of jQuery plugins.

Looking for an alternative approach I came along the Google Feed API. Basically, it allows you to download any public Atom or RSS feed and consuming it in your JavaScript.

Once you got your API key which is based on the domain you want to call the API from, you can immediately  start using it.  The key is valid for all pages within this domain. Usage of the API includes adding the script your head of the HTML, loading the API using Google Loader’s load()call and finally hooking up your code as call-back in the setOnLoadCallback function. The feed is then provided either as JSON or as XML by the Google Feed API and can be easily used within you code without any cross-domain restrictions.

Google Plus Operator

Google has replaced the + (plus) operator for their search. While looking for a certain expression (using the plus operator) Google tells that from now an double quotation marks are necessary to find an exact expression.

SNAGHTML19b9b0e

Not sure if I like this, however, it looks like there are not many options to ignore this change. This probably has to do with all the G+ notation. It feels to me as bad as product and event names like .net or build which in combination with the new double quotation mark operator find some 2,490,000,000 results not relevant at all.

SNAGHTML19f637b

Bookmark Backup

Today, TechCrunch reported about Yahoo shutting down the widely used bookmark  service del.icio.us.Right after this, a statement from Yahoo showed a possible alternate future of the service.

Many of you have read the news stories about Delicious that began appearing yesterday. We’re genuinely sorry to have these stories appear with so little context for our loyal users. While we can’t answer each of your questions individually, we wanted to address what we can at this stage and we promise to keep you posted as future plans get finalized.

However, who still wants to quick backup his/her boomarks could use curl following the tips from Martin Koser:

curl --user username:password -o DeliciousBookmarks.xml -O "http://api.del.icio.us/v1/posts/all"

Master Pages and XHTML

Today, we encountered a really interesting issue with Visual Studio 2010, ASP.NET and Master Pages. Actually Visual Studio denied the design view for all of the pages within the solution except to the master page.

The page has one or more <asp:Content> controls that do not correspond with <asp:ContentPlaceHolder> controls in the Master Page.

No doubt you would check all the pages as well. After verifying that all pages have been correct, the ID as well as the ConteptPlaceHolderID tags are set correctly, you might see that the issue is till persistent.

Master Page Error

In this case check your HTML source code of the Master Page. In particular check for all HTML tags with self closing syntax. Referring the W3C Recommendation for XHTML section C.3 there are some tags that should be not used with self closing syntax.

Given an empty instance of an element whose content model is not EMPTY (for example, an empty title or paragraph) do not use the minimized form (e.g. use <p> </p> and not <p />).

Eventually, you now will review again your source code for any XHTML tags in their minimized form.

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head runat="server">
    <title />
    <link href="~/Styles/Site.css" rel="stylesheet" type="text/css" />
    <asp:ContentPlaceHolder ID="HeadContent" runat="server">
    </asp:ContentPlaceHolder>
</head>
...

In the example above change the title tag to

<title></title>

and the issue will be fixed. Even better would be of course to give your page a title.

While most browsers are quite forgiving here, the Visual Studio designer quits his job. Unfortunately, the error displayed is misleading and you might waste some time in reviewing Master Pages and ASP.NET controls that are obviously correct. Whether this is a bug or Visual Studio designer doing the right job and failing just for those tags based on the W3C Recommendation – it does of course not help a lot if Visual Studio does provide a misleading error message to the developer.

Migrating dasBlog to WordPress

Over the last couple of years, I run my blog using the dasBlog engine. As I started hosting the blog in 2004 on my own server, I choose dasBlog as it did not need any database on the backend, saved everything in XML and did a great job on the full text search over the XML content. Beside that, a blog engine running on ASP.NET seemed the right choice being familiar with the technology. Eventually, I did several fixes and hacks on my installation over the last few years. Unfortunately, there was no new release since March 2009. As I like playing with alternative technologies from time to time and WordPress comes with a rich set of features I miss at dasBlog, I decided to migrate to WordPress. In this article I will describe the steps moving forward to WordPress hosted on a Windows Server 2008.

Overview

Moving forward to the new platform includes several steps. First of all the server has to be prepared to host the new platform. After the new blog engine is set up, the content needs to be migrated. Finally, the old engine needs to be shut down and the server needs to be set up to forward requests to the old engine to the new one.

Installing WordPress

Installing WordPress should be relatively easy as it is available through the Microsoft Web Platform Installer 2.0. However, you might encounter issues during the process on machines running IIS 7 as the required Windows Update KB980363 causes the installation process to hang. The update process only hangs when started from within the Web Platform Installer, so pick it from the Microsoft Download Page and install the hotfix beforehand. Before installing WordPress you need to install PHP on the server. In addition to the instructions how to configure PHP on IIS 7, Ruslan Yakushev provides a very good tutorial how to set up FastCGI on Windows Server 2008.

Migrating from dasBlog to WordPress

Originally, I planned to use BlogML to migrate the content from dasBlog to Worpress. Instead I found dasBLogML which is a simple GUI wrapper around the original BLogML. First you download the content of the old blog to your local machine.

dasBlogML

To import the BlogML data, you might want to follow Edgardo Vega’s article. In order to avoid potential problems during the import, also have a look at Daniel Kirstenpfad’s tip about replacing all &nbsp; occurrences in the XML file. Using the BLogML Importer plug-in you can finally import the previously exported XML file.

Import BlogML

Redirecting dasBlog

In the final step I had to redirect the requests from the old blog to the new one. There are several issues to think about: First of all, all binaries are still referred from the old blog. Consequently it is not possible to just shut it down. Furthermore, there are many entries that are linked from several places all over the web.

My solution is to create a IIS module using managed code, and the ASP.NET server extensibility APIs. First of all I had a look at the schemes of the permalinks or URIs I have chosen for the old blog

http://www.blog.old/yyyy/mm/dd/articletitle.aspx

and the new one

http://www.blog.new/yyyy/mm/dd/article-title/

Consequently the HTTP module has to perform several steps: Replace the domains, remove the technology specific information in form of the .aspx file extension (technology specific information isn’t good practice anyway based on Tim Berner-Lee’s article about cool URIs) and finally add some hyphens. While the later is an somehow impossible task, there is an easy workaround. The scheme for permalinks I have chosen in WordPress will list all articles on a given day if you omit the article title in the URI. Consequently, the requested URI will be rewritten by the module to

http://www.blog.new/yyyy/mm/dd/

and sent back in the response with HTTP status code 301 (moved permanently) base on RFC 2616:

“The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.

The new permanent URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).“

Additional URIs that need to be processed are in the form of

http://www.blog.old/CategoryView,category,categoryname.aspx

Also this one is relatively easy as WordPress expects the category in form of

http://www.blog.new/category/categoryname/

Finally, the selection from the calendar in dasBlog looks like

http://www.blog.old/default,date,yyyy-mm-dd.aspx

and needs to be transformed into

HttpApplication application = (HttpApplication)sender;
HttpContext context = application.Context;

context.Response.StatusCode = 301;
context.Response.RedirectLocation = GetRedirectLocation(context.Request);
context.Response.Cache.SetCacheability(HttpCacheability.Public);

if (!context.Request.Equals("HEAD"))
{
    ...
}

To create the redirect locations I use a set of Regex objects that cover the most important URI types.

Regex singleUriPattern
  = new Regex("http://" + OLD_DOMAIN
  + "/[0-9]{4}/[0-9]{2}/[0-9]{2}/([\w-_\%+]+)*.aspx");
Regex categoryUriPattern
  = new Regex("http://" + OLD_DOMAIN
  + "/CategoryView,category,([\w-_\%+]+)*.aspx");
Regex dateUriPattern
  = new Regex("http://" + OLD_DOMAIN
  + "/default,date,[0-9]{4}-[0-9]{2}-[0-9]{2}.aspx");

Now everything beside the content can be deleted from the old dasBlog installation. In order to avoid any requests not covered by the previously deployed module, the custom error page for status code 404 is set to the corresponding URI on the news blog.

After deploying the module (into the bin folder of the dasBlog installation) it needs to be added to the web.config. Therefore you just have to add it to the httpModules section.

<httpModules>
  <add name="UriRedirector" type="RedirectModule" />
</httpModules>

Edit Custom Error Page Dialog

If the application pool is running in Classic mode, the custom error pages do not cover any ASP.NET content. Therefore add the customError section into to web.config file. Now all requests that do not request any content from the old blog or which a are not redirected by your module are covered by the new WordPress blog.

<customErrors mode="On">
     <error statusCode="404" redirect="http://www.blog.new/404/" />
</customErrors>

Conclusion

Now the content from the old dasBlog instance are displayed on the new WordPress blog, the most important links to your old dasBlog pages are covered by the URI redirection to the new blog and all the rest is caught by the WordPress blog as well. You might want to extend the redirect module with further regular expressions (e.g. to cover CommentView.aspx or other dasBlog pages).