Archive for the ‘Using’ Category

Outlook Taking Hours to Download Email

Wednesday, March 21st, 2012

JIC it helps anyone else out there.  For no apparent reason, Outlook 2010 started taking hours to download emails that usually came down in minutes.  And when I say hours, I mean 3-5 hours!  The app would remain responsive for the most part, but would consume 100% of a CPU/core.  It would download a number of messages and then just pause for 45 minutes or more.

Turns out that the problem was my configured %TEMP% directory was filled up with almost 65,000(!) entries.  An automatic update of my Antivirus software failed, and started looping retry attempts.  This filled up the temp directory with little 1KB  files until it crashed.  It also filled up my event log.

Seems that Outlook gets really cranky when it has trouble with its temp directory.

So if you suddenly start having strange issues like this with Outlook, make sure your temp directory is not too full.

Another Downside of Browser-Based Apps

Thursday, November 20th, 2008

I once again find myself having to use a web-based application. This is a often just a fancy name for a bloated set of code that provides a little more functionality than what a set of CGI scripts could provide.

The beauty of CGI apps was that they were often very succinct – they were used to process relatively small amounts of data that were entered in a small form.

Today’s applications give you multiple form fields and expect you to enter larger amounts of data. Some even play fancy DHTML tricks to allow you to dynamically add more fields so you can enter even larger sets of data. Nice, huh?

But what happens if that server goes down while you are entering all that data? Or if the people operating the site do not take into consideration just how long you can be entering data into one of their pages? You usually do not know about this as you are entering the data, and usually are not aware that you are about to lose all of that data you just entered until you press [Submit] and get back an error — too late!

Now, I do not script web pages, so I could be wrong about this… But we are in a world where we can play all kinds of fancy AJAX tricks, so why the HELL do web scripters (not developers, that term is reserved for people that do more than just write fancy client-side script) not just put a little AJAX code that keeps hitting the server to do things like (1) make sure it is still alive, (2) check for impending session timeouts, (3) and other stuff that make web apps appear more robust and professional?

Having a warning that the server has gone down before I submit some data would be great – I could copy my data to Notepad and then get it back when the server comes back. Now, this would be harder for pages that contain too many fields, but that is another indication that your app needs a better platform.

IIRC, even 3270-based form-style applications could handle server disconnections better than today’s equivalent browser-form based applications — at least they had an icon on the status line to indicate session state! That is the ironic part about this… not only did we take a giant backward in UI evolution, but we completely missed the robustness that those older applications had.

Hurray for progress!

Remember kids – while lots of applications can work in a (D)HTML/AJAX browser-based interface, not all of them can work WELL in that interface. Read up on what happened when someone tried to port Lotus 1-2-3 to a 3270-style interface… Wanna guess how well that went?

Why Performance is Important

Saturday, January 20th, 2007

When discussing topics like optimization and performance, there are far too many developers that either believe that performance is not important(!) or that the things taken to optimize the performance of something somehow magically results in making that system less robust.

For the first point, I can not image any developer that has ever uttered the words Damn, this thing is slow regarding their computer or a particular software application running on it, ever thinking that performance is not important. By the fact that you are complaining about somethings performance, that means that performance is important. Or at least, important enough to complain about.

For the second, there are lots of ways to optimize something, and none of them have to directly result in reduced robustness. One of my favorite examples, which is to prefer stack memory over heap memory, can actually improve the robustness of software – it reduces the possible places where exceptions can be raised and thus lessens the chance for exception mis-management to cause problems.

One of the things to remember before opening your mouth to say that performance is not important is to remember that your compiler still optimizes things to the best of its ability. Newer generations of compilers often offer more and better optimization capability as well. Why is this? It is because performance is NOT important, and the compiler writers wanted to just waste time?

When a new processor architecture is made available, manuals that detail that architecture are produced that often specify the best way to utilize that new architecture. Cache utilization, multiple execution engines, out-of-order execution, register allocation, store/load stall scenarios, etc are usually covered in great detail so that all of the capability of that new architecture can be used to its fullest potential.

Again, was that material written just to waste time, or does someone out there know something that you do not – that again, performance is important.

One of the things that today’s developers may often forget is that while their software is running on better hardware, it is also running along with other software applications. For you Windows users, have a quick look at your Task Bar, and SNA area (often mistakenly called the tray). How many applications are you running? Have a look at the process list in Task Manager and see how many processes are really running.

Now compare that value to how many applications you were running simultaneously on previous versions of Windows – 2000, NT, 9x, or even Windows 3.1. As our hardware gets better, we expect to be able to do more with it. But when that many applications are competing for shared resources (CPU, memory, etc.), the specter of performance once again rears its ugly head.

Just like writing device drivers takes a different discipline than writing desktop applications, writing software that has to execute in a shared environment is different than writing software that runs in a dedicated environment. The average desktop developer cannot forget that their software will not be running in an ideal environment, and that just because it works great on the clean demo system, or the developer’s multi-CPU box with 4GB of memory does not mean that its performance is good enough when it hits the target user’s system.

I want to meet the developer(s) of Sybase SQL Advantage…

Tuesday, December 5th, 2006

Version: 12.5.0.3/EBF 10752 IR/P/NT (IX86)/OS 4.0/Wed Jan 15 12:59:30 2003

Why? Because I want to ask them why it takes SQL Advantage ~16 seconds to process a query that returns 674 rows of ~70 columns each and display them in Grid or Text output, when I have written an application that goes through two additional API layers above the CT libraries, and can do the same thing (even in a Grid) in less than 2 seconds?

You actually have to go out of your way and TRY to write code that slow – that kind of lousy performance does not happen automatically. That is the kind of stupidity that has to be cultivated through bad practices.

I just want to know how someone could write such an app, and consider it suitable for release to the public. I need to know the mindset behind that, so I know what questions to ask potential employees during an interview so that they can be weeded out. I do not even want to sit next to someone like this, for fear of them making be dumber via osmosis.

I can only hope that the GUI developers are not the same ones that implement the underlying libraries or the RDBMS itself…

Worst… Spam… Ever…

Saturday, October 28th, 2006

So while browsing through my spam-basket I came across an interesting message that was caught by SpamAssassin.  The headers from that message follow (edited slightly to remove addresses and to emphasise details):

Subject: §Ú¬O¤@­Ó·Å¬Xªº¨Ä¨Ä¤k«Ä.·Q´M§ä¨ë¿Eªº­ô­ô±z³ßÅw¶Ü?¡ð20·³
X-Spam-Status: Yes, score=63.4 required=5.0 tests=BAYES_99, DATE_IN_FUTURE_96_XX, FORGED_MUA_EUDORA, FORGED_QUALCOMM_TAGS, FROM_ILLEGAL_CHARS, HEAD_ILLEGAL_CHARS, HTML_30_40, HTML_IMAGE_ONLY_08, HTML_MESSAGE, HTML_MIME_NO_HTML_TAG, HTML_SHORT_LINK_IMG_1, MIME_BOUND_DD_DIGITS, MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE, MSGID_SPAM_CAPS, NORMAL_HTTP_TO_IP, RCVD_DOUBLE_IP_SPAM, RCVD_IN_BL_SPAMCOP_NET, RCVD_NUMERIC_HELO, REPTO_QUOTE_QUALCOMM, REPTO_QUOTE_YAHOO, SUBJ_ILLEGAL_CHARS, UNPARSEABLE_RELAY, URIBL_JP_SURBL, URIBL_OB_SURBL, URIBL_SBL, URIBL_SC_SURBL, URIBL_WS_SURBL, X_IP, X_PRIORITY_HIGH autolearn=spam version=3.1.7
Date: Tue, 19 Jan 2038 11:14:07 +0800
X-Spam-Flag: YES
X-Spam-Level: **************************************************
From xxxx.xxxxxxxx@xxxxxx.com.br Tue Oct 24 16: 43:51 2006
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on xxxxxx.xxxxxx.com
Message-Id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Content-Type: multipart/mixed; boundary="----------=_453E7B09.452041D8"
To: support@xxxxxxx.com.tw
From: mailto:¼ÐÃD¡G¡m¥¨¨Å°Ï¡n·s¼W¡m»a¤«ªÅ¡n±j¥´·s¤ù¡A¤ù¤¤¦³¦o¸g¨åªº¼é§jÃèÀY¡I³ôºÙ¥L§@«~¤ºªº¤W¤W¤§¿ï%20(¡m¥¨¨Å°Ï¡n·s¼W¥i·Rµ£ÃCÄ_¨©¡m»a¤«)

I can honestly say – that has got to be the worst message I ever received.  Most of my spam emails never get above a spam-score of 20!  What gets me is that the sender of the message somehow managed to completely mess it up.  So this is an example of the fourth (I think) rule of software development – always test what you are doing (or trying to do)!

I mean, come on now… If you are stupid enough to construct a message that sets off that many spam-traps, you really are an idiot!  It is things like this that give me hope that we will eventually win the war on spam.  Hell, look at the kinds of people we are fighting! :)