Bienvenue sur notre blog

Nieodłącznym elementem nowoczesnych stron internetowych jest JavaScript. Bardzo popularną biblioteką opartą na JavaScript jest jQuery. Posiada ona wiele gotowych pluginów,  dzięki którym tworzenie stron internetowych stało się szybsze gdyż nie musimy tworzyć kodu od podstaw.
Angular JS jest frameworkiem, który w ostatnim czasie zdobywa coraz większą popularność. Co prawda zawiera w sobie podzbiór jQuery (pod nazwą jQLite), jednak z różnych względów potrzebujemy skorzystać z pluginu jQuery.

There are times you feel so very stupid because you can’t do a simple thing… like for example making work a .gitignore file. I don’t know how much time I had spent looking into the guts of git commands before I realised what I’ve done. As you know you can’t really create .gitignore from Windows (or I don’t know how to do it). Every time I need this file, I copied it from another place, another project. This time I had a brilliant idea of creating it from the command line like this :

echo “packages/” > .gitignore

Well, that’s the problem. The file doesn’t work because it’s not encoded with UTF-8. So you have to encode and save it and everything works as expected.

This is the question I’ve been asking myself while confronted to a problem of building a web site and RESTful API at the same time. I’ve been told that I can’t build one and have both. Why ? HTML is just another media-type but what is generally used when building web sites is the capacity of templated view generation which is much more then simple HTML resource representation. And yes, I know, the ambiguity is even more emphasized when we try to chose a right framework for the task at hand. In short, the guideline is; if you want HTML based web site then use ASP.NET MVC and for JSON/XML support use rather ASP.NET Web API or another framework like Nancy (I’m speaking here for the .NET world). Well, I don’t want make my choice based on that criteria. Let’s go deeper to see what options we have.

I’ve been always confused whenever you should or not implement asynchronous execution for “lengthy” operations when it comes to the ASP.NET platform. It has to be said that there is many factors that come into play. The way ASP.NET concurrent request are handled not only has changed over the different version of Framework .NET but also you have to consider how ASP.NET deals with threads and ThreadPool in general. Since the very beginning I hear people saying to make usage of your own threads if you don’t want to starve the ThreadPool in ASP.NET process by queuing too many work items. It will prevent ASP.NET from processing further requests. Some confusion has been added with the recent release of TPL library and its usage inside the asynchronous pages/controllers/handlers in regards to the threads and ThreadPool consumption. All the more there is no clear guidance or rather no easy one to find. So let me now sum up all this when it comes to the latest .NET Framework (4/4.5).

I’ll be speaking with Olivier Spinelli about IoC/DI patterns and anti-patterns at the next meeting of Paris ALT.NET group on 15th of mars 2012. Form more information please look here (french) : http://www.altnetfr.org/2012/01/22/alt-net-presentation-ioc-patterns-et-anti-patterns/#comments.

Thomas.Dispose();

CodeDistillers.WaitFormPendingFinalizers();

I’ve been reading through several blog post about how people configure DI support in the new ASP.NET Web Api. For example you can read about it here :

• Official “Using the Web API Dependency Resolver”
• “Autofac ASP.NET Web API (Beta) Integration“
• “Web Api and Ninject”

What stands out is that every implementation relays on System.Web.Http.Services.IDependencyResolver interface which is similar to the one introduced in the ASP.NET MVC 3 and which lives in the System.Web.Mvc namespace to avoid confusion. Let’s look at it’s implementation details :

public interface IDependencyResolver
	    {
	        object GetService(System.Type serviceType);
	 
	        IEnumerable<object> GetServices(System.Type serviceType);
	 
	    }