Questions Couples Should Ask (Or Wish They Had) Before Marrying

1) Have we discussed whether or not to have children, and if the answer is yes, who is going to be the primary care giver?

2) Do we have a clear idea of each other’s financial obligations and goals, and do our ideas about spending and saving mesh?

3) Have we discussed our expectations for how the household will be maintained, and are we in agreement on who will manage the chores?

4) Have we fully disclosed our health histories, both physical and mental?

5) Is my partner affectionate to the degree that I expect?

6) Can we comfortably and openly discuss our sexual needs, preferences and fears?

7) Will there be a television in the bedroom?

8) Do we truly listen to each other and fairly consider one another’s ideas and complaints?

9) Have we reached a clear understanding of each other’s spiritual beliefs and needs, and have we discussed when and how our children will be exposed to religious/moral education?

10) Do we like and respect each other’s friends?

11) Do we value and respect each other’s parents, and is either of us concerned about whether the parents will interfere with the relationship?

12) What does my family do that annoys you?

13) Are there some things that you and I are NOT prepared to give up in the marriage?

14) If one of us were to be offered a career opportunity in a location far from the other’s family, are we prepared to move?

15) Do each of us feel fully confident in the other’s commitment to the marriage and believe that the bond can survive whatever challenges we may face?

How To Keep Good Posture When In Front Of A Computer

http://ririanproject.com/2006/10/30/how-to-keep-good-posture-when-in-front-of-a-computer/

“We spend a large portion of our lives sitting, especially during the computer age, so it’s important to learn to sit tall. One of the most common mistakes we make is that when we move into a sitting position, we tend to aim for the center of the chair. The proper method is to sit deep in your chair.”

- Dr. Marvin Arnsdorff

Today we are spending more time at computers, an activity through which people’s bad posture can affect their overall health.

Posture ranks at the top of the list when talking about good health. It is as important as eating right, exercising, getting a good night’s sleep and avoiding harmful substances. Unnatural alignment of the body can cause head, shoulder, neck and back pain, and compromise neurological, digestive, respiratory and cardiovascular functioning.

Unquestionably, students and adults alike spend more time at computers today than 20 years ago. So here are nine tips designed to help people’s posture when they’re at the computer at home, school or work:

1. Support Your Back

Does the chair you are sitting on have enough lumbar support? The backrest should fit into the natural curve of your lower back, filling in the space between your back and the back of the chair. This helps avoid excess pressure on the spine and makes it easier to maintain good sitting posture.

Adequate lumbar support also helps prevent muscle fatigue, which causes many people to lean their heads and upper backs too far forward or to slouch downward. With good lower back support, spinal muscles are relaxed and the spine is able to maintain its neutral position.

2. Comfortable Leg Postures

To promote comfortable leg postures, consider clearing away items from your legs to allow comfortable leg positions and movement. Feet should be flat on the floor or you may use a footrest if your feet do not rest comfortably.

3. Minimize Reaching

Position work station components to minimize reaching and twisting. Keep frequently accessed objects as close as possible to body centre.

4. Comfortable Shoulder and Arm Postures

Place your keyboard and mouse or trackball at the same height; these should be at about elbow level. Your upper arms should fall relaxed at your sides.

Also when typing, center your keyboard in front of you with your mouse or trackball located close to it.

5. Wrist and Finger Postures

Keep your wrists straight while typing and while using a mouse or trackball. Avoid bending your wrists up, down, or to the sides. Use the keyboard legs if they help you maintain a comfortable and straight wrist position. Type with your hands and wrists floating above the keyboard, so that you can use your whole arm to reach for distant keys instead of stretching your fingers.

Make sure you keep your fingers relaxed while typing and using a mouse. Use a soft touch on the keyboard instead of pounding keys with unnecessary force.

Also grasp the mouse gently and avoid holding a pen or anything else in your hands while you type or use the mouse. You should relax your fingers and hands between bursts of typing or mousing using a flat, straight wrist posture.

When moving your mouse, you may be more comfortable if you use your arm, not just your wrist. Choose a mouse that fits the size of your hand comfortably and is as flat as possible to minimize wrist strain.

6. Minimize Neck Bending and Twisting

Center your monitor in front of you. Consider placing your documents directly in front of you and the monitor slightly to the side, if you refer to your documents more frequently than your monitor.

Sit comfortably in the chair. Close both eyes and relax. Then, slowly reopen them. Where the gaze initially focuses should be when the eyes open is the place to put the center of the computer screen. The screen can be raised using books or a stand if needed.

7. Minimize Eyestrain

Place your monitor at a distance of about arm’s length when seated comfortably in front of the monitor. Also avoid glare. Place your monitor away from light sources that produce glare, or use window blinds to control light levels. Don’t forget to adjust your monitor brightness, contrast, and font size to levels that are comfortable for you.

Throughout the day, give your eyes a break by forcing them to focus on something other than on your screen. Try the following exercise: Hold a finger a few inches in front of your face; focus on the finger as you slowly move it away; focus on something far in the distance and then back to the finger; slowly bring the finger back toward your face. Next, shift your focus to something farther than eight feet away and hold your eyes there for a few seconds. Repeat this exercise three times, several times a day.

8. Take Short Breaks

Taking breaks can help your body recover from any activity. The length and frequency of breaks that are right for you depend on the type of work you are doing. Stopping the activity and relaxing is one way to take a break, but there are other ways, also. For example, just changing tasks - perhaps from sitting while typing to standing while talking on the phone can help some muscles relax while others remain productive.

9. Periodically Look Up At the Ceiling to Give Your Posture Muscles a Break

So, improve your sitting posture and remember, a healthy lifestyle can help you perform and enjoy your everyday activities, including the time spent at your computer. Learning more about working comfortably and productively, as well as your overall health, are important ways to help you enjoy your computing experience.

How to Shoot Yourself in the Foot in Any Programming Language

*******************************************************************************

The proliferation of modern programming languages (all of which seem to have stolen countless features from one another) sometimes makes it difficult to remember what language you’re currently using. This guide is offered as a public service to help programmers who find themselves in such dilemmas.

C
You shoot yourself in the foot.

C++
You accidentally create a dozen clones of yourself and shoot them all in the foot. Providing emergency medical assistance is impossible since you can’t tell which are bitwise copies and which are just pointing at others and saying, “That’s me, over there.”

JAVA
After importing java.awt.right.foot.* and java.awt.gun.right.hand.*, and writing the classes and methods of those classes needed, you’ve forgotten what the hell you’re doing.

Ruby
Your foot is ready to be shot in roughly five minutes, but you just can’t find anywhere to shoot it.

PHP
You shoot yourself in the foot with a gun made with pieces from 300 other guns.

ASP.NET
Find a gun, it falls apart. Put it back together, it falls apart again. You try using the .GUN Framework, it falls apart. You stab yourself in the foot instead.

SQL
SELECT @ammo:=bullet FROM gun WHERE trigger = ‘PULLED’;
INSERT INTO leg (foot) VALUES (@ammo);

Perl
You start shooting yourself in the foot, but you lose the gun.

Javascript
YOu’ve perfected a robust, rich user experience for shooting yourself in the foot. You then find that bullets are disabled on your gun.

CSS
You shoot your right foot with one hand, then switch hands to shoot your left foot but you realize that the gun has turned into a banana.

FORTRAN
You shoot yourself in each toe, iteratively, until you run out of toes, then you read in the next foot and repeat. If you run out of bullets, you continue anyway because you have no exception-handling ability.

Modula2
After realizing that you can’t actually accomplish anything in this language, you shoot yourself in the head.

COBOL
Using a COLT 45 HANDGUN, AIM gun at LEG.FOOT, THEN place ARM.HAND.FINGER. on HANDGUN.TRIGGER and SQUEEZE. THEN return HANDGUN to HOLSTER. CHECK whether shoelace needs to be retied.

LISP
You shoot yourself in the appendage which holds the gun with which
you shoot yourself in the appendage which holds the gun with which
you shoot yourself in the appendage which holds the gun with which
you shoot yourself in the appendage which holds the gun with which
you shoot yourself in the appendage which holds ….

BASIC
Shoot yourself in the foot with a water pistol. On big systems, continue until entire lower body is waterlogged.

FORTH
Foot in yourself shoot.

APL
You shoot yourself in the foot, then spend all day figuring out how to do it in fewer characters.

Pascal
The compiler won’t let you shoot yourself in the foot.

SNOBOL
If you succeed, shoot yourself in the left foot.
If you fail, shoot yourself in the right foot.

Concurrent Euclid
You shoot yourself in somebody else’s foot.

HyperTalk
Put the first bullet of the gun into the foot of the left leg of you.
Answer the result.

Motif
You spend days writing a UIL description of your foot, the trajectory, the bullet, and the intricate scrollwork on the ivory handles of the gun. When you finally get around to pulling the trigger, the gun jams.

Unix
% ls
foot.c foot.h foot.o toe.c toe.o
% rm * .o
rm: .o: No such file or directory
% ls
%

Paradox
Not only can you shoot yourself in the foot, your users can too.

Revelation
You’ll be able to shoot yourself in the foot just as soon as you figure out what all these bullets are for.

Visual Basic
You’ll shoot yourself in the foot, but you’ll have so much fun doing it that you won’t care.

Prolog
You tell your program you want to be shot in the foot. The program figures out how to do it, but the syntax doesn’t allow it to explain.

Ada
After correctly packaging your foot, you attempt to concurrently load the gun, pull the trigger, scream and shoot yourself in the foot. When you try, however, you discover that your foot is of the wrong type.

Assembly
You try to shoot yourself in the foot only to discover you must first reinvent the gun, the bullet, and your foot. After that’s done, you pull the trigger, the gun beeps several times, then crashes.

370 JCL
You send your foot down to MIS with a 4000-page document explaining how you want it to be shot. Three years later, your foot comes back deep-fried.


Disclaimer: I didn’t write the original article, though I’ve added to it. I have had the funnier definitions above listed in a text file for several years, and I decided to add my own one day.

It has also been pointed out to me that there is another article like this here
(http://www.reed.edu/~tuckers/jokes/foot.html)
, though it’s longer than my original version so I can only assume it is also a hybrid from the original list. Perhaps the original author is updating his list?

********************************************************************************

C++ Optimizations

http://www.custard.org/~andrew/optimize.php

These optimizations are fairly easy to apply to existing code and in some cases can result in big speedups. Remember the all-important maxim though, the fastest code is code that isn't called.
Use Initialization Lists

Always use initialization lists in constructors. For example, use

TMyClass::TMyClass(const TData &data) : m_Data(data)
{
}

rather than

TMyClass::TMyClass(const TData &data)
{
m_Data = data;
}

Without initialization lists, the variable's default constructor is invoked behind-the-scenes prior to the class's constructor, then its assignment operator is invoked. With initialization lists, only the copy constructor is invoked.


Optimize For Loops

Whereever possible, count down to zero rather than up to n. For example, use

for (i = n-1; i >= 0; --i)

rather than

for (i = 0; i < n; ++i)

The test is done every iteration and it's faster to test against zero than anything else. Note also that

++i

is faster than

i++

when it appears in the third part of the for loop statement.


Use 'int'

Always use the int data type instead of char or short wherever possible. int is always the native type for the machine.


Make Local Functions Static

Always declare local functions as static, e.g.,

static void foo()

This means they will not be visible to functions outside the .cpp file, and some C++ compilers can take advantage of this in their optimizations.


Optimize If Statements

Factor out jumps. For example, use

bar();
if (condition)
{
undoBar();
foo();
}

rather than

if (condition)
{
foo();
}
else
{
bar();
}

Use a profiler and good judgement to decide if undoing the bar() operation is faster than jumping.


Optimize Switch Statements

Put the most common cases first.


Avoid Expensive Operations

Addition is cheaper than multiplication and multiplication is cheaper than division. Factor out expensive operations whereever possible.


Initialize on Declaration

Whereever possible, initialize variables at the time they're declared. For example,

TMyClass myClass = data;

is faster than

TMyClass myClass;
myClass = data;

Declaration then initialization invokes the object's default constructor then its assignment operator. Initializing in the declaration invokes only its copy constructor.


Pass By Reference

Always try to pass classes by reference rather than by value. For example, use

void foo(TMyClass &myClass)

rather than

void foo(TMyClass myClass)



Delay Variable Declarations

Leave variable declarations right until the point when they're needed. Remember that when a variable is declared its constructor is called. This is wasteful if the variable is not used in the current scope.


Use 'op='

Wherever possible, use 'op=' in favour of 'op'. For example, use

myClass += value;

rather than

myClass = myClass + value;

The first version is better than the second because it avoids creating a temporary object.


Inline Small Functions

Small, performance critical functions should be inlined using the inline keyword, e.g.,

inline void foo()

This causes the compiler to duplicate the body of the function in the place it was called from. Inlining large functions can cause cache misses resulting in slower execution times.


Use Nameless Classes

Whereever possible, use nameless classes. For example,

foo(TMyClass("abc"));

is faster than

TMyClass myClass("abc");
foo(myClass);

because, in the first case, the parameter and the class share memory.

25 Signs That, Sadly, You've Grown Up

1. Your house plants are alive, and you can't smoke any of them.
2. Having sex in a twin bed is out of the question.
3. You keep more food than beer in the fridge.
4. 6:00 AM is when you get up, not when you go to bed.
5. You hear your favorite song on an elevator.
6. You watch the Weather Channel.
7. Your friends marry and divorce instead of hook up and break up.
8. You go from 130 days of vacation time to 14.
9. Jeans and a sweater no longer qualify as "dressed up."
10. You're the one calling the police because those damn kids next door won't turn down the stereo.
11. Older relatives feel comfortable telling sex jokes around you.
12. You don't know what time Taco Bell closes anymore.
13. Your car insurance goes down and your payments go up.
14. You feed your dog Science Diet instead of McDonalds leftovers.
15. Sleeping on the couch makes your back hurt.
16. You no longer take naps from noon to 6 PM.
17. Dinner and a movie is the whole date instead of the beginning of one.
18. Eating a basket of chicken wings at 3 AM would severely upset, rather than settle your stomach.
19. You go to the drug store for ibuprofen and antacid, not condoms and pregnancy tests.
20. A $4.00 bottle of wine is no longer "pretty good stuff".
21. You actually eat breakfast food at breakfast time.
22. "I just can't drink the way I used to," replaces, "I'm never going to drink that much again."
23. 90% of the time you spend in front of a computer is for real work.
24. You drink at home to save money before going to a bar.
25. You read this entire list looking desperately for one sign that doesn't apply to you and can't find one to save Your sorry old ass.

MASTERING THE INTERVIEW By Sean Bosker

The job interview is your proving ground, the place where you must demonstrate why you are the best person for the job. Making that powerful statement that you're the best of all the candidates requires the three Ps: Preparation, Presentation and Perception. When you walk into an interview, the more prepared you are, the better the chances are that you'll succeed. Memorize everything you put on your resume and cover letter and be prepared to explain each item. But you should also be ready to talk about more than just yourself. Get to know your future employer. Warren Davis, the Director of Recruiting and Employment for RadioShack, emphasizes this point. “Your resume and application are fair game. Candidates should study themselves and the company with whom they’re interviewing.” Read industry trade magazines, visit the company web site, and do a company search on Yahoo! Finance to find current news about your prospective employer. Be prepared to demonstrate what you know about the company and the industry. Michele Stagg, the Director of Human Resources at Banana Republic, says she is consistently impressed when candidates work their skills into the context of company news. “The more an informed candidate can tie past experience to the requirements of the job they are interviewing for, particularly in terms of what the company is doing, the better.” Another important part of preparation is making sure you look the part. Choosing what you wear is so important that it deserves its own article - Interview in Style. Keep in mind that you are marketing yourself to everyone you meet. The more people you leave with a good impression, the better your chances are of being remembered. Project yourself as someone who is thoughtful, helpful, and prepared. Effective presentation includes being in the right place, at the right time. If you're late for the interview, you could inadvertently tell your interviewer that you're not right for the job. With 35 years of experience in HR, Peter Ackerson, Specialist Leader at Deloitte Consulting, has been directly involved in hiring hundreds of candidates. When it comes to job interviews, he's seen it all. “There’s nothing worse than getting a call from someone who is hung up in traffic or went to the wrong office,” he explains. Once you arrive, introduce yourself to the receptionist and turn off that cell phone. “Having a phone go off during an interview is a real turn off,” says Ackerson. According to psychologist Albert Mehrabian, more than half of our communication is nonverbal or body language. Stagg agrees. “Body language is exceptionally important. Positive, upright and open body language shows self confidence and interest.” During introductions give a firm handshake and then take a seat facing the interviewer. When you go over your resume focus on your accomplishments instead of reiterating job descriptions. Presenting yourself as an active problem solver will show an employer that you can contribute and succeed in the role. Stagg agrees that this technique can make a fantastic impact. “Give very specific examples of your qualifications. If you have qualifications in financial analysis, give examples of projects you worked on where your analysis was necessary. Describe your experiences that tie in to your skills or qualifications. Even better, tell me how those will help you meet the requirements of the role you might fill in our company.”

The best way to know if your interviewer is getting what he needs is to ask questions. Susan Vobejda, the VP of Marketing at HotJobs elaborates, “When your interviewer asks you a complicated question, don’t launch into your answer straightaway. Make certain you understand what is being asked." A clarifying question, or restating the question in your own words saves you from wasting your interviewer’s time, and demonstrates that your are a careful listener. Asking the right questions can also demonstrate your ability to think strategically, and help you decide if the position is right for you. To that end, Stagg suggests ending the interview with this question: “What are you looking for in a candidate to fill this role?” If the answer turns out to be something that doesn’t match your expectations, then you need to speak up. Many candidates are so intimidated by the interview, they forget that the interviewer has a stake in seeing the candidate succeed. Peter Ackerson describes his attitude going into an interview as one of “hopeful skepticism.” They don’t want you to fail; they want you to show them why you will succeed with their company. The sooner they hire you, the sooner the search can end.

18 ways to stay focused at work

Here’s a list of 18 ways to stay focused at work I picked up from some article doing the rounds..

1. Write out a daily task list and plan your day. There’s nothing like a task list sitting next to you to keep you focused. When you have a list of the things you need to accomplish in a day, having that close to you constantly reminding you of what needs to be done is a great way of keeping on track.
2. Allocate time slots colleagues can interrupt you. In a busy work place, people are moving and talking all the time. If you play a role in a team where others need to interact with you, try allocating a time slot they can interrupt you. Instead of having people stop by your desk every 10 mins and asking you questions, let them know of a time in the day, say between 2-4pm you can be interrupted. At all other times, you can really get some work done.
3. Apply time boxing. In a previous article, I wrote about the benefits of time boxing. Instead of working at something till it is done, try working on it for a limited period, say 30 mins. By that time, the task is either completed or you allocate another time slot, perhaps in another day, to pick it up again. This way, you keep your work fresh and engaging throughout the entire working day.
4. Setup filters in your email. If you spend a lot of your time communicating and planning in front of your computer, chances are you deal with emails on a frequent basis. Setting up filters in your email client can be a great way of sorting out what’s important and urgent from personal stuff which can wait. Instead of dealing with a single Inbox with hundreds of unread email, you only need to deal with smaller folders categorised by project, priority and context.
5. Do not check personal email in the morning. Checking personal emails can be very distracting even with filters setup. This is especially true when your friends send you links to interesting articles, jokes or videos on YouTube. If you’re not careful, you can get side tracked for hours. Instead of checking your personal email as soon as you get in, try starting work straight away. This will build up some momentum as you ease into your work day. You should check your personal email only after you have a few tasks completed or underway. Also, if you don’t want to perpetuate a particular distracting email thread, just don’t reply to it until after work.
6. Set your IM status. If you use Instant Messenger, when you don’t want to be disturbed, make use of the status and set yourself as being away or busy. Your friends and colleagues will honour that. They can either send you an email or look you up later when you aren’t as busy.
7. Listen to the right types of music. Music is a great way of settling into the working routine. In addition, having music can drown out office noises like printers and background chattering. Be careful though, depending on personal preference, some types of music are not particularly conducive to productive work. For me, I can’t work when listening to songs with lots of lyrics because the words interrupt my thinking process.
8. Use the headphones but leave the music off. Some people prefer to have absolute silence when working. I think that also depends on what kind of work you are doing. If you’re doing some serious planning or something computational, having music blasting in your ears may not be the best thing for keeping focused. Try using headphones or ear plugs to block out the background noise but leave the music off.
9. Fill up a water bottle. Keeping yourself hydrated is pretty important for all sorts of health reasons. Instead of going to the water cooler with your glass every hour, try filling up a water bottle at the start of the day. This does a couple of things - firstly, it limits the starts/stops associated every time you get up for water and secondly, it avoids being sucked into lengthy discussions around the water cooler.
10. Find the best time to do repetitive and boring tasks. No matter how much you try to avoid it, you’re going to have to face doing things which are either repetitive or boring. For these tasks, I find it is best to choose a time in the day to work on them. For example, I’m more alert at the start of the day, so it’s better to work on things which require brain power early. Working on boring tasks that can be done via auto-pilot are better left towards the end of the day when I’m usually tired.
11. Bring your lunch and have it at your desk. I’m not suggesting you do this every day, but if you really have to focus and are trying to meet a deadline, having your lunch at your desk really helps. The normal one hour lunch break can really interrupt any momentum you might have built up during the morning. I find when I’m eating lunch at my desk, my lunch breaks are shorter and I can get through a few emails while I’m eating. After I’m done, I’m straight back working on the next task.
12. Don’t make long personal calls. Most of us have a good separation between our working and personal lives (or a least try to). I think we can all agree we should avoid having work intrude on our personal time as much as possible. The reverse of this also applies. Try limiting the time you spend doing personal things during work as they can be distracting and draining on your motivation. For example, you do not really want to be thinking about your weekend away with your spouse when you really need to get things done.
13. Clean up your desk. Some of you may have desks which can only be described as ordered chaos. That’s not necessarily a bad thing as long as you can find what you need without too much digging around. However, if you can’t, I suggest cleaning up your desk. That doesn’t mean having an empty desk, it just means having neat stacks of paper, all filed in the correct location. It also helps tremendously having all the things you need easily within arms reach. For example, if you need a place to write, having your pen and notepad close by and easily accessible is incredibly useful.
14. Get a good chair. If you sit for long hours at your desk and I’m sure some of you do, you might find it helpful to get a good chair. I find it’s pretty hard to stay focused when my neck and back are sore because I have a bad setup at my desk. A good chair can eliminate this, allowing you to work for long stretches without breaks and physical distractions.
15. Use shortcuts on your computer. If you find you do the same thing with your computer more than once throughout the day, you might find it helpful to look for ways in which you can do them without too much manual repetition. For example, if there’s a project folder you access all the time, try adding a shortcut to your Explorer or Finder so you can get access to it with a single click, instead of expanding folder after folder in the tree panel.
16. Close programs you’re not using. As a software engineer, I use a lot of programs important to my work. However, in most cases, I only need a few applications open at the same time. Instead of Alt-Tabbing constantly and fighting the computer to locate the program you need, try only having the applications you need open. Close everything else. For example, if you have already located a file and no longer need a particular Explorer or Finder instance open, close it. There’s no reason to leave it around at all.
17. Limit time on Digg, Delicious, news sites and blogs. I don’t think I need to say too much about this. There are so many sites on the Internet worth looking at, including this site . Digg, Delicious, news and blogs are great from an interest perspective, but they can really take you away from the work you should be working on. Try to limit going to these sites during the working day. If you really have to, try doing it during your lunch time. No, you don’t need to have your finger on the pulse every single minute of the day…
18. Change your mindset and make work fun. For me, I find it difficult to stay focused on doing things I’m not by nature interested in doing. In most cases, there’s probably nothing I can do about it. However, be mindful of the fact that your perception of work is something you can control. For my last tip here, I suggest you try changing your mindset or turning work into a game. An unfocused mind, is an unchallenged mind. So make things fun!

I hope these tips will take you closer to more focused and productive work days. If you are still in need for more tips about staying focused, you can take a look at a previous blockbuster smash hit article I wrote entitled 11 ways of staying focused. In that article, I approached the issue from a top down, rather than bottom up perspective.

Ok, good luck! If you like this article, tell your friends, Digg it or add it to your Delicious bookmarks.

Hey, what are you still doing here? Get back to work!

Volcano and Aurora in Iceland (Amazing Image)

17 Pithy Insights For Startup Founders

1. Seek transparency and understanding with your partners early. Issues get harder as time passes


2. Startup founders work long hours for a reason. There’s more work than there are people. If you’re seeking balance, seek it elsewhere.


3. Bad customers will drain you of passion. Really bad customers will drain you of both passion and profits. Unfortunately, most bad customers will degenerate into really bad customers if you don’t do something about it.

4. If you’re changing direction ften, worry a little. If you’re changing people often, worry a lot.

5. It’s lonely at the top, but even lonelier at the bottom. In the early days of a startup, hardly anyone wants to talk to you (except some desperate vendors).

6. Eventually, your product will need to work and do something useful. No amount of marketing or strategy will get you around this.

7. At the end of each day, ask yourself: “Did the product get better for customers today?”. If you don’t have a good answer, stay up until you do.

8. Until you are profitable, time is working against you. Once you are profitable, time is on your side.

9. Learn to take calculated risks. The market rarely rewards safe bets.

10. To improve the quality of your output, improve the quality if your inputs. Read, converse and connect with the right people.


11. Force yourself to write, as it will force you to think.

12. At least once every year or so, your startup will almost die.

13. The problem you solve should be ugly. The solution you build should be beautiful.

14. Even the most successful startup ideas had 100 reasons not to pursue them. There is no perfect idea.

15. If the pain doesn’t kill you, it just hurts a lot.

16. You choose your destiny, because you choose your team.

17. Be who you are. Do what you love. Join people you like.

How to restore a hacked Linux server July 17, 2006

Posted by - Marius - in : Linux, Security , trackback

Every sysadmin will try its best to secure the system/s he is managing. Hopefully you never had to restore your own system from a compromise and you will not have to do this in the future. Working on several projects to restore a compromised Linux system for various clients, I have developed a set of rules that others might find useful in similar situations. The type of hacks encountered can be very variate and you might see very different ones than the one I will present, or I have seen live, but even so, this rules might be used as a starting point to develop your own recovery plan.

In most cases if you have a system compromise at root level, you will hear that you have to fully reinstall the system and start fresh because it will be very hard to remove all the hidden files the attacker has placed on the system. This is completely true and if you can afford to do this then you should do it. Still even in this case the compromised system contains valuable information that can be used to understand the attack and prevent it in the future.

Here is a short overview of the steps that I will present:

* Don’t panic. Keep your calm and develop a plan of actions
* Disconnect the system from the network
* Discover the method used to compromise the system
* Stop all the attacker scripts and remove his files
* Restore not affected services
* Fix the problem that caused the compromise
* Restore the affected services
* Monitor the system

Don’t panic. Keep your calm and develop a plan of actions

Ok. You have just found out that you have to restore a hacked system. My first suggestion is to remain calm. Don’t rush and do something you will regret later. Why? Of course you will have to take action as soon as possible, but you can assume that the compromise is probably active for some time and if you act in second 1 or minute 10 this will probably not make much of a difference. If you have experience with such situations and have a proper plan in your mind, go for it, and don’t waste any time. If not, just relax, take 5 minutes to think about what you should do and how to solve this problem.
Example of bad actions during this time: you will rush and kill all the running scripts the attacker has launched and then have a timeout when you will think what to do next… In this time the attacker might see you have discovered him (for example from his irc bot, etc.) and might become upset and clean up the system for you…
Of course you should not go on with your planned trip and take care of this when you get back, I am just saying to use 5-10 minutes to think on this and develop a short action plan. There should be no timeout in your actions and you should always know what is the next step.
Disconnect the system from the network

This might not always be possible. But if you have physical access to the system or even if you are remotely on a system in a datacenter that provides a way to connect from a console (either a regular remote console, or a KVM, or a DRAC card in Dell servers, etc.), then this should be the next step. Connect to the remote console and bring down the network interface.
If you don’t have a remote console, here are some other ideas: you might be able to rent a KVM for a limited time from your datacenter, or you might have to write some iptables rules to block any kind of access besides your own IP.
After this your system will appear down to everyone, including the attacker that will see that the system is completely down.
Discover the method used to compromise the system

This step in my opinion is the most important one and you should not proceed any further until you have a proper answer to the question: “How did the attacker get in?” This step will be probably the most time consuming as the type of attacks can be quite variate. Still if you don’t find out how the attacker got in, then you will risk that you place the system online and he will be able to compromise the system in a matter of minutes. And this time he might not be so nice and you will not have anything to restore… So even if there is not a general method for this, here are some ideas to get you started:

Depending from what tools you have already configured, you need to identify the files uploaded on the system:

* if you have a system like tripwire configured use it to find out what files where added/changed.
* if you don’t have any such system installed, you might have to use the find command to search for the files newer than x days that were added to the system (also changed files in the respective interval).

Who owns the uploaded files?

* finding out the owner of the files will probably show you what application was used to get in. For example files uploaded as the web user will indicate that the web service was used to get in.

Investigate the uploaded files.

* the files that were uploaded on the system might provide valuable information about the attack. For example the attacker might use the same exploit to attack other systems from your compromised server. This can quickly show you what exploit he is using.

Get as much information from the running scripts launched by the attacker.

* as you have seen I have not recommended to stop yet the running scripts that the attacker might have launched. Why? Because they contain invaluable information to identify the attack. Use lsof on them (lsof -p PID) to see useful details. Where are they located? what user owns them? You might find the source of the attack from this information.

Use Rootkit detection tools.

* you might want to run some rootkit detections tools like rkhunter or chkrootkit to quickly identify common attacks.

Investigate system logs.

* with the information gathered by now you might reduce the size of the log information you have to investigate.

Hopefully you have found the source of the attack by now. Again this is very dependent of the type of attack. The most common one you might see these days is an exploit using a vulnerable web application and an attacker that will launch various scripts (irc bots, scanning tools, attacks on other systems, etc.). Still you might see something different like an attacker not launching any script, loading kernel modules to hide its tracks, to make it more difficult to identify or even see the compromise.
Stop all the attacker scripts and remove his files

Once you have identified the cause of the attack you can safely kill all the running scripts launched by the attacker and remove all his files (save them in a different location for further investigation). At this point we no longer need the scripts running as we got the information we could find from them. The system is still unavailable at this point and no service is available to the world.

Don’t forget to clean-up also the locations that the attacker might have entered to start his scripts on system reboot. Look in init scripts, rc.local, cron tabs for this.
Restore not affected services

Once we know the service used for the attack we can stop it and restore the network connection and all the unaffected services the system might provide. For example if the web server was used to get in, we can stop it, and restore other services like mail, dns, to minimize the downtime of the system.
Fix the problem that caused the compromise

Before starting the service used to compromise the system you should fix the problem so this will not happen again once the service is open to the public… Depending on the problem this might involve: patching a vulnerable daemon, upgrading a vulnerable web application (or temporary disable it), writing some special rulers to block it (for ex. mod_security rules might help in case of no patch available for a web application), etc.
Restore the affected services

Once you have fixed the problem you can restart the service used to get inside the system.
Monitor the system

Now is the time to monitor closely the system and see if the fix you have implemented is working. Most certainly the attacker will try to get in again as he will see he has ‘lost’ the system. If you notice any problem stop the service at once and reiterate again to the step to fix the problem (stop the service, fix it, restore it).
Conclusion

These steps are obviously not usable all the time because of the variety of attacks you might encounter, but they can be used as a baseline to develop your own plan of actions. Again in such situations, keep your calm, don’t rush, and work to restore the system based on a clear set of steps.
If you had similar experiences please feel free to share your own tips to help others that might find themselves in such a situation.

What?! Rupert can't leave! He's the only one who know the SCLABE system!

Which is precisely why he's leaving. Poor Rupert has been trying to spend more time with the rest of the .NET team doing cool stuff, but he keeps getting dragged off to fix the old SCLABE* system.

Any time a tweak is required, Rupert's manager gets Rupert to do it, because he's been here the longest, knows it the most, and can fix it the quickest. And he knows exactly why an extra column is added on alternate weekends - a previous customer was having problems with their invoicing, so this was introduced to get round it.

But now Rupert's off, all his manager can think to do is get him to document what he knows about SCLABE. The thing is, Rupert's motivation percentage is equal to the number of days left at the company; today there are 17 days left, so he is 17% motivated. So Rupert adds a table of contents to the document, changes the headers and footers, tweaks "Heading 2" so it has 6pt spacing before and 12pt afterwards. He writes about the objectives of the system, describes the main areas of the system as an overview, and spends the rest of the day trying to get Visio to draw something resembling a diagram of the system.

In other words, he's wasting everyone's time.

To be fair, he's asked what he needs to write, and the answer was "enough for someone else to take over from you". Well, to take over, they need to know what the thing does, right? But that doesn't really help the next guy (who had better not be me) when the next tweak is required. There isn't any documentation that will help. There can't possibly be. Why? Because it isn't Rupert's knowledge that needs to be passed on, it's his experience. And that can't be passed on in a document. I can read a document telling me how to do a backside footplant wallride, but that doesn't mean I understand it, let alone have any success with it.

So what to do? For Rupert's boss, not a lot, except learn for next time. Rupert's experience needs to be passed on, which can only be achieved by showing someone. Although I've never been a manager, if I was stuck managing SCLABE, I would find a volunteer or two (willing or otherwise) to learn from Rupert. When a tweak is required, the volunteer, let's call her Ingrid, would sit at the keyboard, with Rupert next to her. Rupert would tell her how to navigate through the code, what to look for, how to implement the change, how to test it, where to deploy it to, and everything else, without actually doing it himself. Rupert would answer questions, and sometimes withhold information to make sure Ingrid thought about what she was doing. She would either work it out, or have to ask the right questions.

In this way, Ingrid would actually experience the system, and start to understand it. After a few of these sessions, she may be able to fix some things by herself. This would free up Rupert to get on with the cool AJAX stuff. If Rupert spent time with others in the team, then it would seem fair, and people could take turns. If Rupert left, then SCLABE fixes wouldn't be a major trauma, as someone else could do it. Rupert would be less likely to leave anyway, as he's now a confident, successful mentor, and even has time to write some Ruby on skis.


* SCLABE is a fictional legacy system written in COBOL on an AS/400. Rupert is a fictional developer, whose resemblance to anyone you know is the whole point of this exercise.

Confessions of an IT pro: My nine biggest professional blunders

July 12, 2006


Takeaway:
We've all had at least one or two embarrassing moments on the job, whether they involved inadvertently wreaking havoc on a system, making a social gaffe, or mishandling a project. IT pro Becky Roberts decided to come clean and share her worst career moments--along with the lessons she took away from each experience.


This article is also available as a PDF download.

Over the past 16 years of being paid to make computers and people work together in perfect harmony, I have collected a number of incidents that make me wince and blush in embarrassment when I think of them. The mistakes I've made fall roughly into three categories: technical, political, and career management. Here, in no particular order, are my most outstanding screw-ups and the lessons I have, I hope, learned.

#1: Accidentally deleting the VP's files without having a backup. I don't even remember how I did this. Not only did I delete the files, but it wasn't until the format was in process that I realized my mistake. I spent a nervous 30 minutes deciding how to deal with the situation. Should I lie and try to shift the blame? I couldn't blame any other person, as I was the whole IT department. Should I just return his computer and act dumb? "Well, the files were there when I gave the computer to you." Nothing I could think up felt right. In the end, I simply walked into his office, handed him his computer,and confessed, "I have screwed up. I deleted all your files and have no means of getting them back. It was completely my fault." Silence. Then: "Okay. Please be more careful in future." That was it. That was all he said. I could've kissed his feet, my feeling of relief matched only by the feeling of abject stupidity and incompetence.

Lesson learned? BACK UP BACK UP BACK-UP. Never delete, move, modify, upgrade, update, patch, flash, or format without making at least one backup. I have never knowingly lost a file since.

#2: Modifying the payroll program so no one received OT. This was at a ceramics factory in the Midwest. Payroll consisted of a Basic program on a minicomputer. A new rule for calculating overtime was to go into effect, and I was given the assignment of making the appropriate modification. I made the required change on a copy of the live program and did a walkthrough. The logic seemed flawless. I showed the program to my boss and he gave it his blessing. He said that he would put it into production at the start of the next pay period. Alarmed, I asked if we had a test system. I had been working for the company for just two months and was not familiar with the infrastructure. He grinned and said we didn't have one.

Two weeks later, a virtual riot broke out as the employees opened their checks to discover the awful truth: no overtime, none, nil, nothing, nada. My boss said I could go home early as I was looking horrifically pale.

Lesson learned? This is a tough one. Obviously, I had made a programming error and needed to improve my skills. But should I have realized that my abilities as a programmer weren't up to the task and tried to refuse the assignment? I did express my qualms about putting an untested program into production, but perhaps I should've done so more forcefully. Probably the most important lesson I learned from this incident is to ask very detailed questions about the infrastructure when interviewing for a new position and try to identify and avoid companies that don't support best practices.

#3: Going live on a demo copy of Exchange. I was a new hire into a two-person IT department and given the project of installing MS Exchange. The company was using a text-based freeware e-mail system, but it was so difficult to use there was no mail to migrate, so this could be a simple install.

I obtained a demo copy of Exchange, installed and configured it, and selected a small group of test users. I set up training for all users who were interested and soon expanded the "test" group to include all the employees. As days turned into weeks, the amount of data being stored grew rapidly. Users created folders and archives and entered their contacts. I ordered the appropriate Exchange licenses, assuming that they could be applied to the demo version. Finding no way to apply the license, I called Microsoft only to learn the heart-stopping truth that there was no way to apply the license, and worse, after 90 days the demo system would simply cease to function. This was day 88. Needless to say, I spent the next 48 hours on the phone with Microsoft tech support setting up a new server to replace the demo one, migrating data, and changing client configuration. It was one big, panicky mess. The only good to come out of this situation was that it turned into a great opportunity for learning.

Most salient of the many lessons learned?

* Don't go live on a demo application without first checking that it doesn't self-destruct on its expiration date.
* Make a project plan and stick to it. I should not have expanded the test group to the whole company.
* Improve communications with the users. They should not have been allowed to use the test system to the extent that they became dependent on it.
* Insist on being allowed to attend training before assuming responsibility for a new system.

#4: Taking backups for granted. Server backups were my sole responsibility. I set up the backup server and religiously changed tapes every day. The very first time a user needed a file restored, I discovered that the folder containing the file had not been successfully backed up for more than three months. Worse, the particular file in question had never been backed up. Suppressing the urge to blame the failure on a software fault rather than my own negligence, I went to the user and apologized. He was not at all impressed.

Lessons learned?
* Never take backups for granted.
* Check backup logs in detail daily.
* Practice restores on a routine basis.
* Set up a schedule for reviewing the backup strategy.

#5: Possessing unique knowledge. Although it may seem that possessing unique knowledge and skills within a company should offer some job security, not only is this a delusion but the possession of such knowledge can also become a burden that negatively affects your personal life. On several occasions throughout my career, I have allowed myself to be in just such a situation, where my failure to share my knowledge led to interrupted weekends with the family, phone calls at all hours of the night, phone calls while on vacation, and my favorite, a phone call to the ICU less than six hours after brain surgery.

Lesson learned? Document, share, and train. Sometimes, in a small company or during an implementation, it can be impossible not to possess unique knowledge. But staying aware and alert to the danger can minimize this risk. When provided with the appropriate documentation, it is surprising what even a relatively unskilled alternate can achieve in a crisis.

#6: Creating inadequate self-documentation. In addition to failing to document procedures for the purpose of sharing knowledge, I have shot myself in the foot on more than one occasion by failing to document a procedure or configuration I was sure I would remember. While working under pressure, with users breathing down my neck, it's all to easy to take shortcuts and make worthless self-promises to document later, when the crisis is over. Unfortunately, the next crisis hits, and then the next, and soon the documentation is forgotten until it's needed in the midst of yet another crisis.

Lesson learned? This lesson hasn't been fully learned yet. I've started taking screen shots and brief notes while working under pressure, but I still procrastinate in doing a full write-up after the crisis is over.

#7: Failing to establish the extent of my authority at the start of projects. Over the years, I have been the project manager for a variety of implementations, upgrades, and migrations. With one exception, each project was successful, in that the defined objectives were met by the deadline. But the process by which this was achieved was not necessarily the most efficient or the least stressful.

I hadn't seen the need to establish my authority at the start of a project as, until recently, all the members of each team had respected it. On a more recent project, in a very hierarchically structured company, my team consisted of a few peers, my boss, a couple of managers, and a VP. A more experienced PM suggested that I call a meeting specifically to determine exactly how much authority I had over the members of my team. I thought this was unnecessary and soon began to suffer as a result.

The project had various critical path items that had to be complete by specific dates, but despite my fervid attempts to communicate this to the team members responsible for the items, they would frequently thwart me: "I'm taking Friday off. My boss approved it." "I can't do that today; I need to do this." I had all the responsibility for the success of the project but none of the authority necessary to ensure its success. As a result, it was my first project not to meet the deadline.

Lessons learned? The first step of any project I am managing will be to establish what authority I am to be accorded. And if it's not sufficient to guarantee the success of the project, I'll have the temerity to either ask for more or suggest that a more senior project manager be appointed.

#8: Sending an insensitive e-mail to an employee. I received an e-mail from an employee detailing an extensive list of problems she was experiencing with her computer. Without any malicious intention, I shot off a reply saying that it sounded like new computer time. Thinking no more about it, I added her problems to my list of tasks for the day. A few minutes later, I was summoned into an emergency meeting with my supervisor and his boss. As I walked in the door, I was handed a printout of my e-mail reply to the employee and told to explain myself.

Thoroughly confused, I stated that I didn't understand what was going on. My boss explained that the employee was extremely offended by my e-mail as she had interpreted my levity as a refusal to take her problems seriously or help her. I was shocked that a few innocent words, an attempt at a lame joke, had been so drastically misunderstood. I was instructed to apologize to the user and fix her problems immediately.

Lessons learned?

* Do not attempt to be funny or clever in e-mail; play it completely straight.
* Have a formalized procedure for handling requests for help.
* Always inform users of when they can expect their problems to be addressed upon receipt of their request for help.

#9: Not taking advantage of free training and certification opportunities. Each time I have updated my resume in preparation for seeking a new job, I've regretted not having formal certifications to accompany my experience. This has been particularly irritating when the company I am trying to leave has a policy of paying for any classes the employees want to take, whether they're relevant to the business or not. It's kept me from applying to several jobs I was otherwise qualified for simply because they required possession of particular certifications.

Lessons learned? Take advantage of all free training opportunities, even if they have to be pursued out of business hours.

Help With The College To Career Transition

Interesting article for graduating students in search of jobs.. and a career..

Changing from a career as a college student to the dreaded career in “the real world” leaves many students in somewhat of a culture shock. Many college students have an internship or two under their belt by the time they get to college and I highly recommend that to ease the transition.

Here are some things that you can realize or change as a college student that will help you in moving to a 9 to 5:

1. Change doesn’t come easy
Most college students come out thinking they will fix everything in a company. Keep this attitude but be realistic. Even if the way something is done now is inefficient, change is a big deal. People don’t like to change because they have to re-learn or break a habit. There is also usually a bigger picture than you don’t yet know. Just because it should change doesn’t mean it will.
2. Connections often trump performance
You will experience this especially in your job search. The easiest way to get a job is not submitting your resume online, but through someone on the inside. You are also going to see this in your superiors and co-workers. Your superior may not be as qualified or knowledgeable, but they know more people than you. Of course connections without good performance backing you up will catch up to you.
3. Be a nerd, but with social skills
Nerds are not hugely succesful, nerds with social skills are successful. Unless you invent time travel, how well you can talk to a computer doesn’t matter if you can’t also talk to superiors, co-workers, investors and customers.
4. Keep it simple
Many students try to impress with essay emails or big words. Emails should reflect the way you would explain in person. Long emails get ignored or skimmed, so keep them short and/or bulleted. Don’t make me get a dictionary or read a novel.
5. Be casual, yet professional
You will not talk work all the time. Share stories to build relationships, but learn what to talk about with different people. You won’t share the same stories or detail with superiors as you do peers. Even with peers it is possible to go to far.
6. Use your first job experience
More than likely your first job is not where you will retire. You need that job to get experience, but it doesn’t have to be your life’s calling. Use what you learn to find out what it is you do want to do for the rest of your life.
7. Maintain an attitude of innovation
While this may seem to contradict some of what I said, maintain an attitude of bringing innovation. The routine of working can dull your creativity, but people don’t get promoted (usually) for consistently meeting expectations. Bringing innovation will exceed expectations, so maintain your “change the world” attitude, but don’t expect it to happen tomorrow.

find .. linux

CLI Magic: Searching with find

Monday July 10, 2006 (08:01 AM GMT)

By: Paul Hudson and Andrew Hudson

The find command is one of the darkest and least understood areas of Linux, but it is also one of the most powerful. The biggest problem with find is that it has more options than most people can remember -- it truly is capable of doing most things you could want.

Admittedly, the find command does not help itself by using X-style parameters. The Unix standard is -c, -s, and so on, whereas the GNU standard is --dosomething, --mooby, and so forth. X-style parameters merge the two by having words preceded by only one dash. The most basic usage is this:

find -name "*.txt"

That query searches the current directory and all subdirectories for files that end in .txt. The previous search finds files ending in .txt but not .TXT, .Txt, or other case variations. To search without case sensitivity, use -iname instead of -name. You can optionally specify where the search should start before the -name parameter, like this:

find /home -name "*.txt"

Another useful test is -size, which lets you specify how big the files should be to match. You can specify your size in kilobytes and optionally also use + or - to specify greater than or less than. For example:

 find /home -name "*.txt" -size 100k 

 find /home -name "*.txt" -size +100k 

 find /home -name "*.txt" -size -100k 

The first brings up files of exactly 100KB, the second only files greater than 100KB, and the last only files less than 100KB.

The -user option enables you to specify the user that owns the files you are looking for. So, to search for all files in /home that end with .txt, are under 100KB, and are owned by user paul, you would use this:

find /home -name "*.txt" -size -100k -user paul

You can flip any of the conditions by specifying -not before them. For example, you can add a -not before -user paul to find matching files owned by everyone but paul:

find /home -name "*.txt" -size -100k -not -user paul

You can add as many -not parameters as you need, even using -not -not to cancel each other out! (Yes, that is pointless.) Keep in mind, though, that -not -size -100k is essentially equivalent to -size +100k, with the exception that the former will match files of exactly 100KB whereas the latter will not.

You can use -perm to specify which permissions a file should have for it to be matched. This is tricky, so read carefully. The permissions are specified in the same way as with the chmod command: u for user, g for group, o for others, r for read, w for write, and x for execute. However, before you give the permissions, you need to specify a plus, a minus, or a blank space. If you specify neither a plus nor a minus, the files must exactly match the mode you give. If you specify -, the files must match all the modes you specify. If you specify +, the files must match any the modes you specify. Confused yet?

The confusion can be cleared up with some examples. This next command finds all files that have permission o=r (readable for other users). Notice that if you remove the -name parameter, it is equivalent to * because all filenames are matched.

find /home -perm -o=r

Any files that have o=r set are returned from that query. Those files also might have u=rw and other permissions, but as long as they have o=r, they will match. This next query matches all files that have o=rw set:

find /home -perm -o=rw

However, that query does not match files that are o=r or o=w. To be matched, a file must be readable and writeable by other users. If you want to match readable or writeable (or both), you need to use +, like this:

find /home -perm +o=rw

Similarly, this next query matches files that are only readable by user, group, and others:

find /home -perm -ugo=r

Whereas this query matches files as long as they are readable by the user, or by the group, or by others, or by any combination of the three:

find /home -perm +ugo=r

If you use neither + nor -, you are specifying the exact permissions to search for. For example, the next query searches for files that are readable by user, group, and others but not writeable or executable by anyone:

find /home -perm ugo=r

You can be as specific as you need to be with the permissions. For example, this query finds all files that are readable for the user, group, and others and writeable by the user:

find /home -perm ugo=r,u=w

To find files that are not readable by others, use the -not condition, like this:

find /home -not -perm +o=r

Now, on to the most advanced aspect of the find command: the -exec parameter. This enables you to execute an external program each time a match is made, passing in the name of the matched file wherever you want it. This has very specific syntax: Your command and its parameters should follow immediately after -exec, terminated by \;. You can insert the filename match at any point using {} (an opening and a closing brace side by side).

So, you can match all text files on the entire system (that is, searching recursively from / rather than from /home as in our previous examples) over 10KB, owned by paul, that are not readable by other users, and then use chmod to enable reading, like this:

find / -name "*.txt" -size +10k -user paul -not -perm +o=r -exec chmod o+r {} \;

When you type your own -exec parameters, be sure to include a space before \;. Otherwise, you might see an error such as missing argument to ´-exec'.

Do you see now why some people think the find command is scary? Many people learn just enough about find to be able to use it in a very basic way, but hopefully you will see how much it can do if you give it a chance.

11 "Don't-Tell-the-Wife" Secrets All Men Keep --- By Ty Wenger

I was in the ninth grade when I learned a vital lesson about love. My girlfriend at the time, Amy, was stunningly cute, frighteningly smart and armed with a seemingly endless supply of form-fitting angora sweaters. And me? Let's just say I was an adolescent Chris Robinson to her budding Kate Hudson -- and well aware of my good fortune.
More from Redbook

* "He cheated. Now what?"
* Guy Behavior 101
* "The best marriage advice I ever got."
* 12 Things Men Really Find Romantic
* Sex Secrets of Really Happy Couples

Then one day, as we stood in line for a movie at the mall, Simone Shaw, junior high prom queen, sauntered by. Suddenly Amy turned to me. "Were you looking at her?" she asked. "Do you think she's pretty?"

My mind reeled. Of course I was looking at her! Of course she was pretty! My God, she was Simone Shaw! I paused for a second, then decided to play it straight.

"Well, yeah," I chortled.

Five days later our breakup hit the tabloids (a.k.a. the lunchroom).

There comes a time in every man's life when he discovers the value of hiding the grosser parts of his nature. He starts reciting the sweet nothings you long to hear: "No, honey, I play golf for the exercise." "No, honey, I think you're a great driver." "No, honey, I wasn't looking at that coed washing the car in the rain."

We're not lying, exactly. We're just making things...easier. But Glenn Good, Ph.D., a relationship counselor, disagrees, and maybe he has a point. "These white lies are pretty innocent, but they can turn confusing," he says. "Many women think, If he's lying about himself, is he also lying about something else? Is he having an affair? To establish trust you have to tell the truth about the innocuous stuff."

And so, in the interest of uniting the sexes, we've scoured the country for guys willing to share the private truths they wouldn't normally confess. Some are a bit crass. Some you've always suspected. Some are surprisingly sweet. (Guys don't like to reveal the mushy stuff, either.) But read on, and you may discover that the truth about men isn't all that ugly.

Secret #1: Yes, we fall in lust 10 times a day -- but it doesn't mean we want to leave you

If the oldest question in history is "What's for dinner?" the second oldest is "Were you looking at her?" The answer: Yes -- yes, we were. If you're sure your man doesn't look, it only means he possesses acute peripheral vision.

"When a woman walks by, even if I'm with my girlfriend, my vision picks it up," says Doug LaFlamme, 28, of Laguna Hills, California. "I fight the urge to look, but I just have to. I'm really in trouble if the woman walking by has a low-cut top on."

Granted, we men are well aware that our sizing up the produce doesn't sit well with you, given that we've already gone through the checkout line together. But our passing glances pose no threat.

"It's not that I want to make a move on her," says LaFlamme. "Looking at other women is like a radar that just won't turn off."

Secret #2: We actually do play golf to get away from you

More than 21 million American men play at least one round of golf a year; of those, an astounding 75 percent regularly shoot worse than 90 strokes a round. In other words, they stink. The point is this: "Going golfing" is not really about golf. It's about you, the house, the kids -- and the absence thereof.

"I certainly don't play because I find it relaxing and enjoyable," admits Roland Buckingham, 32, of Lewes, Delaware, whose usual golf score of 105 is a far-from-soothing figure. "As a matter of fact, sometimes by the fourth hole I wish I were back at the house with the kids screaming. But any time I leave the house and don't invite my wife or kids -- whether it's for golf or bowling or picking up roadkill -- I'm just getting away."

Secret #3: We're unnerved by the notion of commitment, even after we've made one to you

This is a dicey one, so first things first: We love you to death. We think you're fantastic. Most of the time we're absolutely thrilled that we've made a lifelong vow of fidelity to you in front of our families, our friends and an expensive videographer.

But most of us didn't spend our formative years thinking, "Gosh, I just can't wait to settle down with a nice girl so we can grow old together." Instead we were obsessed with how many women who resembled Britney Spears we could have sex with before we turned 30. Generally it takes us a few years (or decades) to fully perish that thought.

Secret #4: Earning money makes us feel important

In more than 7.4 million U.S. marriages, the wife earns more than the husband -- almost double the number in 1981. This of course is a terrific development for women in the workplace and warmly embraced by all American men, right? Right?

Yeah, well, that's what we tell you. But we're shallow, competitive egomaniacs. You don't think it gets under our skin if our woman's bringing home more bacon than we are -- and frying it up in a pan?

"My wife and I are both reporters at the same newspaper," says Jeffrey Newton, 33, of Fayetteville, South Carolina. "Five years into our marriage I still check her pay stub to see how much more an hour I make than she does. And because she works harder, she keeps closing the gap."

Secret #5: Though we often protest, we actually enjoy fixing things around the house

I risk being shunned at the local bar if this magazine finds its way there, because few charades are as beloved by guys as this one. To hear us talk, the Bataan Death March beats grouting that bathroom shower. And, as 30-year-old Ed Powers of Chicago admits, it's a shameless lie. "In truth, it's rewarding to tinker with and fix something that, without us, would remain broken forever," he says. Plus we get to use tools.

"The reason we don't share this information," Powers adds, "is that most women don't differentiate between taking out the trash and fixing that broken hinge; to them, both are tasks we need to get done over the weekend, preferably during the Bears game. But we want the use-your-hands, think-about-the-steps-in-the-process, home-repair opportunity, not the repetitive, no-possibility-of-a-compliment, mind-dulling, purely physical task." There. Secret's out.

Secret #6: We like it when you mother us, but we're terrified that you'll become your mother

With apologies to Sigmund Freud, Gloria Steinem -- and my mother-in-law.

Secret #7: Every year we love you more

Sure, we look like adults. We own a few suits. We can probably order wine without giggling. But although we resemble our father when he was our age, we still feel like that 4-year-old clutching his pant leg.

With that much room left on our emotional-growth charts, we sense we've only begun to admire you in the ways we will when we're 40, 50 and -- God forbid -- 60. We can't explain this to you, because it would probably come out sounding like we don't love you now.

"It took at least a year before I really started to appreciate my wife for something other than just great sex; and I didn't discover her mind fully until the third year we were married," says Newton. "But the older and wiser I get, the more I love my wife." Adds J.P. Neal, 32, of Potomac, Maryland: "The for-richer-or-poorer, for-better-or-worse aspects of marriage don't hit you right away. It's only during those rare times when we take stock of our life that it starts to sink in."

Secret #8: We don't really understand what you're talking about

You know how, during the day, you sometimes think about certain deep, complex "issues" in your relationship? Then when you get home, you want to "discuss" these issues? And during these "discussions," your man sits there nodding and saying things like "Sure, I understand," "That makes perfect sense" and "I'll do better next time"?

Well, we don't understand. It doesn't make any sense to us at all. And although we'd like to do better next time, we could only do so if, in fact, we had an idea of what you're talking about.

We do care. Just be aware that the part of our brain that processes this stuff is where we store sports trivia.

Secret #9: We are terrified when you drive

Want to know how to reduce your big, tough guy to a quivering mass of fear? Ask him for the car keys.

"I am scared to death when she drives," says LaFlamme.

"Every time I ride with her, I fully accept that I may die at any moment," says Buckingham.

"My wife has about one 'car panic' story a week -- and it's never her fault. All these horrible things just keep happening -- it must be her bad luck," says Andy Beshuk, 31, of Jefferson City, Missouri.

Even if your man is too diplomatic to tell you, he is terrified that you will turn him into a crash-test dummy.

Secret #10: We'll always wish we were 25 again

Granted, when I was 25 I was working 16-hour days and eating shrimp-flavored Ramen noodles six times a week. But as much as we love being with you now, we will always look back fondly on the malnourished freedom of our misguided youth. "Springsteen concerts, the '91 Mets, the Clinton presidency -- most guys reminisce about the days when life was good, easy and free of responsibility," says Rob Aronson, 41, of Livingston, New Jersey, who's been married for 11 years. "At 25 you can get away with things you just can't get away with at 40."

While it doesn't mean we're leaving you to join a rock band, it does explain why we occasionally come home from Pep Boys with a leather steering-wheel cover and a Born to Run CD.

Secret #11: Give us an inch and we'll give you a lifetime

I was on a trip to Mexico, standing on a beach, waxing my surfboard and admiring the glistening 10-foot waves, when I decided to marry the woman who is now my wife. Sure, this was three years before I got around to popping the question. But that was when I knew.

Why? Because she'd let me go on vacation alone. Hell, she made me go. This is the most important thing a man never told you: If you let us be dumb guys, if you embrace our stupid poker night, if you encourage us to go surfing -- by ourselves -- our silly little hearts, with their manly warts and all, will embrace you forever for it.

And that's the truth.

best cieling drawing ever

10 tips on writing reusable code

(http://hoskinator.blogspot.com/2006/06/10-tips-on-writing-reusable-code.html)

I have been trying to increase code reuse in the projects I have been doing recently. In my first few years of coding I hardly ever got to reuse any of my code because it was always too coupled together and dependant upon other parts of the code.

So recently I have been trying to write code which I can reuse. It has been interesting that since I have been doing this I have noticed that my library of code is starting to grow. I have started to create more Static Helper classes with useful methods in. I have also been removing the business logic away from any Struts actions or framework work.

To do this I have tried to do a number of things to help this and these are the sort of rules and things I do (in no order) to help me try and achieve this. They are a number of rules and tips I have picked up but can't remember where from

1. Keep the code DRY. Dry means Don't repeat yourself. This is one of the main changes I have tried to bring in. Always try to eradicate duplication and if you find any then move remove the duplication to a relevant place. Sometimes this has lead me to create Static Helper classes or sometimes move it to the class it makes most sense to have it.

2. Make a class/method do just one thing. This is along the lines of the advice of giving the class only one reason to change. This often means creating methods that other methods use but this helps to make the methods/classes simple and less coupled.

3. Write unit tests for your classes AND make it easy to test classes. Writing code that is easy to test is decoupled. If you write code and are thinking about writing a unit test for it then you tend to split up the code into smaller testable chunks.

4. Remove the business logic or main code away from any framework code. Following the rules above will help this. An example I have seen is code that is inside Struts Actions classes, this code is practically impossible to reuse because of all the Struts dependencies that it now linked with.

5. Try to think more abstractly and use Interfaces and Abstract classes. Try to hide dependencies of code behind a more Generic interface/abstract class. The benefit this gives the code is it creates a flexible point in the code where you can then hide future changes behind.

6. Code for extension. Write code that can easily be extended in the future. This is particularly true with the above point. If you write code that uses interfaces then you can extend that interface at a later point.

7. Don't write code that isn't needed. Do the simplest thing possible. Don't waste your time adding methods and classes that might be used in the future. Keep the code simple and focused on what you are trying to deliver. I think I read/heard Josh Bloch say once that "if in doubt, leave it out". Basically who wants to write code that no one (including yourself) is going to use again.

8. Try to reduce coupling. When writing code think about the links and coupling the code is creating, does it need to be linked to those other classes.

9. Be more Modular - make your code more modular, think modular, be modular.

10. Write code like your code is an External API. Imagine the code you are writing is a self contained component.

It wasn't going to be ten until I got to 8 and then thought no one writes 8 tips, lets add two more on. It isn't really a list but it's sort of aims and mental notes I try tell myself when writing code. They are more small bits of code I have written recently that has helped. I would like to hear people's comments and especially their tips on writing reusable code

Interesting article analyzing the myths and truths sorrounding women

---

Date: 2006-04-18, 11:09PM PDT


Some rants and accumulated experience about women. Men in happy marriages or stable relationships don't need to read this; neither do men who get laid every week (or even every month). The "truth" I'm putting out here is for all of those men who, like me, worship women and can't figure out why they keep getting screwed over and dumped. The myths are things that I used to believe before I wised up.

MYTH: Women want love and affection. Women want to be treated well. If you treat a woman well, she'll treat you well.

TRUTH: Young women want whatever other young women want. They're herd creatures. If you lavish a woman with love and affection she'll think you're doing it because nobody else wants you (which may be true) and she'll dump you. In fact, if you do anything that betrays that you're a loser that other women won't touch, she'll dump you. Why? Because she wants to impress her friends with what a great catch she's made, and if she thinks that they wouldn't want you, then she doesn't want you either.

There are only three exceptions to this rule. The first exception is psychos, otherwise known as "witches, bitches, and crazy ladies." They'll stay with you because nobody else wants them, or because you're the only one who put up with their abuse. The second exception is women who like to "fix men up": those women who like to take "broken" men and turn them into the man they want. These women are single because a mature man will recognize that these women don't want him... they want to turn him into someone else. The third exception is that once in a long time you meet a woman who isn't psycho, still wants to stay with you when she finds out that you're not super stud, and doesn't want to change you into someone else. This is the one you marry.

BITTER MYTH: Women are out for money.

TRUTH: Women are out for status and fun or for security, depending upon their age. A few women are out for cold cash, but not too many. Status-seeking women aren't ready to settle down. They just wanna have fun, and they want their girlfriends to know it. They're looking for a guy they can dangle in front of their friends and say, "Look what I got!" You don't have to have money to be that guy, you just have to come across as desirable. Of course if you have money you don't need to do anything else, but having no money isn't the end of the world. The women who are out for security have had their wild fling and want to settle down. They want a guy who can provide a stable base for the future (and that includes finances).

All in all it's sort of like what guys do (and women whine about endlessly): when you're young you want some bright, bubbly thing with huge tits, a nice ass, and a trimmed bush who screams like a banshee in bed, although you'll settle for much less; when you're ready to get married you want a nice girl who isn't going to break your balls. They're usually different people unless you're very, very lucky. Young women want bad boys who will show them a good time. When they're ready to get married they want some guy who is going to be able to pay to keep them comfortable.

MYTH: Women are out for looks.

TRUTH: See above. Women are out for looks, after a fashion. A guy in good physical shape who wears decent-looking clothes is attractive because he looks after himself and probably isn't a wimp or a whiner. She can convince her friends that he's a "catch." A guy who looks and smells like a laundry bin, or who can't climb a few flights of stairs without a rest had better have some spectacular attribute to show off to her friends (like being a genius) or he's not worth her time. Any guy can compensate for lack of looks or lack of money with showmanship. He doesn't have to be a catch, just seem like one. All he has to do is make her friends think, "Damn, I wish I were going out with him instead of the loser I'm with."

MYTH: I should find one woman I like who likes me, and stick with her through thick and thin.

TRUTH: This is the biggest mistake I ever made. I used to be loyal to whomever I was with, even when someone better came along. All that happened was that I missed out on some great opportunities while I hung on with losers that ended up dumping me anyway. Do this if the two of you are getting married; once you've tied the knot it's a whole other can of worms. However, if you're just dating, do exactly the opposite. In very subtle ways you have to let her know that although you like her, there are lots of other women out there and you still notice them. Glance at tits and legs. Smile at and chat with pretty ladies, even while she's with you (you're just being friendly, of course). This is the most important thing I've learned about dating in a decade. I even thought of dating WASP bitches again, so long as I could keep this in mind. Never, never let her know that she's the only game in town. As soon as she believes that she's your "everything," she'll start whining and bitching and making demands.

Think of it like buying a car. If you let the salesman know that this is your dream car, that you've stayed awake nights thinking about buying exactly this car, do you think the price will go down? Of course not! He'll jack the price up as high as he thinks he can go and still have you buy it. If you tell your girl that you've dreamed all of your life of going out with someone like her, do you think she'll smile and kiss you and things will go on as before? Of course not! She'll realize that you'll put up with more of her bad habits, and that she can put up with fewer of yours, and the bitching will start. She'll try to make the relationship as comfortable for her as possible and still keep it going. Remember the car salesman? Remember the attitude that "this is a nice car, but there are hundreds of other great ones, including that one across the street", even as your heart is thumping and you're practically drooling? If you're just dating, this is the attitude to take.

MYTH: Having a girlfriend / fiancée / wife means being able to tell someone my problems.

TRUTH: Nobody gives a shit about your problems. Nobody ever will. I know that sounds harsh, but it's the reality of being a man. Want to tell people about your problems? Get a sex change. Or join a men's group; the flip side is that you have to listen to their problems, but it helps. I know of only two kinds of women who want to hear about your problems: ones with far more problems than you have, and ones who fancy themselves amateur psychiatrists and like "fixing" men. Neither is good company. Let's face it: many women spend all day whining to their friends about how awful their lives are and listening to their neurotic friends responding in kind. The last thing they want to do is go out with you and hear more of the same.

To make matters worse, women simply don't "get" many of men's problems. Women have problems with things that don't even bother us, but they expect us to be understanding or at least tolerant; we have problems with things that don't even bother them, and no amount of explaining will cause the light to go on or elicit any sympathy.

So why not just commit hara-kiri now? Because it's not that bad. You get over it. In particular, once you figure out how to handle women a lot of your problems seem smaller and more manageable.

MYTH: Having a girlfriend / fiancée / wife means someone will finally understand me.

TRUTH: Understanding—true understanding—takes decades. If you spend most of your time with the love of your life trying to explain yourself, she will have nothing but contempt for you, for two reasons. First, because she doesn't want to hear your whining (see above). Second, and more important, women want to maintain the self-delusion that they already understand men. Women everywhere claim that they understand men and that "men are simple creatures." The truth is that women haven't a clue where most men are coming from and furthermore they care only insofar as they want to control us. Nonetheless, they want to maintain the fiction that they have us figured out.

It's a pride and status thing. A woman who doesn't "understand" her man can't control him, and a woman who can't control her man is a loser. The more you try to explain yourself, the more complex and multi-dimensional you become (a.k.a. "difficult"), and the less she can claim to understand you.

Besides, most of the time you're explaining yourself to her you're really trying to figure yourself out. Go do it in a corner, hire a professional listener, or join a men's group. She doesn't want to hear it. If you master the art of keeping your problems to yourself she will complain bitterly about this. She will bitch and whine that you're not open enough and that she has to drag things out of you. She will also secretly love this. It gives her one more thing to complain about to her friends.

MYTH: If only I could meet the right woman, my life would have meaning.

TRUTH: If your life doesn't have meaning right now, when you're single, then a relationship isn't going to help. You'll pile too much baggage on top of the delicate emotional bonds too early, and the whole thing will collapse like a house of cards. Want to see this in action? Watch women: they do this all the time. In particular, women who whine about men who can't make a commitment are probably doing exactly this: looking to a man to make their life mean something. It doesn't work.

The only way to have a happy life is to develop one for yourself, then leave an opening for someone else to come and share it with you. Neither of these two things is easy. In particular, it's too easy once you've developed a life for yourself to end up with someone who was doing exactly what you were doing before—waiting for Prince Charming (or in your case Lady Love)—to come and rescue her life. People like this end up draining away all of that energy you've worked so hard to build up, leaving you exhausted and frustrated.

Take it from me: I waited for Lady Love for decades. Finally I gave up, got angry, got off my ass and tried to make a life for myself, and suddenly I was surrounded by women who wanted to date me. After a while I met someone who was very special to me and I married her. Now my life is about the same as before, but I have someone with whom to share it. As much as I prefer being with someone, I must tell you that having her with me doesn't make my life any more or less meaningful. I'm pretty much where I was before, only now I have company, which is nice.

[P.S.: After two years she turned into one of those people who was waiting for her life to mean something, and she drained away all of my good energy. Oh well. Some things just don't turn out as planned, no matter how hard you try. Rats.]

MYTH: If I treat a woman well and listen to what she says, she'll stop complaining

TRUTH: Women never stop complaining. For them, it's a sport. Some complain more than others, but none of them will ever stop, any more than one day men will stop discussing football. Men have built civilizations, created law, invented husbandry (that's keeping domestic animals by the way, not marriage; women invented marriage), built skyscrapers, invented cars, washing machines, antibiotics, toilets, computers, and microwave ovens, and generally dragged us out of caves and into condos. Don't kid yourself: men did it all. If it were up to women we'd still be living in caves and dying at 20. I know that men did it all because I know why they did it: they hoped that it would stop women complaining. It didn't.

If you listen to your girlfriend's bitching and try to make everything better, you'll suffer the same fate as all the men who came before: you'll run yourself ragged, and at the end of it all she'll still be bitching. If you ignore all but the most important complaints, she'll bitch about that, too, but you'll feel far better about your life.

MYTH: Men don't listen to women because men don't care about women.

TRUTH: Men ignore women because women normally have nothing worthwhile to say. This is not a condemnation of women, but rather a difference in what talking is for. This is one of the few areas where John Gray has something useful to say. Men mull things over, organize things in their heads, then speak. Men have to do this because they have to get things done, and if they blabbered all day long about nothing in particular then eventually other men would pay them no attention. Men talk to communicate ideas, negotiate compromises, and secure cooperation. Life and experience has taught men to be brief and pithy.

Women talk to organize their thoughts. It's the difference between doing the math problem in your head and writing the answer at the top of the page, and scribbling all over the page in order to arrive at the answer in the bottom corner. Women want men to listen to them. Women want men to follow along as they scribble all over the page, not just wait for the answer. Quite frankly, who cares? As I mentioned above, there are lots of things that women don't want to hear from men. If you want to talk about these things, you'll have to find some other men who want to listen, because she sure as hell won't. If she wants to attach her mouth to her brain and vocalize all of her mental processes then she should find someone who cares to listen, in other words another woman.

MYTH: She said she loves me. She must think I'm really special.

TRUTH: When women say, "I love you" it can mean almost anything. "I want to spend the rest of my life with you," "I'm desperate to get married and have babies and you're the best thing I've come across so far," "You're better than the last jerk I went out with," "You're the best guy I've come across this week," "All my girlfriends are in love and I want to be too," "I have a million problems and I want you to feel obliged to listen to them," "I want another date and I want you to feel like you have to ask me out again," "It's time I put my foot down and started controlling you," and any number of other things. OK, most women think they mean it when they say, "I love you." However, remember the old saying, "It's a woman's prerogative to change her mind"? She loves you this minute. Maybe today. Maybe this week. Maybe even this month. However, this says nothing about how she will feel next month, next week, or tomorrow.

One of the biggest problems men like me have is that when we say, "I love you" to a woman we want to really mean it. Like "I love you forever." Men don't understand that a woman can say, "I love you forever" and change her mind next week. All she does is convinces herself that in hindsight, and despite everything you've ever said or done, you never really loved her, so all the times she said, "I love you" didn't really count. You have to learn to use the same language. Go ahead and say, "I love you," but inside your head say, "I love you right now. Tomorrow may be a different story." When you break up and she screams that you said you loved her, tell her that you did, but she did this and that and now you don't love her any more. When women say, "I love you" they aren't promising eternal devotion, so why should you be? One day you'll meet a woman who says, "I love you" and it'll really hit home. You'll test her love a bit and it will hold up. That's the one you marry.

MYTH: Women understand relationships; men don't.

TRUTH: This myth is perpetuated by women, pussy-whipped men, and psychiatrists. If women truly understood relationships... that is, if they understood relationships with men... then we wouldn't have a 45% divorce rate. Maybe back in the pioneer days women understood relationships. These days, they have coffee with their girlfriends, talk about "men", examine and dissect relationships, study interpersonal dynamics, talk, talk, talk about what works and what doesn't, then go out and perfectly screw up their next relationship. I know. I've watched it happen from the sidelines.

Women spend more time analyzing relationships; they talk about them incessantly, and in doing so discover more truths than men know. However, all of this talk in a vacuum also means that their heads are filled with more bullshit and myth than are men's. The combination of superior insight and copious nonsense puts them right back where we are. Men tend to see what's going on in a relationship more clearly, but have no idea how to express what they see or what to do about it. Women would probably know what to do about it if they could only see it as it truly is, instead of through a fog of preconception.

The other big difference between the sexes is that women are absolutely certain that they know what is going on, whereas men make no such claim. The last man who claimed to have his own radical theories about relationships was Freud, and nobody pays any attention to him any more. It is women's ideas about relationships and why they do or don't work that have been imported lock, stock, and barrel into the field of psychiatry. Most male therapists you'll meet are basically honorary women with university degrees, and as such they don't really understand relationships either.

MYTH: Women are fairer and more even-handed than men

TRUTH: Nothing could be further from the truth. Traditionally men have favoured the same rules for everyone: "He who lives by the sword dies by the sword." Women on the other hand make up the rules as they go along. Although women's approach is patently unfair, it was valuable when they had to be the ones to point out that the rules needed to be changed, or that the rules should be bent in some cases. Back then they did this for the good of everyone. These days men still feel bound by rules, but women are in a conflict of interest. They still keep watch over the rules and break them as they always have, but now they modify and break the rules in their own favour.

Men's justice is often harsh, but it's fair. Women's justice is arbitrary and these days often self-serving. (Liberal "situational ethics" are essentially the same as women's ethics.) You'll find this out quickly in a relationship. The joke going around about "The Rules" and how women change them all the time isn't such a joke. It's a documentary. If you doubt this, think of it this way. A man caught breaking or bending the rules of good behaviour will become either defensive or repentant; his wife will beat him over the head with his transgression for months, if not years. A woman caught modifying the rules of good behaviour to suit herself will giggle and freely admit it. She thinks it's a game.

MYTH: Women do a lot for the relationship; men do a lot for themselves

TRUTH: My ex-girlfriend invented a little ditty that made her puff up with smug, self-satisfied pride. It went like this, "Women think of 'we'; men think of 'me'." OK, so e.e. cummings she wasn't. The point is that she actually believed this, and a lot of other women do, too. She thought that she was living and breathing our "relationship," while I was just kind of hanging around and taking up space. Meanwhile, I drove her everywhere (she couldn't drive), I spent hours making her gifts and writing her notes, and I spent hours thinking about what was going on with us and where we were going.

The truth of the matter is that women don't think of 'we' any more or less often than men do. Women think of their own needs most of the time, too. The difference is that women redefine their own needs as being those of "the relationship". For example, when a man needs to talk to his belle about something, he says, "I need to talk to you." When a woman needs to talk to her beau about something, she says, "We need to talk." Notice the difference? Suddenly what she needs becomes what we need. Women do this all the time, and then pout and whine that they work so hard at the relationship and you don't. In fact they're just playing with words.

The other truth is that there are two relationships: the one you're really in—the one that exists between you and her—and the one in her head. Remember how women are always talking and theorizing about "relationships"? Well, much of what she defines as "our relationship" is really just a collection of theories and prejudices from past conversations with her girlfriends, and has nothing to do with what's going on between the two of you. In that sense, even if she is doing more for "the relationship," it isn't necessarily anything that concerns her real relationship with you.

MYTH: Women are more involved in the relationship; men are more aloof.

TRUTH: Finally one that's true. The false part is the assumption that being deeply involved in the relationship is always a good thing, and that aloofness is fatal to relationships. If you doubt this, look around you and find a couple in which both people do little else but sit around with each other and talk, and watch how fast the relationship blows itself apart. Every relationship has to have a balance between looking inward and looking outward. Most women who complain that their men don't pay enough attention to "the relationship" aren't seeing the relationship clearly and/or are buried in "the relationship" up to their necks and so are creating more problems than they solve. Recently I was skimming a book by Dr. Laura and saw a chapter that gets this one right. Where is it written that when a man wants to go back to college and a woman wants to get married, and she gets angry that he's "not thinking of the relationship" that she's automatically right? Maybe the right thing to do at that moment is for both of them to go back to college for a couple of years. Women confuse obsessing about "the relationship" with healthy involvement, particularly considering that half the time they're seeing stuff that isn't even there. Sometimes your relationship needs more attention than you're giving it; other times she's smothering it. The assumption that more involvement equals more love simply isn't true.

MYTH: When she says no, she means no (so why am I so confused)?

TRUTH: Nobody means no every time they say "no." Think about it: do you? You've never said no when you were too shy to say yes? You've never said no because you were nervous, didn't know what you were getting into, and didn't really have time to think about your answer? You've never said no because you thought that was the right thing to do even though you really wanted to say yes? You've never said no and then changed your mind? You've never said no as a joke, just to get a rise out of someone, when you really meant yes?

I've done all of these things at one time or another; most men I know have, and most women I know have as well. However, for men there's a catch. If she's prone to saying no when she really means yes, then you should dump her. Immediately. Especially if she's told you in no uncertain terms "no" and then starts dropping huge hints that you're supposed to ignore this and go for it anyway. Dump the bitch. This is just far too dangerous. If you doubt this, imagine sitting in court, accused of rape. "Did she tell you no, Mr. Smith?" "Yeah, but afterward she tried to rip my pants off, then stripped naked and sat on my face!" "But did she say no, Mr. Smith?" "Umm... yes she did." "Case closed."

I once went out with a woman who told me, on our second date, that there was no way she would sleep with me, that her ex-boyfriend was coming to visit and that it would be "too complicated" if she were sleeping with me when he came to stay. On our third date she did everything to let me know that she wanted me, including lying on my bed, making comments about removing her clothes for a nude massage. Spooked, I drove her home, dropped her off, and never went out with her again. I consider it one of the smartest things I've done in my dating life. (Incidentally, apparently so does she. Every time I meet her she asks why I don't call her any more.)

MYTH: Women are social geniuses; all women get along well with each other, while men just fight

TRUTH: I lived in a mixed-sex dorm for two years in university where each floor was segregated by sex. It alternated: one floor men, one floor women, one floor men, etc. A few nearby residences were completely mixed. A couple of the men's floors looked much the worse for wear at the end of the year. You know, men are so destructive. The women's floors all looked perfect. All the girls were smiling and friendly. Talk to any of them, however, and they'd tell you that they hated living on an all-female floor, and every last damned one of them was moving to the mixed dorms the very next year, and not with each other. According to them, underneath the tidy rooms and smiles were claws and forked tongues. Every day was a quiet, mannerly, pitched social battle. The men, on the other hand, got along just fine with only a few exceptions. Most of us were quite happy where we were, the only complaint being that we didn't see the ladies enough.

One thing that is true along the lines of this myth is that any woman will defend another woman against a man, even a woman that she doesn't know. Start bad-mouthing women, even a particular woman that isn't known to "present company," and you'll find women defending her even though they have no idea what's going on. If anyone—a woman or another man—verbally attacks a man, other men will not jump in and defend him. Why? Men assume that other men can look after themselves and, after all, they're competition. Women assume that an attack on one woman is an attack on all women.

BITTER MYTH: Women are all the same.

TRUTH: Women are not all the same, and in particular women change with age. A woman who wouldn't give you a second look at 15 may be asking you out at 35. In part this is the dreaded "biological clock" at work, but in part it's also changing priorities. At 15 she wants to impress all of her friends with her "catch" and she is starting to learn to control men. She wants variety and excitement. At 25 she wants to have fun with no strings attached and wants to hone her controlling skills. She wants more stability but she doesn't want Ward Cleaver or Bill Gates. At 35 she realizes that the fun days are over and it's time to settle down and get serious.

Boring, nerdy guys who were dog meat at 15 can be studs at 35. The guys grow up and mature, they learn to need women less, and they settle into a life of resigned solitude, which means that they cheer up because they're no longer striving for something they can't have. The field narrows, and there are fewer single guys with no divorce history. Finally, her priorities have changed. She's no longer impressed by "bad boys" on motorcycles with a few convictions for petty crime. She knows that her friends aren't impressed by flashy, fast-living rogues any longer, any more than they're still impressed by fashions from Suzy Creamcheese. She's more interested in building a nest than impressing her friends anyway (and she knows that building a nest is what will impress them). So, just because you can't get anywhere now doesn't mean that your whole life will be a write-off. Take a clue from me: I never had a single date in high school. I had one girlfriend for a year in University. Ten years later I was beating women off with a stick.