IPL 2010 Schedule
The following code sample shows that “How to add multiple items to a paypal shopping cart at once” :-
<form action=”https://www.paypal.com/cgi-bin/webscr” method=”post”>
<input type=”hidden” name=”cmd” value=”_cart”>
<input type=”hidden” name=”upload” value=”1″>
<input type=”hidden” name=”currency_code” value=”GBP”>
<input type=”hidden” name=”business” value=”email@example.com”>
<input type=”hidden” name=”item_name_1″ value=”MyItem #1″>
<input type=”hidden” name=”amount_1″ value=”5.00″>
<input type=”hidden” name=”item_name_2″ value=”MyItem #2″>
<input type=”hidden” name=”amount_2″ value=”7.00″>
<input type=”submit” value=”PayPal”>
Below discussed are various Google’s special commands and I shall be explaining each command in brief and will show how it can be used for critical information digging.
[ intitle: ]
The “intitle:” syntax helps Google restrict the search results to pages containing that word in the title. For example,“intitle: login password” (without quotes) will return links to those pages that has the word “login” in their title, and the word “password” anywhere in the page.
Similarly, if one has to query for more than one word in the page title then in that case “allintitle:” can be used instead of “intitle” to get the list of pages containing all those words in its title. For example using “intitle: login intitle: password” is same as querying “allintitle: login password”.
[ inurl: ]
The “inurl:” syntax restricts the search results to those URLs containing the search keyword. For example: “inurl: passwd” (without quotes) will return only links to those pages that have “passwd” in the URL.
Similarly, if one has to query for more than one word in an URL then in that case “allinurl:” can be used
instead of “inurl” to get the list of URLs containing all those search keywords in it. For example: “allinurl:etc/passwd“ will look for the URLs containing “etc” and “passwd”. The slash (“/”) between the words will be ignored by Google.
[ site: ]
The “site:” syntax restricts Google to query for certain keywords in a particular site or domain. For example: “exploits site:hackingspirits.com” (without quotes) will look for the keyword “exploits” in those pages present in all the links of the domain “hackingspirits.com”. There should not be any space between “site:” and the “domain name”.
[ filetype: ]
This “filetype:” syntax restricts Google search for files on internet with particular extensions (i.e. doc, pdf or ppt etc). For example: “filetype:doc site:gov confidential” (without quotes) will look for files with “.doc” extension in all government domains with “.gov” extension and containing the word “confidential” either in the pages or in the “.doc” file. i.e. the result will contain the links to all confidential word document files on the government sites.
[ link: ]
“link:” syntax will list down webpages that have links to the specified webpage. For Example: “link:http://www.example.com” will list webpages that have links pointing to the SecurityFocus homepage.
Note there can be no space between the “link:” and the web page url.
[ related: ]
The “related:” will list web pages that are “similar” to a specified web page. For Example: “related:www.example.com” will list web pages that are similar to the Securityfocus homepage. Note there can be no space between the “related:” and the web page url.
[ cache: ]
The query “cache:” will show the version of the web page that Google has in its cache. For Example: “cache:http://www.example.com” will show Google’s cache of the Google homepage. Note there can be no space between the “cache:” and the web page url.
If you include other words in the query, Google will highlight those words within the cached document. For Example: “cache:http://www.example.com guest” will show the cached content with the word “guest” highlighted.
[ intext: ]
The “intext:” syntax searches for words in a particular website. It ignores links or URLs and page titles.
For example: “intext:exploits” (without quotes) will return only links to those web pages that has the search keyword “exploits” in its webpage.
[ phonebook: ]
“phonebook” searches for U.S. street address and phone number information. For Example: “phonebook:Lisa+CA” will list down all names of person having “Lisa” in their names and located in “California (CA)”. This can be used as a great tool for hackers incase someone want to do dig personal information for social engineering.
This class can be used to schedule a backup of a Cpanel hosting account.
It accesses the control Web server of a Cpanel installation and sends an HTTP request to schedule a backup with given parameters.
Currently it supports parameters for specifying the FTP account to where the backup files should be uploaded and the e-mail address to where the notifications should be sent.
The class displays the result page of backup schedule request using a given theme.
This class can be used to generate CAPTCHA validation images.
It generates an image with a given width and height display a random validation text with a given length. The generated random text is stored in a session variable for posterior validation.
Everyone want to make the Web Faster. But the question is “How”. Okay, i have collected some information’s from the world of web which I want to share with you. Please go through the below URL’s :
Yahoo Developers URL: http://developer.yahoo.com/performance/rules.html
Google URL: http://code.google.com/speed/articles/
Check Website Performance: http://www.webpagetest.org/test
Hope you find the above links useful.
I think this article will help when a Website Cost need to estimate. This article is copied from webdevbiz.com by Patty Ayers.
There’s no getting around it – almost every web site client you’ll ever have will want a cost estimate before work begins.
If the prospect makes you anxious, you’re not alone. Estimating a web project is not easy to do, even for pros. In fact, some very skilled web developers I know use systems of estimating which have more in common with consulting a Magic 8-Ball than with detailing time and costs – basically, they make wild guesses. Although this may get the unpleasant task over with quickly, it’s not helpful for keeping clients happy or for running a viable business.
But with some preparation and organization, estimating can be done with reasonable accuracy, and without any permanent damage to your mental health.
A Few Thoughts on Free Estimates
Some web developers offer free estimates as a matter of policy. I believe that this can be problematic, especially for very small companies, and so recommend giving it due consideration before publishing that offer.
The reasoning is simple: estimating well takes time, and not every estimate will net you a contract. Depending upon your market and the tone you set with your business, you may get a lot of “shoppers”. Shoppers are looking to get estimates from several companies and compare them, and you may very well be only a pawn in their process of finding the supposedly “best deal” – or worse still, in driving the price down with someone who they’ve already decided to work with.
If this turns out to be the case, it’s not the end of the world, of course – but how many times a month do you want to spend several hours (or more) working for someone for no pay? Of course, that decision has to be up to you.
In my business, we provide an estimate for free if we think that an accurate specification can be determined and written up within a couple of hours. If we feel that it’s a complex enough project that it will take us 5-10 hours or more of meeting, talking, researching, and writing and re-writing the specifications, we charge for that time. We tell the client that we’ll be spending valuable consulting time with them, determining their needs, and that we’ll produce a detailed specification document and cost estimate. This information is obviously of value whether or not they decide to work with us. If they do decide to work with us, the cost of the specification-development phase is applied to the total cost of the project. Either way, their money is well-spent.
After all, developing a web site is not the same as painting the living room or fixing a leaky faucet. Free estimates and convenient price-shopping may be commonplace in a lot of industries, but they aren’t necessarily appropriate for complex creative and technical work.
But whether or not you’re being paid for your time, the process should be the same.
A Five-Step Process
Estimating is essentially a five-step process:
- Determine what the specifications are for the site
- Break these specifications down into as many smaller tasks as possible
- Figure as accurately as possible the amount of time each task will take
- Add up the total hours and multiply by your hourly rate
- Add a percentage for contingencies, add expenses, and total it all up
Determine what the specifications are for the site. This is usually the most difficult part of the process. Clients often don’t have a clear idea of what they want; they need your help to clarify and articulate what kind of web site they have in mind. This can be done through in-person or telephone meetings and emails, but you have to take the wheel, and you often have to persevere through a certain amount of uncertainty, hesitance, and outright fogginess.
It’s helpful to have a list of the various aspects and features of web sites to help you and the client through this process. Your conversations need to cover every aspect of the proposed web site, including:
- Total number of pages
- What kind of navigation bars or menus
- More than one page design?
- Number of custom graphics needed
- Number of graphics provided by the client
- How design-intensive a site do they want?
- What type of text content, provided in what form?
- Interactive forms? How many fields?
- Database-driven applications? (Detailed description of all functionality is needed)
- Administration areas?
- Domain registrations or changes?
- Hosting arrangements?
- How important is search engine positioning?
- Will any client training be necessary?
You won’t get all of this information worked out in a single conversation. For me, the process usually involves a series of conversations and email exchanges. After the first consultation, I go over my notes, usually typing them up so that they’re easier to read. I then write out a “sketchy” specification, usually somewhat vague at this point. This makes obvious what information I still need.
For instance, the client may have told me, “We want to display photos of the houses our firm has built”, but I need to know more. How many photos? Displayed in what way? With thumbnails linking to larger photos? Will they need captions? In what form will he be providing the photos? These questions are jotted down for the next conversation. When I have a complete list of questions, I phone the client, making sure he has some time to spend, and I ask him the questions one by one. The discussion is usually far from linear, and may jump from one subject to the next, but I make sure that I’m in charge, and that I get the information I need. Remember, the client doesn’t know how to write a specification for a web site – you do. The tangents and side-trips often provide valuable information too, so I try to be sure to listen well.
A friend of mine recently took a sales seminar, and came back very excited about what he had learned. Basically, he said, he learned that he needed to really, really listen to his potential clients and customers. This is crucial during the specification-development phase. But again, be sure that your questions are answered, and that an unfocused or overly chatty client doesn’t waste everybody’s time.
Always take notes when conversing with a client. Even if they are just scrawled notes, make sure you commit the crucial points of the conversation to writing, and be sure to date it.
The information you have after this second meeting may be enough to write up a detailed specification. Add the information you’ve gained to your sketchy specification document, and see if you can flesh it out enough that you feel you are very clear on what’s expected of you – and that the client will be very clear on what he is getting for the estimated price.
A note on pinning the client down on specifications: web site clients are notorious for figuring out what they really need and want only after a contract is signed and work has begun. This is so common that there’s really no point in fighting it – it’s almost guaranteed that the specifications will change. No problem – but make it clear to your client that when the specifications change, the cost estimate will change as well. Say this more than once during this phase: “This specification is only a snapshot, so that I can provide an estimate. If you add or subtract significant content or features, the cost estimate will definitely change. When that happens, I’ll provide you with a written description of the change and the difference in cost.”
You may need more conversations, or a series of emails, to clarify the specifications. Don’t rush it! Be sure that you have enough information before you commit to an estimated cost total.
Break the specifications down. Now, take each part of the specification document and break it down into as many actual tasks as possible. For instance, “Gallery of 30 photos of 6 different houses” might involve:
- Receiving and sorting out client’s photos
- Cropping, sizing, optimizing, and renaming photos
- Working with client to figure out how to present photos
- Creating thumbnails
- Building pages
- Receiving client’s feedback, correcting and refining gallery page design
Figure how much time each task will take. This part of the process requires a little brow-furrowing. For each task in your list, make your most honest estimate of the time it will require. Be realistic. You may want it to take one hour to build an entire page draft, but the reality is probably going to be closer to three or four hours. Give yourself enough time to do a good job! And remember – this type of time estimate is almost always short. Be generous!
Add up the total hours and multiply by your hourly rate. Even if you don’t plan to charge the client by the hour, but rather by the project, figuring by the hour is the only reasonable way to go, as it’s the only real available objective measure of “how much work”. The client doesn’t need to know anything about the hours you’re estimating it will take you, but you should know this.
Figuring your hourly rate is beyond the scope of this article; we’re assuming here that you have decided what you need and want to earn for each hour you work “on the clock”.
Add a percentage for contingencies, add expenses, and total it all up. The “contingency allowance” is something that experienced web and graphic designers don’t even question. Underestimating is so universal that providing a cushion against your own probable inaccuracy is highly advisable. Between 10-20% is typical. Expenses, of course, are any out-of-pocket costs such as the price of graphics purchased, paying subcontractors, etc. Add it all up, and there’s your total!
Stand your ground. You may be tempted to shrink the total estimate down, fearing that your potential client will find it too high, but resist that urge. You came up with as accurate an estimate as possible, and it makes no sense to lower it. The client may or may not like your price, but if you offer to do the job for less than what is fair for you, no good can come of it. Stand your ground! You won’t get every job, but the ones you do get will go much smoother if your estimate was accurate and fair.