SEO basics

An interesting video about SEO basics.
 
The most important knowledge:
1) Good SEO: proper page + proper links
2) Proper page:
  • Title tag filled according to the content
  • Description tag filled accordingly
  • Keywords are ignored these days.
  • There is one and only one H1 tag containing page title.
  • To be on the safe side, fill these tags (and other textes in the page) for the customers, not for the robots.

3) Proper links:

  • Use links with keywords (for example shop.com/products/Microsoft-Zune-80gb.aspx)
  • Delimit keywords in the link with “-“, not with “_”
  • Urls treated case sensitive by search engines, make sure your links are uniform (better lowercase).
  • http://shop.com, www.shop.com and www.shop.com/Default.aspx are different pages for the search engines. If 30% of your inbound links use shop.com, 65% www.shop.com and 5% the latter URL, the PageRank “power” of those links is splitted between the 3 Urls, even if they lead to the same page
  • Therefore stick with one version of the homepage url and use it uniformly (prefferredly use the short version, because people tend to type it in their blogs).
  • Inbound links from respectable pages improve the page ranking more than other links. Inbound links from malicious pages penalize the ranking. It is possible to see the figures a search engine has for your page, at least in case of live.com

4) When page is not found, don’t return an error page with HTTP code 200. Don’t return HTTP 404 either. Instead, redirect user to some other meaningful page of the site.

5) Don’t use HTTP 302 for redirects, only 301.

6) Tools:

https://siteexplorer.search.yahoo.com

http://webmaster.live.com

DLINQ vs SQL

I’ve compared SQL based data access layer with LINQ based one for a concrete use case: building a REST web service for high load systems.
 
My résumé reads as follows:
 
Generally, I would prefer to use SQL DAL for production code in high-loaded REST service systems. Not only it allows controlling all performance-relevant aspects, but also no DTOs are needed. In a typical high-load service with static pre-computed results, no business logic is expected to be performed during REST requests, so implementing DTOs is a clear development time overhead.
On the other side, when implementing mock services, it may be advantageous to use DTO LINQ, because of its DTO auto-generation features. When creating a mock service, it could be enough to create and populate a mock DB; and the DataContext and DTOs are generated just in seconds. If some custom attributes are required, it is also possible to switch to ad hoc objects at any time. Finally, the performance of mock services is unimportant.
ADO.NET Data Services (aka Astoria) should be additionally evaluated. While its output formats are fixed (JSON and standard Atom feed), it provides several promising features like CRUD operations and easy Windows Azure integration.

MSBuild Extension Pack

• System Items: Certificates, COM+, Console, Date and Time, Drives, Environment Variables, Event Logs, Files and Folders, GAC, Network, Performance Counters, Registry, Services, Sound
• Code: Assemblies, CAB Files, Code Signing, File Detokenisation, GUID’s, Mathematics, Strings, Threads, Zip
• Applications: BizTalk 2006, Email, IIS7, MSBuild, SourceSafe, StyleCop, Team Foundation Server, Visual Basic 6, WMI

http://www.codeplex.com/MSBuildExtensionPack

Julia Roberts, Training Wheels, and Bureaucracy

“When a young child first rides a bicycle, the bike is often equipped with training wheels to make learning easier. […]  But the full capabilities of the bicycle cannot be exploited while using training wheels—you certainly never see anyone in a bicycle race using them.”
“Businesses can’t win the competitive race using training wheels.”
 
 
I tend to agree with the article. If you’re in a full control, you’re too slow.
 
Another (and rather sad) story is, that (some) businesses don’t need to win the race because of their markt position. Think Deutsche Telekom for example.