Everyone is looking for a competitive edge in the Search Engine Page Results (SERP’s), and to get there the competition lies in the Page Ranks given by the search engines, well how does one get the edge?

Search Engines have dramatically changed the web and the way we design and develop our website content for that matter. The revolutionary algorithms and techniques that have evolved over the decades have given birth to a new domain: Search Engine Optimization (SEO).  According to wikipedia, SEO is defined as "the process of improving the volume or quality of traffic to a web site from search engines via "natural" ("organic" or "algorithmic") search results."

Google has the winning edge and is clearly at the top of the list when it comes to search engine usage and popularity. Yet, while Google is no doubt in lead with its most accurate and comprehensive search engine, I do believe other search engines such as Microsoft Bing and Yahoo are still viable contenders that should be considered when optimizing your website.

SEO in itself is not that big a deal... any website developer can jump into it quickly thanks to the large volume of beginners guides available online from various blogs and forums.  However, optimizing for all leading search engines at the same time is not an easy task.  It is important to note that when you optimize for Bing or Yahoo, keep it simple so that your rank standing in Google is not hurt.

I have waded through a lot of SEO blogs, forums, consultants, and other web references so that I could complie the following checklists for each of the top 3 search engines.

Optimizing for Google

The following list is based on Google's started guide, “Google Search Engine Optimization” which can be downloaded in pdf format from: http://www.google.com/webmasters/docs/search-engine-optimization-starter-guide.pdf

  • Create Unique, Accurate Page Titles: A title tag tells both users and search engines what the topic of a particular page is. The <title> tag should be placed within the <head> tag of the HTML document. Ideally, you should create a unique title for each page on your site.
  • Make Use of the "description" Meta Tag: A page's description meta tag gives Google and other search engines a summary of what the page is about. Whereas a page's title may be a few words or a phrase, a page's description meta tag might be a sentence or two or a short paragraph.
  • Improve the Structure of Your URLs: Creating descriptive categories and filenames for the documents on your website can not only help you keep your site better organized, but it could also lead to better crawling of your documents by search engines.
  • Make Your Site Easier to Navigate: The navigation of a website is important in helping visitors quickly find the content they want. It can also help search engines understand what content the webmaster thinks is important. Although Google's search results are provided at a page level, Google also likes to have a sense of what role a
    page plays in the bigger picture of the site.
  • Offer Quality Content and Services: Creating compelling and useful content will likely influence your website more than any of the other factors discussed here. Users know good content when they see it and will likely want to direct other users to it. This could be through blog posts, social media services, email, forums, or other means.
  • Write Better Anchor Text: Anchor text is the clickable text that users will see as a result of a link, and is placed within the anchor tag <a href="..."></a>.
    This text tells users and Google something about the page you're linking to. Links on your page may be internal—pointing to other pages on your site—or external—leading to content on other sites.
  • Use Heading Tags Appropriately: Since heading tags typically make text contained in them larger than normal text on the page, this is a visual cue to users that this text is important and could help them understand something about the type of content underneath the heading text. Multiple heading sizes used in order create a hierarchical
    structure for your content, making it easier for users to navigate through your document.
  • Optimize Your Use of Images: Images may seem like a straightforward component of your site, but you can optimize your use of them. All images can have a distinct filename and "alt" attribute, both of which you should take advantage of. The "alt" attribute allows you to specify alternative text for the image if it cannot be displayed for some reason.
  • Make Effective Use of robots.txt: A "robots.txt" file tells search engines whether they can access and therefore crawl parts of your site. This file, which must be named "robots.txt", is placed in the root directory of your site. You may not want certain pages of your site crawled because they might not be useful to users if found in a search engine's search results. If you do want to prevent search engines from crawling your pages, Google Webmaster Tools has a friendly robots.txt generator to help you create this file.
  • Be Aware of rel="nofollow" For Links: Setting the value of the "rel" attribute of a link to "nofollow" will tell Google that certain links on your site shouldn't be followed or pass your page's reputation to the pages linked to. Nofollowing a link is adding rel="nofollow" inside of the link's anchor tag.
  • Promote Your Website in the Right Ways: While most of the links to your site will be gained gradually, as people discover your content through search or other ways and link to it, Google search engine understands that you'd like to let others know about the hard work you've put into your content. Effectively promoting your new content will lead to faster discovery by those who are interested in the same subject.
  • Google's Webmaster Tools: Major search engines, including Google, provide free tools for webmasters. Google's Webmaster Tools help webmasters better control how Google interacts with their websites and get useful information from Google about their site. Using Webmaster Tools won't help your site get preferential treatment; however, it can help you identify issues that, if addressed, can help your site perform better in search results.
  • Google Analytics:
    If you've improved the crawling and indexing of your site using Google Webmasters Tools or other services, you're probably curious about the traffic coming to your site. Web analytics programs like Google Analytics are a valuable source of insight for this.

Optimizing For Bing

  • Backlinks are of Less Importance: If you compare the first 10 results in Bing and Google, it is noticeable that all equal, the winners in Bing have less backlinks than the winners in Google. It is unclear if nofollow matters with Bing.
  • Inbound Anchor Text Matters More: The quantity of quality inbound links might be of less importance for Bing but the anchor text certainly matters more. Actually, since anchor text is one of the measurements of the quality of inbound links, it isn't much different. Get quality anchor text and you will do well in both Bing and Google.
  • Link Spamming Won't Do Much For You on Bing: Since the quantity of backinks (even if they are of supreme quality) seems to be of less importance to Bing, link spamming will be even less effective than with Google.
  • Onpage Factors Matter More Than With Google: This is one of the most controversial points. Many SEO experts disagree but many also think that onpage factors matter more with Bing than with Google. Still, it has nothing to do with the 90s, when onpage factors were definitive.
  • Bing Pays More Attention to the Authority of the Site: If this is true, this is bad news for bloggers and small sites because it means that search results are distorted in favor of older sites and/or sites of authoritative organizations. Age of domain is also very important with Bing – even more than with Google.
  • PR Matters Less: When you perform a search for a competitive keyword and you see a couple of PR2 or even PR1 sites among the top 10 results, this might make you wonder. On Google this is hardly possible but on Bing it looks quite normal.
  • Fresh Content Matters Less: Bing looks a bit conservative – or maybe it just can't index sites that quickly – but it seems that fresh content is not so vital as with Google. This is related to the age of domain specifics and as a result you will see ancient pages rank high (but these ancient pages are relevant to the search query).
  • Bing is More Flash-Friendly: Optimizing a Flash site for Google is a bit of a SEO nightmare. It is too early to say but it looks like Bing is more Flash-friendly, which is good news to all sites where Flash is (still) heavily employed.

Optimization for Yahoo 

  • Search Submit Program: The fastest way to show up in Yahoo's search results is to pay Yahoo to join their Search Submit Program. Once you've submitted your site, Yahoo will send out a SLURP crawler to index the site and put it up for review by one of Yahoo's editors. If you're after Google, expect to see rankings on Yahoo before you see them on Google.
  • Links and On-page Factors: Yahoo places more value on on-page factors than Google does. Google will usually aim to filter out pages too aligned with a targeted keyword in inbound anchor text, title, H1 and H2 headings, while Yahoo is more forgiving. Yahoo is also much easier on link quality than Google. While Google is top-heavy on power links, Yahoo will count many spammy links that Google would drop. Be careful though, since too many spammy links can hurt Google rankings.
  • Cloaking Link: Cloaking links so that MSN and Yahoo see different links than Google. For example, if you had a site with thousands of pages, add a site wide link to one of your other sites. then do some simple cloaking so that Google didn't see the site wide link, but MSN & Yahoo did. This allows you to be really aggressive with link building for Yahoo & MSN and not raise any flags with Google.
  • Link Relevancy: Yahoo also looks at links that go to a page vs links that go to a site when determining its relevancy. The down side of the technology is that they don't count link age and link domain as much as Google does, so it's easier to manipulate their results. Pages from a new site can do well as long as there are inbounds with targeted anchor text.
  • Site Age: Yahoo places some weight on site and domain age, but not as much as Google does.
  • Human Editors: Yahoo is known to review its index and adjust search results for some popular categories. When you use Search Submit, the site is reviewed by human editors by default. If a site is of good quality it can be given a boost in the search results, while low quality or spam sites can be easily dropped. It's not clear how the review process works in Yahoo. Yahoo may go in 100% manual and do section reviews without regard for algorithms.
  • Content Quality Guideline: You can check Yahoo's Search Content Quality Guidelines to see what Yahoo considers spam. If a site gets flagged, you'll need to clean it up and then ask Yahoo to put it back in the search results.
  • Crawls & Spam: Yahoo is pretty good at crawling the web. One of Yahoo's better features is Yahoo Site Explorer and Search Command, which help with competitive link analysis. It's not as good at detecting spam, so it crawls far more spam. Yahoo needs to focus more on search technology than on content-based products to decrease Google's lead in the search arena.

List of Best and Worst Practices for Designing a High Traffic Website

And finally, here is a checklist that I find to be very helpful.  It outlines all of the factors that affect your rankings with Google, Bing, Yahoo! and the other search engines: http://www.webconfs.com/15-minute-seo.php

 

Information for this post was gathered from the following sites:
http://blog.searchenginewatch.com/
http://www.searchenginejournal.com/
http://www.seochat.com/
http://www.blackhatdigest.com/
http://www.webconfs.com/

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

A bug report is a technical document that describes a system failure or functional defect in a system under test during the software quality assurance process. It is the core artifact which is generated as the result of software testing. Bug reports are written to ensure (and improve) product quality by communicating the specifics of a particular issue to the software developers and among the development team as a whole. Based on my experience the following are the key “DOs” that make up an effective bug report:

  • Testers should carefully retrace and document their steps ensuring that they are able to reproduce the issue prior to writing the report.
  • They should also try to determine if the same error occurs in other alternate scenarios or in other modules of the application so that all instances of the problem can be reported and fixed in one pass.
  • Attempt to determine why the error occurred and try to identify its root-cause. Is it data specific, platform specific, configuration specific, etc.?
  • Try to reproduce the error on another workstation to help determine if the problem is related to all workstations or specific to your test machine.
  • Write the report in clear and simple language, but include as much detail specific to the issue as possible. Try to put yourself in the mindset of the developer… would you be able to understand what the issue being reported was just by reading your bug report?
  • In addition to a clearly written description of the problem, attaching screen shots of the problem (bitmaps, jpegs etc.), application or system logs, and other pertinent documents is always helpful, making it easier for the developers to reproduce the problem.
  • Properly set the priority and severity of the issue. While this may seem obvious, it is very important not to overlook this step so that the development team can forecast their efforts accordingly.
  • And finally, always review what you have entered into your bug report before final submittal to the team.

Now let’s focus on what not to do… an ineffective bug report in return frustrates both the testers and developers on their respective ends. A typical response to poorly written reports is that the bugs are not reproducible – I am sure we have all heard the “well, this doesn’t happen on my machine” response to a reported problem. This leads to inefficiencies in the testing/remediation process and creates an adversarial relationship between testers and developers. In order to avoid these problems, I will now focus on the “DON’Ts” of bug reporting:

  • Do not write superfluous information – stay focused on the problem at hand and be concise in your explanation.
  • However, too little detail is even more fatal. Finding the right balance of detail to describe your issue is the key to a good bug report.
  • Avoid criticism or sarcasm. Be conscious of your tone – be careful not to blame or attack the development team. And by all means, never use offensive language (you would think I would not have to mention this, but believe me, I have heard stories…)
  • Avoid using verbiage that is misleading or has multiple meanings.
  • Be careful not to waste the developers’ time -- avoiding be repetitive and get straight to the point.
  • And most importantly, don’t feel that your job stops once you enter your report. You are the owner of this issue, and it is your responsibility to ensure that the development team is clear on when you have defined. Make it a point to follow up with the team in person to ensure that everything is clear.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

In our practice, software test automation can be an extremely powerful tool which if implemented properly can help ensure a successful testing engagement.  But the fact remains (as a lot of you may know first hand) that when not managed properly the use of automated testing tools will be a complete waste of time and energy and can even create substaintally more problems than solutions for the project. 

It is important to point out that it is not always necessary to automate all

functionality of the application under test.  In fact, based on my experience with software quality assurance it rarely makes sense to do so.  Usually it makes the most sense to automate the “happy path” test cases, core business rules validation and critical application functionality, and any repetitive tasks or test cases that must be duplicated thousands of time.  If the remaining functionality is relatively easy to manually test, and it will take more effort to develop automated test scripts, then continuing with manual testing.

The following list outlines some guidelines that can be used to determine when it is a good idea to introduce automated testing into the QA process of a software development project.

Test Cases Execution and Validation

At the start of each project we analyze the system from the automation tool perspective to determine the difficulty level of test cases automation. Projects are evaluated on GUI elements and overall GUI complexity, as well as identifying the applications use of validation patterns.  The more consistent the validation patterns, the easier and more effective test automation will be.

Repetitive Tasks

Repetitive tasks which can have multiple outputs are also very good candidates for automated testing.  An example of this would be testing application security, permissions, and user roles.

Ensure Consistency

Test cases that must always be run following very precise steps are excellent candidates for automation, as automation will ensure that a test is always run following a consistent set of exact steps during each execution.

Testing Data Generation

Test automation can be used for generating the test data required for both manual and automated testing.

Testing Staff Skills

An important matter to consider is the overall skill set and technical abilities of the testing team.  Automation is obviously a better choice when you have access to a  highly technical testing staff.  Conversely if you have access to a highly successful (yet not very technical) manual testing team it is better to continue to take advantage of the manual execution as opposed to putting in the extra effort required while attempting to automate the test suite.

Project Planning

Depending on the project schedule and estimated project lifespan (are multiple versions anticipated or is this a 'one-off' project) you can determine if test automation is a good solution.  Developing an automated test suite involves a substantial investment in time and effort -- so a one-off project with a short develpment schedule is not the best candidate for automated testing.  Whereas a longer project that is anticipated to have a longer lifespan would be a much better fit.

Number of Module and System Integrations / Regression Testing Needs

When a development project has a large amount of module and system integrations regression testing is extremely important to ensure that all exiting functionality remains in working order. If developed properly, having an automated test suite is an excellent solution to ensure fast and consistent regression testing with each test cycle.

Currently rated 5.0 by 2 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

The growing trend of outsourcing software development projects and the utilization of remote development team is leading to the need for stronger management of these distributed development teams.  The Subversion source code repository tools have been growing in popularity lately among development teams due to the fact that it is easy to implement across remote and distributed teams.

Having a centralized SVN repository that is accessible round the globe using Internet is possible but this can introduce latency issues due to large geographic differences.  In some developing countries the problem is increased due to power and bandwidth issues.

Problems such as these have resulted in the development of solutions that require having multiple redundant SVN servers that are in sync with each other, allowing teams across the globe to work with the server readily accessible to them. In the following sections I would like to discuss some options out of the box and some open source solutions provided by the Subversion community. More...

Currently rated 5.0 by 2 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

In this post I will outline how to develop a custom web part in Microsoft Visual Studio 2005. When creating a WebPart for, you can either create SharePoint based WebPart or ASP .Net based WebPart. As per current best practices, I suggest you should always create an ASP .Net 2.0 based WebPart.

In this case, we will develop ASP .Net based web part which require that we use a simple class library type project in VS 2005.

To develop a web part, we just need a normal .Net class which must be inherited from System.Web.UI.WebControls.WebPart class. We will have to add a reference to System.Web in our class library project because it doesn't have this reference by default. After adding the reference, you can now inherit your class from WebPart base class.

public class MyFirstWebPart : WebPart

You can now override the base class methods to provide the required functionality to the web part. In order to create the web controls inside the web part, we will override its CreateChildControls method. More...

Currently rated 5.0 by 1 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

The purpose of this post is to provide a quick background of Microsoft web parts. Web parts are one of the great features of ASP .NET 2.0 which provides high level of customization and reusability. The user can place a web part anywhere on the page, and even can define communication between multiple web parts.

Web parts are ASP .NET server side controls, which are essentially Microsoft's version of a web widget or portlet (however, web parts do not require a web portal, such as SharePoint, to host them). Web parts allow web developers to create sites where users can modify the user interface and content of the site directly from their browser. They can be easily added or removed on a web part page, and also enable personalization on pages.

A SharePoint site can be composed of one or more web part pages that can display content in the available areas known as web part zones. One or more web parts can be hosted inside a web part zone. Although SharePoint has provided lots of pre-built web parts, sometimes it is required to create your custom web part to fulfill some specific requirement. SharePoint allows developers to deploy the custom web parts they develop. I will explain in future posts all the steps required to create, import and configure a web part into a SharePoint web part page.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Recently I was working on a report for a client when I came across a requirement which reminded me of a similar task I completed few years back in SQL Server 2000. Since that time there have been a lot of cool new features added in SQL 2005 and SQL 2008, so I decided to try a new way of tackling this problem which I will be outlining in this post.

So first let me give you some background on the issue I was dealing with. The requirement was to merge one master table with two child table columns into one result set… sounds easy, right?

The data structure I was dealing with has one master table, dbo.Object, which has two child tables: dbo.ObjectProperty and dbo.ObjectMethod. Both of the child tables are tied to master table on their ObjectID fields.

Here is a quick snapshot of the data in these tables:

SELECT * FROM dbo.[Object]
SELECT * FROM dbo.[ObjectProperty]
SELECT * FROM dbo.[ObjectMethod]

I needed to list all properties and methods for each object in one result set as shown in following image.  Look at the result set below. This is want I needed my query to return. Notice that when there are more PropertyName values than MethodName values for a particular Object that the MethodName value will display as NULL. And the reverse is true... when there are more MethodName values than PropertyName values for an object the PropertyName value is NULL. More...

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Imagine its late Sunday afternoon… you’re at the office, and have been all weekend.  You are diligently working to ensure that the Monday build deadline is met.   You have been testing your code, and all is looking good in your dev environment, so you decide it’s time to check in your code and run the build process.  But once you get the latest code from your repository the build no longer compiles!!! How frustrating!

Why did this happen… who is responsible… You could be here all night trying to track down the cause!  If you are working in a remote environment or on a multi-site team tracking down the problem will be even more difficult.

Now imagine that your development team uses a Continuous Integration (CI) process.  When anyone checks in code to the team’s source code repository the build is automatically run, and if there are any compile issues an email is sent out to the team.  Now you know exactly what code broke the build, and which team member was responsible.  Better yet, the issue can be addressed immediately.  But why stop at just compile issues?  Why not automate your suite of unit tests as well?  Throw in a code coverage tool and just imagine how confident you would be that not only your build will consistently compile, but that the new code you have introduced has not broken any existing functionality.

If your team does not employ any of the tactics mentioned above, you know these integration pains firsthand.  And while implementing a Continuous Integration process is not a change that will happen overnight, the time and effort spent in implementing such a plan will certainly be less than the amount of agonizing hours spent by team members tracking down such integration issues.

According to Martin Fowler:

The fundamental benefit of continuous integration is that it removes sessions where people spend time hunting bugs where one person's work has stepped on someone else's work without either person realizing what happened. These bugs are hard to find because the problem isn't in one person's area, it is in the interaction between two pieces of work. This problem is exacerbated by time. Often integration bugs can be inserted weeks or months before they first manifest themselves. As a result they take a lot of finding.

I recommend implementing your CI process in stages:

  1. Implement a Source Code Repository that meets the needs of your team.  For example, does it work well with remote teams (accessible from the internet)?, does it integrate well with other CI tools (auto-build tools, unit testing tools, etc.)?
  2. Document your build process and train all developers on this.  This should clearly layout items such as when you should check in your code, what structure you will use and what each folder is used for, under what circumstances to tag or branch the repository, how to version the build, etc.  The idea is to make sure everyone is familiar with and follows this consistent process.
  3. Once this is in place you should add the automated build component. There are a lot of good tools out there.  Finding one that integrates with your code repository is a must (this should not be hard).  Here is a feature matrix published by ThoughtWorks that is an excellent resource for evaluating which CI system is the best fit for your organization.
  4. Train your development team to effectively use test-driven development and strive to have the team write ‘self-testing code’.  This is the hardest and most time consuming step because this is not just a tool that needs to be learned and configured… this is a fundamental change in your approach to writing code.
  5. Automate the running of your unit tests.  Once the team is writing effective unit tests, you will want to have these run every time the build is compiled.  This adds an even greater level of assurance that everything is still ‘a-ok’ after introducing new code.
  6. And finally, use a code coverage tool to ensure maximum effectiveness of your unit tests.

Currently rated 4.5 by 4 people

  • Currently 4.5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

An article highlighing CTO 24/7 was posted on the front page of P@SHA today.  The article states that CTO 24/7 has signed a major new BPO project which will result in substatial growth and hiring this year.

Click to read the full article

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

In the previous post, I showed you how to setup your SVN Repository. We also saw how to checkout files, but all that was limited to the machine where your SVN repository is setup. In the real world however, we do not create repositories for just ourselves. We use them to share, collaborate, and version our documents and project files.
In order to allow remote users to access the repository, we need to setup an SVN server... and that’s what we are going to see in the sections below. For our purpose, we will be installing our server on a Windows Platform.

Setting Up SVN Server

Before we setup the SVN server it is important to realize how SVN server works. The server is basically a service that simply listens to incoming requests and redirects those requests to the appropriate repositories. Our SVN repositories do not have any built in mechanism for communication with outside world. It’s the service listening on a particular port that does this communication, pulling requested items from the repository for remote users. More...

Currently rated 5.0 by 2 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5