Had a funny problem today. I’ve written a spec (tests) for a code that should have iterated over a collection of items and with some conditions do a yield return for each of them.

In it’s form, its a very simple piece of code, but somehow I could not for the light of me get the spec (test) to pass. It always seemed that the code didn’t even execute… I kept thinking to myself, WTF? This code is simple, and it does what it needs to!? Why doesn’t it pass? (as you can imagine I got a bit frustrated).

Then I remembered one *small* bit… yield return coupled with IEnumerable provides the deferred execution for my code, so this example:

When called like this in my spec (test):

Actually does nothing at all, so my specs would fail… it was really frustrating.

What can be done?

Actually, three things:

So:

s1) We are enumerating like we are expected to. This will execute the functionality

s2) We are manually assembling the enumerator and asking him to call our functionality

s3) We are feeding the deferred execution functionality to a new List which internally then executes it

I personally prefer and use option 3 now.

Hope this helps someone, it sure would me if I’ve remembered it out earlier.

Cheers!

So, quite a simple rule… someone likes it, someone doesn’t.

I’ve seen over and over these kinds of examples:

This is probably to simple of an example, but should prove a point.

To some extended, this code (because it’s stupid and simple) could be converted to:

But what I would advise you is that instead you fail early with the logic instead of branching and complicating the code like above (keep in mind once more that that above is too simple of an example)

How would you fail early in this case?

What do you think? How do you do it?

Cheers!

A question came up on the Alt.Net mailing list asking why would you use IoC and Containers.

I think Ayende summed it up real good:

“Is is a pattern that is useful when you are already doing the right things, then you begin to feel the pain of managing all the moving pieces, at which point the container comes in and manages that for you.
I’m going to have a post about it soon…”

Enough to say that I’ve felt the pain… and used the pain killer

It’s a great idea, and when I’ve implemented Windsor on the project I am working on currently, it has helped me a great deal.

My next step is to replace XML configuration with Ayende’s great Binsor.

Cheers!

Well I would rather say, fluentish interface as it is only a tiny implementation of the idea.

As you might know I am against switch statement + enumeration combination in once code… I became grown to a habit of getting that unpleasant feeling in my stomach when I see that in code. Not that I don’t like the language constructs as such… but simply, often when they are a sign of bad programming practices which I’ve done (hopefully only in the past if I can help myself) and see other people do as well.

So, a little bit more concrete. You often write something like:

Lets say this is the standard way of doing it.

Some of the problems I have with this approach is:

• When adding a new timeout value you are doing changes in more then one place
  (enum + dreaded switch, not to mention if you have to repeat the logic somewhere else)
• It’s not as readable and as clean as it can be

The other way that you could do it (which I like much more then the previous one):

Now this I like

Hope this give you some ideas for your own code.

Cheers!

I often see how developers do the same mistake over and over again.

This time it’s concerned with using the magic numbers in the database.

Often you get a request to realize something like:

“If a given piece of data is in positive status 1 or 101 then do this or that” or “Export all data which is in the positive status 1 or 101″

Usually what I see as being done then is:

Now think about what happens when the client calls you in 3 months from now asking to add another positive status?

Probably you will need to *hard code* it’s positive status in half a dozen places and then even forget about a couple of them… argh… awful.

What can be done?

Well, you can introduce your own level of abstraction - or better said - classify your statuses to avoid maintenance nightmare.

Now you can create your “Positive response” status classification in the Status Classifications table, and connect it to the current and future statuses pretty easily through the third table StatusClassificationStatuses.

Also, then you can do a better and cleaner query with something like:

This way your code doesn’t depend on the clients direct changes but on your abstraction - which in my book is a lot better.

As you can see this is a very simple and effective way to get yourself out of some bugs and issues in your applications.

Cheers!

While talking on DotNetNuke forums, a few of the guys asked if they could see the VladanStrigoNET.HttpModules.EnsureScriptManager source code.

As I understand the concerns of the guys from the community, and their desire to see how the HttpModule works, I’ve released the source code.


As with the rest of the bits from my Ajax implementation in DotNetNuke, you can find it on the start page of my Ajax in DNN project (in my Projects section).


Enjoy!

While going through my blog list, found some articles that I would like to link here:

Jon Henning

• Researching MS AJAX: PageMethods
• Researching MS AJAX: ScriptControlBase and Callbacks

Eilon Lipton

• Attributes to consider applying when writing a custom control

Enjoy!

While talking to one of the users of my new MS Ajax & DNN implementation approach, he mentioned (thanks Kevin :)) a small bug in the HttpModule.

The module was outputting the ScriptManager to ALL .aspx pages, and as it needs to be added to the HtmlForm, when it came over Logoff.aspx page (which doesn’t have a HtmlForm)… it simply broke.

I’ve fixed this issue pretty easily… by limiting the output of the HttpModule to only Default.aspx page and now everything works great.


If you need a new version of the EnsureScriptManager HttpModule, you can visit my DNN & Ajax project in the Projects section and download it.

Cheers!

As promised the first part of the tutorial series on how to best implement Microsoft Ajax with DotNetNuke 4 is released!

The first part is focused on the changes needed to be done to DotNetNuke to make it enabled to run Ajax code and functionalities.

As with BlankModule, this guidance is a new project of mine, and can be found in the projects section of this site…


Cheers!

For some time now I have a need to sumarize all my resources on certain subjects. This need has been capitalized today by opening a new section of this website called “Resources”.

Currently it only has DotNetNuke 4 Module development resources links, some of the sites and resources I’ve encountered in recent time.

The current page, and the current resources are only the starting point… I hope to put there every interesting resource I encounter duirng my work, for both you and me to have reference to in the future.


One more thing… as currently only the DNN 4 Module dev. section is opened, I am currently only accepting links for that part. So if you have any resources on module development that are interesting, and not mentioned there… feel free to email them to me via the contact page.

In DotNetNuke we have a specific situation, we develop modules for a bigger system which we cannot change that much… Unfortunatly that system cannot be changed that easily to add Ajax required functionalities, the easiest thing (without changing the core of the project) is to do changes to web.config.

In that purpose… if you want to use Microsoft Ajax in your modules (or in any other similar enviroment) you would need to be able to change web.config only. So how to succedeed in doing that?

Obviously the biggest problem is the ScriptManager, because it needs to be present in every .aspx page (DotNetNuke has only one… Default.aspx) for Ajax to work.

One workaround I found is to write a HttpModule which does the ScriptManager insertion in the request pipeline so that Ajax can work.


You can download this HttpModule here:

VladanStrigoNET.HttpModules.EnsureScriptManager.zip


You need to place the dll in the bin directory and add this to your HttpModules list in the web.config file:

name=“EnsureScriptManager“ type=“VladanStrigoNET.Web.HttpModules.EnsureScriptManager, VladanStrigoNET.HttpModules.EnsureScriptManager“ />

and it should work (it does for me :))!


If you still don’t understand “the big picture” of implementing Microsoft Ajax in your modules, don’t worry I am planning to write a guidance article which will explain the complete thing

One nice link I found this morning, it’s a site that has great cheat sheet documents on all the various subjects:

- NET Format String Quick Reference
- ASP.NET 2.0 Page Life Cycle & Common Events
- Visual Studio 2005 Built-in Code Snippets (C#)
- ASP.NET Page Life Cycle Diagram
- Visual Studio 2005 Default Keybindings C# | VB
- Microsoft ASP.NET AJAX Library
- VB.NET/C# Comparison
- HTML Character Entities
- CSS
- JavaScript
- XHTML
- Regular Expressions
- Microformats
- ASP/VBScript

Look it up, it can be really usefull:

http://john-sheehan.com/blog/index.php/net-cheat-sheets/


Cheers!

With the 1.0 version of Ajax behind us, my company is looking into aspects of integrating MS Ajax into our future applications.

One thing that we’ve asked ourselfves is, well this is all great…. but what about security? We do all these nice web service calls, out of band requests… how does that relate to security issues?

So, I’ve digged a little into the subject and found some articles that might be of interest to you as well:

Top 10 Web 2.0 Attack Vectors
http://www.net-security.org/article.php?id=949

AJAX Security Talks
http://blogs.msdn.com/brada/archive/2006/12/18/ajax-security-talks.aspx

App security tools target Ajax vulnerabilities
http://searchappsecurity.techtarget.com/originalContent/0,289142,sid92_gci1189575,00.html

[UPDATE 26.01.2007]


Upcoming AJAX Security Webcasts
http://www.joeon.net/archive/2007/01/12/Upcoming-AJAX-Security-Webcasts.aspx


[/UPDATE]


These are by far only the starting point resources… when I found some others I will point them to you as well.


Cheers!

Well I suppose that by now we all know that live applications should have this set to false (debug=false)!

But why would we do this?

2 great articles have come up with this answer:

Tess says: “ASP.NET Memory: If your application is in production… then why is debug=true”

and also:

Scott says: “Don’t run production ASP.NET Applications with debug=”true” enabled“

both of these great articles from MS guys (and girls :)) explain the exact reasons why you shouldn’t do this!

So I’m currently finishing up an improved FileSyncronization routine for DotNetNuke. As in DotNetNuke, information about all files on the file system is stored in the database (not files, only info about them!) the process works in a way that the application retrieves all files from the database in a DataTable and then iterates through files and directories on the file system and compares each file to the records in the data table. Depending on the file in the data table it determines the action to be executed with the file – Create, Update, No Action and later on in the process executes the appropriate action based on the mentioned mark.

Now, I’m doing my tests on 2000+ files in one portal, with simultaneous running of both the scheduled job and the manual synchronization run, which in total runs the synchronization routines for some 4000 times in one test sequence (2000 are synced with the scheduled job and again 2000 manually)

I’ve gotten it almost fast enough for our needs, it does both the manual run and scheduled job run each in some 45 seconds (previously it was some 5 minutes), but greedy as only a human being can be… I wanted it faster! J

So I’ve fired up the profiler and went digging…it turned up that there were 2 hotspots on which I can influence:

1. DataTable.Select – I will leave this for some other post
2. Image.FromFile

So now we get to the point….

As in DotNetNuke along with the file info also the routine checks and saves the info on a potential images (if the file is an image, its height and width are saved along with it’s info) it uses the following code piece to do it:

Dim imgImage As System.Drawing.Image

Try
imgImage = imgImage.FromFile(sourceFilePath)
With imgImage
imageHeight = .Height
imageWidth = .Width
.Dispose()
End With
Catch
contentType = “application/octet-stream”
End Try

When profiled the application I got the following results (on 3 test runs) for the bolded function above:

So I went looking if I could find an alternative for the same functionality, and discovered it in the bitmap:

Dim imgBitmap As Bitmap
Try
imgBitmap = New Bitmap(sourceFilePath, False)
With imgBitmap
imageHeight = .Height
imageWidth = .Width
.Dispose()
End With
Catch
contentType = “application/octet-stream”
End Try

This one worked fine (it gave the same dimensions of the picture, it didn’t brake and such), and gave me the following info when being profiled:

So as you can see, on average the bitmap snip. has shown itself to be some +- 30% faster than the Image.FromFile in this scenario!