Create a Slide Show with the Dreamweaver Timeline

The Dreamweaver Timeline uses layers and JavaScript to create animation and interactivity. To create a series of rotating images, prepare each image at the same size in a graphics program first (i.e., Photoshop, Fireworks, ImageReady, etc.). Then insert a layer on the page. This layer will serve as a placeholder for the rotating images.

To rotate the images:

1) Choose Insert...Image and select the image to appear when the page first loads

2) Open the Dreamweaver Timeline by choosing Window...Timeline

3) Select the image and choose Modify...Timeline...Add Object to Timeline

4) The Timeline contains 15 frames by default. Drag the animation bar to frame 25 by selecting the ending bullet (keyframe) and dragging.

5) Select frame 5 on the Timeline and choose Modify...Timeline...Add Keyframe

6) Change the image source by clicking on the folder icon on the Property Inspector. Select another image. This image will appear on frame 5 of the Timeline.

7) Select frame 10 and choose Modify...Timeline...Add Keyframe.

8) Change the image source again and select an image that will appear on frame 10.

9) Select frames 15 and 20 and add keyframes to each frame respectively. Then change the image SRC on the Property Inspector at each keyframe.

10) Scrub through the Timeline by dragging the playhead. Scrubbing allows you to see a preview of the animation at each keyframe.

11) Select the AUTOPLAY checkbox on the Timeline to play the animation automatically when the page loads. Select the LOOP checkbox on the Timeline to continuously play the timeline once the page is loaded.

12) Preview the animation in your browser.

This article could be read in
http://www.flawebdeb.com/septdebtip.htm and it was developed by Debbie Berg

More information on this topic could be found in

• Example 1
  
• Example 2
  
• Example 3
  

Example of Slide Show:
Sample Page

Sample files :
Zip File 1
Zip File 2

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

From macromedia site:

You can use the Image Viewer to display a series of images. The Image Viewer is useful in personal websites as a slide-show viewer for vacation photos or in e-commerce sites to showcase product photos.

Note: Website visitors must have Flash Player 7 installed to see any Image Viewers in your pages.

To use the Image Viewer in your page:

1. Place the insertion point in your page where you want the Image Viewer to appear and do one of the following:
   • In the Flash Elements category on the Insert bar, click the Image Viewer icon.
   • Select Insert > Media > Image Viewer.

   The Save Flash Element dialog box appears.

2. Browse to a location in your site to save the element, enter a name for the element, and click Save.

   Note: It's a good idea to save the Flash element in the same Dreamweaver site as the page to which you are adding the Image Viewer.

   The Flash element placeholder appears in your page and the Tag inspector opens.

3. Select the Flash element placeholder. In the Tag inspector (Window > Tag inspector), click in the field beside the imageURLs parameter, and click the Edit Array Values icon at the end of the line.

   The Edit imageURLs dialog box appears.

4. Click the Minus (-) button to remove placeholder elements; click the Plus (+) button to add images.

   You can add JPEG or SWF files.

   Note: It's a good idea to use files that are located in the same Dreamweaver site as the page to which you are adding the Image Viewer.

5. You can use the Tag inspector to set other parameters for the Image Viewer.

   For more information about the parameters, see Image Viewer parameters.

   Note: You can also set properties for the Image Viewer in the Property inspector. For more information, select the Flash element, and click the Help icon in the Property inspector.

6. Click the Play button in the expanded Property inspector to start the Image Viewer, and use the following Image Viewer controls to view images:
   • Click the Next or Previous button to view sequential images.
   • Enter a number in the text box to skip to a specific image.
   • Click the Play button to view the images as a slide show; click the Stop button to stop the slide show format.
7. Click the Stop button in the expanded Property inspector to stop playing the Image Viewer.

New Sober.Y variant is 2005 largest email worm outbreak

If you get a message from FBI or CIA or anyone, that looks like this
Examples of such messages include:

Dear Sir/Madam,
We have logged your IP-address on more than 30 illegal Websites.
Please answer our questions!
The list of questions are attached.
Yours faithfully,
Steven Allison
*** Federal Bureau of Investigation -FBI-

and has an attachment file in zip format or any other format, please delete the mail. DO NOT OPEN IT.

The first Sober was found in October 2003, over two years ago. F-Secure believes all 25 variants of this virus have been written by the same individual, operating from somewhere in Germany. Unlike most of the other widespread viruses nowadays, Sober doesn't seem to have a clear financial motive behind it.

Some Sober variants have displayed neo-nazi messages, but the latest version of the virus (Sober.Y) does not do this. However, all Sober variants send German messages to German email addresses and English messages to other addresses.

Several millions of emails infected with Sober.Y have been seen by Internet operators over the last hours.

MessageLabs has so far intercepted over 2.7-million copies of the new Sober virus, many of which are being spoofed to appear as though they are sent from the FBI or the CIA. The first copy was stopped on 21st November. The size of the attack indicates that this is a major offensive, certainly one of the largest in the last few months.

These emails suggest to recipients that their Internet use has been monitored by the FBI or CIA and that they have accessed illegal Web sites. The email directs users to open the ZIP attachment containing the executable, which once opened delivers the Sober virus payload. It then spreads by searching the infected computer for other email addresses to send copies of itself to, but ignoring any domains for certain security organizations, including MessageLabs.

The virus will send emails in German for domains ending .DE or .AT and a few others, with the remainder being sent in English. It seems that despite warnings, many recipients are still opening the emails allowing the virus to spread still further.

Since the virus first struck on Monday 21st November, the amount of viruses being sent per hour has approximately tripled, indicating that this particular strain of Sober virus has been written to rapidly exploit the so-called ‘zero hour’ holes in anti-virus security software (the time before anti-virus software writers have prepared and distributed an update to repair infected PCs).

Email Systems has noted that there are currently approximately thirty times the usual quantity of virus infected emails being sent and received online. This new virus has doubled email traffic in 24 hours.

Neil Hammerton, CEO of Email Systems, commented: “This is one of the worst viruses to strike in some time, spreading extremely rapidly. Although AV updates are actually now available from the major software vendors, it seems as though this particular variant managed to quickly grab a sufficiently large foothold to continue to propagate once the fixes were unveiled. Again this serves to underline the importance of using a specialist managed service for corporate email as users experience no zero hour syndrome as with AV software, given that our systems are specifically designed to continually check for virus-like activity and block infected emails before they reach the users’ network or PC.”

One of the reasons why this email worm seems to be so successful in spreading is that some of the messages it sends are fake warnings from FBI, CIA or from the German Bundeskriminalamt (BKA).

"The numbers we're now seeing with Sober.Y are just huge", comments Mikko Hypponen, Chief Research Officer at F-Secure Corporation. "This is the largest email worm outbreak of the year - so far!"

SQL Server Query Execution Plan Analysis

When it comes time to analyze the performance of a specific query, one of the best methods is to view the query execution plan. A query execution plan outlines how the SQL Server query optimizer actually ran (or will run) a specific query. This information if very valuable when it comes time to find out why a specific query is running slow.

There are several different ways to view a query's execution plan. They include:

• From within Query Analyzer is an option called "Show Execution Plan" (located on the Query drop-down menu). If you turn this option on, then whenever you run a query in Query Analyzer, you will get a query execution plan (in graphical format) displayed in a separate window.
  
  
• If you want to see an execution plan, but you don't want to run the query, you can choose the option "Display Estimated Execution Plan" (located on the Query drop-down menu). When you select this option, immediately an execution plan (in graphical format) will appear. The difference between these two (if any) is accountable to the fact that when a query is really run (not simulated, as in this option), current operations of the server are also considered. In most cases, plans created by either method will produce similar results.
  
  
• When you create a SQL Server Profiler trace, one of the events you can collect is called: MISC: Execution Plan. This information (in text form) shows the execution plan used by the query optimizer to execute the query.
  
  
• From within Query Analyzer, you can run the command SET SHOWPLAN_TEXT ON. Once you run this command, any query you execute in this Query Analyzer sessions will not be run, but a text-based version of the query plan will be displayed. If the query you are running uses temp tables, then you will have to run the command, SET STATISTICS PROFILE ON before running the query.

Of these options, I prefer using the "Show Execution Plan", which produces a graphical output and considers current server operations.

If you see any of the following in an execution plan, you should consider them warning signs and investigate them for potential performance problems. Each of them are less than ideal from a performance perspective.

• Index or table scans: May indicate a need for better or additional indexes.
• Bookmark Lookups: Consider changing the current clustered index, consider using a covering index, limit the number of columns in the SELECT statement.
  
• Filter: Remove any functions in the WHERE clause, don't include Views in your Transact-SQL code, may need additional indexes.
• Sort: Does the data really need to be sorted? Can an index be used to avoid sorting? Can sorting be done at the client more efficiently?

It is not always possible to avoid these, but the more you can avoid them, the faster your performance will be.

If you have a stored procedure, or other batch Transact-SQL code that uses temp tables, you cannot use the "Display Estimated Execution Plan" option in the Query Analyzer to evaluate it. Instead, you must actually run the stored procedure or batch code. This is because when a query is run using the "Display Estimated Execution Plan" option, it is not really run, and temp tables are not created. Since they are not created, any references to them in the code will fail, which prevents an estimated execution plan from being created.


On the other hand, if you use a table variable (available in SQL Server 2000) instead of a temp table, you can use the "Display Estimated Execution Plan" option

If you have a very complex query you are analyzing in Query Analyzer as a graphical query execution plan, the resulting plan can be very difficult to view and analyze. You may find it easier to break down the query into its logical components, analyzing each component separately.

The results of a graphical query execution plan are not always easy to read and interpret. Keep the following in mind when viewing a graphical execution plan:

• In very complex query plans, the plan is divided into many parts, with each part, listed one on top of the other on the screen. Each part represents a separate process or step that the query optimizer had (has) to perform in order to get to the final results.
• Each of the execution plan steps is often broken down into smaller sub-steps. Unfortunately, you don't view the sub-steps from left to right, but from right to left. This means you must scroll to the far right of the graphical query plan to see where each step starts.
  
• Each of the sub-steps and steps is connected by an arrow, showing the path (order) taken of the query when it was executed.
• Eventually, all of the parts come together at the top left side of the screen.
  
• If you move your cursor above any of the steps or sub-steps, a pop-up windows is displayed, providing more detailed information about this particular step or sub-step.
  
• If you move your cursor over any of the arrows connecting the steps and sub-steps, you see a pop-up window showing how many records are being moved from one step or sub-step to another step or sub-step.

The arrows that connect one icon to another in a graphical query plan have different thicknesses. The thickness of the arrow indicates the relative cost in the number of rows and row size of the data moving between each icon. The thicker the arrow, the more the relative cost is.

You can use this indicator as a quick gauge as to what is happening within the query plan of your query.

You will want to pay extra attention to thick arrows in order to see how it affects the performance of your query. For example, thick lines should be at the right of the graphical execution plan, not the left. If you see them on the left, this could indicate that too many rows are being returned, and that the query execution plan is less than optimal.

In an execution plan, each part of it is assigned a percentage cost. This represents how much this part costs in regard to resource use, relative to the rest of the execution plan. When you analyze an execution plan, you should focus your efforts on those parts that have the largest percentage cost. This way, you focus your limited time on those areas that have the greatest potential for a return on your time investment.

In an execution plan, you may have noticed that some parts of the plan are executed more than once. As part of your analysis of an execution plan, you should focus some of your time on any part that takes more than one execution, and see if there is any way to reduce the number of executions performed. The fewer executions that are performed, the faster the query will be executed.

In an execution plan you will see references to I/O and CPU cost. These don't have a "real" meaning, such as representing the use of a specific amount of resources. These figures are used by the Query Optimizer to help it make the best decision. But there is one meaning you can associate with them, and that is that a smaller I/O or CPU cost uses less server resources than a higher I/O or CPU cost.
When you examine a graphical SQL Server query execution plan, one of the more useful thing to look for is how indexes were used (if at all) by the query optimizer to retrieve data from tables from a given query. By finding out if an index was used, and how it was used, you can help determine if the current indexes are allowing the query to run as well as it possibly can.

When you place the cursor over a table name (and its icon) in a graphical execution plan, and display the pop-up window, you will see one of several messages. These messages tell you if and how an index was used to retrieve data from a table. They include:

• Table Scan: If you see this message, it means there was no clustered index on the table and that no index was used to look up the results. Literally, each row in the table being queried had to be examined. If a table is relatively small, table scans can be very fast, sometimes faster than using an index.
  
  So the first thing you want to do, when you see that a table scan has been performed, is to see how many rows there are in the table. If there are not many, then a table scan may offer the best overall performance. But if this table is large, then a table scan will most likely take a long time to complete, and performance will suffer. In this case, you need to look into adding an appropriate index(s) to the table that the query can use.
  
  Let's say that you have identified a query that uses a table scan, but you also discover that there is an appropriate nonclustered index, but it is not being used. What does that mean, and how come the index was not used? If the amount of data to be retrieved is large, relative to the size of the table, or if the data is not selective (which means that there are many rows with the same values in the same column), a table scan is often performed instead of an index seek because it is faster. For example, if a table has 10,000 rows, and the query returns 1,000 of them, then a table scan of a table with no clustered index will be faster than trying to use a non-clustered index. Or, if the table had 10,000 rows, and 1,000 of the rows have the same value in the same column (the column being used in the WHERE clause), a table scan is also faster than using a non-clustered index.
  
  When you view the pop-up window when you move the cursor over a table in a graphical query plan, notice the "Estimated Row Count" number. This number is the query optimizer's best guess on how many rows will be retrieved. If a table scan was done, and this number is very high, this tells you that the table scan was done because a high number of records were returned, and that the query optimizer believed that it was faster to perform a table scan than use the available non-clustered index.
  
  
• Index Seek: When you see this, it means that the query optimizer used a non-clustered index on the table to look up the results. Performance is generally very quick, especially when few rows are returned.
  
  
• Clustered Index Seek: If you see this, this means that the query optimizer was able to use a clustered index on the table to look up the results, and performance is very quick. In fact, this is the fastest type of index lookup SQL Server can do.
  
  
• Clustered Index Scan: A clustered index scan is like a table scan, except that it is done on a table that has a clustered index. Like a regular table scan, a clustered index scan may indicate a performance problem. Generally, they occur for two different reasons. First, there may be too many rows to retrieve, relative to the total number of rows in the table. See the "Estimated Row Count" to verify this. Second, it may be due to the column queried in the WHERE clause may not be selective enough. In any event, a clustered index is generally faster than a standard table scan, as not all records in the table always have to be searched when a clustered index scan is run, unlike a standard table scan. Generally, the only thing you can do to change a clustered index scan to a clustered index seek is to rewrite the query so that it is more restrictive and fewer rows are returned.

In most cases, the query optimizer will analyze joins and JOIN the tables using the most efficient join type, and in the most efficient order. But not always. In the graphical query plan, you will see icons that represent the different types of JOINs used in the query. In addition, each of the JOIN icons will have two arrows pointing to it. The upper arrow pointing to the JOIN icon represents the outer table in the join, and the lower arrow pointing to the JOIN icon represent the inner table in the join. Follow the arrows back to see the name of the table being joined.

Sometimes, in queries with multiple JOINs, tracing the arrow back won't reveal a table, but another JOIN. If you place the cursor over the arrows pointing to the upper and lower JOINs, you will see a popup window that tells you how many rows are being sent to the JOIN for processing. The upper arrow should always have fewer rows than the lower arrow. If not, then the JOIN order selected by the query optimizer might be incorrect (see more on this below).

First of all, let's look at JOIN types. SQL Server can JOIN a table using three different techniques: nested loop, hash, and merge. Generally, the fastest type of join in a nested loop, but if that is not feasible, then a hash JOIN or merge JOIN is used (as appropriate), both of which tend to be slower than the nested JOIN.

When very large tables are JOINed, a merge join, not a nested loop join, may be the best option. The only way to really know is to try both and see which one is the most efficient.

If a particular query is slow, and you suspect it may be because the JOIN type is not the optimum one for your data, you can override the query optimizer's choice by using a JOIN hint. Before you use a JOIN hint, you will want to take some time and learn about each of the JOIN types, and how they are designed to work. This is a complicated subject, beyond the scope of this tip.

JOIN order is also selected by the query optimizer, which it trying to select the most efficient order to JOIN tables. For example, for a nested loop join, the upper table should be the smaller of the two tables. For hash joins, the same is true, the upper table should be the smaller of the two tables. If you feel that the query optimizer is selecting the wrong order, you can override it using JOIN hints.

In many cases, the only way to know for sure if using a JOIN hint to change JOIN type or JOIN order will boost or hinder performance is to give them a try and see what happens.

If your SQL Server has multiple CPUs, and you have not changed the default setting in SQL Server to limit SQL Server's ability to use all of the CPUs in the server, then the query optimizer will consider using parallelism to execute some queries. Parallelism refers to the ability to execute a query on more than one CPU at the same time. In many cases, a query that runs on multiple processors is faster than a query that only runs on a single processor, but not always.

The Query Optimizer will not always use parallelism, even though it potentially can. This is because the Query Optimizer takes a variety of different things into consideration before it decides to use parallelism. For example, how many active concurrent connections are there, how busy is the CPU, is there enough available memory to run parallel queries, how many rows are being processed, and what is the type of query being run? Once the Query Optimizer collects all the facts, then it decides if parallelism is best for this particular run of the query. You may find that one time a query runs without parallelism, but a few minutes later, the exact same query runs again, but this time, parallelism is used.

In some cases, the overhead of using multiple processors is greater than the resource savings of using them. While the query processor does try to weigh the pros and cons of using a parallel query, it doesn't always guess correctly.

If you suspect that parallelism might be hurting the performance of a particular query, you can turn off parallelism for this particular query by using the OPTION (MAXDOP 1) hint.

The only way to know for sure is to test the query both ways, and see what happens.

When reviewing a graphical execution plan, you may notice that one or more of the icon text is displayed in red, not in black, as is normal. This means that the related table is missing some statistics that the Query Optimizer would like to have in order to come up with a better execution plan.

To create the missing statistics, right-click on the icon and then select the option, "Create Missing Statistics." This will display the "Create Missing Statistics" dialog box, where you can then easily add the missing statistics.

If you are given the option to update missing statistics, you should always take the opportunity to do so as it will most likely benefit the performance of the query that is being analyzed.

Sometimes, when viewing a graphical query execution plan, you see an icon labeled "Assert." All this means is that the query optimizer is verifying a referential integrity or check constraint to see if the query will violate it or not. If not, there is no problem. But if it does, then the Query Optimizer will be unable to create an execution plan for the query and an error will be generated.

Often, when viewing a graphical query execution plan, you see an icon labeled "Bookmark Lookup." Bookmark lookups are quite common to see. Essentially, they are telling you that the Query Processor had to look up the row columns it needs from the table or a clustered index, instead of being able to read it directly from a non-clustered index.

For example, if all of the columns in the SELECT, JOIN, and WHERE clauses of a query don't all exist in the non-clustered index used to locate the rows that meet the query's criteria, then the Query Optimizer has to do extra work and look at the table or clustered index to find all the columns it needs to satisfy the query.

Another cause of a bookmark lookup is using SELECT *, which should never be used.

Bookmark lookups are not ideal from a performance perspective because extra I/O is required to look up all the columns for the rows to be returned.

If you think that a bookmark lookup is hurting a query's performance, you have four potential options to avoid it. First, you can create a clustered index that will be used by the WHERE clause, you can take advantage of index intersection, you can create a covering non-clustered index, or you can (if you have SQL Server 2000 Enterprise Edition, create an indexed view. If none of these are possible, or if using one of these will use more resources than using the bookmark lookup, then the bookmark lookup is the optimal choice.

Sometimes, the Query Optimizer will need to create a temporary worktable in the tempdb database. If this is the case, it will be indicated in the graphical query execution plan with an icon labeled like this: Index Spool, Row Count Spool, or Table Spool.

Anytime that a worktable is used, performance is generally hurt because of the extra I/O generated when maintaining a worktable. Ideally, there should be no worktables. Unfortunately, they cannot always be avoided. And sometimes their use can actually boost performance because using a worktable is more efficient that the alternatives.

In any event, the use of a worktable in a graphical query execution plan should raise an alert with you. Take a careful look at such a query and see if there is anyway it can be rewritten to avoid the work table. There may not be. But if there is, you are one step closer to boosting the performance of the query.

In a graphical query execution plan, often you see the Stream Aggregate icon. All this means is that some sort of aggregation into a single input is being performed. This is most commonly seen when a DISTINCT clause is used, or any aggregation operator, such as AVG, COUNT, MAX, MIN, or SUM.

The Query Analyzer is not the only tool that can generate and display query execution plans for queries. The SQL Server Profiler can also display them, albeit in text format only. One of the advantages of using Profiler instead of Query Analyzer to display execution plans is that it can do so for a great many queries from your actual production work, instead of running one at a time using Query Analyzer.

To capture and display query execution plans using Profiler, you must create a trace using the following configuration:

Events to Capture

• Performance: Execution Plan
• Performance: Show Plan All
• Performance: Show Plan Statistics
• Performance: Show Plan Text

Data Columns to Display

• StartTime
• Duration
• TextData
• CPU
• Reads
• Writes

Filters

• Duration. You will want to specify a maximum duration, such as 5 seconds, so that you don't get flooded with too much data.

Of course, you can capture more information than is listed above in your trace, the above is only a guideline. But keep in mind that you don't want to capture too much data, as this could have a negative affect on your server's performance as the trace is being run.

If you use the OPTION FAST hint in a query, be aware that the Execution Plan results may not be what you expect. The Execution Plan that you get is based on the results of using the FAST hint, not the actual Execution Plan for the full query.

The FAST hint is used to tell the Query Optimizer to return the specified number of rows as fast as possible, even if they hurts the overall performance of the query. The purpose of this hint is to return a specified number of records quickly in order to produce an illusion of speed for the user. Once the specified number of rows is returned, the remaining rows are retuned as they would be normally.

So if you are using the FAST hint, the execution plan will be for only those rows that are returned FAST, not for all of the rows. If you want to see the execution plan for all the rows, then you must perform an Execution Plan of the query with the hint removed.

Please visit my other blogs too: http://edwardanil.blogspot.com for information and
http://netsell.blogspot.com for internet marketing. Thanks !!

Stored Procedures Vs Dynamic SQL : The Argument Continues

Argument For Stored Procedures and Against Dynamic SQL
http://weblogs.asp.net/rhoward/archive/2003/11/17/38095.aspx
http://weblogs.asp.net/rhoward/archive/2003/11/18/38298.aspx
http://weblogs.asp.net/rhoward/archive/2003/11/18/38446.aspx

Argument For Dynamic SQL and Against Stored Procedures
http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx

Argument For Dynamic SQL and For Stored Procedures !!
http://www.simple-talk.com/2005/04/11/to-sp-or-not-to-sp-in-sql-server/

When did Dynamic SQL get such a bad name?
http://radio.weblogs.com/0101986/stories/2003/11/12/whenDidDynamicSqlGetSuchABadName.html

DATA POINTS
http://msdn.microsoft.com/msdnmag/issues/03/11/datapoints/

Bogus resumes and unblushing lies: navigating the database hiring waters

by Phil Factor

I have mixed feelings about selecting a team for a development project. I’ve been so long in the industry and have played every part - from blushing young novice to hard-bitten contractor to harassed employer - that I should find the process a simple, straightforward affair. In selecting the right people to work with though, I’ve learned that the more I know the more I know what I don’t know.

One problem with selecting candidates to undertake an IT role is that so many of them write bogus resumes and lie unblushingly about their skills and experiences during the interview. In a well-ordered universe, all references would be contacted, qualifications checked, and previous employers phoned to check the story, but I have yet to inhabit this dream world. And even with these precautions, errors are made.

Making false statements regarding qualifications on a resume and thereby obtaining a job is a serious criminal offence. I’ve only heard of prosecutions against teachers or doctors, but if the police were to turn their attention to the IT industry, our prisons would be overflowing. Quite often, when employment agencies call about a job they want me to apply for, I’m asked to rewrite my resume so it fits the job requirements more closely. Occasionally, they want to do it for me.

The unworthy wunderkind

I once got a job as a SQL Server developer for a telecommunications company. The pay was good, and it was a restful job after the helter-skelter of the dot-com boom. A month after I started, the IT director rushed in excitedly, holding a resume, saying he had just interviewed, and hired, a most excellent fellow to be my team leader. Would I move my desk over to give him a cubicle commensurate with his qualifications? The name sounded vaguely familiar, but I shrugged and thought fondly of my hourly rate - the perfect panacea for stress in any contractor.

The wunderkind arrived a fortnight later. I recognized him immediately. I’d recently employed him as a C++ programmer, before his reincarnation as a database expert. He had, in fact, been a mediocre C++ programmer with a poor grasp of databases. Then he emerged, like a moth from its cocoon, as a SQL Server expert. For three months I stared at him like Macbeth’s ghost of Banquo as he messed up catastrophically. I had, of course, told the IT director, who assumed I was motivated by professional jealousy.

Programming in Croydon

In another position, I interviewed a programmer for some tricky database work that required interfacing with a variety of languages. Was he familiar with Pascal, I asked? Had he used Visual Basic? Having worked my way through the list of languages and been assured with great effusions of sincerity that he had programmed in all of them, I moved on to other questions.

Our office was located in an out-of-the-way borough of London, and, with my radar on alert from his overenthusiastic responses, I thought to ask the candidate if he minded programming in Croydon, which was, of course, the name of our town. To my surprise, he burst into a speech about his expertise with the Croydon language!

To make matters worse, when employment agencies get wind of an opening in the IT field, there’s often a feeding frenzy and the hiring manager is called repeatedly and bombarded with resumes. Over the past 20 years, I have known a good number of agents, some of whom are honest and check the resumes of their candidates. To these I send Christmas cards every year. Three extra cards is not a great expense, after all.

Some candidates go too far. One resume I reviewed stated that the applicant had two PhDs and had worked for IBM, Microsoft and a host of other large employers. I was intrigued enough to interview the man, at which time it was immediately apparent that his resume was a complete fabrication. He wasn’t old enough to have attained his alleged qualifications, let alone his work experience. His ignorance of the elementary principles of database theory was startling as well.

Questions from a wily nincompoop

After countless experiences like this, I determined that the way to weed out the poor candidates was to ask some searching technical questions. I have lost count of the times I have suffered these myself, and I know only too well that one’s brain can be reduced to jelly when having to remember a few facts that are so familiar that, outside of an interview setting, they are like remembering the names of one’s parents.

It’s monstrous to confront someone with an examination without warning, like some human resource departments did in the 1990s with their intelligence and personality tests. I always warn candidates, via their agents, that they may be asked a few relevant technical questions, but that these would not take too long.

When conducting an interview, I generally adopt the persona of a kindly, middle-aged nincompoop. I gaze at the candidate with the bonhomie one imagines Santa would adopt. Other employers adopt a sullen approach, but I try not to upset the candidate just in case he subsequently lies himself into a job from which he might one day interview me. It has happened. The following approach never seems to have caused resentment in a candidate.

The first part of the interview consists of a rather optimistic account of the company and the pleasure one would derive from working for it. After this softening-up exercise, I gaze at the candidate benignly and ask how he would rate his SQL Server skills. If I have done the first part of the interview correctly, he will tell me his skills are superb.

“Oh, good, so you wouldn’t mind answering a few simple questions about SQL Server?” I ask, with a kindly, paternalistic smile. “Nothing particularly technical, you understand, but I would like to see how you would approach a simple problem in any of the major SQL databases.”

“Of course I wouldn’t,” the candidate inevitably replies, in anticipation of being tickled with a feather duster.

The metaphorical baseball bat that I then use consists of a number of simple questions that anyone who had done serious work in SQL Server would easily tackle but which immediately seem to sort the wheat from the chaff.. In no particular order, below is a small selection of the questions I use, just to give the feel for what they are like.

You have two tables of identical structure, with some identical entries and some different entries. How would you list out the rows from one table that were not contained in the other? How might you list out all entries in either table that were not common to both tables?

Not hard, eh? There are several neat ways of doing this, all of which are valid. I’m pleased when the candidate gets the first part of the question right, and overjoyed if he gets both. More often I hear replies such as: “One would never have two identically structured tables in a database,” or “It can’t be done.”

Imagine you are in charge of a database that has a customer table with an identity field used as a primary key. You find out that this table has duplicate entries. How would you go about finding them? What strategy would you use for eliminating them? What might you need to watch out for?

A good candidate will rattle on about the various tactics that could be adopted and the pitfalls of any rash attempt at de-duplication. It must be difficult to have had experience at the sharp end of commercial database work without being faced with the task of mopping up. I get a little flush of pleasure if the prospective candidate mentions the possibility of using the “group by” clause.

You are asked to produce an accounting report that lists credits and debits in each row on a number of customer accounts, and requires a column that gives a running total for that particular account holder after the transaction. How would you tackle that?

It is always nice to hear the words “correlated subquery” in the answer, but that’s not often the case. Maybe simple financial accounting skills are not taught any more. But even if the programmer is not familiar with subqueries, it is fascinating to see how he wrestles with the problem.

In the interview, I spell out the problem in more detail, and often pull out the report so the candidate can see what I’m talking about. Many times I’m told with complete assurance that it simply isn’t possible to do what I’ve requested in SQL, and I’m given an elaborate account of creating a Java module to do it. How’s that for insight into the candidate’s work?

There’s nothing too technical in my questions. A smart database developer will do as much as he can without specific details of a particular database system or version, as this general knowledge has a long shelf life. It’s more important to know where to get the information to do the job in the shortest possible time.

Also important is an appreciation of set theory, an understanding of SQL, and insight into non-procedural programming. You would weep to know how few candidates who claim to be professional database programmers even understand the questions, let alone come up with answers. If they can tackle one question, they can generally tackle them all. And even if one question is, by a quirk of past experience, unfamiliar to them, they will come up with wonderful solutions that illustrate their essential understanding.

Works well with others?

Before one runs away with the idea that these questions represent the royal road to the ideal database developer, remember that knowledge is nothing if the candidate can’t work with the team.

At one multinational company I worked for, the resume and erudition of a new Sybase programmer dazzled the IT director. He seemed wonderful, and at least technically, he was.

Soon after he had been shown his desk in our crowded, open-plan IT office, he began laughing out loud sporadically and inappropriately while reviewing code. It wasn’t my code, so I didn’t mind. But then his strange mannerisms began, complete with bizarre, jerky arm movements. His digestion seemed to be shot to pieces, and foul air issued noisily from him. Work in the department slowed to a crawl as every neck craned to see what he would do next next.

I tried to fit the man into the team. He confided in me that fools and idiots surrounded him. He mercilessly criticized the work of his colleagues. He definitely lacked personal skills.

Finally, after he had cleared an impressive space around his cubicle, his indignation at the incompetence of his co-workers proved too much for his self-restraint.

“Look at this code,” he spluttered. “It is outrageous! I shall go and speak to the IT director!”

“Hmm. Not a good idea.”

“He must be made aware!” he said firmly and with great zeal. So off he went. The IT director made it clear to me that the man had to go. Shortly thereafter, we reclaimed our space and settled back to our former mundane harmony.

There is something to be said for top-notch technical skills on the development team, but only when combined with an affable personality and appropriate social skills.

###

Phil Factor (real name withheld to protect the guilty), aka Database Mole, has 20 years of experience with database-intensive applications. Despite having once been shouted at by a furious Bill Gates at an exhibition in the early 1980s, he has remained resolutely anonymous throughout his career.

Believe it or not, Try it youself

An Indian discovered that nobody can create a folder anywhere named as 'con'.
Not only “con” but you can not create folder named as “aux” and “nul”.

This is something pretty cool...and unbelievable... At Microsoft the whole Team, including Bill Gates (ok, that was too much, but what the heck :o) ), couldn't answer why this happened!

Try it out yourself...

Provided by Ganesan [i7Asia]

Stored Procedure Naming Conventions

By Joseph Sack

Discussions of naming conventions can, and usually do get ugly. There are so many ways you can do it. Some people don't give standards any thought, while other database developers are zealous to the point of renaming system generated constraints. How far should one go to implement standards across your databases? Do you apply standards to all database object types or just some (for example just views, tables, columns, stored procedures)? What about third party applications where you can't control or modify their object names and source code? The larger the team of database developers, the harder it is to build consensus. Even if you are able to pound out a standard, enforcing it can be difficult.

Why then, is it worth the effort? The best argument I've seen for establishing and using database object naming conventions is for ongoing supportability. Intuitively named database objects can be located more easily when troubleshooting a problem. Consistently named columns communicate their usage and "class" to the developer having to reference them. When it comes to the scope of your standard, I would recommend that any "home grown" code developed in your company should follow a standard. Third party products are outside of your scope, but that doesn't mean the rest of your code need be neglected.

Stored Procedure Naming Conventions

This article specifically discusses stored procedure naming standards. If your application uses stored procedures, defining a naming convention is absolutely critical for future supportability. If all of your Transact-SQL code is embedded in stored procedure, you'll need to know where to find exactly what you are looking for. This is particularly important for databases that contain procedures from multiple applications. You need a visual means of defining which procedures belong to what application, and have a general understanding of each procedures purpose.

First off, if I am absolutely positive that a single database will only be used for a single, less complex application, I’ll use the following naming conventions:

usp_ PredominantAction_TableNameOrBusinessProcess

The usp_ prefix is used to let me know that this is a user stored procedure. Some people don't like this prefix. I prefer it because I can easily identify stored procedure objects when querying system tables. I don’t want to be using sp_, as SQL Server interprets this as a system stored procedure.

The PredominantAction part describes what the stored procedure is intended to do. I’ve used an array of values over time, and I’m sure they will keep changing once I migrate to SQL Server 2005, but here is the list I’ve amassed so far:

SEL – Select – returns multiple rows

GET – Returns 1 row

UPD – Update

DEL – Delete

INS – Insert

EXT – Extract

IMP – Import

SAV – Combines insert/update

The TableNameOrBusinessProcess is used to tell me what the procedure references or does. If the procedure just works with a single table, I’ll use the table name. If it works with multiple tables to perform some kind of operation, I’ll use a brief process description.

Examples of this naming convention:

usp_SEL_SaleDetail
usp_UPD_Salesperson
usp_GET_ProcessIndicator
usp_IMP_MainframeFiles


If a database is shared across multiple applications or meaningful segments, I usually add a third element to the stored procedure name:

usp_NNN_ PredominantAction_TableName or Business Process

NNN indicates the project, application, or logical segment abbreviation. For example if you have a project called “Master Shipping Application”, you can use MSA as the code, for example:

usp_MSA_INS_ShipOrders

Or if you would like to segment procedures by areas in your application, you could designate the Sales site as SLS and Employee sit as EMP, for example:

usp_SLS_UPD_Budget
usp_EMP_SEL_AnnualReview

This standard allows for much improvisation based on your company standards and application requirements. No matter what standard you come up with, do at least choose to standardize stored procedures. I'm not talking about perfectionism here, just a general respect for how much time naming conventions will save you and your company down the road.

Increase in Bagle Virus Variants

For free Download of virus remover, click here: Free Cleaner
Select the virus type and click download to get the free cleaner. You could download all the files in the dropdown list (around 60 virus cleaner) But please remember to download the Bagle Virus Removers (around 6 cleaner files)

More Details:
ESET'S NOD32 Detects Huge Increase in Bagle Virus Variants; Traditional Antivirus Signature Updates Can Not Keep up with Rapidly Spreading Trojan

SAN DIEGO--(BUSINESS WIRE)--Sept. 23, 2005--ESET, a global security software company providing next-generation malware protection, today warned customers of a massive increase in new Bagle virus variants. The first variants were detected on Monday and have increased dramatically throughout the past week. ESET's Threat Labs determined that the variants are being modified to avoid detection by specific antivirus programs, once again underlining the need for proactive protection. ESET's NOD32, a unique anti-threat solution, uses advanced ThreatSense(TM) technology, which employs behavior-based analysis to detect malicious threats in real-time.
The recent increase of Bagle variants are being spammed out in large quantities through a distributed network of compromised machines, called botnets. Some of the variants are older versions of the Bagle virus, repacked to avoid detection. The new Bagles are Trojan downloaders, which retrieve and install malicious files from a pre-programmed Web site location and create a backdoor on a machine. This distribution mechanism causes variants to spread outside of the spam channels and leaves unprotected users or systems with outdated virus signatures vulnerable to attack.
ESET's Threat Labs have detected that new variants are being released, on average, every two hours. Different waves of the variants are issued with unique changes designed to avoid signature-based detections, leaving many antivirus companies scrambling to respond to the constant barrage of emerging threats. Some of the worms were designed to get around even advanced heuristics systems. Although one or two variants were not detected immediately, ESET updated both the signatures and their ThreatSense heuristics, ensuring that all further variants were caught proactively.
"ESET's Virus Radar system was detecting over 10,000 messages per hour carrying new, heuristically-detected Bagle variants on Tuesday and Wednesday," said Andrew Lee, chief technology officer of ESET. "At this rapid reproduction and distribution rate, there is no way that traditional, signature-based antivirus software can protect users from the Bagle variants. ESET customers are protected from the variants in real-time, demonstrating the power of our ThreatSense technology."
ESET is providing a free remover for the most prevalent variants of the Bagle worms, which can be downloaded at www.eset.com.
ESET's Virus Radar (www.virusradar.com), a real-time malware tracking tool, identified the new Bagle variants using NOD32. Virus Radar provides site visitors with easy access to in-depth analysis of the latest malicious outbreaks and processes approximately four million email messages per day to provide information such as the exact date a virus was first detected and its current detection rate. Virus Radar is also capable of tracking the progression of a single virus over a given period -- in some instances from the earliest heuristic detection of a new virus to the point where the virus disappears.

You could read the original article, by clicking here.

Freelancer Sites

Here are the list of freelancer sites. I have provided with a rating for each site (and that's my personal rating on those sites depending upon the number of projects posted, user friendly and features)

Site Name	Rating
Get A Freelancer	*****
Scriptlance	*****
Codelance	****
Get A Coder	****
Outsourcing Plans	****
Cheaplance	***
Freelance Auction	***
Freelancer Space	***
Newyork Freelancers	***
Out Source Today	***
Freelancers Direct	**
I Need A Freelancer	**
Job Quote	**
Pay4projects	**
Powerlance	**
All Freelance Work	*
Freelance Center	*
Freelance Dog	*
Freelance Job Search	*
Freelance Seek	*
Freelance Web Programming	*

Please visit my other blogs too: http://edwardanil.blogspot.com for information and http://netsell.blogspot.com for internet marketing. Thanks !!

String Manipulations with SQL Server 2000

String manipulations are an inherent part of any programming language. Fortunately, Microsoft SQL Server 2000 provides a number of functions that help you along the way. In this article, Baya Pavliashvili introduces you to the many string functions available in SQL Server, and gives you an example of how you can apply these functions in your code.

Its really a good article with examples of how to use the String functions in SQL Server 2000.
Click here to check out this article :
String Manipulations with SQL Server 2000
By Baya Pavliashvili.

Javascript form validation - doing it right

When using Javascript for form validation, there is a right way, a wrong way, a very wrong way, and a suicidally wrong way! Unfortunately many sites use one of the wrong ways, including even some which claim to be form-validation tutorials. This page tries to help people in the right direction. Javascript form validation - doing it right

This code page was writen by Stephen Poley.

If you do not find this page, please send me a comment. I would be glad to send it you or set it up in my server. Until then I have to give credit to the original author.

Beware! New virus on the loose

Network anti-virus and Internet content security major, Trend Micro on Tuesday warned Internet users of a new memory-resident worm that takes advantage of newly announced Microsoft Plug-and-Play security flaw.

What makes the new worm, WORM_ZOTOB, so notable is its exploit of Microsoft security hole and this 'exploitation' is believed to be the fastest in the history of malware creation, a statement said.

The new worm drops a copy of itself into the Windows system folder as Botzor.exe and it modifies system's Host files in the infected users' computer so as to prevent the user from getting online assistance from certain anti-virus Web sites.

The backdoor capabilities of the worm enable it to connect to a specific Internet Relay Chat (IRC) servicer and allow hacker a remote control over affected system, which can be used to infect other machines in the network.

Hundreds of 'infection reports' were sighted in US and Germany. Since most of the users may not be aware of the newly announced security hole so as to install the necessary patch during last weekend, more infections in Asia Pacific and other regions are foreseen, it said.

Job Hunting - Proper Preparation

When you are in the company of someone who is more knowledgeable than you, do yourself the favour of shutting up and listening. You will gain respect. And you will gain information and knowledge faster.

Take note of compliments, commendations and recognition for your work. Any sales person worth their salt knows that credibility is an intangible yet crucially valuable asset. And be assured, in any job search, you are selling yourself to the job market place. Again, any such detail you present will not surface in a job reference. But in interview, it all helps to reenforce the general positive impression you want to create, as we discussed earlier.

Your personality and working style can more determine your suitability to a job than your qualifications and experience. If your personal approach doesn't fit the regime, you will be excommunicated from promotional lines. Compromising your natural style and even your integrity and values can be a difficult and unsustainable strategy. You should seek out conditions more in-tune with your own style. This brings a satisfaction that can naturally fuel your progress without extra machinations on your part.

Wake up and smell the roses before they have wilted. Keep your options open, keep your eyes on the jobs pages, and always believe you can do better than your current situation. Trust your sentiments when things don't add up. There are always a number of rational viewpoints that can delay or distort your overall judgement, but your sentiments are true. Go with them.

The first in the above list is becoming ever more evident. Flat organisational structures predominate and demarcation lines are diffuse. Whether they like you and your style can make the difference between success and stagnation.

Conversely, if you get a bad feeling about someone at interview, you can either take heed and flee or you can risk setting yourself up for a rough time if you accept the post. You can waste a lot of time and effort and end up going through the same routine again a year later. It's hard not to feel flattered and grateful when you are offered a post, but a little confidence, objectivity and
bravery could see you holding out for a better one. A tough call. Either option is a risk. You either risk spending time in a bad firm and damaging your CV or you risk losing out on an offer. It depends on your personal situation, your own needs at the time and your instincts.

Never trust your superiors. The higher up they are, the more political they are and that means ulterior motives. Have your own agenda and be aware of their hidden agendas. Prepare for a worst-case scenario. Then the only surprise you'll get is likely to be a pleasant one.

To a company, you are an expendable asset, to be used until your value runs out. They are businesses, not charities, so don't expect any. That's why you need to develop your own agenda and plan your own career. Don't rely on the company to understand, appreciate or value what you believe counts for your career. They only value what counts for them personally.

Keep notes of your work and your progress. It is proof of your value and of the value you have added to the firm. This implies to prospective employers you are capable of doing the same for them. This removes some of the risk associated with taking you on.

1. Choose the correct Location. If you want to work in an IT field, check out the area, which has more IT companies or has a major potential to be an IT hub.
2. Don't explain your life story to prospective employers and expect them to be interested in it. Pick out the relevant points and explain each from the point of view of your target.
3. Keep your studies in line with your career. You should pick an area to work in, find a company willing to offer themselves up for your studies and use this experience to apply around that same business sector. Do not simply used the course as a means to an end.

• Accumulate as much information from each job as possible. It's all part of your experience and professional value. Get hold of quality documents, work procedures, performance reports, quality controls, work plans, in fact anything that goes into what's called "the managementsystem". This is the paperwork and documentation that keeps the business turning.
• Make as many contacts as possible. You don't have to be best mates, but you do need to be genuine with them. Be honest and professional and they are more likely to remember you and be open with you next time you come calling.
• Get recommendations. Even copies your annual assessments may come in useful. Things can get rather political when a company has to lose you, which can play havoc with references.

Appear impressive and you will be perceived as impressive. Perception is reality. However others perceive you, that is actually who you are, regardless of the reality you feel inside. Dress rich, they'll think you're rich. Act authoritative, they think you're in total command. And so on.

Find out what it is your target values – and give it to them. If the job requires a great deal of people work, emphasise that on your CV. Get your interview answers geared around those topics. If there's problem solving and analytical techniques needed, put that at the top. If there's detailed work involved, get hold of facts and figures to show how precise you are. And, just as importantly, keep everything else off, or at least put it after the important stuff. Every day, you are preparing for your next role. That's why you need a plan. Then you work with purpose and that purpose becomes crystal clear as you discuss your next posting. Collect those figures, keep that log, write down those compliments, collect those letters of praise, copy those charts and graphs. You did it, you keep it. It's your proof of capability, your proof of progress, your proof of direction.

Job Hunting - Target Identification

1a. Accumulate Company Information
There are basic expectations at interviews and having some company information is one of
them. You are unlikely to get an annual report from the company themselves – which are pretty useless anyway, unless you really know how to decipher them – but there are other sources:

Business directory. Don protective footwear before dragging these off the library shelves. These directories doesn't list every company, but does have the basics of many thousands. You may uncover nothing of value, or you may get some useful leads, such as HQ address, other site addresses and telephone numbers. If your target has various locations, each doing something different, find out which site is being recruited for. Start with whatever lead you have and get the phone number of the Personnel department you will be dealing with and give them a call.
Use something along the lines of the following script:
"My name is ____ from (town/company/college/university). I'll be talking with some of
your people soon about vacancies at your site. I'd like to make the short time we'll be
having together as productive as possible, so I was hoping you could mail me out a little
company info – the kind of thing you might find on the front desk – company brochure
and product info, perhaps. It would be a great help."

If they object, then reply,
"I appreciate you must get a few calls like this, but there really is nothing to go on in the
public domain. This interview is extremely important. I really want it to go well and I'd
like to do your people the justice of making it worth their time talking to me."

All you're looking for is company basics – products, plans, opportunities, company prosperity,
etc. Something to show you have done your homework and can hold a conversation about the firm you are applying to. There's no worse way to start an interview than answering the opening question of "What do you know about us?" with "Nothing!".

You should get the names of your interviewers and their respective positions or titles on your
invitation letter. If not, ask for these also while you're on the phone.

Company Annual Reports
Unless you're already familiar with these and understand them (and how they can mask the
truth), then quite simply, don't bother. It'll take far too long here even to explain the basics. And
you'll get precious little of practical value from them anyway. All you need is to understand
whether or not you are entering or staying in a growing, stagnant or declining business sector.
Then you can ask how they are dealing with present circumstances.

1b. Accumulate Business Sector Information
This is far easier. What you're looking for here are trends, competitor names, current business
issues, sector outlook and so on.

Mintel. Short for "Market Intelligence". You'll find them in main public libraries only (because of the cost), in report form and on CD-ROM. If you belong to a wealthy educational establishment, you may also find them on campus. Their reports cover every imaginable business sector (almost!) and contain every macro fact and figure you may need.

Key Point. Same thing. Between these two, you'll be most unlucky to come up short.

Newspapers. Don't go raking through acres of broadsheet. Your main public library or campus
library will have many of the national papers on CD-ROM. If you were an ancient Greek, there
would be a God of IT and his name would be KeyWord Search. You should be able to copy and
paste the interesting bits onto a floppy disk file, take it with you and print it out.

For a first interview, it isn't often you need anything more than basic company and product info.
Just enough to gain familiarity, to feel confident that you can hold a conversation and to ask some fundamental questions. Mostly they will be interested in you.


2. Personal Plans
Ah, there's the rub. This is often the most important part of a first interview. Your qualifications
will be taken as read, so don't expect to create too much of an impression with your subject
knowledge. You will most likely be asked about your current work or studies, why you chose that field and what you like about it. This is often used to ease you into the session, to get you talking and for your interviewers to get familiar with you. However, don't be mis-lead into thinking that this is only idle chit-chat. They are very real questions. They are probing for sound rationale about your chosen career path and your enthusiasm for it.

If you're in the lower corporate echelons, don't feel obliged to ply them with talk of super
success or of wanting to run the company by the time you're 40. You simply have to show you're a thinker, that you know what you're doing and where you are going, that you are aware of your contribution, that it is your choice and that you can reason with them about it. Come across as a drifter with no real idea of direction and you'll drift from interview to interview for ever and a day.

Your are recruited for a purpose. If you can't explain to an employer what believe your own purpose to be, they will see no reason to employ you.

Say, for example, you want to be a secretary but you don't want to be a department head PA.
If you're happy doing what you do, say so. If your family takes up too much of your time, the extra hours might be impossible to accommodate. Of course, it always looks better if you give your reasons from the company point of view. "I wouldn't be able to guarantee my full support to my boss," for example, sounds better than "I wouldn't want the extra work load." Maybe you want to stay on shifts for family reasons and not take a managerial day job. That's fine as long as you emphasise how your experience can be the bedrock of the department, how you can
comprehensively train and coach others and be a link-pin for future management initiatives.

If you're looking for your first job, you will need to have a reasonable idea of where your first
post might take you and why you think your chosen career is the one for you.

Talk about it. Discuss your plans with your friends, peers and colleagues; pass ideas around;
exchange views and opinions. You can get more fresh insights and ideas from a ten minute
sounding off than you can get by musing over it all day. In a professional sense you can call this
networking. We'll talk more about this later. Some of the large search engine sites and careers
sites also have "Expert Centres", where you can ask career questions. And there are always
careers centres to visit.

Seek out the experience and wisdom of others when considering any career move. The more research you do, the more focused you will be and the less the risk you will take.


Always display yourself in the strongest possible light. Don't lie, but by all means display the Truth as if it were Crufts – all nicely preened and viewed from the best angle

.

A little bit of artistic licence can go a long way. You should work on creating your best window
display. If you don't, you're not going to get very far. After all, employers do it all the time.
Interviews are a two-way process. Your interviewers are also trying to sell the company and the job to you.
So the point is, if it's hard for new employees to see through the façade presented by interviewers, then it's just a tricky for your interviewers to see through your positive front – provided it is solidly put together.
So avoid negativity, hints of failure and of giving any clues that you are at all fazed by any past
hiccups.

Avoid negative talk at all costs. When practicing your interview answers, be aware of complaining, moaning, criticising, put-downs, derisory comments, bad-luck stories and so on. Always frame your comments in a positive light.

So always look at the events in your career positively, no matter what the truth and no matter
how bad you feel about them personally. And present that version. Be especially prepared when
talking to recruitment agents. You can not re-frame later what you first tell them. Their work codes require them to tell the truth as far as they are aware of it. So what you first tell them goes down as gospel and can not be changed.

OK. To recap.

• You have all your info together
• You've identified your career area
  
• Your possible targets.
  
• The next task is to start building your application. And I don’t mean write a CV. That comes later. If you're not ready for a job move yet, building your application still needs to start now – today. I'll explain what I mean in the next section.
  

Effective Job Hunting

You must have noticed how the number of companies devoted to job listings, both
on- and off-line, are multiplying like a plague. But very few of them realise that the
job hunt starts way before you ever open a newspaper or log on to your favourite search
site. It begins in your current job. And that means today!

It begins with maximising your potential in your current job and then providing you
with the guidance and advice you need to move onwards and upwards.
You see, just as you only build a house brick by brick, so each working day you are
progressing your career in some way, adding to your experience, moving towards your
annual goals, monthly quota or shift targets. It all adds up to whether you can do your job,
are good at it, or are great at it. You either build a town house or a mansion. It just
depends on the number of bricks you lay. It also helps to put your best looking ones in full
view – a quick self-marketing analogy for you, which will become apparent in the section
of CVs.
Preparation for your next job starts TODAY – in your present one.
But before I jump the gun, let me back track to re-emphasise that it is your current job you
need to focus on as preparation for your next job. Because without proof of success in
what you do now, the harder will be your task of finding a newer, better one later.
Conversely, if you excel at it, the stronger and quicker you will swing up the corporate
ladder.

The employment market is growing ever more fluid and competition is growing progressively
fiercer. To win through – and to win quickly – you will need all the help you can get.
Playing the game is far more fun when you know you can win.

As the number of 'visible' job seekers drops, wage offers tend to rise, there being fewer to pick out of the dole queues. Simple supply and demand. This encourages those already in jobs to jump ship. So unless you're a fresh-faced graduate, who typically have their own specially reserved territory to fight over, you will usually have to compete against more people looking to switch jobs than those looking to get re-employed. There are advantages and disadvantages in this, depending upon which group you currently belong to – employed or unemployed.
If you're employed, you can more afford to bide your time, waiting for the right job to crop up.
You can apply in full confidence that if you don't get it, it's probably no great shakes. You are still getting paid and can wait for the next offer. That takes off a huge amount of pressure and boosts your confidence enormously. This confidence can't help but show through in an interview and that is a big plus in any interviewer's note book.

When you're unemployed, though, the urgency is more real. Every interview counts. To get
turned down after all your efforts and all your raised hopes can be tremendously depressing. You have to be tougher, more focused, more determined and more resilient. Ironically, the gravity of the situation focuses the mind wonderfully. And that can bring quick success.
When you're unemployed, you have the advantage of being a full-time, "professional" job hunter.

Moreover, you get all the time you need to research your target company, practice your
interview technique, rehearse your answers and review your performance between interviews.
You make job-hunting your full time job. And that makes you more of a professional at it than the others. So do not despair. You do, in fact, have the upper hand in many respects.

Everybody's situation is different and every application unique in some respect. The key is
to take the principals on board and apply them to your situation and to your job applications.
Key words throughout this will be "informed and prepared" – the two most powerful weapons
you can carry with you. These should be the two main reasons why you are reading this – to get
pre-informed about job hunting and to thoroughly prepare yourself for the task ahead. Keep these two words in mind throughout and you'll find the final experience a whole lot more palatable.

Happy hunting.