GUI for Valgrind

Callgrind uses runtime instrumentation via the Valgrind framework for its cache simulation and call-graph generation. This way, even shared libraries and dynamically opened plugins can be profiled. The data files generated by Callgrind can be loaded into KCachegrind for browsing the performance results. But there is also a command line tool in the package to get ASCII reports from data files without the need to use KCachegrind.

Link

How to Backup Data in MySQL

To make a backup:

* mysqldump --user=username --password=password databasename >path/backupfilename

After the Software Wars by Keith Curtis

Given the technology that's already available, we should have cars that drive us around, in absolute safety, while we lounge in the back and sip champagne. This book explains how we can build better software and all get our own high-tech chauffeur.

NEW YORK TIMES BOOK REVIEW:
"Keith Curtis, an 11-year veteran of Microsoft, takes a programmer’s approach in “Software Wars,” attempting to systematically build a case that free software can help pave the way for a 21st-century renaissance in many fields ranging from artificial intelligence (cars that drive themselves) to the human journey into space (space elevators). For Mr. Curtis, free software is all about leveraging our collective intelligence."

Download Free Pdf Version

The Free PDF Edition of Ubuntu Pocket Guide and Reference

The PDF Edition of Ubuntu Pocket Guide and Reference is available entirely free of charge. It is practically identical to the Print Edition. You can get it by clicking one of the links below. Over half a million people worldwide already have!

You can share the PDF file with people you know, and even upload it to file sharing networks. You may NOT sell the PDF! Click here for more information, or check out the FAQs.

The information in Ubuntu Pocket Guide and Reference is distributed on an “as is” basis without warranty. Although every precaution has been taken in the preparation of Ubuntu Pocket Guide and Reference, neither the author nor publishers shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the information contained in Ubuntu Pocket Guide and Reference.

Link

How to Calculate a md5sum and Validate it

Prerequisite: The md5sum's application is installed in your system.

1) To calculate the md5sum on a file and place this result in another file with the extension .md5

The command is : md5sum FileName > FileName.md5

2) To validate a md5sum's file. Note that the original file and the generated md5sum file are in the same directory for this demonstration.

The command is : md5sum -c FileName.md5

How to Print Shared Library Dependencies

ldd prints the shared libraries required by each program or shared library specified on the command line.

To see all modules dependencies use the command ldd [options] filename

Linux Command Line to format c source file

In Linux system you can use this command line to format your c source file :

> indent -i4 -ts4 -br -brs -cdw -lp -ce -nbfda -npcs -nprs -npsl -nbbo -saf -sai -saw -cs -l90 foo.c

You may want to put these settings in your ~/.indent.pro to automatically invoke this configuration next time.

In verbose, the above means:

* -i4: indent level 4
* -ts4: tab size 4
* -br: braces on if line
* -brs: braces on struct decl line
* -cdw: cuddle do while
* -lp: line up continuation below parenthesis
* -ce: cuddle else
* -nbfda: dont break function decl args
* -npcs: no space after function call names
* -nprs: no space after parentheses
* -npsl: dont break procedure type
* -saf: space after for
* -sai: space after if
* -saw: space after while
* -cs: space after cast
* -ln90: line length 90 columns

How to estimate software tasks

Estimating software development schedules is a skill, not an art. Here are some tips to get better estimates.

Let developers estimate their own work
Any system where management writes a schedule and hands it off to programmers is doomed to fail. Only the programmer who is going to do the work can figure out what steps they will need to take to implement that feature. And only the programmer can estimate how long each one will take.

Design first, and in detail
Attempting to estimate a feature before you've figured out how the feature is going to work, in detail, can't possibly work, even if you "multiply your best guess by three," because your "best guess" is based on very little in the way of facts. The nature of software development is that things which seem simple are often surprisingly complicated when you think about all the details. For example, when you think about creating a registration and logon system, you might forget that you're going to need a way to prevent passwords that are the same as the user name, and a way to deal with forgotten passwords, and a way for people to unregister, and so on. Until you try to figure out the design of all these things, you have no basis for an estimate at all.

Break things down to very small tasks
This is the most important part to making your schedule work. Your tasks should be measured in hours, not days. (When you see a schedule measured in days, or even weeks, it's probably not real). You might think that a schedule with fine grained tasks is merely more precise. Wrong! Very wrong! When you start with a schedule with rough tasks and then break it down into smaller tasks, you will find that you get a different result, not just a more precise one. It is a completely different number. Why does this happen?

When you have to pick fine grained tasks, you are forcing yourself to actually figure out what steps you are going to have to take. Write subroutine foo. Create dialog such and such. Read the wawa file. These steps are easy to estimate, because you've written subroutines, created dialogs, and read wawa files before.

If you are sloppy, and pick big "chunky" tasks ("implement grammar correction"), then you haven't really thought about what you are going to do. And when you haven't thought about what you're going to do, you just can't know how long it will take.

As a rule of thumb, each task should be from 1 to 16 hours. If you have a 40 hour (one week) task on your schedule, you're not breaking it down enough.

Here's another reason to pick fine grained tasks: it forces you to design the feature. If you have a hand-wavy feature called "Internet Integration" and you schedule three weeks for it, you are doomed, buddy. If you have to figure out what subroutines you're going to write, you are forced to pin down the feature. By being forced to plan ahead at this level, you eliminate a lot of the instability in a software project.

Track actual times and learn from your mistakes
Most programmers have no idea how to guess how long things will take. That's okay. As long as they are continuously learning and continuously updating their estimates as they learn, the schedule will work. (You may have to cut features or slip, but the schedule will still be working correctly, in the sense that it will constantly be telling you when you have to cut features or slip). Most programmers become very good estimators with about one year of experience.

Account for vacations, holidays, meetings, etc.
If your schedule is going to take about a year, each programmer will probably take quite a few days of vacation. In FogBugz, you can set up company-wide holidays, and each developer can enter their own planned vacations as well.

Add schedule items
You need to enter schedule items for:

1. Integration time, that is, time spent getting code written by different developers to work together.
2. Buffer time: extra time in each developers' schedule to account for unplanned features and tasks. This may need to be as much as 50% to 100% of the planned time, depending on how much confidence you have in the accuracy of your design.
3. Competitive buffer time: time to allow for new features added at the last moment to match a competitor's features.
4. Debugging time: time spent fixing bugs discovered during testing.
5. Alpha and beta tests: time spent distributing test versions of the software, gathering and responding to feedback and bug reports, incorporating feedback into the product, and fixing bugs discovered by beta testers.

In FogBugz, a schedule item is a special kind of case. You should enter schedule items for each developer. If you have five developers on your team, you should have five "debugging" schedule items, one assigned to each developer, so that the calculated dates produced by EBS are correct.

Ignore business needs (and your manager)
Many rookie software managers think that they can "motivate" their programmers to work faster by giving them nice, "tight" (unrealistically short) schedules. This kind of motivation is brain-dead. Most developers, when behind schedule, will feel doomed and depressed and unmotivated. When they're working ahead of schedule, they're cheerful and productive. As such, the schedule is not the place to play games of chicken.

Why do inept managers try to get programmers to reduce estimates?

When the project begins, the technical managers go off, meet with the business people, and come up with a list of features which they think would take about three months, but would really take nine. When you think of writing code without thinking about all the steps you have to take, it always seems like it will take n time, when in reality it will probably take more like 3n time. When you do a real schedule, you add up all the tasks and realize that the project is going to take much longer than originally thought. Reality sinks in.

Inept managers try to address this by figuring out how to get people to work faster. This never works. You might be able to get 10% more raw code out of people temporarily at the cost of having them burn out 100% in a year. Not a big gain, and it's a bit like eating your seed corn.

You might be able to get 20% more raw code out of people by begging everybody to work super hard, no matter how tired they get. This causes debugging time to double. An idiotic move that backfires in a splendidly karmic way.

The business is best served if estimates are as realistic as possible. While estimating, you must completely ignore the wishful thinking of the client and focus on what is really going to happen.

Learn more
The idea that software estimation is an "unsolved problem" is simply not true. True, a lot of software developers organizations have managed to remain ignorant of everything that has been learned over the last 40 years about how to estimate software and deliver it on time, but there are also plenty of development teams that reliably produce accurate software estimates and ship within 5% or 10% of estimate.

You can learn more about estimating software schedules from Steve McConnell's book Software Estimation: Demystifying the Black Art, published by Microsoft Press.

If you've never read it, The Mythical Man-Month by Frederick P. Brooks (Addison-Wesley) is a requirement.


FogBugz 6.0 Documentation Home

UML: Aggregation or Composition

In this Association there are two types mainly Aggregation Association and Composition Association.

Aggregation Association signifies that the whole object can exist without the Aggregated Object. For example in the below figure we have three classes university class, department class and the Professor Class. The university cannot exist without department which means that university will be closed as the department is closed. In other words lifetime of the university depend on the lifetime of department.

In the same figure we have defined second Association between the department and the Professor. In this case, if the professor leaves the department still the department continues in other words department is not dependent on the professor this is called as Composition Association.

Note: The filled diamond represents the aggregation and the empty diamond represents the composition. You can see the figure above for more details.

Ref

Apple's Cover Flow Clone for the Web

MooFlow
For fans of Apple’s Cover Flow feature in Leopard, MooFlow is taken directly from Apple’s playbook. MooFlow is a JavaScript gallery script that uses MooTools and adds a bit of JavaScript magic to make beautiful image galleries, complete with a slider that mimics Cover Flow.

Just like with Cover Flow, you can manipulate MooFlow’s gallery layout and functionality. You can toggle full-screen mode, image reflection, and autoplay. MooFlow is quite configurable and easy to set up because it just grabs all of the images within an element




Ref.

Rules of 'Zero-Defect Software Development'

Here are the ten basic rules of ZDSD:

1. Test your product every day as you develop it, and fix defects as soon as you find them. Apply the daily build and smoke test. At the end of every day you work on your project, build the current version of your software, and test it for basic functionality. Microsoft enforces this policy religiously, using large teams to build each project on a daily basis. A programmer whose code breaks the build may be called in the middle of the night and must go back to work to fix the problem immediately. For independent game developers working on small projects, this is far easier. At the end of each day, test your program for at least ten minutes. Make a list of anything you would consider a "defect," and resolve to fix all defects before implementing any new features. Once you find a defect, fixing it becomes your number one priority, and you avoid writing any new code until the defect is 100% eliminated.

2. Review your code regularly. When most people think of QA, they think of testing, but testing is actually one of the least cost-effective strategies for finding bugs. The most rigorous testing will typically find less than 60% of all bugs in a program, and there are certain types of bugs that testing will rarely find. Studies conducted at many large software organizations have concluded that code inspections are far more cost-effective than testing. A NASA study found that code reading detected almost twice as many defects per hour as testing. Whenever you've added a few hundred lines of new code to your project, set aside an hour or two to read over your work and look for mistakes. One hour of code review is equivalent to two or more hours of methodical testing. As you gain experience, keep a list of the types of defects you find, and run down your list whenever reviewing new code. To find even more defects, have someone else read your code as well.

3. Rewrite poor-quality modules. When you discover an obscure new bug, do you ever pray, "Oh no! Please don't let it be in that module!" We all have monster modules of legacy code that were written when we weren't such seasoned programmers as we are today. Don't fear them; rewrite them. Often a better approach will only become clear when an inferior solution has already been implemented. This is certainly true for John Carmack, who coded dozens of different approaches when writing the Quake engine before discovering one that satisfied him. Defects will not be distributed evenly across your code. You will typically find that 20% of your routines are responsible for 80% of your errors. In my programs it is normally the modules that interact with the hardware or with third-party drivers, especially DirectX, that are the most buggy. Raise your standards for those modules that seem to produce a never-ending supply of bugs, and take the time to rewrite them from scratch. You may find that other intermittent bugs disappear completely as a result.

4. Assume full responsibility for every bug. 95% of all software defects are caused by the programmer. Only 1% of defects are hardware errors, and the remaining 4% are caused by the compiler, the OS, or other software. Never dismiss a potential bug; find out the exact cause of any anomaly. When the Mars probe suffered serious software glitches during its mission, it was learned that the same glitch had occurred only once during testing on earth, but the engineers dismissed it as a temporary hardware hiccup. Unless your hardware drinks soda, it does not hiccup.

5. Handle change effectively. You will always think of great new features to add after you have started coding. Carefully consider how each change will impact your pre-existing code. Poor integration of unanticipated features is a major cause of defects.

6. Rewrite all prototyping code from scratch. Sometimes you may quickly prototype a new feature to see if it will be viable. Often this is done by sacrificing code quality in the name of rapid development. If you eventually decide to keep the feature, it is very tempting to simply tack on some basic error checking to the prototyping code. Don't fall into this trap. If you weren't writing the code originally with quality as a priority, scrap the prototyping code, and re-implement the feature from scratch. Rapidly prototyped features that slip into the final product are a major source of bugs because they are not subject to the same quality standards as the rest of the code.

7. Set QA objectives at the beginning of every project. Studies have shown that developers who set reasonable QA goals will usually achieve them. Decide in advance if your product must be fast, small, feature-rich, intuitive, scalable, etc. Then prioritize those objectives. When designing the interface code for an upcoming game, I decided that my top three priorities were to make it beginner-intuitive, fast, and fun, in that order. Consequently, my game's interface isn't as graphically rich as other games, but it is easier to use and faster than any other game of its type. Whenever you have to make a design decision, keep your objectives in mind. If you do not set clear QA goals, then you are doomed to accept the results of random chance.

8. Don't rush debugging work. Fully 50% of all bug fixes are done incorrectly the first time, often introducing new bugs in the process. Never experiment by simply changing "x-1" to "x+1" to see if that will do the trick. Take the time to understand the source of the bug. Long ago when I was a boy scout and had to put out a campfire, the Scoutmaster would sometimes test my thoroughness by asking me to put my hand in the ashes. I learned very quickly how to put out a fire so well that I had complete confidence it was 100% extinguished. When you find a defect, it means your code is on fire. As long as the defect remains, any new code you write will add fuel to that fire. Whenever you find a defect, drop everything to fix it, and don't move on until you are 100% confident that your fix is correct. If you don't take the time to do it right the first time, when will you find the time to do it over?

9. Treat the quality of your code at the same level of importance as the quality of your product. Rate your code on a scale of one to ten for overall quality. The first time I did this, I rated my 30,000-line project as a four. I rewrote the worst of the code until I reached an eight overall. It was one of the best investments of time I ever made because I was then able to add new features at double my previous rate. The quality of your code is highly indicative of the quality of your product. You may find as I have that your best selling products also receive your highest ratings for code quality.

10. Learn from every bug; each one represents a mistake that you made. Learn why you made each mistake, and see if you can change something about your development practices to eliminate it. Over the years I have adopted many simple coding practices that allow me to avoid common bugs that used to plague me. There are many types of bugs that I now never encounter because my coding style makes it physically impossible for me to introduce them.


Process Methods in Zero-Defect Software Engineering Guideline

How to Create SSL Certificate

These are steps to generate a SSL certificate.
Have openssl installed before
Log with root

1)Create these repositories in a repository
demoCA
demoCA/newcerts
touch demoCA/index.txt
echo 01 > demoCA/serial

2)Create a private key for your server
openssl req -x509 -newkey rsa:1024 -days 3650 -keyout ca.pem -out ca.crt

3)Create a private request file needed to sign
openssl req -newkey rsa:1024 -days 3650 -keyout server.pem -out server.req
note: When to process ask you to "common name" this means the server name or host name

4)Create the server certificat from the request
openssl ca -days 3650 -cert ca.crt -keyfile ca.pem -out server.crt -in server.req

to see the information in the certificate
openssl x509 -noout -text -in serveur.crt

Now Make your face your password, with KeyLemon software

Have you ever wondered creating your own facial password like the matrix film or the Lenovo Advertisement? Well it’s time to make your own security system with keylemon. Facial recognition is not all about buying a high tech surveillance system but a simple webcam and some blocks of programs would help you build up your own face recognition security system.

How to setup your face recognition security?

By downloading keylemon and with a good quality webcam, your security system is not far away. After installation, the program acts as a default authentication system for your computer requiring your facial expression to be your password.

How does it work?

It collects your facial features by a webcam which is used to build a statistical representation of face and does stores it in binary format for execution and detection. This spyware free program which gives a lot concern for your privacy stores your image in encrypted format meaning no third party programs can access it.

The backend of this program seems like it can support all webcams launched way back to 2 years but the application is still in beta stage. keylemon has released its version only for windows platform where Mac users have to wait a bit. I myself tried the program which sits lite in the system and unlocks quickly after showing my face but the cons is it doesn’t allow multi-user support as far now.

Other review : ref



Veriface from IBM:

Libra - Organize your stuff, beautifully

Libra is a library software to organize your stuff: Books, Audio CDs, Movies, & Games (for a start). And it does so beautifully, and at an amazing price ($0 for non-commercial use).

Link

Apple's Cover Flow Clone

PictureFlow is a Qt2/Qt3/Qt4/Qtopia4 widget to display images with animated transition effect, much like Apple's Cover Flow (used among others in iTunes, Finder, iPhone, and iPod). PictureFlow uses a portable and optimized software renderer and runs smoothly on smartphones and other mobile devices.

Project's link

FullSync Greate Backup Tool !

FullSync is a universal file synchronization and backup tool which is highly customizable and expandable. It is especially for developers, but the basic functionality is easy enough for everyone. Written in Java, so can be run everywhere.

Link

The New Google OS -- gOs

The Amazing Water Clock

A clock that runs on water?
Yes it's the Amazing Water Clock!

The Code Linux

How to Configure a free VPN solution in your home

Windows Xp solution

link