Now your turn to take decision ???

Now your Turn that either you have to go with SEO or not??
Our team is ready 24/7 whenever you want any feedback to us than we are capable to give your all question's answer as soon as possible.

SEO in RAJKOT

We doing SEO on your KEYWORD...

Choose your keywords

We choose your keyword which give you more trafic.
The first thing you need to do when you begin chasing a good search engine ranking is decide which words you want to rank well for. This is called performing a keyword analysis. Keyword analysis involves a bit of research and a good knowledge of your business and the benefits you offer your customers.There are several websites specifically designed to make keyword analysis easier.

i.You’re in a niche market with relatively few customers searching for the keyword. In this situation, you’ll probably find it relatively easy to reach the top of the rankings,but you won’t generate a huge volume of traffic when you get there.

Do SEO in short time !!!!

Want to do seo in short time than meet my teem SEO secrate team at staying in RAJKOT But actually what we are doing that i am describe in some short?

Optimizing your web copy

The trick to optimizing your copy is using the most important keywords frequently and in the
right places without compromising the readability of your copy. But how do you define
“frequently”? And what are the right places? What if you want to target a few different
keywords? And for that matter, what should the wordcount of my pages be? Below are a few
tips which will help you out.

Grand pa

My grand pa's temple at aambardi taluka jamjodhpur dist.jamnagar gujarat INDIA.

PERSONAL DOC

1.) Standard Controls: The standard controls enable you to render standard form elements such as buttons, input fields, and labels.

Submitting Form Data Control: the Button, LinkButton, and ImageButton controls are use to submit a form to the server
A.) Button : push button that you can use to submit a form to the server
script runat="server"

Sub btnSubmit_Click(ByVal sender As Object, ByVal e As EventArgs)
lblTime.Text = DateTime.Now.ToString("T")
End Sub
script

asp:Button
id="btnSubmit"
Text="Submit"
OnClick="btnSubmit_Click"
Runat="server"



asp:Label
id="lblTime"
Runat="server" />


Some properties
OnClientClick, click, Command Raised when the Button control is clicked. The CommandName and CommandArgument are passed to this event.

B.) ImageButton : However, the ImageButton control always displays an image.
Note: Always include alternate text for any image. The accessibility guidelines require it. Furthermore, remember that some people turn off images in their browsers for a faster surfing experience.
You can use the ImageButton control to create a simple image map.
Sub btnTarget_Click(ByVal sender As Object, ByVal e As ImageClickEventArgs)



Code
If (e.X > 90 And e.X < 110) And (e.Y > 90 And e.Y < 110) Then
lblResult.Text = "You hit the target!"
Else
lblResult.Text = "You missed!"
End If
Design
asp:ImageButton
id="btnTarget"
ImageUrl="Target.gif"
Runat="server" OnClick="btnTarget_Click"

Some Important properties of image button;
AlternateText, CommandArgument, CommandName, GenerateEmptyAlternateText
ImageAlign : Possible values are AbsBottom, AbsMiddle, Baseline, Bottom, Left, Middle, NotSet, Right, TextTop, and Top.
ImageUrl, OnClientClick, Focus, Click, Command

C.) LinkButton : Unlike a Button control, however, the LinkButton control renders a link instead of a push button.

Example:
Code
Sub lnkSubmit_Click(ByVal sender As Object, ByVal e As EventArgs)
lblResults.Text = "First Name: " & txtFirstName.Text
lblResults.Text &= "
Last Name: " & txtLastName.Text
End Sub
Design
asp:LinkButton
id="lnkSubmit"
Text="Submit"
OnClick="lnkSubmit_Click"
Runat="server"

hyperlink rendered by the LinkButton control looks like this:
a id="lnkSubmit" href="javascript:__doPostBack('lnkSubmit','')">Submit a

Supports the following properties : AccessKey, Enabled, OnClientClick, PostBackUrl, TabIndex, Text, Focus, click, Command


Displaying Images
A.) Image : The image is displayed by setting the ImageUrl property of the Image control contained in the body of the page.
Sub Page_Load()
Dim rnd As New Random()
Select Case rnd.Next(3)
Case 0
imgRandom.ImageUrl = "Picture1.gif"
imgRandom.AlternateText = "Picture 1"
Case 1
imgRandom.ImageUrl = "Picture2.gif"
imgRandom.AlternateText = "Picture 2"
Case 2
imgRandom.ImageUrl = "Picture3.gif"
imgRandom.AlternateText = "Picture 3"
End Select
End Sub

Image control supports the following properties
AlternateText, DescriptionUrl, GenerateEmptyAlternateText, ImageAlign, ImageUrl


k) Label : Whenever you need to modify the text displayed in a page dynamically, you can use the Label control
script runat="server"
Sub Page_Load()
lblTime.Text = DateTime.Now.ToString("T")
End Sub
script



form id="form1" runat="server"
div
asp:Label
id="lblTime"
Runat="server" /

/div
/form
/body Output

you can place the text between the Label control's opening and closing tags
By default, a Label control renders its contents in an HTML span tag.
The Label control supports several properties Some of them are describe here
• BackColor, BorderColor, BorderStyle, BorderWidth , CssClass,Font, ForeColor Style , ToolTip
Note: use Cascading Style Sheets to format the rendered output of the Label control.


Accepting User Input Control : The ASP.NET Framework includes several controls that you can use to gather user input. TextBox, CheckBox, and RadioButton controls. These controls correspond to the standard types of HTML input tags.
A.) TextBox : The TextBox control can be used to display three different types of input fields depending on the value of its TextMode property
a. SingleLine Displays a single-line input field.
b. MultiLine Displays a multi-line input field.
c. Password Displays a single-line input field in which the text is hidden.

asp:TextBox
id="txtUserName"
TextMode="SingleLine"
Runat="server" /

br / br /

asp:TextBox
id="txtPassword"
TextMode="Password"
Runat="server" /

br / br /

asp:TextBox
id="txtComments"
TextMode="MultiLine"
Runat="server" /

You can use the following properties to control the rendering characteristics of the TextBox contro
AccessKey: AutoCompleteType: The ASP.NET Framework does not support AutoComplete for other browsers such as FireFox or Opera.
AutoPostBack: You should avoid using the AutoPostBack property for accessibility reasons. Because it’s very confusing to someone
Columns: Enabled: MaxLength: ReadOnly: Rows: TabIndex: Wrap:
Focus: You can also set the form focus by setting either the Page.SetFocus() method or the server-side HtmlForm control's DefaultFocus property.
TextChanged
B.) CheckBox: enables you to display, well, a check box.

asp:CheckBox
id="chkNewsletter"
Text="Receive Newsletter?"
Runat="server" /
• CheckBox includes a Text property that is used to label the CheckBox
• If you use this property, then the proper (accessibility standardscompliant) HTML label tag is generated for the TextBox.
• Some Properties
o Checked, Enabled, Text, TextAlign, Focus, CheckedChanged
C.) CheckBoxList : The CheckBoxList control renders a list of check boxes.
• rendered horizontally or vertically
• can select multiple items when using a CheckBoxList control.

asp:CheckBoxList id="cblMovies"
DataSourceID="srcMovies"
DataTextField="Title"
DataValueField="Id"
RepeatColumns="2"
Runat="server" /
three properties that affect its layout
• RepeatColumns , RepeatDirection ,RepeatLayout

D.) RadioButton : use the RadioButton control in a group. Only one radio button in a group of RadioButton controls can be checked at a time.
Example:
How did you hear about our Website?

ul
li
asp:RadioButton
id="rdlMagazine"
Text="Magazine Article"
GroupName="Source"
Runat="server" /
/li
li
asp:RadioButton
id="rdlTelevision"
Text="Television Program"
GroupName="Source"
Runat="server" /
/li
li
asp:RadioButton
id="rdlOther"
Text="Other Source"
GroupName="Source"
Runat="server" /
/li
/ul

Some properties of radio button
Checked, GroupName, TabIndex, TextAlign, CheckedChanged
E.) RadioButtonList : like the DropDownList control, enables a user to select only one list item at a time, arranged either horizontally or vertically
Example: asp:RadioButtonList
id="rblMovies"
DataSourceID="srcMovies"
DataTextField="Title"
DataValueField="Id"
RepeatColumns="3"
Runat="server" /

asp:SqlDataSource
id="srcMovies"
SelectCommand="SELECT Id, Title FROM Movies"
ConnectionString=" %$ ConnectionStrings:Movies % "
Runat="server" /



Using the Panel Control
A.) Panel : The Panel control enables you to work with a group of ASP.NET controls. you can use a Panel control to hide or show a group of ASP.NET controls.
Design view’s code
asp:Panel
id="pnlOther"
Visible="false"
Runat="server"

asp:Label
id="lblOther"
Text="Other Language:"
AssociatedControlID="txtOther"
Runat="server" /
asp:TextBox
id="txtOther"
Runat="server" /

/asp:Panel
The Panel control supports the following properties:
DefaultButton, Direction, GroupingText, HorizontalAlign, ScrollBars

If you set the GroupingText property, however, the Panel control renders a fieldset tag. The value that you assign to the GroupingText property appears in the fieldset tag's legend tag.
Notes: Don't use the values Horizontal or Vertical with the ScrollBars property when you want the scrollbars to appear in browsers other than Microsoft Internet Explorer. If you want the scrollbars to appear in FireFox and Opera, use either the value Auto or Both.

Note: Every control in the ASP.NET framework supports the Visible property.
h) HyperLink : The HyperLink control enables you to create a link to a page. Unlike the LinkButton control, the HyperLink control does not submit a form to a server.
Example:
Code
Sub Page_Load()
lnkRandom.NavigateUrl = GetRandomFile()
End Sub
Design
asp:HyperLink
id="lnkRandom" Text="Random Link" Runat="server" /
HyperLink control supports the following properties
Enabled, ImageUrl, NavigateUrl, Target, Text
Note: Notice that you can specify an image for the HyperLink control by setting the ImageUrl property. If you set both the Text and ImageUrl properties, then the ImageUrl property takes precedence.

Using the Rich Controls
A.) FileUpload : control enables users to upload files to your web application.
Enabled, FileBytes, FileContent, FileName, HasFile, PostedFile, Focus, SaveAs
The HttpPostedFile class has the following properties (this is not a complete list): ContentLength, FileName, InputStream
Design asp:FileUpload
id="upImage"
Runat="server" /


B.) Calendar: The Calendar control enables you to display a calendar
You can use the calendar as a date picker or you can use the calendar to display a list of upcoming events.
Design: asp:Calendar
id="Calendar1"

Runat="server" /

Calendar control supports the following properties
DayNameFormat(FirstLetter, FirstTwoLetters, Full, Short, and Shortest), NextMonthText, NextPrevFormat(CustomText, FullMonth, and ShortMonth.), PrevMonthText, SelectedDate, SelectedDates, ShowTitle, TodaysDate, VisibleDate
The Calendar control also supports the following events:
• DayRenderRaised as each day is rendered.
• SelectionChangedRaised when a new day, week, or month is selected.
• VisibleMonthChangedRaised when the next or previous month link is clicked

e) DropDownList

g) HiddenField
m) ListBox
n) MultiView and View
p) PlaceHolder


2.) Data Controls
a) GridView
b) DataList
c) DetailsView
d) FormView
e) Repeater
f) SqlDataSource
g) SiteMapDataSource








3.) Validation Control
Technically, you can use the validation controls with any control that is decorated with the ValidationProperty attribute.
By default, the validation controls perform validation on both the client (the browser) and the server. The validation controls use client-side JavaScript.
You can use the validation controls with browsers that do not support JavaScript (or do not have JavaScript enabled). If a browser does not support JavaScript, the form must be posted back to the server before a validation error message is displayed.

a) RequiredFieldValidator : control enables you to require a user to enter a value into a form field before submitting the form.
set two important properties when using the RequiredFieldValdiator control:
• ControlToValidate The ID of the form field being validated.
• Text The error message displayed when validation fails.

Design code is
asp:TextBox
id="txtFirstName"
Runat="server" /
asp:RequiredFieldValidator
id="reqFirstName"
ControlToValidate="txtFirstName"
Text="(Required)"
Runat="server" /

Note: By default, the RequiredFieldValidator checks for a nonempty string (spaces don't count).


b) RangeValidator : control enables you to check whether the value of a form field falls between a certain minimum and maximum value.

Using the RangeValidator Control
The RangeValidator control enables you to check whether the value of a form field falls between a certain minimum and maximum value. You must set five properties when using this control:
• ControlToValidate The ID of the form field being validated.
• Text The error message displayed when validation fails.
• MinimumValue The minimum value of the validation range.
• MaximumValue The maximum value of the validation range.
• Type The type of comparison to perform. Possible values are String, Integer, Double, Date, and Currency.
Example: asp:TextBox
id="txtAge"
Runat="server" /
asp:RangeValidator
id="reqAge"
ControlToValidate="txtAge"
Text="(Invalid Age)"
MinimumValue="5"
MaximumValue="100"
Type="Integer"
Runat="server" /

with an age less than 5 or greater than 100, then the validation error message is displayed.
Note: Don't forget to set the Type property when using the RangeValidator control. By default, the Type property has the value String, and the RangeValidator performs a string comparison to determine whether a values falls between the minimum and maximum value.

D) CompareValidator: can use the CompareValidator to perform a data type check. In other words, you can use the control to determine whether a user has entered the proper type of value into a form field, such as a date in a birth date field.
The CompareValidator has six important properties: ControlToValidate, Text
• Type: The type of value being compared. Possible values are String, Integer, Double, Date, and Currency.
• Operator The type of comparison to perform. Possible values are DataTypeCheck, Equal, GreaterThan, GreaterThanEqual, LessThan, LessThanEqual, and NotEqual.
• ValueToCompare The fixed value against which to compare.
• ControlToCompare The ID of a control against which to compare.
Design Code:
asp:CompareValidator
id="cmpBirthDate"
Text="(Invalid Date)"
ControlToValidate="txtBirthDate"
Type="Date"
Operator="DataTypeCheck"
Runat="server" /

C) RegularExpressionValidator : You can use a regular expression to represent string patterns such as email addresses, Social Security numbers, phone numbers, dates, currency amounts, and product codes.
Code: enables you to validate an email address
asp:RegularExpressionValidator
id="regEmail"
ControlToValidate="txtEmail"
Text="(Invalid email)"
ValidationExpression="\w+([-+.']\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*"
Runat="server" /

Note: There are huge collections of regular expression patterns living on the Internet. The easiest way to find a good regular expression for a pattern is to simply Google it.
E) CustomValidator : If none of the other validation controls perform the type of validation that you need, you can always use the CustomValidator control.
The CustomValidator control has three important properties:
• ControlToValidate The ID of the form field being validated.
• Text The error message displayed when validation fails.
• ClientValidationFunction The name of a client-side function used to perform client-side validation.
The CustomValidator also supports one event:
• ServerValidate This event is raised when the CustomValidator performs validation.
You associate your custom validation function with the CustomValidator control by handling the ServerValidate event.
Code:
Protected Sub valComments_ServerValidate(ByVal source As Object, ByVal args As System
.Web.UI.WebControls.ServerValidateEventArgs)
If args.Value.Length 10 Then
args.IsValid = False
Else
args.IsValid = True
End If
End Sub
Design
asp:CustomValidator
id="valComments"
ControlToValidate="txtComments"
Text="(Comments must be less than 10 characters)"
OnServerValidate="valComments_ServerValidate"
Runat="server" /

The second parameter passed to the ServerValidate event handler is an instance of the ServerValidateEventArgs class
• Value Represents the value of the form field being validated.
• IsValid Represents whether validation fails or succeeds.
• ValidateEmptyText Represents whether validation is performed when the form field being validated does not contain a value.

F) ValidationSummary : The ValidationSummary control enables you to display a list of all the validation errors in a page in one location.
If a user enters the wrong value for a form field located toward the end of the page, then the user might never see the error message. If you use the ValidationSummary control, however, you can always display a list of errors at the top of the form.
You might have noticed that each of the validation controls includes an ErrorMessage property. We have not been using the ErrorMessage property to represent the validation error message. Instead, we have used the Text property.
The distinction between the ErrorMessage and Text property ?? ErrorMessage property appears in the ValidationSummary control, and any message that you assign to the Text property appears in the body of the page
NOTE: If you don't assign a value to the Text property, then the value of the ErrorMessage property is displayed in both the ValidationSummary control and the body of the page.
Example: asp:ValidationSummary
id="ValidationSummary1"
Runat="server" /



4.) Login Controls
a) Login
b) LoginView
c) PasswordRecovery
d) LoginStatus
e) LoginName
f) ChangePassword

5.) Navigation Control
a) SiteMapPath
b) Menu
c) TreeView
6.) Data source Controls
d) Sql Datasource
e) Xml Datasource
f) Object Datasource
g) Sitemap Datasource








Themes
12. Applying Styles, Themes, and Skins
a) Applying Styles to Controls

b) The App_Themes Folder
You create a Theme by adding a new folder to a special folder in your application named App_Themes.
When using Visual Web Developer, you can create a new Theme folder by right-clicking the name of your project in the Solution Explorer window and selecting Add ASP.NET Folder, Theme.
A Theme folder can contain a variety of different types of files, including images and text files.
The most important types of files in a Theme folder are the following:
• Skin Files
• Cascading Style Sheet Files
Warning: Be careful about how you name your Theme (the folder name). The contents of a Theme folder are automatically compiled in the background into a new class. So you want to be careful not to name a Theme with a class name that conflicts with an existing class name in your project.

C) Global and Application Themes
You can share the same Theme among multiple web applications running on the same web server. A Global Theme can contain both Skin files and Cascading Style Sheet files.
You create a Global Theme by adding the Theme to the Themes folder located at the following path:
WINDOWS\Microsoft.NET\Framework\[version]\ASP.NETClientFiles\Themes
After you add a Theme folder to this path, you can immediately start using the Theme in any file systembased website.
If you want to use the Theme in an HTTP-based website, you need to perform an additional step. You must add the Theme folder to the following path:
Inetpub\wwwroot\aspnet_client\system_web\[version]\Themes
You can copy the Theme to this folder manually or you can use the aspnet_regiis tool to copy the Theme folder. Execute the aspnet_regiis tool from the command line like this:
aspnet_regiis -c

D) Assigning a Theme to a Page
A Theme can contain one or more Skin files. A Skin enables you to modify any of the properties of an ASP.NET control that have an effect on its appearance.
The Skin is applied to every page to which the Simple Theme is applied.
Add Code in Head %@ Page Language="C#" Theme="Simple" %
Note: By default, all control properties are themeable (can be modified in a Skin file). However, certain control properties are decorated with the Themeable(False) attribute, which disables theming.

e) Assigning a Theme in Config
Rather than add the Theme or StyleSheetTheme attribute to each and every page to which you want to apply a Theme, you can register a Theme for all pages in your application in the web configuration file.
Code in Web.Config
?xml version="1.0"?
configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0"
system.web

pages theme="Site" /

/system.web
/configuration
Rather than use the theme attribute, you can use the styleSheetTheme attribute to apply a Theme to the pages in an application.
?xml version="1.0"?
configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0"
system.web

pages styleSheetTheme="Site" /

/system.web
/configuration

After you enable a Theme for an application, you can disable the Theme for a particular page by using the EnableTheming attribute with the %@ Page % directive.
Code: %@ Page Language="VB" EnableTheming="false" %


f) Disabling Themes for a Control
Every ASP.NET control includes an EnableTheming property.
You can use the EnableTheming property to prevent a Skin from being applied to a particular control in a page.

g) Default and Named Skins
Default:
Create: Simple\TextBox.skin
Code:
asp:TextBox
BackColor="Yellow"
BorderStyle="Dotted"
Runat="Server" /

And add code before the head
%@ Page Language="VB" Theme="Simple" %

Now all textbox in that particular form become dotted and yellow
Named Skins : When you create a Named Skin, you can decide when you want to apply the Skin.For example, you might want required fields in a form to appear with a red border. In that case, you can create a Named Skin and apply the Skin to only particular TextBox controls.
Create: Simple2\TextBox.skin
asp:TextBox
SkinID="DashedTextBox"
BorderStyle="Dashed"
BorderWidth="5px"
Runat="Server" /

asp:TextBox
BorderStyle="Double"
BorderWidth="5px"
Runat="Server" /

Design Code:
asp:TextBox
id="txtFirstName"
SkinID="DashedTextBox"
Runat="server" /

br / br /

asp:TextBox
id="txtLastName"
Runat="server" /

the first TextBox appears with a dashed border and the second TextBox appears with a double border


h) Contents of a Theme and Skin

i) Using CSS in Themes
As an alternative to Skins, you can use a Cascading Style Sheet file to control the appearance of both the HTML elements and ASP.NET controls contained in a page.
If you add a Cascading Style Sheet file to a Theme folder, then the Cascading Style Sheet is automatically applied to every page to which the Theme is applied.
For example, App_Themes\StyleTheme\SimpleStyle.css
Write code in simplestyle.css is
html
{
background-color:gray;
font:14px Georgia,Serif;
}

Now just add %@ Page Language="VB" Theme="StyleTheme" %
The Cascading Style Sheet is used to style several HTML elements in
Style Sheet sets the background color of the page to the value Gray.
The advantage of using Cascading Style Sheets is that they result in leaner and faster loading pages. The more content that you can place in an external Style Sheet, the less content must be loaded each time you make a page request
When you add multiple Style Sheets to a Theme, the style sheets are linked to a page in alphabetical order
link href="App_Themes/Simple/ThemeA.css" type="text/css" rel="stylesheet" /
link href="App_Themes/Simple/ThemeB.css" type="text/css" rel="stylesheet" /
link href="App_Themes/Simple/ThemeC.css" type="text/css" rel="stylesheet" /

j) Using Images in Themes
k) Assigning the Theme in Code
http://quickstarts.asp.net/QuickStartv20/aspnet/doc/themes/default.aspx

What we do in company

See me

testing of html

!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
HTML
HEAD
TITLE New Document /TITLE
META NAME="Generator" CONTENT="EditPlus"
META NAME="Author" CONTENT=""
META NAME="Keywords" CONTENT=""
META NAME="Description" CONTENT=""
/HEAD

bODY

BODY
HTML
----------------------


!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
HTML
HEAD
TITLE Form Tag /TITLE
META NAME="Generator" CONTENT="EditPlus"
META NAME="Author" CONTENT=""
META NAME="Keywords" CONTENT=""
META NAME="Description" CONTENT=""
/HEAD

BODY

h4 align="center" Forms Example Use For Geting Some Inout From User /h4

form

Name :        input type="text" br
Password :  input type="password" br

input type="radio" name="sex" id="optmale" value="male" Male br
input type="radio" name="sex" id="opftmale" value="female" FeMale br


input type="checkbox" name="sex" id="optmale" value="male" Male br
input type="checkbox" name="sex" id="opftmale" value="female" FeMale br
input type="checkbox" name="man" id="opftmale" value="man" Mans br


/form
select name="number"
option value="First" First /option
option value="Second" selected="selected" second /option
option value="Third" Third /option
/select

Address :  textarea rows="10" cols="10" the cat is come in the garden for the get more detail /textarea

fieldset

legend align="center" Personal Information /legend
Name: input type="text" size="5" /input
Add: input type="text" size="7" /input

select
!multi step tree view is not supported
optgroup label="Indian Cars"
optgroup lable="Funty"
option name="funty" value="funty" Funty1 /option
option name="funty" value="funty" Funty2 /option
option name="funty" value="funty" Funty3 /option
/optgroup
option name="fiat" value="fiat" Fiat /option
/optgroup
/select


button type="reset" value="Submit" reset /button
/fieldset
/BODY
/HTML


----------------------




-> without form tab you can easily run the all input control

-> Suppose at the time of ooption buttin you write the wrong parameter in name you write nmae by nistake
than in IE you can see that option button but you can't able to click on than but in case FireFox it is

possible to select that option button and other button too.

-> Why should i write all control's tag in the

-->By the use of optgroup you can easily make one step tree view but you can not make multie step tree view in

combo box

Masum and nayan

B4 apti

Jagdish b4 aptitude

@ rigen

Masum after clearing 1st apti

At rigel

Nayan with masum

Rigel baroda

Masum and jagdish

At baroda

Nayan and jagdish

@ baroda

Nayan and jagdish

@ baroda

JagdiSh

At baroda

Nayan with masum

Jagdish at rigel

At baroda

Masum try to muskan.

Means smile yar.

Nayan try to ..

..fire vs nayan and who win?

Nayan at dwarkesh

Care him sorry care compny

boolywood photo-Hero's photo-Recently releases picture hero-filmy photo

Karina kapoor nice scene in HERO

Titanic

Hm

Jagdish sagar

Photo at the time of engage sandip

Last stage

Moon's last stage

Chanda mama so gaye

Chanda mama so gaye

Chandra grahan

Nice scene

Still moon is in darkness

Chandra grahan is still cotinue

Moon has suffer

Moon has to suffer

Live chandra grahan

Live photo

Chandra grahan at INDIA

chandra grahan's photo at the time of a'bad

Live moon

Thats a memorable night

Why we make website In rajkot or any where? Why my site required SEO (Search Engine Optimization)

We are making our website for and only for publishing, advertisement or marketing of our product but what things will be happen if no one sees our website?? I think you had spent more than 8,000/- to 10,000/- Rs or 300$ to 400$ minimum for developing your web site. But you never think that have you got any business from your website’s investment? If I spent 5,000/- for advertisement than I expect minimum 15,000/- to 20,000/- business from my web site. But how that thing is possible? That thing is possible only and only doing SEO (Search Engine Optimization) on your site.

But before understanding seo tell me, who will come on your web site? Simply a person who know address of your web site. Than another question coming who know address of your web site??? Again simply we can say a person who is either in my contact or I give him address of my site. What about rest of people???

You know that when any person want any information from internet but they have not exactly idea about site than a person go in google, yahoo, msn, live which are major search engine in whole world and try to find information. Search Engine has millions of visitor per day. But problem of man mind is that they see only 2 or 3 pages in search engine’s given result. Suppose for example I want to develop software or doing seo of my site but I don’t know whether I should go. At that time I open google and write “Software developer in rajkot” or “seo in rajkot” or “Developer in rajkot” I found thousands of pages , But which I preferred. I preferred only first 2 to 4 pages. So whose site come first 4 pages they got batter visitor as well better business too. So if my developed web site is on first 4 pages than defiantly I don’t want to go any where for marketing. And I got lot of business per day. But that things are happen only and only when you are come top on selected search engine.

Now you have to think whether you should go with seo marketing or only marketing????

Contact Detail:
Mr. Sagar Jagdish K.
Mail: sagar.net2005@gmail.com
Mo: +91 999 888 98 04.

Software Development In Rajkot, Seo in rajkot, Web development in rajkot.

Hello friends i m sagar jagdish from rajkot again with you with new development with my team in rajkot. I have 3.5 year experience in programming field so if you want to make any software, dynamic website, you want to go on top with top search engine like google, msn, yahoo, AltaVista ,live and many more with your preferred keyword . By doing seo (Search engine optimization) on your site you can go on top of the Search Engine and done your business as batter than present.

I have developed numbers of software at my job. Which is currently in rajkot with Mitul Dadhaniya.

1.) Cold storage management system.
Software developed for Rajendra Cold Storage Metoda Rajkot. Software which can manage all terms of cold storage with billing system, account, and thirty five reports etc.
2.) File Secrete.
Software is totally based on system level. You can secure your file and that file you can mail it. Clean the system with temporary unwanted file etc.

3.) All Web submitter.
Software had developed for and only for SEO (Search Engine Optimization) .Software has many features like Directory submission, Link submission, Auto Submission with our given more than 1500 directory and you can also verify your submission that is also totally automatic.

We are doing SEO (Search Engine Optimization in rajkot ) too. And also directory submission, article submission, Link submission etc.
So if you have any project on desktop application, web application, SEO Search Engine Optimization, Directory submission , Link Submission with (100% approval Guaranty) in rajkot or any where.
I have 8 people team who are working with me since last 1.8 years. All member in my team have good knowledge in specific technology. Who can able to work more than 12 hours so if you want to develop any urgent project than you can go with us.

We are working on
a).Net technology,
asp.net with c# and vb
b)PHP
c)Visual Basic 6.0

With

a)Ms Access.
b)Oracle 8i
c)MS Sql server 2005.

You can contact me any on my mail my contact detail is:-

1) Sagar jagdish K.
sagar.net2005@gmail.com
jagdish.net2005@gmail.com
sagar.softwareengg@gmail.com
My personal blog is
http://friendza4u.blogspot.com

Mo. +91 9998 88 98 04

2) Rabadiya Kaushik C.
kaushikkavi@gmail.com
kaushik.rabadiya@gmail.com
See Me @
http://kaushikkavi.blogspot.com
http://kaushikrabadiya.blogspot.com

Mo. +91 9998 77 12 67.

3) Mogal Masum I.
er.masum2007@gmail.com
Mo. +91 9898 04 16 77

Sagar jagdish's farm

My jakas farm at aambardi

My grand papa's temple

Temple is in my farm

Sweet home at my farm

My Home at aambardi

Naginawadi ahmedabad

At the time of daksha's birthday

Nice scene of nyari

That is captured at the time of jalsh

software developer's life

My life as a Code Economist

The six billion people of the world can be divided into two groups:

People who know why every good software company ships products with known bugs.
People who don't.
Those of us in group 1 tend to forget what life was like before our youthful optimism was spoiled by reality. Sometimes we encounter a person in group 2, perhaps a new hire on the team or even a customer. They are shocked that any software company would ever ship a product before every last bug is fixed.

Every time Microsoft releases a new version of Windows, major news services carry a story about the fact that the open bug count is a five digit number. People in group 2 find that sort of thing interesting.

The surprising truth is that a person in group 2 can lead a productive life. In fact, as with most any other kind of ignorance, they're probably happier that way.

The exception of course is if you are a software developer. That's an entirely different story. If you earn your living building shrinkwrap software products, you need to get yourself in group 1.

Perhaps, dear reader, you are a software developer in group 2? If so, I'm sorry I had to be the one to tell you this. I feel like I'm telling the neighbor kid that Santa Claus isn't real. :-)

Okay, seriously. I apologize for the mock arrogance of the previous paragraphs, and for the Santa Claus remark. I mean no condescension. Just like everybody else, I've got lots to learn. But I've also got lots of gray hair. Some people read my stuff because they want to benefit from the lessons I learned from all the stupid mistakes I made which caused that gray hair.

Which reminds me -- let me tell you a story...

In hindsight, releasing on Halloween probably wasn't such a good idea.
Last week was a terrible week at SourceGear. Most weeks I really enjoy my job. By the end of last week, I was reminding myself every hour that I get paid to do this.

Everything started out great on Monday, October 31st. It was the very first day in our new office space, and our whole company had a feeling of enthusiasm. We planned to release the Vault 3.1.3 maintenance release that day. It was ready the week before, but it didn't make sense to release it just before the move.

(Here at SourceGear, we ship a "maintenance release" of Vault whenever we want to provide our customers with bug fixes or other minor improvement. Our version numbering scheme is "Major.Minor.Maintenance". Version 4.0.7 would indicate that it is the seventh maintenance release since Vault 4.0. Historically, we have done one maintenance release each month or so.)

It started raining around noon. Those of us with children began to dread the prospect of going out to Trick-or-Treat in the rain. Still, a little bad weather wasn't enough to squash the mood. Our new office space is great, and we had a general feeling of confidence about 3.1.3. Vault 3.1 has been a really solid product. The 3.1.3 release contained several bug fixes, but none of them were really urgent. We shipped the release believing that it would be the last maintenance release for quite a while.

Unfortunately, things didn't work out that way at all. The 3.1.3 release introduced two new bugs.

But we didn't know that yet when we came in Tuesday morning wearing all smiles. The rain was gone and it was a beautiful fall day. Looking out my east window I could see the bright sun highlighting the colors of the autumn leaves on thousands of trees on the University of Illinois campus. With the relocation and the 3.1.3 release behind us, I looked forward to having the entire team focused on the development of Vault 4.0.

Then the groaning began. We found the first bug that morning: Something in 3.1.3 broke the ability for the client to store certain settings in the registry. It was a minor bug, but very annoying. Any user who changed their personal settings after installing 3.1.3 was going to lose those settings when we eventually released a fix.

The fix for this bug was easy. We really wanted to get it done quickly. The longer we left 3.1.3 out there, the worse it was going to be. So on Wednesday, we released version 3.1.4, containing nothing more than a fix for this client settings bug.

I'm a golfer, so I refer to this kind of situation as a "mulligan". In golf, a mulligan is basically a "do-over". You hit a bad shot, so you just ignore it and try again.

I hate mulligans. We shipped a maintenance release 48 hours after the previous one! This was just embarrassing, but we figured the best we could do was just forget about it and go back to work.

When we came to the office Thursday morning, the world didn't seem quite as wonderful as it did on Tuesday, but we were ready to be optimistic again. The mulligan was behind us. We told ourselves we wouldn't need another maintenance release for the rest of the year. Everyone went back to being busy developing the cool new features for Vault 4.0.

And then we discovered the second bug which was introduced in 3.1.3. The first bug caused groaning. This one provoked a few colorful metaphors. Here's the bug: Add a binary file to the repository. Branch the folder containing that file. Now try and retrieve that file from the branch. You can't. The Vault server returns an error.

This bug had to be fixed. There was no other alternative. Developers get kind of fussy when they can't get their files from the repository.

So on Friday we released Vault 3.1.5, the third maintenance release in a week. This felt like one of the lowest points in our company history. We started asking ourselves what went wrong.

Regression Testing
Clearly, this was a failure of "regression testing". I am a little hesitant use this term, as it makes me sound like a testing guru when I am not. The real experts in the field of software testing can speak at great length about the many different kinds of testing. There is unit testing, regression testing, integration testing, system testing, black box testing, white box testing, stress testing and that funky "Australian rules" testing where you have to hit the bug with your fist. These guys can pick any one of these types of testing and write an entire textbook on it.

Sometimes when I see all this jargon I break out in a Forrest Gump imitation:

"I'm not a smart man, but I know what testing is." (mp3)

I am definitely not a testing guru, but I know about regression testing. Regression testing is used to verify that you didn't accidentally break something. Regression testing is what you do to make sure that the product didn't accidentally get worse. Regression testing is the testing you do to prevent mulligans.

Despite the fiasco here at SourceGear last week, we do believe in regression testing. In fact, we use three different ways of verifying that our product isn't moving backwards:

Automated tests. Our automated build system sends every Vault build through a suite of regression tests to verify that nothing got broken.
Manual tests. Every build we release is manually examined by testers to verify that nothing looks broken.
Dogfooding. We use our own product, so most of the time we catch problems before the bits ever leave the building.
Somehow, those two bugs slipped through all three of these safety nets. Evidently we need some more work in the area of regression testing.

As luck would have it, we were already in the process of revamping our build system to use continuous integration. We originally started doing this because our customers want us to make sure that Vault works extremely well with CruiseControl.NET. But we will obviously gain the benefits internally as well. The concept makes enormous sense. If the product should "regress", we want to know as quickly as possible.
So now we have a brand new automated build server which throws a hissy fit whenever something gets screwed up. It's an absurdly fast machine with dual-core Opterons and RAID disks. Our build/test time went from 45 minutes on the old machine to just 15 minutes now. We're also going to get one of those nifty build orbs that changes color whenever the build fails.
Our next step is to write a few more regression tests to specifically deal with the situation from last week.
Then we need to set up NCover. This will of course be a bad day. Code coverage is the perfect example of the old maxim that "things get worse before they get better". Everyone's experience with code coverage is basically the same. The first time you run code coverage, you are horrified because no matter how comprehensive you think your test suite is, the initial percent coverage is surprisingly low. That's the beauty of using code coverage -- it gives you a useful quantitative result to replace a qualitative guess which is almost always wildly optimistic.
Finally, we need to start writing more regression tests and watch our percent coverage go up.
Our build and test practices were already very important to us. Now we're taking those practices to the next level.

However, and getting back to the place where this article started, sometimes the way to prevent mulligans is to not break the code in the first place.

An ounce of prevention...
So why would an ISV ever intentionally release a product with known bugs? Several reasons:

You release with known bugs because you care about quality so deeply that you know how to decide which bugs are acceptable and which ones are not.
You release with known bugs because it is better to ship a product with a quality level that is known than to ship a product which is full of surprises waiting to happen.
You release with bugs because the alternative is to fix them and risk introducing more bugs which are worse than the ones you have now.
All of the reasons for such a decision are tied up in this one basic truth:

Every time you fix a bug, you risk introducing another one.

Every code change carries the potential for unintended side effects. Stuff happens.

Even as I write this, I miss the blissful ignorance of life in group 2. Don't we all start out with the belief that software only gets better as we work on it? The fact that we need regression testing is somehow like evidence that there is something wrong with the world. After all, it's not like anybody on our team is intentionally creating new bugs. We're just trying to make sure our product gets better every day, and yet, somewhere between 3.1.2 and 3.1.3, we made it worse.

But that's just the way it is. Every code change is a risk. A development cycle that doesn't recognize this will churn indefinitely and never create a shippable product. At some point, if the product is ever going to converge toward a release, you have to start deciding which bugs aren't going to get fixed.

To put it another way, think about what you want to say to yourself when look in the mirror just after your product is released. The people in group 2 want to look in the mirror and say this:

"Our bug database has ZERO open items. We didn't defer a single bug. We fixed them all. After every bug fix, we regression tested the entire product, with 100% code coverage. Our product is perfect, absolutely flawless and above any criticism whatsoever."

The group 1 person wants to look in the mirror and say this:

"Our bug database has lots of open items. We have carefully reviewed every one of them and consider each one to be acceptable. In other words, most of them should probably not even be called bugs. We are not ashamed of this list of open items. On the contrary, we draw confidence from this list because we are shipping a product with a quality level that is well known. There will be no surprises and no mulligans. We admit that our product would be even better if all of these items were "fixed", but fixing them would risk introducing new bugs. We would essentially be exchanging these bugs which we find acceptable for the possibility of newly introduced bugs which might be showstoppers."

I'm not talking about shipping crappy products. I'm not suggesting that anybody ship products of low quality. I'm suggesting that decisions about software quality can be tough and subtle, and we need to be really smart about how to make those decisions. Sometimes a "bug" should not be fixed.

Should we fix this bug or not?
There are four questions to ask yourself about every bug:



Question One
When this bug happens, how bad is the impact?
Severity

Question Two
How often does this bug happen?
Frequency

Question Three
How much effort would be required to fix this bug?
Cost

Question Four
What is the risk of fixing this bug?
Risk




Two of them are "customer questions", and the other two are "developer questions".

The Customer Questions: Severity and Frequency
For the first two questions, I like to visualize Severity and Frequency plotted on a 2D graph:

The vertical axis is Severity.
The top of the graph represents a bug with extremely severe impact:
"This bug causes the user's computer to burst into flame."
The bottom of the graph represents a bug with extremely low impact:
"One of the pixels on the splash screen is the wrong shade of gray."
The horizontal axis is Frequency.
The right side represents a bug which happens extremely often:
"Every user sees this bug every day."
The left side represents a bug which happens extremely seldom:
"This bug only affects people who live in eastern Washington state and who have both Visual Studio 2003 and Visual Studio 2005 installed and it only happens during leap years on the day that daylight savings time goes into effect and only if the first day of that month was a Tuesday."


Try not to get hung up figuring out the exact line or curve which separates the bugs to be fixed from the bugs to be deferred. Speaking very broadly, stuff gets more important as you move up or to the right of the graph. The orange bug in the upper right should be fixed. The blue bug in the lower left should not.

This graph isn't terribly useful as a formal analysis tool for bug sorting. Attempts to be more quantitative are not likely to be productive. However, the graph can be helpful as a communication tool. Sometimes in a team discussion I actually draw this graph on a whiteboard when I am trying to argue for or against a certain bug.

The Developer Questions: Cost and Risk
Questions One and Two are about the importance of fixing a bug. Questions Three and Four are about the tradeoffs involved in fixing it.

Corollary: The answers to Questions Three and Four can only make the priority of a bug go down, never up. If after answering Questions One and Two it seems obvious that a given bug does not deserve attention, the other two questions should be skipped. A common mistake is in using Question Three to justify fixing a bug which isn't important. Don't make unimportant code changes just because they're easy.

The real purpose of these two questions is when you already know that the Severity and Frequency suggest that a given bug should be fixed. The questions about Cost and Risk are like a dialog box that says, "Are you sure?"

Every code change has a cost and a risk. Bad decisions happen when people make code changes ignoring these two issues.

Example: Item 6740
Vault stores all data using Microsoft SQL Server. Some people don't like this. We've been asked to port the back end to Oracle, PostgreSQL, MySQL and Firebird. This issue is in our bug database as item 6740. The four questions would look like this:

Severity: People who refuse to use SQL Server can't use Vault at all.
Frequency: This "bug" affects none of our current users. It merely prevents a group of people (those who refuse to use SQL Server) from using our product.
Cost: Very high. Vault's back end makes extensive use of features which are extremely specific to Microsoft SQL Server. Contrary to popular belief, SQL isn't portable. Adapting the backend for any other database would take months, and the ongoing maintenance costs of two backends would be quite high.
Risk: In terms of newly introduced bugs, the primary risk here lies in any code changes we would make to the server to enable it to speak to different back end implementations of the underlying SQL store.
Bottom line: This example is easy. It's obviously more of a feature request than a bug. Still we've talked about this, and the four questions play a part of the discussion.

Example: Item 10016
I told the story of Vault 3.1.3-4-5 mostly to illustrate the fact that code changes can have unintended side effects and that we need more regression testing. However, it is reasonable to discuss this fiasco in the context of my four questions.

As an example, consider the "can't fetch binary files after a branch" bug. We introduced this bug during an attempt to fix bug 10016, another bug which involves a problem with conversion of End-Of-Line terminators for Linux and MacOS users. The four questions for this EOL bug would have looked something like this:

Severity: For a certain class of users, this bug is a showstopper for their use of Vault. It does not threaten data integrity, but it makes Vault unusable.
Frequency: This bug only affects users on non-Windows platforms, currently a rather small percentage of our user base.
Cost: The code change for this bug is small and appears simple.
Risk: We obviously thought the risk here was low. Hindsight is 20/20. :-)
If regression testing had told us that the Risk was higher than we thought, we would have revisited the four questions. Because the Frequency is relatively low, we might have decided to defer this bug fix until we figured out how to do it without breaking things.

In fact, that's what we ended up doing. In the 3.1.5 release last Friday, we simply un-did the fix for bug 10016. Bug 10016 is now "open" again. A 3.1.6 maintenance release is therefore probably on the way. :-(

Example: Item 4860
From an idealist's point of view, a nice feature of a version control system is the fact that nothing ever really gets deleted. Your repository is a complete archive of every checkin which has ever occurred.

But in real life, sometimes you actually do want to pretend that something never happened. For these situations, Vault has a feature called Obliterate. Unlike the Delete command, which doesn't really delete anything, the Obliterate command is destructive.

Bug 4860 basically says that our Obliterate command is slow.

Severity: Obliterate is slow. Really slow.
Frequency: Obliterate is not a command which is used every day. Still, most users need it once in a while.
Cost: The effort required is very close to a complete rewrite of the feature. Ballpark estimate: One developer, code complete in a month.
Risk: Stunningly high. This is the only feature in our product which destroys anything. Every other aspect of Vault was designed with a pathological paranoia over loss of data.
Bug 4860 is a real pain the neck. Users gripe about it, and we totally understand why. However, in terms of Severity and Frequency, we're only talking about slow performance of a feature which is not frequently used. When you add Risk to the discussion, it suddenly becomes easy for our developers to procrastinate on bug 4860 and find something else more urgent to do. The current implementation of this feature is slow as molasses, but it is known to be safe. We are terrified of touching it.

Nonetheless, this bug is on the schedule for Vault 4.0. A product in its 4.0 release should be more polished and refined than it was at 2.0. I am not fond of this feature, but I admit that bug 4860 is valid and its time has come.

Market Context
Some of you already think I am making this issue far too complicated. If so, you're not gonna like this next part.

Not only do you have to answer the four questions, but you have to answer those questions with a good understanding of the context in which you are doing business. Markets vary. Each has its own competitive pressures and quality expectations. You need to understand two things:

Understand the Quality Expectations of your market segment.
Understand what the Market Window is for your product.
I'm probably going to get flamed for saying this, but it's the truth, so here it is: The reason we can ship products with "bugs" is that there are "bugs" that customers will find acceptable. Nobody wants a crappy product, but that doesn't mean that everybody expects every product to be utterly perfect.

Quality Expectations
Different market segments have different expectations about product quality. People who write code for the space shuttle are dealing with higher quality standards than people who write casual games.

Years ago I worked as part of a team where the quality standards were incredibly high. We were building software which was burned into the ROM of consumer cell phones. This is a world where mulligans are not an option. You only get one chance to burn that ROM. Life is unbelievably bad if you discover a serious bug just after your software shipped inside a million phones. Our development cycles were incredibly long, since most of the time was spent testing and bug-fixing until the code coverage level was well over 90% and the traceability matrix was complete.

At SourceGear we build and sell version control tools. People use our product to store and manage their own source code. The quality expectations in our market are extremely high, but there is still a gap between those expectations and perfection. Understanding those expectations is an important part of our decision-making. A bug which affects the safety of our customers' data is obviously going to be prioritized higher than anything else.

The fact is that last week's mistakes are not going to be fatal for SourceGear. In fact, in a bit of irony, it was our highest revenue week ever. :-)

What happened last week was embarrassing and frustrating, but the company will certainly survive. The bugs we introduced in 3.1.3 were a potential inconvenience for our customers, but their data was never threatened, and since they download Vault releases over the Internet, it's relatively simple for us to release fixes. After three maintenance releases in five days, we swallowed our pride, briefly acknowledged how happy we are that Vault is not burned into the ROMs of a cell phone, and start figuring out how to prevent mulligans in the future.

Market Window
We all know what happens if a product falls short of the customers' quality expectations. For some ISVs, this is a problem, but most developers naturally have a sense of craftsmanship and pride in their work. Good developers want to exceed the quality standards of their customers.

But is it possible to make a mistake by going too far? Can we err by exceeding the quality standards of our customers too much? Why would anyone mind if we shipped a product which was higher quality than the market needs?

If quality could be obtained without tradeoffs, there would be no problem. However, time is always a constraint. There is a "market window" for your product, and it is closing. After a certain point, the market doesn't want your product anymore. It's too late.

And product quality takes a lot of time. Increases in the quality of your product tend to become an exercise in constantly diminishing returns. Which of the following choices makes more sense?

Deliver a product today with a quality level that your market considers acceptable.
Deliver a product one year later with a quality level that is higher than your market requires.
Choosing the second option gives you the warm and fuzzy feeling of building a really high quality product. This is a cool thing. Good developers must have a sense of pride in their craftsmanship, and nothing I say should be construed to diminish the importance of that.

Furthermore, having a higher quality product offers competitive benefits. All else equal, fully informed customers will choose the higher quality product.

But the fact is that shipping a year later means missing out on a year of important benefits, not the least of which is revenue. In most market segments, there is a competitor who is ready and willing to help customers while you spend that year climbing the asymptotic hill toward product perfection. Congratulations on building a product which makes you feel good. Unfortunately, your ISV is now dead.

Remember, I'm not arguing for crappy software. I'm arguing that building products to please yourself instead of your customers is always a mistake.

Quality and craftsmanship are incredibly important. If you're going to err to one side of this issue, obviously you should go for more quality, not less.

But black-and-white perfectionist thinking will kill your ISV. Most people can intuitively recognize that there is no such thing as a software product which is absolutely 100% perfect. A central skill of managing an ISV is making tough decisions about exactly how your product is going to miss perfection.

Eric, why are you making this so complicated?
I'm not the one making this complicated -- it got that way all by itself. :-)

I know what you want. I want it too. I want a way to make all these decisions easy. I want an algorithm with simple inputs that tells me which bugs I should fix and the order in which I should fix them.

I want to implement this algorithm as a feature in our bug-tracking product and make gigabucks selling it to all those people who think they can save money by hiring software development managers that are devoid of clue. Wouldn't this be a killer feature?

In the Project Settings dialog, the user would enter a numeric value for "Market Quality Expectations" and a specific schedule for the closing of the "Market Window".
For every bug, the user would enter numeric values for Severity, Frequency, Cost and Risk.
The Priority field for each bug would then be automatically calculated. Sort the list on Priority descending and you see the order in which bugs should be fixed. The ones near the bottom will have a Priority less than zero, indicated that they should not be fixed at all.
Heck, I'd probably even patent this algorithm. I have long suspected that I am a complete hypocrite on the issue of software patents. In principle, I believe that software patents are fundamentally evil, but my ethics would probably do a 180 if I had a patent which allowed me to purchase a Gulfstream jet. :-)

Alas, this ethical quandary isn't going to happen, as "Eric's Magic Bug Priority Algorithm" does not exist, and it never will. There is no formula to make this easy. Figuring out exactly how your product is going to be imperfect is hard. It should be hard.

The bad news is that there is no shortcut. Understand your context, ask all four questions, and use your judgment.

The good news is that experienced developers can usually make these decisions very quickly. In many cases, it only takes a few seconds to mentally process the four questions and make a decision. In the tougher cases, gather two coworkers near a whiteboard and the right answer will probably show up soon.

Eric Sink, Code Economist
The title on my business card says "Software Craftsman", a choice which reflects my preference for speaking of software development in terms of craftsmanship rather than engineering or art.

But I admit that my metaphor is not a perfect match. Comparing shrinkwrap software development to handcrafts doesn't adequately reflect the part of my job which requires tough decisions. A cross-stitch piece can be perfect. A non-trivial software product cannot.

For this reason, I also like to compare shrinkwrap software development to macroeconomics. It's an optimization problem. Every choice involves tradeoffs. Success is not found by building a perfect product, but rather, by finding a perfect set of compromises.

Apparently Federal Reserve chairman Alan Greenspan is going to be out of work in a couple months. Perhaps he should consider a career in software? He might be good at it. :-)

Jagdish

Photo comes in my best selection