# Friday, August 03, 2007

This is not how I want to find out that my mosquito zapper bat hasn't been killing mosquitos.

mosquito

Look at all the marks!


Friday, August 03, 2007 1:16:14 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Comments [1]  | 

As I stated before in my post about Citibank's INSANE security features, sometimes being TOO secure just ends up frustrating the users. Here's another example of security that *might* be a bit too much.

A Silverlight plugin is able to go into fullscreen mode and basically fully takeover the display of your system. Therefore in order to ensure that people aren't able to easily spoof you  into thinking you're actually visiting your bank's website or anything like that... well I'll just paste the paragraph from the docs.

Once a Silverlight plugin is displayed in full-screen mode, keyboard events are prevented from being passed on to keyboard event handlers in the application. The only valid keyboard input that is acted upon is the set of keystrokes that return the Silverlight plugin to embedded mode. This limitation of keyboard input during full-screen mode is a security feature, and is intended to minimize the possibility of unintended information being entered by a user.

In english it basically means that when the Silverlight plugin is in fullscreen mode, all keyboard input is disabled. Drastic? YES. The scary part about this is that, I actually think it's a GOOD idea, cause it basically means the user won't be presented with a screen where they think they're logging into the bank and then just merrily key in their username and password.

Yes, they could just present the user with a soft keyboard but hopefully the user's are smart enough to realise that they keyboard isn't working at all so something must be up.

Would you rather there be a constant watermark when Silverlight is in fullscreen mode to tell people they're viewing a plugin and not their actual desktop?


Friday, August 03, 2007 12:20:16 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Comments [0]  | 
# Thursday, August 02, 2007

Today after I came back from work as a fugitive my mother told me something that just added to my problems.

She heard WZ crying through the baby monitor and thus ran into the room and saw... NOTHING on the bed. But she could hear WZ crying, she got down on the floor and found WZ sulking UNDER the bed. Yup.. WZ fell OUT of the bed. Strange thing was that there were no marks on his body indicating how he fell off.

At night just night while I played with WZ on the bed I noticed that if he timed his flailing of his arms properly he'd catch the edges of the bed railing and thus be able to push himself over the railing and onto FREEDOM!!! Freedom followed by a fall to the concrete floor below that is....

Shit.... I don't need this right now!!


Thursday, August 02, 2007 9:53:46 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Comments [0]  | 

Oh god... now I've done it!!! I'm now a fugitive on the run, running from a most heinous crime!! My friend recommends that I go turn myself in or face the consequences.

Fark!


Thursday, August 02, 2007 8:52:23 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Comments [0]  | 
# Wednesday, August 01, 2007

Hmmm, what would be the best way to process 50000 records in a database?

Bruteforce :- Just run the query through a SQLDataReader and process them one by one. Simple, easy and straightforward. Unfortunately doing something like that would tie up system resources and processing pretty badly.

ThreadPool :- Same as above but, execution would be on a seperate threadpool thread. Which usually yields processing to the OS when needed.

MSMQ :- Put all the records into MSMQ and then have another thread do the processing, since MSMQ is in charge of releasing the items for processing. Processor load would not be 100% during processing, going this route requires the presence of MSMQ on your server and also the maintainence of a new private queue.

Chunks :- Process a number of rows.. say... 500 at a time, and then take a breather of say.. 10 seconds.. and then go again, because the code takes a breather the processor load is comparatively lower since it's not CONSTANTLY in use. Unfortunately, because your code takes a breather... since you're not processing all the time, you need a lot more time to finish the job.

Hmmm.. so which method should I use?


Wednesday, August 01, 2007 12:13:07 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Comments [1]  |