A as in Hay

We recently got a comment about this exercise.

Oh my gosh!

“the dog has A furry paw.” A as in HAY??

I spent a lot of years in the elementary classroom trying to soften that pronunciation to “uh” instead. Middle school and HS too!



It could be our Midwestern accent, but there are many occasions where we prefer the long a to a short one.

Long a used for emphasis (or surprise).
We had a wonderful time at your party.
I hadn’t seen her for a while so I gave her a big hug.
I didn’t study and I still got a B on the test!
Guess what? I got a car for my birthday!

Long a used in enumeration to indicate just one of something.
We took seven bats and a ball to practice.
She had pens, paper, some textbooks, and a sandwich in her backpack.

Almost always when starting a sentence.
A speeding car almost hit the kids.
A penny saved is a penny earned.

And sometimes, it just sounds better to use a long a.
Congress met on New Year’s day to avoid a fiscal crisis.
This is a fine mess you’ve got us in Ollie.

In this particular case, we were probably just being consistent with the short phrase.
We are trying to get the initial p pronunciation and the short phrase is: a furry paw
Since it has a long a, when we said the sentence, we probably just used the same intonation. Although, we could have unconsciously been applying the first rule, and used the long a for emphasis.

And possibly.

I suspect the real reason I said “ae” is because when you read that many sentences sometimes you switch to the decoding only mode and don’t say it as if you were speaking it. It is easy to over articulate as well. I have a note from a teacher in college that gave me an A- because of my “over precise speech.” Think I might still frame that!

Using an NSDictionary as an argument to a method.

I have a series of animated scenes that I am adding as rewards to my apps. The animation takes place on three layers at the moment, but I keep adding layers and every time I do that I have to change my method definition and all the method calls. I decided to put all my arguments into an NSDictionary so that I don’t have to keep changing the method.

This is the original code.

NSInteger numRewards = 10;
NSInteger randomReward = arc4random() % numRewards;

if (randomReward == 0 ) {
    UIColor *backgroundColor = [UIColor colorWithRed:102/255.0 green:204/255.0 blue:255/255.0 alpha:1];
    [self animatedReward:@"Boat"

Every time I add a layer I need to change the method. And all the method calls. By making it an NSDictionary, I can play around with layers, and anything else I want to add, without having to change the method each time.

NSInteger numRewards = 10;
NSInteger randomReward = arc4random() % numRewards;

if (randomReward == 0 ) {
    UIColor *backgroundColor = [UIColor colorWithRed:102/255.0 green:204/255.0 blue:255/255.0 alpha:1];
    NSDictionary *partsCounts = [NSDictionary dictionaryWithObjectsAndKeys:
                                 [NSNumber numberWithInt:4],@"foreground",
                                 [NSNumber numberWithInt:3],@"moving", nil];
    NSLog(@"Parts counts%i",partsCount);
    [self animatedReward:@"Boat"

The method is declared as:

- (void)animatedReward:(NSString *)scene
   withBackgroundColor:(UIColor *)backgroundColor;

Notice that the number of images in each layer are stored as NSNumbers in the dictionary. That’s because NSIntegers aren’t objects. To get the integers back out of the dictionary, you use this line.

    NSInteger foregroundCount = [[partsCounts objectForKey:@"foreground"]  integerValue];

Command line tips and tricks

While cleaning up my server recently I found that stringing together several commands with pipes made it easier to check logs, find defaults, and remember Linux commands.

I don’t do a whole lot of things from the command line, so when I want to do something that I’ve done recently, I just use the up arrow key to find the command from the last time I used it. If I’ve done a lot of work on the command line, the history command will save some scrolling. Here’s the tail end of a recent history command.

  499  exit
  500  history
  501  sudo grep sshd:session /var/log/messages 
  502  sudo tail -n 1000 /var/log/php/error.log
  503  sudo grep Authentication /var/log/messages | wc -l
  504  history

If I want to check the error log I can just up arrow a couple of times and then hit return. Or I could type !502 and hit return.

grep and pipes
I can never remember all the options for tarring up a file, so I almost always find the last time I used it and use the same command again. But it was a while ago and searching through 500 lines of history isn’t particularly efficient. That’s where grep and pipes come in.

history | grep tar

history normally displays on the default output, in this case the terminal. But you can redirect the output to another command or a file. I used the pipe | to redirect the 500 lines of history into the grep command and looked for the characters tar. Rather than displaying 500 lines, I got a few with restart and a coupe of with tar. The target characters are highlighted in red on the terminal.

  279  sudo /etc/init.d/apache2 restart
  280  sudo /etc/init.d/mysql restart 
  428  sudo tar -czvf ./mysql-backup.sql.tgz mysql-backup.sql 

While checking the messages log, I noticed that someone was trying to break into the server by sending login requests every second or so. I was curious about how many attempts there were, so I looked for the words ‘Authentication failure’ in the logs. Note that there is a space in the text I’m looking for so I need to put the search text in quotes. I then piped the result to the wc -l command to count the number of lines. There were almost 10,000 all from the same IP address. We changed our iptables config to only allow 3 attempts from the same IP address and then disable logins for a while.

493  sudo grep 'Authentication failure' /var/log/messages
503  sudo grep 'Authentication failure' /var/log/messages | wc -l

The output of 493 was thousands of lines like this—all with different users.

Jan  1 11:04:56 server sshd[12551]: error: PAM: Authentication failure for illegal user testtest from
Jan  1 11:05:05 server sshd[12564]: error: PAM: Authentication failure for root from

You can have multiple pipes as well. Here I want to check just the Authentication’s for Jan 3 so I cat the messages file to a grep that looks for Jan 3 (note the quotes) and then pipe that to a grep that looks for Authentication.

sudo cat /var/log/messages | grep 'Jan  3'| grep Authentication

Now that the logs are cleaned up, I check for successful logins with this command>

sudo grep Accepted /var/log/auth.log | tail -20

If there have been more than 20 logins since I last checked, I can make the number larger.

php error log
We have our server set up to put error messages into an error log rather than displaying them on the screen. Visitors to the site don’t care about the error messages and crackers can take advantage of the messages to exploit vulnerabilities so there is no reason to display them. However, if you are writing a new page or changing an existing one, you as a programmer can benefit from knowing where your code failed. When I’m coding I always have a terminal window open with this command running.

tail -f /var/log/php/error.log

One more grep command
When we updated to the latest version of PHP we started getting messages in the logs for deprecated commands. We fixed most of them, but the locations of others weren’t obvious from the error messages. Specifically, we needed to replace all of the places we used PEAR to access the MySQL database. So starting at the root of our website code I look for every file where we use the PEAR initialization code for MySQL. The -R in the grep command means to recursively search through all folders. You start with the current location and traverse the entire directory tree. Notice the * at the end of the command. I don’t want to look at a specific file, like I did in other examples, but want to look at all files.

grep -R initialize_db.inc *

Organizing the spice drawer.

We try to keep our code clean and commented but every once in a while we do some maintenance that falls into what I call “Organizing the spice drawer.” It’s not something that has to be done and the amount of time lost by not doing it is small, but it’s just one sign of a well organized shop. The same applies to our server, backups, and the office in general. This time of year is perfect for these endeavors because there’s not usually much else going on.

Log files
We set up the server logs to automatically archive and then delete themselves so we don’t have to worry about them. We do have some custom logging programs that write data to the MySQL database. They’re not huge, but we’ll never use more than a year’s worth, so they get manually cleaned from time to time. I just deleted 45,000 records from one database.

It’s a good idea to check what’s in here from time to time. We has some session cookies that weren’t being properly expired so we wrote a cron job to remove them. There were also some files created by a shell script that weren’t getting deleted, so we adjusted the script to remove them.

Every once in a while, it’s a good idea to review the settings in the php.ini file to make sure you are happy with them. In our case, we were getting warnings from two deprecated commands, register_long_arrays and magic_quotes_gpc and we decided to turn them both to Off since we don’t have any code that relies on them and the code that triggered the warnings is in WordPress. The WprdPress code works fine if the settings are Off.

BAK files and databases
Before we do any major change to a file or database we make a backup copy. These usually get deleted when we’re happy with the result, but sometime they stay around when they aren’t needed any more. For the database, I make a complete dump of the database to a .sql file and then remove databases that are backups. If I ever need them, I’ve got the backup in storage.

Our websites have been up since 1998 and we sometimes end up with files that are no longer referenced. If we suspect that a file is not used anymore we grep for its name in the web directory and if it’s not found we put a line of code in it that writes to the server when it is referenced.

error_log("Accessing Orphan File with referrer $refer");

If we reference it from one of our pages, the referrer will be our site. If not, then either it’s being accessed by a spam-bot or another website that has an old link to us. Either way, we can then deal with it.

Lately, spambots have been hitting just about every page with a submit button on it. They can’t do anything on those pages but I’ve started logging their attempts using the method described in Orphans above. If it’s a real problem we may start requiring CAPTCHAs or simple radio buttons that default to “I am a robot, please ignore this request”.

Error logs
When we updated to the latest version of PHP our database access method, PEAR, was deprecated. That generated literally thousands of error messages. Over time we updated the code, but there were still lots of errors generated for pages that aren’t accessed that much. With so many error messages, it’s hard to see real errors. So we spent a half day finishing off the update. Now the error logs only show the log messages that we want it to show and we can quickly check for errors.

We have a wiki for office procedures, how-to’s for ordering supplies, adding users, version numbers for our products, etc. This is the kind of thing that can quickly become out of date if it is not updated regularly. A couple of times a year, we review the wiki and make updates for changes to our processes that were made, but didn’t make it into the wiki.

Office Electronics
Do we really need 12 VGA monitor cables? Three turntables? The 12 year old computer that only runs OS9? The box of old hard drives—the largest of which is 5GB? We don’t keep a lot of stuff we don’t use but things get shoved under desks and put in boxes on the bottom shelf and forgotten about. Every once in a while we make a big pile of stuff and take it to the electronics recycling center. I have yet to regret throwing away anything.

We got rid of a complete shelf of books. I will never need the manual for Photoshop 4 or Flash 5. In fact, I haven’t used a manual for years, relying instead on the web for the answers to most of my questions. My guess is next year the other two shelves of books will be gone.