Interesting websites I visit: 2004

Thursday, December 30, 2004

Find what you want on eBay and sell for a profit!

Find what is wanted by people and sell it.

http://kicksfinder.com is the place for you.

Give to victims of the Tsunami.I am doing my bit and Inshallah (Allah willing) I will do more than just popularize the links through www.stumbleupon.com

All readers please stop the mindless destruction of the environment and chopping of trees-there will be a price to pay and not us - our children and near and dear ones will pay it!

Is this the kind of world we want to live in?

http://www.approtec.org/tech.shtml

Keep checking out my stumble upon profile-all of you will really appreciate the same and know I keep finding really good stuff and keep writing nonsense also-do ignore the comments I make and do whatever possible!

Thursday, December 23, 2004

retain top employees

Top employee - defined

An employee who understands a company's culture,a company founder's nature,the law of the land,works from within the system,using the least resources,disseminates the key learnings to all other colleagues (when required),gets things done,always is inquisitive about how things are done presently and how things can be done better, stays on top of trends,knows how to use technology and understands the implications of the technologies,assumes responsibility for each and every action of the company,team and self,is ethical and fair to competitors,to the world in general,knows how to find and use information and give results to a company in time!.

How does a company retain such people ?
Do these people exist ?
How does an entrepreneur find such people ?
How should such people be treated ?

These type of people do exist and are the backbone of every small or large enterprise.
They are retained by using a variety of methods:
(i) paying them a little less than they are actually worth
(ii) giving them additional responsibilities and making sure their jobs are well defined giving them freedom in their jobs and free time to pursue new experiences
(iii) keeping your eyes and ears open and networking with as many people as possible is the only way to find such employees-sources I use to find such people are:
newsgroups,
alumnii associations
blogs,
social networks,
google groups,yahoogroups,etc.
challenge-response invites on places like /.,mirror.,\.,wikipedia and its variants,ddj,
reputed institutions of higher learnings like IIT's,IVY-league universities,
organizations like SPE,SPI,RSC,CUR,COS,
Companies in VC firm portfolios,angel investor portfolios,
friends and family and advertising in select sources and any other ideas that strike me
(iv) How you expect to be treated in society and by these people in return is how you treat such rough gems-polish is what they have come to you for ! . Recognition and appreciation is important.Quality always gets noticed by people if not in your company or organization definitely outside-is the risk of not doing worth it?If companies and organizations are able to manage the above it will really make the world a better place!

Think and decide for yourselves!

Monday, December 13, 2004

Build a School!

buildaschool.org/info/info.cfm - Info to Help to build schools globally!.Doing my bit for education!

why I blog?

I blog therefore I exist!
I blog so people do something positive with the information I have painstakingly collected!whatever,whenever....
I blog to get inb touch with gud folks-who knows when I will be appreciated!
I blog to make amends with people whom I have upset!Someday they may be good friends and respe ct me again!.
I blog to spread some of the best info I find on the internet!
I blog to share ideas I have
I blog to sell Incense Sticks
I blog to promote net usage in my own way
I blog so that my visitors read,understand,execute and spread the word about me!
I blog to show I too can write a blog

Are not these reasons enough!

Wednesday, December 01, 2004

Get that Job!

Find where the jobs are
Learn the requirements of the job
Bruh up what you already know
Show how you will be useful to the company and the community and country and the world
Stick to the promises you make-if you do not who will!
Always be truthful to your employer
Stick up for your colleagues and company at all costs
Persist and try to meet as many people as you are able to from the company to prove yourself!It has been done before and will happen again and again-what is important is to get the message across.

See the website http://getthatjob.blogspot.com

Finally GET THE JOB! or START SOMETHING ON YOUR OWN-Plenty of opportunities exist-one has to start looking for the opportunities.Eg: eBay is the biggest opportunity I know about!.

Saturday, November 27, 2004

MySQL update

The MySQL database server is the world's most popular open source database. MySQL 4.1, the latest production-ready release includes numerous enhancements that improve performance, internationalization, and the ability to embed the MySQL Server with other hardware and software solutions.

http://dev.mysql.com/tech-resources/articles/4.1/index.html

I am a fan of Open Source.

Net Travel Websites

Find out how much you will actually save on global travel by visiting the websites below and see what the lesser known websites too have to offer.Major companies have taken a stake in the lesser known companies.

http://www.sidestep.com
http://www.cheapflights.com
http://www.qixo.com
http://www.mobissimo.com
http://www.kayak.com
http://yahoo.farechase.com
http://www.expedia.com
http://www.travelocity.com
http://www.orbitz.com

Monday, November 22, 2004

Mooter

I love the search engine Mooter.Search on the internet is finally becoming more meaningful!

www.mooter.com

Sunday, November 14, 2004

Tips for selling a product & getting attention

Find people who might be interested in your product.

If a anybody posts about an itch that your product scratches, email them, work a link to their post into yours, and be sure to send them a trackback ping.

If people with the same itch comment on the blogger's post, email them too.If people mention similar products that don't quite scratch the itch, look for posts and comments on those products, and repeat.

I have a lot of new products to try, too.Tell people how you found them and why you think they might be interested in your product. "I read your post on , and I think you might be interested in because ." is more compelling than "! ! !"

Find the people who use your product.

If someone sends you a trackback ping, read their blog, see if anyone commented on their post or sent them a trackback ping, and repeat.

Not everyone sends trackback pings.

Search for your name, your product's name,trade names name with search engines.

Be accessible and engage everyone.Solicit feedback, constantly, about everything. Ask everyone what they like, dislike, would like added, would like changed, etc. Incorporate their feedback into your product.

Help people use your product. This is easy if you know who's using it.Ask individuals to help you do things that you can't do yourself.
A list of stores in a city where your products are available will help customers,a newsletter giving related information on developments in the industry also helps.

Thank everyone.It probably doesn't need to be said, but if someone plugs your product, finds a bug, submits a patch, or suggests a feature, thank them for it. If someone doesn't like your product, but they're polite about it, thank them for trying it. I don't think anyone will object to a thank-you email.

Don't go overboard.Don't email everyone you've ever talked to about your product every time you release a new version or make a change to it. Instead, email everyone who contributed to the new version, thanking them for their contribution, and let everyone else subscribe to your blog or opt-in to a mailing list.

Don't blatantly advertise on all channels.Remember, no matter how proud you are of your product, you don't want to annoy potential customers do you?

Saturday, November 06, 2004

Investors will ask?

INVESTORS will always ask such questions and it is best if you are prepared with answers to questions posed below:

1. What's the opportunity? It's not enough to say you've spotted a problem and a way to fix it. Investors despise those marketing studies that say "this market is expected to grow 250% a year for the next 10 years, and if we can capture just 1.7% of the market, we'll all be multi-billionaires." Instead, you need to show how your approach will work better than any previous attempts to exploit the opportunity, and how you'll make money doing so.

2.What special advantages do you have? That might mean a management team with a distinct skill set that a rival company couldn't easily match. Investors probably won't be impressed if you claim your advantage is having a head start on the competition — not unless you have a barrier to entry, such as a patentable product or process that would make it hard for new rivals to imitate your offering.

3.What is the secret of your expected sales success? Investors know that selling is a special talent, and one that many young companies don't have on board. They'd love to hear that you have a rainmaker on your team, or a proven sales technique that can easily be taught to others.

4.What have you learned from the competition? The more specific your answer, the better. For instance, "competitor X impresses us by being so systematic in asking new customers what they like and dislike about its service. We plan to take that idea a step further by responding immediately to customer dislikes."

5.How will you use the funds you raise? Investors are more concerned than ever that their money be spent in ways that most directly generate revenue and profits. They'd rather hear you itemize how you'll use it to hire three more salespeople and develop sales support literature than on product innovation research.

6.What are the risk factors? Your realism in this area will reassure investors. If it's likely that competition in your industry will intensify over the next six months, then tell them you expect this to happen and explain how you plan to respond.

7.How do you plan to use the Internet,why and how many people do you know who will actually help you and make the venture a little less risky ?

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 –

questions that spark interesting conversations,
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:

Who is accessing your network
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 described 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:

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

Monday, September 27, 2004

Rules for developing software

1. Great software is built by small teams or individuals. If you're building a great BIG software product use lots of small teams or do it yourself to silence critics or find someone to do it for you. The team leaders (if you use a group) should be able to carry on a civilized conversation with others; conversely, they should not be trying to torpedo each others' careers behind their backs.

2. Great software projects always, always have one person who gets the big picture. He/she codes. Repeat: he/she codes. This person is called the architect.

3. Software "architects" that don't code are not software architects. Sorry.

4. If you check in code that breaks the build, shame on you. If you didn't bother to test it before you checked it in, you should be reassigned to writing dot-matrix printer drivers for CP/M for the rest of your natural life.
If on the other hand your checkin broke the build because it conflicted with another checkin, get out of your office and make some new friends among your coworkers. And talk to the architect and get the big picture. If you're really conscientious maybe one day you might be like him/her.

5. In any given source file there should be more comments (as measured by number of ASCII characters, if nothing else) than code. The comments should reflect the fact that the coder knows what he/she is doing and why this code was, in fact, necessary.

Your comments should be comprehensible and grammatically correct. One day you will die, or be transferred to another project, or leave the company, and someone else will take over your code. Think about that.

6. Any coder that puts profanity in his/her code should be forced to write BIOS keyboard interrupt service routines for the rest of his/her natural life, preferably for an eight-bit microprocessor on an S-100 bus.

7. Test/QA is not there to find your bugs. (Read that twice, please.) You are there to find and fix your bugs. (Read that ten times.) Test/QA is responsible for telling manager(s) and customer(s) if your code is any good, and if it's ready to ship.

8. XML does not solve all your problems. Neither does model-driven design, or UML. You still have to write good code. Sorry.

9. Great software architecture requires thought in advance. Sorry.

10. Any coder that doesn't get the importance of user interface design up front should be forced to write IBM System/360 Job Control Language for the rest of his/her natural life.

Any coder working on a client-side app (including web-based apps) that codes without a UI design up front ought to be forced to write programs for OS/2 1.1 for the rest of his/her natural life.

11. Every coder must spend as much time as possible listening to a customer/user complaining bitterly about his/her software and act on the feedback.

12. Julie's Corollary: there is a difference between "programmers" and "engineers." You know who you are.My question-do you?andwhat do you want to become?Are acting to make that happen?

13. Coders with Big Egos usually have Big Problems with their code.

How can you tell a Coder with Big Ego? Easy. They often
a) close their office doors and refuse to talk to anyone who is "unworthy," including marketing, QA, product managers, and their own managers;
b) yell derisively at QA, who have the unmitigated gall to claim their code may have bugs;
c) tell everyone that "no customer would ever do that," when in fact every customer "does that";
d) usually quit either immediately before or immediately after ship, so as not to be accountable.

Pride comes before a fall-the bigger the ego the faster and harder it shatters and hurts you most where you least expect the same.

14. Great coders are not afraid of the words "value proposition." (Converse: good software marketers are not afraid of the words "object model.").A customer/user must actually see value in your work and enable consumers/clients to use the same efficiently.Period.

Become slashdotters (http://slashdot.org) and alterslashers (http://alterslash.org) -and the best coders compete in a no holds barred competition and make do with least-the barest minimum.

15.Learn from failures and improve !

Learning from failure
This is difficult. Writing and publishing encourages me to carefully examine my ideas and helps to clarify them. But looking closely at my own failure hasn't been fun, even if it has been rewarding. Hopefully others can spare themselves the pain by learning from my mistakes.

Back in April, May, and June I had an embarrassingly bad time with the import problem I mentioned. I took three months banging my head against various aspects of the problem. In spite of my post about the importance of knowing when to stop I chased one wrong turn after another for three months. When Rob returned from his vacation he asked Paul to take over who finished it in four days.

Three months vs. four days. That is embarrassing.

It would be easier if I could claim to have solved most of the problem. But Paul's solution little resembled what I had started and addressed aspects of the problem I hadn't even considered. I know Paul is a better programmer. I know he is fast. But I was not prepared for the internal shock and dismay of so glaring a comparison.
With a few months hindsight I can see that I made my most fundamental and most drastic mistake right before I started working on the problem. I assumed it would be easy, but tedious. I underestimated my opponent.
I then failed to notice just how much I was actually struggling. This is especially hard to accept, even in hindsight. How on earth could I go on for weeks, let alone months, without noticing how seriously I had underestimated?
When presented with evidence that conflicts with our beliefs, we dismiss the evidence rather than adjust our beliefs. Getting my butt kicked by an "easy, but tedious" problem is inconsistent with my hot-shot-programmer self-image. I continued to believe the problem was easy and that I was on the verge of the solution, in spite of mounting evidence to the contrary.

The last dimension of failure grew from the same poisoned soil. I couldn't bring myself to ask for help on something "so easy." I didn't want to interrupt Rob and Paul who seemed quite busy on more important matters. I didn't want to admit that this busy-work was kicking my butt. I flailed and struggled and silently suffered along.
As in aikido, getting properly slammed into the mat can really focus your attention. A number of important lessons came hard and fast in July and August.

Sean McGrath's description of the breakthrough syndrome offered some solace, if not a solution:
The syndrome affects all walks of IT professional life but is most acute in software developers. ... The developer "wraps their head" around a problem. ... From that moment of immersion onwards, ideas for solving the problem come thick and fast [and] the developer gets a sense that a triumphant breakthrough is not far away.... That person is likely to feel - really and truthfully - that a breakthrough is just around the corner.It may be, but it probably isn't.

Paul says "there's no busy-work in programming." I haven't heard that anywhere else, and it's still hard to believe. But there's no question that I would have called for help much sooner if I hadn't thought of it as busy-work.
My failure exposed the underlying importance of a collection of extreme programming practices. For starters, my silence violated three of the four XP values, specifically communication, feedback, and courage. Silence is not an effective form of communication. I was cowardly in concealing my failure rather than courageously admitting that Easy and Tedious had beaten me. I broke the feedback loop and we suffered for it.

By contrast, once my failure was out in the open, I was immediately back into the communication and tight feedback loops that are typical for bivio. Rob offered a couple rules of thumb to measure future progress: most tasks should take less than a day and the hard ones should be done in a week. These rules are hidden in continuous integration. In order to integrate continually, you have to break the tasks into day-sized chunks or smaller. Alarms should be going off if you can't integrate your code at the end of the day.

David called for the planning game -- something we hadn't been doing. For this particular problem, the split would have been especially valuable. I had misjudged the problem and taken on a task that was too big for me to properly get my head around. It would have been useful to get help early in slicing the problem into smaller pieces. Also, regularly reporting and adjusting scope and tasks would cause a failure like mine to fail fast. I would only have gone one week before the alarms started going off. If it went as long as two weeks, serious interventions would have been put in place and a months-long failure would have been averted.
I had to get over my hesitation to interrupt. This is about courage and communication. I had two fears holding me back. First, I was afraid of interrupting Rob and Paul. Second I was afraid of looking stupid. Courage is taking action in spite of fear. I need to trust Rob and Paul to manage their own interrupts. The fear of looking stupid is both simple and incredibly difficult. I simply need to get over it. That is substantially harder than it sounds, and also a story for another day.

Update: We only occasionally pair program. Doing that more consistently would obviously prevent a mistake like mine. If we were always pair programming, it would be hard for me to have even developed a fear of interrupting.

Perhaps the most important lesson of this whole experience is about my coworkers at bivio. No one berated me for my failure -- perhaps it was clear that I had that job well in hand. Instead they offered encouragement and stories of their own failures. In some way we bonded through my failure. We looked at the problem as a team and brainstormed various measures to learn from the experience. My mistake became an authentic opportunity to learn and grow, not to judge and condemn. That's not just a slogan on a motivational poster, but what really happened in action

16.Do not give broken links-nothing irritates more if you are not able to substantiate your claims in front of whomever you want to impress!.IBM's latest may make broken links a thing of the past.

(GOAL Create a system that can convert the anarchy of online data„Web pages, e-mail, chat rooms, and more„into a format that can be analyzed to identify commercially valuable information
WHY IT'S A WINNER By leveraging the vast reserves of untapped information online, WebFountain will let companies make smarter business decisions while creating an open platform that will encourage more machine understanding research to leave the laboratory.).

Wednesday, September 22, 2004

Build your tech career

to buid your technology career in US refer the website

http://www.techies.com

Friday, September 17, 2004

2 tech companies I find very interesting

Yes been sometime since I updated this blog.I wonder how many actually see this and are making the best use of the information here!
I would love to here some feedback-it will spur me on and no negative stuff please UNLESS you tell me how top correct the same or else you are indeed wasting time.
The 2 startups I like currently are:

http://www.telecontinuity.com - provides real emergency communication - has an innovative shoelace type of a repair system for communication systems.
http://www.transitive.com - eases the application migration of software between different conventional computer families, it has potential in the design of application-centered CPUs, in dynamic re-optimization of performance-critical software at run-time, and as a component in computer systems deeply embedded in consumer electronics – from cell phones and PDA's through digital entertainment centers and games consoles

Friday, September 03, 2004

more interesting websites and articles for Software engineers