PHP Performance

We've been working hard the last few days to squeeze every ounce of performance out of our PHP code. This article from Linux Journal was especially helpful:

http://www.linuxjournal.com/article/7213

Also, if you haven't seen George's slides on PHP performance, check them out:

http://www.schlossnagle.org/~george/talks/ZendPerf.pdf

Life Insurance 101

Making sure my family is taken care of if I kick the bucket unexpectedly is important to me. Keeping my life insurance policy updated is one of the major steps I can take to make sure this happens. But I'm never sure which type of policy (term vs whole), the amount, or the length of a policy I should buy. I trust my life insurance agent, but I like to do a ton of research on my own. So I find consulting my financial advisor very helpful. His advice on life insurance can be found here, very useful stuff, highly recommended.

Book Review: The Ultimate Question

French fries or baked potato?

Khakis or Jeans?

Do I really need to do sit-ups today?

These are all questions I struggle with on a daily basis but none of them are “The Ultimate Question.” The Ultimate Question is a powerful, yet simplistic approach to achieving profitable growth. The book does a great job explaining why customer satisfaction and loyalty is so important and how it will ultimately lead to true growth. Definitely a book the entire organization should read.

Open Files

lsof -p process_id | wc -l

is just way too slow sometimes, I finally figured out a faster (and more accurate) way to quickly get a count (or list) of open files.

ls -l /proc/process_id/fd/ | wc -l

Thanks to http://www.netadmintools.com/art295.html

Running Version 2

I finished my 10 week running plan over a month ago. I've been slacking since then, but today I'm going to pick it up again. I'm going to start training for that 5K I have to run at some point this year. My 10 week plan worked out great. It wasn't too hard, I had more mental issues than physical. Here is the plan for the next 6 weeks:

Week	M	T	W	H	F	S	S	Total
1		2		2		2		6
2		2.5		2.5		2.5		7.5
3		3		3		2.5	2	10.5
4		3.5		3.5		3	2	12
5		4	2	3.5		3.5	2	15
6		4		2		2		8

Book Review: Inside Intuit

This book is one of the most fascinating, intriguing, and entertaining books I've ever read. Every entrepreneur should get a copy of this book. Intuit went through all of the stages a startup company might imagine including an epic battle with Microsoft. Software developers will love all of the great stories about the challenges and hard work that it took to make Quicken and the other Intuit products so successful. Service oriented companies will love to hear about how this company truly valued their customer's and their feedback. Management will love to hear how they acquired companies, raised money, and were almost acquired by Microsoft. A truly amazing story about a startup who beat all odds.

Why Code Reviews Are So Important

Yesterday I spent five hours participating in a hard core code review / bug fix session. The code we were reviewing was rather small, but there were a lot of cases to test. Code reviews can be structured in many different ways, but we took the following approach:

1. Review the functional specification to understand the goals of the project
2. Run a few preliminary test cases to make sure the product met the goals
3. Compare every screen to the designs to make sure they were 100% correct (right fonts, colors, wording)
4. Fix bugs on the spot. This was the most time consuming part, but I'm glad we did this right away, avoiding having to hold another session the following day.
5. This project was primarily modifying existing code to add additional functionality. This means that we can use trac in combination with svn to review only the changes made to each file. This makes the code review process very thorough and very fast. Trac does a great job color coding differences and we were able to find a dozen or so typos and bugs simply from looking at the trac diffs. We fixed the bugs right away, committed the code, and repeated the process.
6. After we finished fixing all of the bugs we went through a more thorough testing of the entire application to make sure we didn't break anything and that all of the bugs discovered were indeed fixed.

Overall I was very pleased with the results. The code review not only produced many bug fixes, but it emphasizes the importance of good coding, documenting your code, and being able to work with others.

Book Review: Blue Ocean Strategy

I'm posting this one rapidly in hopes that I can cover up my last post before anyone sees it. :) "Blue Ocean Strategy" is a very thought provoking book that puts structure behind strategic planning. It reminds me a lot of "Purple Cow" type of thinking and is definitely worth a read. My only real complaint is the authors don't make the book all that exciting or entertaining. It did a good job putting me asleep on more than one occasion.

The sub-title of the book is "How to Create Uncontested Market Space and Make Competition Irrelevant." The focus of the majority of the book is strategies for discovering your Blue Ocean. I liked their ideas on how to put a process around strategic thinking.

Damn, too late, AMartin is already on my case for the Martha post.... :)

So, what is a Blue Ocean? Just think about how instead of one-upping your competition with the next big feature, how can you make the competition irrelevant by creating a new market space where there is no competition. For example, "Curves for Women" created a new type of health club aimed at the millions of women who hated working out at home, but also hated spending hours at a high priced, intimidating health club. Typical health clubs want you to spend a lot of time there, spend a lot of money, and use equipment that is complicated. On top of that, there are a ton of bulky guys there starring. Curves created a new environment that had equipment that was easy to use and didn't require a lot of time to workout. Curves made regular health clubs and home workout equipment irrelevant by moving into this uncontested market space.

Damn, second comment on my blog, I can tell I'm in trouble so I'll go ahead and post this one!

Book Review: Martha Stewart's Homekeeping Handbook

The sub-title of this book is "The Essential Guide to Caring for Everything in Your Home". I think the key word in that statement is "Everything". This book is huge and covers every topic you could ever imagine with regards to caring for your home.

I'm sure I will get a hard time from some of my co-workers for even picking up this book, much less reading it from cover to cover, but I am definitely a huge Martha fan after reading this book.

A word of warning though, this book reads like an encyclopedia. Martha has a lot of talents, but don't expect her to crack a joke or two when discussing the proper way to clean your sink.

You can see why Martha has been so successful in her life (going to jail aside), she doesn't do anything unless she does it 100%. Anything worth doing is worth doing right, even if it is cleaning a toilet, you should know the right way to clean it. Another lesson from the book that can be applied to any area of life is being organized. It's amazing how much better you feel after you clean and organize a room in your home. Over Christmas break I spent almost a full day with Velvet organizing our garage. It's gone from being an eye-sore to my favorite room in the house.

Being a home owner (well, the bank technically owns it, but in 26 more years it will be all mine) I want to do everything I can to maintain my home and make it a place where I enjoy returning to after a long days work. I learned a lot from reading this book and I would recommend it to anyone.

Book Review: The 22 Immutable Laws of Marketing

This book is on Joel's reading list and was occupying space on Pat's bookshelf so I decided to steal...errrr...borrow it for the week. Working for a company that is heavily driven by marketing, it's important for me to learn as much as possible on the topic. This is the second book I have recently read on marketing. The first was “The Purple Cow” written by Seth Godin. I found both books very good and hard to put down. This book is a little more outdated in terms of the examples that it provides, but is nonetheless a great book. As I was reading the first few chapters, I had the urge to argue in my head the validity of the laws. But after reading the entire book I understand now understand each law and I would argue that each one is indeed immutable.

2007 Goals

The end of 2006 is only days away and I've done a good job accomplishing many of my 2006 goals. Looking back, I'm very pleased but some goals were rather unrealistic, some were just not easily measured. So this year's goals are going to be more measurable. I have also broken out my personal goals and my work goals. My work goals are posted on the door to my office.

My personal goals are as follows:

1. Read for at least 30 mins every day.

2. Run the Draper Mile in under 6 mins.

3. Run a 5K.

4. Do abs three times per week.

5. Bench press 250 lbs.

6. Spend at least 30 mins cleaning the house every day.

7. Try to force myself and my kids to eat at least 1 vegetable every day.

8. Get my weight to 175 pounds.

One of my work goals is to work at least 60 hours every week. Looking back over the last year, I've averaged 51 hours per week. That's just not good enough. So I've laid out a plan to workout less, work more from home and on weekends, and sleep less. If I stick to the plan I shouldn't have any trouble fitting in an extra 9 hours. And since football season is over there is really no reason to even have a TV, so no more TV for me either.

Hopefully all of this will still leave me plenty of time to spend with the kids and most importantly, Velvet. ;)

Bench Press Results

Friday was the last day of my 12 week workout. I can't believe I started that workout in September. The end result is that I was able to complete each workout successfully, except for the last week. The last week I benched 205 pounds 2 times on the first set, which would put my max at 217 pounds. Seventeen pounds over my goal for the year. 225 is still my nemesis...I'm taking a week off but I'm determined to get it in 2007!

Book Review: User Interface Design for Programmers

The book is written by Joel Spolsky (www.joelonsoftware.com) who provides an entertaining look at user interface design from a programmer’s perspective. Joel is good at seeing things from both a non-technical and technical perspective. He provides some great guidelines in this book, which for the most part I agree with 100%. The book could be updated to reflect a lot of the changes that have occurred over the last few years in the area of web development. The non-web parts of the book are excellent though, and I would recommend this book to anyone who builds user interfaces. The book stays focused on usability and not “use this color and this font” type of issues. The book is not for designers, it’s for programmers, but even designers could learn a thing or two from reading this book.

My two favorite quotes from the book are:

“A user interface is well designed when the program behaves exactly how the user thought it would.”

and

“Usability is not everything. If usability engineers designed a nightclub, it would be clean, quiet, brightly lit, with lots of places to sit down, plenty of bartenders, menus written in 18-point font sans serif, and easy-to-find bathrooms. But nobody would be there. They would all be down the street at Coyote Ugly pouring beer on each other.”

Book Review: First, Break All The Rules

This book was recommended by Pat and it is based on an in-depth study of over 80,000 managers. The book's title says it all, the world's best managers are not afraid to break every rule held sacred by conventional wisdom. This book is one I would recommend to anyone who is in a management position. As I was reading this book I jotted down several notes and the page numbers for reference. I plan on going back through these notes and making a detailed summary of this book so that I can refer back to it often.

If I had to summarize the book with a picture, I would steal the one from Appendix A, which is summarized in text as:

• Identify the strengths of every employee

• Based on these strengths, find the right fit for each employee

• The right people in the right roles with the right managers drive employee engagement

• Engaged employees drive customer loyalty

• Loyal customers drive sustainable growth

• Sustainable growth drives real profit increase

• Real profit increase drives stock increase

I strongly encourage everyone to read this book, even if you don't manage people.

Book Review: How to Win Friends & Influence People

I’ve decided to make a concerted effort to read more, so last week I started reading the book “How to Win Friends & Influence People” by Dale Carnegie. The book has sold over 15,000,000 copies since being published in 1937. The book was written after teaching over twenty years worth of educational courses on the topic in New York City. The book is divided into four parts, each part ending with a set of principles that Carnegie suggests are the keys to remember when dealing with people. The four parts of the book are:

1. Fundamental Techniques in Handling People
2. Six Ways to Make People Like You
3. How to Win People to Your Way of Thinking
4. Be a Leader: How to Change People without Giving Offense or Arousing Resentment

Each principle is examined by looking at real life examples either from famous personalities such as Abraham Lincoln and Charles Schwab, to everyday people who he taught in his courses. Carnegie gives examples from business, teaching, parenting, and many other avenues to show that his principles apply to every part of your life. Carnegie gives just enough information about each principle to make his point, but doesn’t bore the reader by repeating the same thing over and over. Carnegie suggests that each chapter should be read twice and I agree.

I was so impressed by this book that I made a cheat sheet with every principle and formatted it onto a single piece of paper. I plan on referencing this cheat sheet on a daily basis so that the ideas will stay fresh in my memory.

Truncating MySQL Log Files

Often I want to have MySQL logging turned on so that when there are problems I can quickly tail the log file to see what is causing the problem. The problem with leaving MySQL logging on for an extended period of time is that the log files can get big quickly. So I usually leave logging turned off and only turn it on when needed. Which works fine, but in order to turn off or on MySQL logging you have to restart the server. This is not ideal in most cases because a restart means that any clients trying to connect during the process of restarting will get an error.

Typical log rotation scripts won't work because when the file is rotated the MySQL server won't recreate the file or log to a new file even if you create it by hand.

Last week I thought of a solution that seems to be working well. I realized that I could leave logging turned on but have a nightly script that simply truncated the file with this command:

echo '' > /var/log/mysql.log

This will reduce the size of the file to zero bytes and at the same time MySQL will continue to log to the file without requiring a restart.

But this method doesn't allow you to actually rotate the log file in case you wanted to keep it around. So after researching a bit, I found this:

shell> mv host_name.log host_name-old.log
shell> mysqladmin flush-logs
shell> cp host_name-old.log backup-directory
shell> rm host_name-old.log

This would allow you to do an actual log rotation instead of just deleting the old file.

If you installed from RPM there is a log rotate script provided, and details can be found here:

http://dev.mysql.com/doc/refman/4.1/en/log-file-maintenance.html

Softball Season

On Tuesday we played our final softball game of the season. We lost 6-4 in the first game of the playoffs. We finished the season 1-11. Our co-ed league has three division: A, B, and C. We joined the B league (A is for the best skilled teams, C is the worse skilled teams) by a majority vote from our team members. This was the first year we have joined a softball league, and the first time I have coached a softball team. We had a number of players on our team that had no softball experience at all, so needless to say we had a lot to learn. I certainly learned a lot about coaching and since hindsight is 20/20 here is a list of things I would do differently or keep the same next year.

Changes for next year:

• Join the C league. We had absolutely no chance of beating some of the better teams in the B league. There were 2 teams in particular that were way better than us. There were 2 teams I thought we could beat, and 2 teams that were slightly better than us. But if I had to do it over again, I would join the C league, nobody likes to lose every game.

• Buy equipment not uniforms. We pooled our money to buy everyone a cool looking, tight fiting, uncomfortable shirt for the season. They had a really great design with our number and nickname on the back. They were extra expensive because of the lettering and the company that made the shirts made them too small and they felt as if they were on backwards when you wore them. Funny stuff, but I think our money would have been better spent on a couple of good bats. I don't think anyone on our team realizes how a good bat can make all of the difference in the world. I'm sure our team average would have been better if we had a few good bats. I do appreciate all of the hard work that Manny, Cameron, and Velvet put into those cool shirts.

• Better batting instructions. I spent so much time each practice going over fielding, relays, defense, etc that we never had much time to break down each persons swing and go into details on how to become a better hitter. We had so much work to do fielding wise that I never felt that batting would matter that much, and it probably didn't, but in those few close games that we lost an extra run or two would of put us over the top.

• Walk. The real difference between the good teams and the bad teams is that good teams don't swing at bad pitches. Good teams generate a lot of walks. I never drilled this point home enough. The best teams beat us by 10 or more runs each time we played them, but they didn't hit 20 home runs. They hit one or two home runs, but the bases were usually loaded when they hit those homers. They know how to take a lot of pitches, get base on balls, and not strikeout. It's a lot harder than it sounds and it takes practice. When you get a strike your natural instinct is to swing at the next pitch no matter where it's at because you don't want to strikeout. But the better hitters know how to identify a ball and not swing, even if they already have a strike.

• Don't keep statistics. Who cares anyway? Let's focus on wins, not stats.

• We need more females. League rules require that half of the team on the field is female, half is male. We barely had enough females each game and it made substitutions really hard. I wish I had more options so that I could put in a pinch hitter or move people around in the field. I'm proud of the girls we had, they played hard and gave 100%, I just wish we had more of them.

Things we did right:

• Practice. Our team was pretty dedicated when it came to practicing. I'm proud of them for working so hard, we came a long way from the first practice to the last game. Heck, we even skipped the first game because we had a scheduled practice. :)

• Cut-Offs. There are two points I worked on over and over in practice and the first one was hitting your cut-off. From the first game to the last game we did an excellent job of knowing where to be and who to throw the ball to when we had it.

• Backing Up. The second point I worked on over and over was backing up the cut-off. We did this better than any team in the league, I have no doubt about this.

• Base running. I thought for a first year team we did an excellent job running the bases.

• Communication. On defense we did a great job of yelling out where to throw the ball, and when we were base running we did a great job helping the runners along. I've seen teams do this terribly and for a first year team we did a great job.

• PK's. Thank goodness for a cold beer, hot pizza, and the camaraderie of friends after each game.

Looking at our defense:

• Outfield. It didn't take long for me to realize that our fastest players needed to be in the outfield. The majority of the hits go to the outfield and there is a lot of territory to cover. I thought after the first few games we got it right and were doing a great job out there. Brian probably had more outfield assists than anyone else in the league and gets my vote for team MVP.

• Pitching. Mike was our only pitcher the entire season. It's way harder than it looks and he did a great job. It took about half the season before I realized he was gripping the ball wrong resulting in too many walks, but overall he did a great job. I still don't know who I would of put at pitcher if he wasn't there every game.

• Catcher. Beth was a trooper and probably our most improved player from the beginning of the year to the end. That first few games the umpire did more catching than she did, but by the end of the year she was doing awesome. It's a tough gig back there and she never once complained.

• Shortstop. Becky was by far the best female shortstop in our league

• Second base. I'll never forget Marisa missing that one throw and it hitting the dude right in the, ugh, well, “private parts”. Awesome stuff, no way was I putting anyone else at second base after that gold-glove play. :)

• First base, third base. I had a lot of options to choose from at these positions. I'm sorry I couldn't get everyone all of the playing team they wanted. It's hard to plan out substitutions when you only get to play 4 or 5 innings. I think everyone who played did a great job, we just needed more innings so that everyone could get more playing time.

Overall we came a long way from that first game to our last game. I'm proud of our team. We played together, never argued, never gave up, and were always encouraging each other. Thanks for a great year and I can't wait to kick some (C league) butt next season. :)

The New Blogger

When I logged into blogger today I was asked if I wanted to upgrade to the new version. I have read that the new version was built on Google's well known architecture so I decided to go ahead and upgrade. I wanted to check out any new features they may have added as well. I guess my blog is somewhat large because after waiting a few minutes for the upgrade to complete, I got a message saying that they would send me an email when they finished the upgrade process. One interesting note is that before I was allowed to upgrade I had to supply a valid GMail account to use for future logins...hmmm.

After 20 mins or so I finally got the email and was able to login to the beta of blogger. I love the new spell checker and the improved speed. Seems like there are a few bugs with "Delete Post" and the preview pane, but overall it seems pretty stable. The speed at which blogs are posted is very fast so I'm sure they worked primarily on speed and scaling in this version.

gunzip, grep, sed, awk, sort, and mail

These are by far my favorite UNIX commands. I use most of them on a daily basis. Let's go through a simple problem to help understand how to use each tool.

Let's say that your UNIX server is configured to rotate your email logs nightly. After the log rotation you want to setup a script that will give a quick summary of the top email recipients on your server.

Here is some example output from the log:

[root@server1 root]# tail -n 40 /var/log/maillog

Nov 17 09:40:28 server1 postfix/qmgr[31224]: E602E44C002: removed
Nov 17 09:40:35 server1 postfix/pickup[6300]: DDD6C44C002: uid=0 from=
Nov 17 09:40:35 server1 postfix/cleanup[6045]: DDD6C44C002: message-id=<20061117144035.ddd6c44c002@server1>
Nov 17 09:40:35 server1 postfix/qmgr[31224]: DDD6C44C002: from=, size=805, nrcpt=2 (queue active)
Nov 17 09:40:36 server1 postfix/smtp[6060]: DDD6C44C002: to=johnsmith@webmail.us relay=192.168.127.1[192.168.127.1], delay=1, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as E091B44C17E)
...

The only line I'm interested in is the last line, so I can easily 'grep' for that data:

[root@server1 root]# grep "postfix/smtp" /var/log/maillog

Nov 17 09:22:33 server1 postfix/smtp[4077]: A63D444C002: to=johnsmith@webmail.us relay=192.168.127.1[192.168.127.1], delay=0, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as ABB8E44C188)
Nov 17 09:22:58 server1 postfix/smtp[4077]: AAD5244C002: to=jsmith@gmail.com relay=192.168.127.1[192.168.127.1], delay=0, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as ADF86C1DC)
...

That's great, but what I really need is only the email address part of that line, that's where 'awk' is very useful:

[root@server1 root]# grep "postfix/smtp" /var/log/maillog | awk '/.*/ {print $7}'

to=johnsmith@webmail.us
to=jsmith@gmail.com
to=johnsmith@webmail.us
to=vvv@webmail.us
...

Almost there, but I only need the part after the 'to=', here comes 'sed' to the rescue:

[root@server1 root]# grep "postfix/smtp" /var/log/maillog | awk '/.*/ {print $7}' | sed {s/to=//}

johnsmith@webmail.us
jsmith@gmail.com
johnsmith@webmail.us
...

Now, the tricky part, I want to group all of the duplicate lines together and get a count of the number of 'johnsmith@webmail.us' entries, luckily I stumbled upon this great awk script which helps me do this:

# histsort.awk -- compact a shell history file
# Arnold Robbins, arnold@gnu.ai.mit.edu, Public Domain
# May 1993
# Thanks to Byron Rakitzis for the general idea
{
if (data[$0]++ == 0)
lines[++count] = $0
}

END {
for (i = 1; i <= count; i++)
print data[lines[i]], lines[i]
}


[root@server1 root]# grep "postfix/smtp" /var/log/maillog | awk '/.*/ {print $7}' | sed {s/to=//} | awk -f history.awk

17 johnsmith@webmail.us
1 jsmith@gmail.com
16 vvv@webmail.us

Now it's easy to sort the list, numerically, in reverse order:

[root@server1 root]# grep "postfix/smtp" /var/log/maillog | awk '/.*/ {print $7}' | sed {s/to=//} | awk -f history.awk | sort -r -n

17 johnsmith@webmail.us
16 vvv@webmail.us
1 jsmith@gmail.com

And finally, let's email the results to myself:

[root@server1 root]# grep "postfix/smtp" /var/log/maillog | awk '/.*/ {print $7}' | sed {s/to=//} | awk -f history.awk | sort -r -n | mail -s "Daily Summary" jsmith@gmail.com

Oh, I almost forgot, I need to gunzip the nightly version an put it in cron:

[root@server1 root]# gunzip -c /var/log/maillog.1.gz | grep "postfix/smtp" | awk '/.*/ {print $7}' | sed {s/to=//} | awk -f history.awk | sort -r -n | mail -s "Daily Summary" jsmith@gmail.com

Combining all of these really simple tools allows you to create just about any type of report imaginable.

Computer Science Majors

I had another opportunity to speak to a group of students at Virginia Tech on Monday. I was on a 5 member panel talking to freshman "General Engineering" majors about computer science. General engineering majors haven't yet chosen a specialty such as electrical engineering, computer engineering, etc. The purpose of the panel was to talk about the CS major. The students filled out a survey before the session about their current thoughts on the computer science major and if they were interested in the major. The majority, like 99%, were not interested in CS. The two major themes of the survey were:

1. Computer Science is boring
2. They didn't want to sit at a desk all day.

The other members of the panel represented IBM, Lockheed Martin, and Eastman Kodak. Although I really liked all of them, they all managed to crack me up at one point or another. They tried their hardest to explain that computer science wasn't boring and you don't spend all day coding (one guy said 30 minutes / day was the average). I didn't say it, because I wanted to get invited back, but if you need convincing that CS is a great major, please major in something besides CS.

The best computer scientist could spend all day in front of computer and love every minute. If my programmers only spent 30 mins a day programming I would be an unhappy person. I don't know what goes on at IBM, but at a small nimble company your programmers should be coding / debugging at least 6 hours a day. The other 4 hours are for the meetings, designing, etc. The point I'm trying to make is that you should have a passion for computers, you shouldn't need to be convinced or talked into the computer science major. Sure, I wish there were more CS majors, but on the other hand, people who aren't passionate about CS won't make good developers. And let's face it, that is what CS is all about. Despite how often some professor tells you that CS is more than programming, that's not the real world. CS is about programming, it's about writing great software, and writing it as quickly as possible, with as few defects as possible.

Wikipedia lists the following fields in computer science:

* 4 Fields of computer science
o 4.1 Mathematical foundations
o 4.2 Theory of computation
o 4.3 Algorithms and data structures
o 4.4 Programming languages and compilers
o 4.5 Concurrent, parallel, and distributed systems
o 4.6 Software engineering
o 4.7 Computer architecture
o 4.8 Communications
o 4.9 Databases
o 4.10 Artificial intelligence
o 4.11 Soft computing
o 4.12 Computer graphics
o 4.13 Scientific computing

11 of the 13 fields require programming. CS is about programming, don't let the recruiters fool you. That's why it's important to find a job where you are working on interesting projects that are actually going to be released.

If you want to find people who will be great at computer science, you need to start at the high school level. I'm convinced that students who take any type of programming class in high school have a huge advantage in college. If you want more females to major in CS, start teaching them CS at the high school level. This panel would of been great for high school students, not for college freshman.