Hi,

Great post that gathers around 100+ resources that could make the web developer life much more easier; code snippets, sites that automate processes, cheat sheets and more and more...

This priceless list is listed here.

BTW, don't become confused from the first image - I also know that this is not a common vision in our world of code... ;)

I read a great article about performance and scalability. Some of the issues there were helped me a lot and the rest were sharpen my knowledge.

So, if you are an ASP.NET developer (beginner or senior), It is recommended for you to read that one by Omar Al Zabir at the codeproject site here.

Some if the things that he talks about are: ASP.NET pipeline optimization, Things you must do for ASP.NET before going live, Caching AJAX calls on browse and more...

Worth a reading...

By the formal definition, Microformats designated in the first place for humans and just after to machines. Actually, this is a set of simple informational formats that based over generic and well unified standards. This set of formats comes to simplify common problems into a behavior and common templates (like XHTML, XML etc...).

The main goal of this formats is not to invent a new language or force these kind of changes over the 'world', however it comes to adapt a different way of thinking regarding storing information and publishing it to the world.

I going to apply this set of formats in my new web 2.0 working application. By doing it I can publish to a third level party data from my site easily in unified structure.

So what is the main different from what we have today?

Today we are using XML structure in order to keep data and to publish it or even publishing a specific  API that will explain the consumer the way she can retrieve the data. These kinds of solutions spends the developer's time that wants to get the data (she has to learn the API in order to use it); the Microformats comes to save up this time because it's a well know formats.

You can use RSS or some other feeds you'll ask not? In fact yes! BUT, these Microformats has a variety of patterns that help you publish extended unified structure data which supplies you more functionality.

Common standards are: hCalendar which supplies a calendar format in order to publish events, hCard which is a format for personal details card.

One more good advantage is search engines. Step by step, search engines crawlers starts to learn this kind format and knows to index this data in efficient way; this is also improves your site's SEO.

More details regarding it you can read here - http://microformats.org/

I have a problem (or used to have a problem...). In my working on web 2.0 startup, I bumped in a problem which in first thought looked to me as a simple one but after something like 5 seconds I figured out that it's actually a problem (or something to think about - I like this phrase much better ;)).

So after this introduction, lets introduce the 'something to think about' issue: I had to run each period of time a set of tasks in order to update some database statuses. If my web application was hosted on a dedicated server, this one had be solved very quickly; windows service - I guess you thought about it yourselves...

BUT, we are not going to host this web 2.0 application in a dedicated server (at least not now) and the scheduled task became a task itself, because (if you are web developers you'd better know) application is lives as long as there is at least one client that consumes it. When the last consumer is going home, also the application in going home to relax...

Now to the main question: how can we keep it alive?

After doing some thinking between me and myself, gathering up some good resolutions and not I thought about good one; in your web application create a web service that most of its job is to expose a KeepAlive web method that will return a dummy value and will keep the web application alive all the time and also will perform the tasks that you to establish for permanent period of time.

In your local PC, create a small desktop application in order to handle the tasks. This application will be a windows service that will run automatically under your machine every X interval and will ping the web service in order to keep the web application alive.

Note: the web service itself will know to execute the specific task itself every predefined period of time.

What about performance? This solution could affect your web application performance (I think that you know the reason why), in this case you can create another wen application that will be placed in the same server and all its job is to be kept alive and perform your tasks.

Any addition will be appreciated... I am going to write this web service now...

I am working now on a large web application, that need to be used by more than one websites (at least 5 of them, websites and web services), therefore I have needed to do some isolating here with my main core projects.

Some background...
I have a common assembly (web application) that holds only the user controls, server controls and custom controls, which need to serve the all other web applications that are using them. This assembly has a reference to the other web application in order to have some information about some properties, session variables and global members, by this information, it knows to gereate some actions on runtime (or even in design). BUT, in the other hand, this web application need to use the controls that the first assembly has published, here we have a problem, we got a circular references, which is now allowed in .NET framework, also it isn't allowed anywhere I think...

So, how we gonna solve this problem?

The solution is quite simple and is known as Seperate Interface Pattern. (Click here to get some more info).

The main steps to implement it are:
Let define a project that called ProjectA and holds the user controls (etc...) implementations along with InterfaceB. ProjectA would maintain a reference to InterfaceB, which will hold any properties such as members, methods, events etc...

Now, lets define ProjectB which will implement InterfaceA. Now, ProjectB would reference ProjectA and (BUT) ProjectA would not reference ProjectB of course.

The result, ProjectA can access to ProjectB's specific exposed members and ProjectB can use the controls of ProjectA.