Wednesday, July 2, 2008

One Hundred Pushups: Day 2, Week 1

The number of pushups increased and I am on the highest level. I am still a little skeptical that I will be able to do 100 pushups by the end of the six weeks, but we will see. I felt stronger today despite the day break. I did a set of 12,10,10,10,10(max). I did an extra set on accident but it won't hurt. On Friday, the sets will be 15, 13, 10, 10, 15. I continue to eat healthy and have at least a serving or two of fruit at every meal. Have not drank soda in a while and starting to get caffeine headaches. Snapple is a good replacement to help ween me off soda.

Monday, June 30, 2008

One Hundred Pushups - Week 1 Day 1

I started out on the one-hundred pushups program. I can usually do about 43 pushups in one sitting and I want to increase my overall output up to 100 (if possible). I stumbled upon the website: www.hundredpushups.com and instantly got hooked. I don't think I will have too much problems with the program, but I think the hardest part is maintaining the hundred sets after I am finished since the program does not continue past six weeks.

Wednesday, May 14, 2008

Why Timers Suck (and Why You Shouldn't Use Them)

After working on this particular POS software for Parking Garages, I have become increasingly dumbfounded how annoying my predecessor was when it came to synchronizing different devices and the overall system. The software is polluted with annoying Windows Timer controls that run incessantly, checking status' constantly, and just eating up system resources. As the software grows more and more, the timers are becoming more bogged down and now I am faced with the latest problem....

A customer recently had a problem where the cash drawer keeps kicking. The cash drawer is connected via the receipt printer. Whenever the cashier needs to login to start his/her shift, logs out, or ends a transaction, the cash drawer kicks. There are several flags which determine whether or not the drawer is open or closed and whether the drawer was just opened and it is waiting for it to close. The problem is that on certain POS hardware, the processors are not so good and the timers themselves are not so perfect either. In this particular case, the drawer keeps kicking and clicking the relay annoyingly until the other timers finally get a chance to catch up and signal that "YES, the drawer is open".

Which leads to me to my point about Timers. The Timer control that I inherited from this piece of junk software is based on a Timer control distributed with Borland C++ Builder 5. Unfortunately, I am locked into C++ Builder 5 at the moment because there is no time to switch to C++ Builder 2006 or 2007 and we are not sure if QuickReport is supported in that latest version. I am reminded by a poster's question at the "Joel on Software" blog (http://discuss.joelonsoftware.com/default.asp?joel.3.224702.17):


"In our current project, we need to trigger a event every second. We've got to
make it to one millisecond accuracy.I tried the CreateTimerQueryTimer and the
multimedia timer. It seemed that the former could do better than a 15 ms
occasionally (15 being the ressolution of the system timer); the latter did
better but ate a lot of resources when I set the resolution to 1 ms. And no
matter what we used, if there were a lot of concurrent processes, the timing was
not accurate.After some testing, we conclude that it is impossible to guarantee
a 1-ms accuracy for time events under normal Windows XP environment. But before
we tell our boss this, I'd like to listen to what the experts will say to this.
So I post this and hope you can give me some suggestions.Postscript: I've
googled and I've read MSDN, Systeminternals, the codeproject tutorial and a
couple more; still cannot find an answer.Thank you. "
Unfortunately, Win32 does not seem to be a RTOS, but there has to be a better solution?

"It's not just the accuracy of timers that you are concerned about here. To
respond to the time event without delay you need your program to be given
the CPU immediately, no matter what other things the system might have been
doing at the time. Amongst other things, that means your code needs to be
locked in memory, and the operating system needs to prematurely suspend any
other operations that may have been in progress when your event is
triggered, so you can be given immediate control.If you use Windows XP a
lot, you will notice that disk activity often gets given priority over
anything and everything else on the system. That is going to kill real-time
performance stone dead. "

So maybe threads are the answer? It needs more investigating.