Friday, October 22, 2004

Webpages that sell

• Simplicity: strong callouts, key selling features, price, all where it is easily found and quickly read.

• Zoom and alternative views: "Customers want a complete picture,showing the tops and bottoms of shoes, for instance, or displaying a suitcase both closed and open so the shopper can see interior dimensions.It helps to reassure a customer-it simply works!

• Informative content: Talk to super sales personnel in stores to find out how they describe products to customers.

• Multi-channel synchronization: That creates trust when customers see the same offers, products and quality across channels, he said.

• Product comparison: That resulted in higher conversion rates and a sale with a higher gross margin, ultimately created a 56% increase in sales of compared products which in turn created a 3% increase in overall sales.

• Placing newspaper inserts online: Moving the insert to the home page resulted in a 250% increase in online sales of advertised products.

• Store pick-up: Communicating delivery options on product pages increased completion rates by 32%, store pick-ups by 44% and sales by 65%.

• Larger view: It's the No. 1 most visited page on the web site.People need to know and feel assured they are buying from among the best and most popular vendors.

• Useful tips: Adding suitable tips increased products added to the shopping cart by 5-10% and conversion rates on related items went up fourfold.

• Live chat: Making the live chat option available on every page increased live chat contacts by 70%, which resulted in more closed sales. An audience member asked why increased contacts to the call center was a benefit. Because they resulted in sales.

NetDisco-Not what you think

Netdisco is an Open Source web-based network management tool.

Designed for moderate to large networks, configuration information and connection data for network devices are retrieved by SNMP. With Netdisco you can locate the switch port of an end-user system by IP or MAC address. Data is stored using a SQL database for scalability and speed.Cisco Discovery Protocol (CDP) optionally provides automatic discovery of the network topology. The network is inventoried by both device model and operating system (like IOS). Netdisco uses router ARP tables and L2 switch MAC forwarding tables to locate nodes on physical ports and track them by their IP addresses. For each node, a time stamped history of the ports it has visited and the IP addresses it has used is maintained. Netdisco gets all its data, including CDP topology information, with SNMP polls and DNS queries. It does not use CLI access and has no need for privilege passwords. Security features include a wire-side Wireless Access Point (AP) locator.

http://www.netdisco.org

was it what you thought?

Wednesday, October 20, 2004

How not to go about programming

Ignore messages

Compilers, operating systems, etc. generate error messages designed only to be read by their creators (maybe to justify their salaries). Precious time is wasted reading these messages; time that could be better spent … writing code, of course! Error messages make us less productive. Don’t fall into the trap. Ignore them.
As for warning messages, ignoring them makes you feel like a professional programmer who’s not scared of computers. What better way of showing one’s experience as a programmer than delivering a program that generates dozens, no, hundreds of warning messages when it compiles without its author feeling the slightest bit concerned? Everyone can see that you’re an experienced, laid-back programmer who is too busy to waste time on drivel.

Don’t stop to think

Let’s not kid ourselves here. What are we building? A program. What is the only thing that really matters in a program? Code. What really works? Code. Why use outdated resources like pencils, pens or paper? You are a paid-up member of the SMS generation; you don’t make a fool of yourself writing time-consuming syllables, right? Then, stop messing around thinking about nothing when there’s so much code to write.
You should never stop coding. We all know that error messages are an unacceptable interruption, a pointless obstacle as we go about our work. So what do you do if you get a compiler error message? As you should know by now, reading and understanding it is just not an option.
You can try making some random change to the source code. You never know, you might pull the wool over the compiler’s eyes. But if this doesn’t work, don’t waste any more time. NO, don’t be tempted by trying to read the message or understanding it. Just keep churning out code - that’s the only way of finishing off this horrendous assignment. You’ll get to sort the error out later on. And as we all know, errors tend to disappear by themselves if they’re ignored. At the end of the day you’ll compile, you’ll run, and even if you had tested (not that you needed to) you’d have seen that everything was OK.
If the code compiles but does something wrong, it doesn’t really matter; sort it out later, when it’s finished. Anyway, you might get lucky and find out that the lecturers have changed the assignment outline and that it fits in with your program after all. So don’t take the risk of fixing programs that seem to be off track – you might be wasting your time.

I don't want any trouble

If your program contains a bug that crops up every now and again, it will be difficult to find and it won’t probably show up during the exam demo. Maybe it will disappear by itself. Don’t worry. But if the bug comes up again and again, change things at random until it disappears. We’ve already said that pausing for thought is not an option. If you decide to get rid of the bug - simply because the urge takes you - just write the same code in different ways. Maybe the problem will disappear; something you’ll have achieved without 1) understanding what caused it, and 2) having to stop writing code. Clearly, this is the most professional approach.
Don’t compile on a regular basis, don’t tiptoe your way forward. You’re a professional and professionals take giant steps. Write thousands of lines of code first and leave the compiling for later; it will be far more entertaining and worthwhile to look for compiling errors.
The same rule applies for runtime errors. If you try to keep your program correct as it grows, it will be too easy to pinpoint a new bug. Only cowards do that. A real programmer writes the entire program and then digests it whole like a boa constrictor. Looking for a bug hidden in the last 10,000 lines is exciting but if there are only 10 or 20 lines, well, what fun is there in that?
And… why use debuggers? It’s up to the lecturer to look for your bugs. Programming errors are the exception, not the norm, and when you become a pro you won’t have to face them. Why waste time then or expend your energy learning to deal with them as part of your education?

If only I could find the words

Reading

Outlines and specifications are a real drag. These tedious and long-winded tracts refer to irrelevant problems and are nothing more than an opportunity for lecturers to display their narcissistic traits. You only need to take a quick look at them and get the gist of what they are after. Reading them for a second time only gets in the way of our real mission, which is nothing other than… writing code. So once you’ve got a rough idea of what’s expected from you just stick the assignment outline at the bottom of the biggest heap of paper on your table.
On the other hand, coding and presentation rules show how arrogant our lecturers are. They like controlling us, forcing us to do pointless exercises - that‘s why they write rules in the first place. Don‘t play their game. Reading or applying rules won’t make our work any better or worse. And as for making our exercises easier to handle, well, they get paid to correct them, don’t they? Don‘t even bother to put your name or your class on them. Lecturers will have little trouble remembering your face and your unmistakable programming style so they’ll know it’s yours anyway.

Writing

Don’t write comments. We’ve said it before and we’ll say it again: what’s the point of all this? To create a program, i.e. code. Non-executable stuff is unnecessary and explanations are an insult to a programmer’s intelligence - after all, he or she can read the source, right?
If there are mandatory comments to write (function descriptions and stuff like that) then write them, even if you have nothing interesting to say. Lecturers like this drivel and you’ll get higher marks.
As for the docs, write them at the end. How can you write a document describing a program that doesn’t exist yet? What’s the point in writing documents for yourself about what you’ve just done? The only reason for writing documentation for a program is that the lecturers ask for it. It’s something you can sort out the day before the deadline. What’s more, there’s no chance of you forgetting anything as it will all be fresh in your mind.
Also, use abbvns ‘n strange konsonants when u write. Lecturers are old fogeys. You are a member of the SMS generation. Try to write messages that are difficult to read. Although he might not notice it, the lecturer will have to make an extra effort, after a long day stuck in front of a computer screen. All of which should help raise the old concentration levels and put him or her in a really good mood.
What about spelling? Spelling is a drag. Even Juan Ramón Jiménez put his letter j’s wherever he wanted and Gabriel García Márquez once called for spelling to done away with for good. Obviously, you’re just as good as them and so you’ve just as much right to write however you want.
Let’s face it, who doesn’t make spelling mistakes? It’s all too easy. And there’s a brutal poetry in abrupt contractions and semantic hijackings that fling treacherous letters at the reader. Ever wanted to give your lecturer a slap in the face but never had the guts to do it? Drop him a line such as:
I’m trying to do you’re exercise. I think its two difficult.
It’ll have the same effect, don’t worry.

NOTE: Juan Ramón Jiménez: Spanish poet who won the Nobel Prize for Literature in 1956. He liked to flaunt spelling rules by writing almost phonetically (in Spanish the change involves only a handful of letters, g/j among them).

Your relationship with your lecturer

Don't ask for help

If there’s something you can’t do, if you have a query or if you’re lost, don’t look for help, don’t ask questions during the lecture and don’t go to your tutorials. There are thousands of reasons why you shouldn’t but here’s just a few of them:
Going to a tutorial and asking questions is tantamount to admitting you’re stupid.
Better to be ignorant than to run the risk of revealing that you don’t know something you should.
Ask a question during the lecture and your fellow students will think you’re stupid. You don’t think that of them when they ask a question, but they will about you. This argument holds true for each and every student in a lecture room at any given moment; that’s why none of them ask any questions.
Conclusion: never ask for help or go to a tutorial. There is, however, an exception to this rule; you are allowed to turn to the lecturer in the last few days before a deadline. There may well be a long queue, he will dedicate his time to helping students while neglecting other duties but don’t worry, he won’t be able to resist helping you in those dark, gloomy hours of need.

Challenge your lecturer

If, despite everything we've said, you decide to ask for help, always remember a golden rule that’ll also help you in your professional career - after all a whole host of pros and computer users follow it too. NEVER give a detailed description of a problem.
Here’s an example. If something untoward happens while you’re building a program, go and see the lecturer and tell him: “Something strange happened with my program yesterday.” He’ll look at you expecting more details but don’t give in, don’t say anything else. Don’t even think of going into details such as:
Whether the strange event happened while compiling the program or while running it.
Whether the strange event caused the program to end suddenly or to keep running indefinitely, or simply, the program didn’t do what you expected.
Here’s another one. If the strange event happened while you were compiling, don’t tell the lecturer what the error message said or the line of code where it appeared. Just say something like: “It gave some error message, or something.”
Here’s yet another example. If the strange event happened during runtime and caused the program to terminate suddenly, never write down the error message or tell the lecturer what it said. Just say: “It gave some error message, or something.”
Of course, if the strange event involved the program not doing what you expected it to do, don’t even think of telling the lecturer the exact circumstances of how it happened. Avoid descriptions like: “This error comes up whenever I load a second file and the first one was empty.” Just say the magic words: “It gave some error message, or something.” Have you got that?
Let’s suppose that you’re a stubborn ingrate who goes see the lecturer to ask about a specific problem. That’s two mistakes rolled into one but you can at least get something right - take the wrong source code with you. If you have a bug and the things you try out only make the situation worse, take the most recent code to your tutorial but ask about the original problem. That way the lecturer will embark on a fruitless search for an error when, in actual fact, another one will show up. When it does, just say something like: “Oh yeah, I tried something out. Delete that line there ...” Perfect this art and you’ll be able to do a whole coding session in the tutorial. I know - I’ve seen it done.
If you insist on being irresponsible and asking for help in tutorials, don’t even think of pinpointing the problem before you go. If there is an error in a 1-MB input file, don’t try smaller files until you identify the cause of the error. Don’t try to create a mini-program with that selfsame error. If you do, the lecturer will probably find the problem straightaway. What kind of challenge is that for him? Better to make him read thousands of lines of code and make traces with hundreds of steps. That’ll give him a chance to practice his clairvoyance skills and you’ll be able to check out his powers of deduction.

Be clever using electronic mail

Some questions are almost impossible to answer by e-mail, if you put them in the right way. Nurture this skill and make your questions completely vague. Here’s an example: “It gave some error message, or something. I’ve attached the source code”. You can go the other way as well, if you want, by asking a more specific question but forgetting to send the code. “The constructor in my TDevice class gave some error message, or something.”
It goes without saying that you should write your message straightaway and send it. Never reread messages.
There’s another reason why email is so much fun. You can sound off without the guy knowing which group you’re from or your name. Everything will be OK if you take the informal approach – it makes it all so much cosier, making your name an irrelevant detail.
And, of course...

Leave it all for the last minute

Right from day one your lecturers will tell you to hand your work in the following week. They’ll tell you to work at a steady, constant pace from the off.

Don’t listen to them.

Although it might be a relatively new discipline, computer programming has already built up a number of sacred traditions, one of which is the last-minute rush to get your work in on time. Subjecting yourself to this stress is an essential part of preparing yourself for the world of work. Relax. Let your work pile up gradually and blithely ignore all the warnings and telltale signs that you’re behind schedule. Don’t let studying get in the way of your life. Don’t duck out of that skiing trip in a vain attempt to make up for lost time. And just when you’re on the edge of the precipice, just when you’ve only got two weeks to hand in a program that you’ve had four months to do, then the code’ll start to flow like there’s no tomorrow.

What attraction would computer programming have if we didn’t put together programs in a breathless, last-minute dash? What would become of the image of the long-haired, bearded, smelly (there’s no time to shave, trim your beard or have a shower, you see), Megadeth-T-shirt-wearing programmer (remember that stains show up less on dark Heavy Metal T-shirts with their elaborate designs) tapping away at a keyboard for 48 hours non-stop? Would you have the stamina to go to the local LAN Party, park your bum down on a plastic chair and spend three days cooped up in a marquee in 35-degree heat gunning down monsters on a screen? What right would we have to call ourselves heroes if we had a kip every day just because we felt a bit tired? Just think about it. What would happen to Coca Cola and all its factories? What would happen to Juan Valdés ? And what would happen to all the coffee factories that dedicate half of their production to computer programmers? When Sandra Bullock and Robert Redford became hackers, did they put their notes down by the side of the computer, sit and think for a while and then methodically tap away on the keyboard for an hour or two before heading off to the gym or the bar on the corner, day after day for four months? And what about that bloke in Operation Swordfish? Would he have cracked the Pentagon password if one of Travolta’s hitmen hadn’t been pointing a pistol at his head while another Travolta hitwoman was trying to distract him?

The answer, my friend, is no. You want an easy life? Go and take another course.
Being up to date with your work and understanding what’s going on in the lecture room is for swots and wimps. You know what to do - leave it all for the last minute.

NOTE: Juan Valdés is the name of the coffee grower in Café de Colombia’s TV adverts.

Cheat with your assignment

Copy the programs. Lecturers will probably have to mark dozens of them, making it difficult to spot similarities between them. And even if they do, it sure as hell ain’t easy to prove. Appeal against your mark and take it to the High Court if necessary. That will take much more money and effort than writing the programs, but the goal is to prove that you're smarter than the lecturer and never, ever give way.

Always RTFM and STFW before asking me for pointers-I am too busy to give them to you anyway-I am trying to avoid leearning programming as long as possible.Do not ask me what the 2 acronyms mean as I am not telling anyone.


Monday, October 11, 2004

How to create the next new thing

The source of anything new is questions –

  1. questions that spark interesting conversations,
  2. questions that create controversy.

Ask yourself:

What questions should we ask?

And more important, ask yourself:

What questions are we not supposed to ask?(Why not-Ask those questions)

Ask yourself:

Who aren’t we conversing with?

And then ask them:What are your questions?

Ask questions that don’t come easily –questions that are tough, awkward, even taboo.

Ask unnatural questions-questions you know the other person will not be able to answer fully and fill in the gaps by asking more people the same questions and complete the answer(s).

Nothing ventured nothing gained!

Who says "C" is simple?

I knew there was always a catch-many of my friends say computing is simple!Well I found out it is not so simple after all-it does take a lot of effort to learn programming and management of software to give out quality results to companies and people and not for profit bodies alike and all this calls for mastery of programming and knowing how to use programs and the internet.


Who Says C is Simple?

"When I (George) started to write CIL I thought it was going to take two weeks. Exactly a year has passed since then and I am still fixing bugs in it. This gross underestimate was due to the fact that I thought parsing and making sense of C is simple. You probably think the same. What I did not expect was how many dark corners this language has, especially if you want to parse real-world programs such as those written for GCC or if you are more ambitious and you want to parse the Linux or Windows NT sources (both of these were written without any respect for the standard and with the expectation that compilers will be changed to accommodate the program). The following examples were actually encountered either in real programs or are taken from the ISO C99 standard or from the GCC's testcases.

My first reaction when I saw these was: Is this C?.

The second one was : What the hell does it mean?

Provide answers before going through the website below.

Who Says C is Simple?
Standard C
GCC ugliness
Microsoft VC ugliness

http://manju.cs.berkeley.edu/cil/ciltoc.html



Saturday, October 09, 2004

Write good code

Execute-only code: One of the classic ways of attacking a web server with a known security hole is to feed that server with a command that triggers the security hole, and which contains a piece of code that is run as a result. Cox cited recent developments in microprocessor design which allow execute-only and read-only areas of memory, which provides protection against such potential damage because, for instance, any data fed to trigger a security hole won't run if it's not in executable memory.

Firewalling by default: "Red Hat has been doing this for four years now, Microsoft is finally doing it, Apple has been reasonably intelligent about this for a long time as well. You don't leave your front door open just in case you need to walk in and out. It's much much safer to have your front door shut. So by having firewalling by default, it actually allows users to accept, there is probably insecure software on my computer system. It may have bugs in it. But if the rest of the world can't get at my software, I don't care - not too much."

Languages are very important, particularly when it comes to the issue of memory allocation. "If computer programmers get the memory allocation wrong, why are we letting the computer programmers do the memory allocation? The computer can do this. The world has moved on since the design of languages like Fortran and C." "So for other newer languages, we have garbage collection, we have sensible memory allocation, and this means we can take things away from the programmer, so that providing the language has done it right, the programmer cannot make that mistake anymore. And this works out incredibly effectively when you look at the kind of bugs you get in software. Even when just doing it by getting programming interfaces right, we see huge improvements.""I looked at this for some of the Linux desktop code. And instead of using standard C functions for a lot of the memory handling for text, it has a library which doesn't allow the programmer to screw it up. If you look at the history of this kind of error, almost none of them occurred in desktop [environment] compared to a very large number that were found elsewhere in applications on Linux. So it tells us that using the right tools works."

Validation tools: "They used to be very expensive, they're getting a lot cheaper. So we know for example if a given function takes a lock, it should also get rid of the lock in all paths. So one of the cases where the error code forgets to do things, we catch."

Type safety: "Things like type safety are now taken for granted. When I was an undergraduate at Swansea University, we thought it was a novelty when the C compiler told you if you passed a floating value to a function instead of an integer."

Tainting: "The idea is that when you've got untrusted data, you actually tell the computer this data is untrusted, because then you can look through how the untrusted data is used, and what other data it creates. And you can look for cases where you're doing stuff with untrusted data that you shouldn't be - like relying on it. And so we catch human mistakes before we ship them to the consumer."

Rule verification: "If you have rules in your software, you know how certain bits of it should behave, you can start to use software in some cases to verify or to validate these rules."

Good interfaces: This is another surprisingly effective one. If you look at a lot of other businesses, if you're a car manufacturer and you find you've got a lot of faulty cars coming off the production line because someone's put a part in backwards, the first thing you do is make a new version of that part which has a knob on it or something so it won't fit backwards. That's the immediate reaction. So we've started to do this kind of thing in software. So we have things that are simple and hard to misuse.""An example of this is, with locking, instead of having one function for taking a lock and another function for releasing the lock, which inevitably means that someone always has an error handling or an unusual case where they forget, you have a single function which calls another function locked; it takes the lock, calls the function, and drops the lock. All of a sudden it's another mistake you can't make because the computer won't let you, because fundamental to your language, fundamental to the way you're coding, is the idea that this lock must be released. And it turns out you can do a lot of these things in languages like C++ by being a bit clever."

Defensive interfaces: "Locks with corrupt flags is another example. One of the things the telco industry cares about is that systems stay up. So eventually your software crashes with somebody owning the lock - someone currently has the sole right to some critical data structure. And in this case what the telecoms people do with newer systems is that after a certain amount of time, the system has a watchdog, much like your video recorder does. If the video recorder or your DVD player crashes, it just reboots after a certain amount of time, as if nothing has happened. This is great until you've got locking, and you kill a particular part of your phone switch and it owns some critical part of the system.""[With] defensive interfaces, I can now take a lock and I can be told, 'I'm giving you this lock, but be aware that something terrible happened to the last user of it' - which means that when you take this lock you can actually start to take defensive actions."

Mathematical models: "People have started to use mathematical models for things like defect rates. Turns out all the models exist - the large part of industry that actually makes physical objects has known about them for a considerable number of years. They tell you interesting things like when you should release software beta. Providing you've got a good estimate of the cost of finding faults yourself, and the quality of the fault finding relative to your beta testers, you can actually do the maths to tell you when you should be going into beta testing."

Scripted debugging: "Traditionally you think of your debugger as something that you use after your software has crashed. But a debugger turns out to be very useful in quality assurance, because you have a lot of things in your software which you can't easily inspect. You can actually use a debugger as part of your QA testing to go in at the end of the run and say, are all the internal values right? Does the software appear to have behaved as we expected on the inside as well as on the outside?"

Brute force testers: "These are beta testers, and users of dot-zero versions of software, of course. And tools like CrashMe, which is one of the ones we use for Linux. And there are application level equivalents of this. The basic idea is, generate random input, feed it to the application, keep doing this until the application breaks. It's surprisingly effective. In a recent study they did this with Windows application software, feeding random Windows events to it, so effectively it simply sat there at full computer speed continuously clicking randomly, closing and opening dialog boxes, picking menu items, and typing. And about half the Windows software they subjected to this particular torture, crashed."

Root cause analysis: "I've got a friend who works on aeroplanes, and he has the wonderful job of, when a piece of an aeroplane falls off, cracks, or something before it was supposed to, they go to him and say 'why did it happen?'. And it's then not a case of saying 'oh, this analysis is wrong', it's saying 'how did this analysis come to be wrong? How did it make this wrong decision? Where else have we made this decision?' People are starting to do this with software.""The OpenBSD Project started doing it with security in particular, and found it very effective. Every time somebody found a mistake, they'd take the entire software base for these systems - bear in mind, working in the open source world you have a lot of source code, so it's much easier - and you look, with the aid of automated search tools, for every other occurrence of the same problem, in all your software. Because if someone's made a mistake once, we know lots of other people will have made the mistake. "All of this sort of analysis then leads back to things like, what tools didn't we use? Are our interfaces wrong? And because you're able to actually start digging in and get data, you can start to understand not only the 'oh, it's failed, I'll fix it', sort of the car mechanic approach to software maintenance, but actually the need do the kinds of things that should be done and which go on elsewhere, where you say 'Why did this fail? Where else have we got this? Where else will it fail? What should I do proactively? How do I change the software component involved so it can't happen again, or so that it blows up on the programmer when they make the mistake, not blows up on the user when they run the software?".

Document trails: "I've worked for several large software companies, before I worked for Red Hat, and trying to answer questions like, 'Who wrote the first version of this software?' and 'What other code is this function in?' can be interesting.""So you're looking at an ISDN router and you say, that's a security hole. And you have no idea where else this code appears in your company's product line. So you have no ability to test all the cases. Someone has to test each one individually, and possibly get it wrong, possibly find the code. So document trails are also a big help; where did this code come from, where is it going, what things do we know programmers get wrong with it? Actually carrying the documentation around with this software not only makes you get the documentation right so you can tell the programmer, by the way, people always get this wrong, but more importantly, you can fix it so they can't get it wrong. Because after all, programmers don't read documentation - you know that."

Rigorous reviews: "The effect of having to explain it to a second person is sometimes truly startling, as people try to explain what the code is doing and then realise that what they've written doesn't do the same thing."

Statistics: "And the final one which turns out to be really useful is statistics. Because if you've got enough copies of a piece of software out there, you can actually do statistical analysis, and so we've been doing this now with Linux, and you can start asking questions like, is there a 90% probability that all of these mysterious crashes with this kind of pattern, happened on a machine with a particular physical device, like a particular SCSI controller? Did 90% of them happen on a machine with a USB keyboard? We've actually pinned down hardware problems in this way - in one case we managed to pin down a fault in a particular brand of disk drive, because we looked at it and we realised it is directly correlated to this particular make of disk. And we went to the disk vendor, who ignored us, and eventually enough Windows people hit the problem that Microsoft went to the disk vendor, whereupon it got fixed."

The code should be reusable and should be able to run on many devices.It should be simple to understand and apply.

Finally if you really think it (the code you have written) is too good http://slashdot.org the same and test it again.Neutralize the Slashdot effect by using http://mirrordot.org and also check the criticism of http://alterslash.org

Do everything stated above but write good software please!A lot depends on the same!

Monday, October 04, 2004

eTelemetry

Want to know who is on your Network ?

The company will help you just do that-it is so simple.The kind of questions answered are:
  1. Who is accessing your network
  2. Where are they located

For more information please get in touch with the company.

http://www.etelemetry.com

Software for Research (using Windows)

This is an answer to many a dream for researchers.Though most of it is using Windows only I know Open Source users will come up with interesting stuff very soon.Point the same to me folks if any OS users do read this blog.

The link is below folks.

http://ist-socrates.berkeley.edu/~jaytate/software.htm

Pass on this information to as many as you can and it will really help advance research and who knows I may benefit someday along my friends.

Want to own a Used Ferrari?

Wait till 2006.Schumi and Barrichello's Ferraris are for sale during that time.All it takes is hard cash dudes.My guess is that whoever becomes the owners if they ever want to sell-and that is a very BIG IF it will be up for auction on an eBay or Sothebys or Christies.

The conservative price estimates are for 4 such F1s were describ­ed in a sales packet handed out to potential Clienti at the recent Monterey Historic event. Newest on the list was the F2003-GA in which Barrichello won last year’s British GP. Price was €1.5 million (about $1.82 million), not including tax. That car was still under a two-year “technological moratorium” designed to keep Ferrari secrets away from Minardi and Jordan, but it can be released next Jan. 1.

The other three were 2002 models, which could be taken home right away. Prices were €1.4 million apiece ($1.7 million) for two that had each won a single Grand Prix, and €1.5 million for a two-time winner. Note an extra victory is worth another $120,000 on the résumé.

The red missile comes with a complete set of the ancillary equipment needed to make it work—tire warmers, coolant and oil pre-heaters, pneumatic-valve air compressor, hydraulics unit, even a set of jacks.

Thats not all friends - To cover administrative costs, Ferrari Racing Owners are charged annual dues of €1,000, about $1,200. This entitles buyers to have their cars custom-fitted, and to drive shakedown laps at the factory’s Fiorano test track. Owners can send their mechanics through service training, too—the rumor is not true that a factory tech must be on-scene whenever the car runs. Once they learn how, anyone can operate an F1 Ferrari and one would do well to remember it’s not a space shuttle, it’s a car.

For more info well get in touch with Ferrari the dream machine makers in my opinion.

Saturday, October 02, 2004

Car websites

People buy cars online at low costs and sell the same on eBay at higher costs.I am sure it is possible to replicate this model wherever you are and nobody can stop you.If you cannot beat them them join them or convert the naysayers to your line of thinking.The best car websites in my opinion are:
  1. http://www.autotrader.com
  2. http://www.cars.com
  3. http://www.edmunds.com
  4. http://www.imotors.com

Java related websites

I do not know programming but am sure that programmers will thank me for these websites.


Certification


Certification Record: www.galton.com/~sun/
Java Certification: suned.sun.com/US/certification
JCertify: www.enterprisedeveloper.com/jcertify
Individuals
developerlife.com
Hot Java Sites: www.michael-thomas.com/java/javahotsites.htm
Mr.Haki's JBuilder: www.drbob42.com/JBuilder/index.htm

Online Info

DevX Help: www.devx.com/gethelp
IBM DeveloperWorks: www-106.ibm.com/developerworks/java
Java Report: www.adtmag.com/java/index.asp
Java WinHelp: http://www.confluent.fr/javadoc/indexe.html
www.javaworld.com
www.jguru.com
www.onjava.com
Thinking in Java: www.mindview.net/Books

Parsing/Compiling

Compiling To Native Code: www.bearcave.com/software/java/comp_java.html
Excelsior Java Compiler: www.excelsior-usa.com/home.html
JFlex - Scanner Generator: home.in.tum.de/~kleing/jflex/index.html
Sun: java.sun.com
Icons: developer.java.sun.com/developer/techDocs/hi/repository/
JavaOne: servlet.java.sun.com/javaone/
JMF: java.sun.com/products/java-media/jmf/index.html
JDC: developer.java.sun.com/developer/index.html
JSP Tag Libs: http://java.sun.com/products/jsp/taglibraries.html
Sound: java.sun.com/products/java-media/sound/
www.artima.com
www.cinjug.org
COTUG: www.objectwind.com/cotug
ColdBeans: www.servletsuite.com
GNU Java: www.gnu.org/software/java/java.html
www.hotdispatch.com
jakarta.apache.org
Jakarta Tomcat: jakarta.apache.org/tomcat/index.html
www.jspInsider.com
Max Training: www.maxtrain.com
www.TheServerSide.com