Well, the security company came and went without much of a problem. So I guess I survived my first code review pretty well with no major problems reported.

Experience, and of course this book (absolute must read for ANY programmer) helped ensure that our code was pretty tight (yes it wasn't perfect, but we did very good).

Best quote from a member of the review team.

Generally .Net code has fewer security problems.

I know a few people who would love to have you make that an official statement. ;)

I just conducted an interview just now. The interviewee mentioned that he knows ASP.Net 2.0, the MS Ajax Toolkit, and Ajax via Javascript. And yet everytime I probe him to see how much he understands the topic, he back pedals and says he doesn't know what I'm talking about.

Then after all that he says something about my voice, and that he can't concentrate and needs to go to the bathroom. When he comes back he tells me he isn't feeling too well and has to go...

On one hand, maybe he wasn't feeling too well. On the other hand maybe he was just trying to put up a good image during the interview when I asked him what he knows and just said yes to everything.

Update : It seems like the guy was sick, he felt that it wasn't nice to cancel the interview and decided to wing it even though he was having a high fever. Hmmmm.. not sure how to look at his choice of priorities.

We need to cater for people who don't read instructions.

So? Our application is supposed to encourage people that it's ok to do anything they want because they can't read simple instructions?

I'm gonna chalk this one up on my own inexperience but... AAAARRRRGGG... Visual Sourcesafe, how you pain me so much!!

The Malaysian leg of Tech Ed will be held next week at the KLCC (Convention Center, not the shopping mall) And I'll be there to take lead of the ASP.Net Atlas Instructor Led Lab.

But as a pre conference event there's a little party happening at Bangsar Village on the 9th. There'll be lotsa fun & games, coffee...(since it's in a Starbucks) and LOTSA EXPENSIVE PRIZES (that's what the organizer tells me lar) So be sure to check it out if you're a member of the industry.

More details here.

This is just something that seem to be causing confusion among some people. When MS came out with the four new components to the .Net Framework which are.. Windows Communication Foundation, Windows Presentation Foundation, Windows Workflow Foundation and Windows Cardspace. I'm guessing they didn't want to give it a spiffy name like ".Net Advanced Features Pack" but they couldn't exactly just slip it into the 2.0 framework then called it .Net 2.5 (cause usually a point release doesn't come with new features... I think)

So they decided to call the new modules the .Net Framework 3.0, and I was fine with that.

Until now when a client is telling me that they want me to upgrade an old application written in 1.1 to 3.0. I keep telling them that they are not using 3.0 bits in the program, but they keep telling me that the MS consultant that talked to them recommended them to use the latest version of the framework and not use a product at the end of their lifecycle (ie. .Net 2.0 in this case)

I wonder if the guy knows that because .Net 2.0 is included in Windows Vista support will last as long as Windows Vista is supported (if i remember how that's calculated) in this case.. 12th April 2011 so how the heck does a 4 year lifespan make .Net 2.0 an end of lifecycle product?

I want the page to load in 5 seconds.

That's one of the scariest requirements your client can give to you for a web application. Cause the main thing is... WHERE are you going to count the 5 seconds?

From the server? so you get 5 seconds of processing for the page?
From the client's office? but then how would you account for any proxy problems, or other network connection issues inside their office, say maybe some colleagues are downloading stuff through BT or something?
What if their ISP just isn't able to give them such performance?

Therefore I would prefer if they asked that the page has content loaded within 15 seconds, not including the other parts of the page say images, scripts, etc. etc.

But... it's always hard to convince them that the internet isn't magic and they can't expect the page to load THAT fast!

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?

I have this funny feeling that I've actually posted something like this before... but hey, it's an interesting topic.

As an ISV that works to serve the client's needs and there are many times where we are presented with a requirement where we KNOW it's a critically bad idea which would generally cause a lot of usability problems should we go ahead with the requirement.

But... the client doesn't listen, even though we were brought in there in the first place to advise them as well as develop the system.

Even worse is when the client just puts their foot down and says "You just do what we tell you to do!"

That's when we do what the client tells us to do, but we try our best to take the necessary precautions so that if the problems crop up it either doesn't hurt the system that badly or we can apply our fixes as quickly as possible.

That is... unless the problem is formed at the very core of the system and since everything is built around the core... there's no easy way to fix it once it goes down.

At times like this I really wish that I could just tell the client Look, we're trying our best to help you here, can you please just listen to us? We are looking out for your best interests too you know.

We shouldn't stop thinking about implementing the feature just because of some security concerns.

So.... If we shouldn't stop implementing a feature due to security concerns, when DO we stop? When something happens and the customer starts complaining?