Archive for the ‘Uncategorized’ Category

Spam & Fraud Prevention

February 25, 2009

Objective: we want to prevent spam send from our contact form.

Let’s look at the problem a little closer. What kinds of spam are there?

1. Messages send from a bot issuing direct http requests

How the prevent this:

Using javascript and/or css detectionn should be pretty successful to kick this kind of bots out. For javascript prevention we could make the client to submit  the result of an artithmetic expression ( easier to crack ) or dom manipulation back to us.

2. Messages send from a bot automating the browser

How to prevent this:

Since these bots are using full blown browser they can’t be beaten with javascript tricks, because they have this. The impact isn’t that big, because using the browser they could probaly just send about 10 Emails per minute opposed to a couple hundred or thousand if sending direct http requests. However 10 Emails per minute isn’t that little.  What to do:

One Idea would be to measure time needed to submit a form. It is less than 10 seconds – kick it, its a bot.

3. Spam send by real people

This is the hardest one to beat, it is actually unbeatable.  The only think you can do to display captcha with increasing number of characters to type for each sent email. So if someone sends 5 Emails it would be OK,  but after 10-15 Emails it is going to get slower and slower for him.

MCTS is Microsoft Certified Technology Specialist

February 10, 2009

I’m now Microsoft Certified Technology Specialist for ASP.NET 3.5
after I passed the second exam
70-562 TS: Microsoft .NET Framework 3.5, ASP.NET Application Development

MTS ASP.NET 3.5 Logo

Dependeny Injection vs Encapsulation

November 24, 2008

Dependency Injection vs Encapsulation

When trying to show coworkers of the advantages of Dependency Injection I often encounter the argument, that it hurts one of the major object-oriented principles – encapsulation.

Let us consider the following basic example of class that has two dependencies, created in the constructor:

public class SomeClass
{
	IWriter writer;
	ILogger logger;

	public SomeClass()
	{
		this.writer = new StreamWriter();
		this.logger = new RegistryLogger();
	}
}

Client code:

SomeClass someClass = new SomeClass();

SomeClass has direct dependencies and can’t be used without them and is clearly not testable. Let us see a implementation with dependency injection:


public class SomeClass : ISomeClass
{
	IWriter writer;
	ILogger logger;

	public SomeClass(IWriter writer, ILogger logger)
	{
		this.writer = writer;
		this.logger = logger;
	}
}

This is clearly much better, but is considered to be violating the encapsulation principle form some developers. Encapsulation principle tells us to hide the class inner workings form the user. This is important in order to allow us to change the class implementation without changing all of its clients. This is a valid point, that I respect, we all strive to the “low maintenance road” (Ayende) – the most important thing in software development.

However let us look at the client code and see if it actually breaks the encapsulation principle:

ISomeClass someClass = Container.Resolve<ISomeClass>();

What we see here is that, the client code does not even know a damn thing about the class dependencies!
We just let the dependency injection container do the heavy lifting for us and don’t worry how to create all of the class dependencies.
In practice we actually do not even have the possibility to use the constructor!
That’s true – in production code instantiating a class from the constructor would require creating all of its dependencies, which would require instantiating their dependencies and so on. It would be safe to say, that the developers can’t even use the constructor and must instantiate their objects using the dependency injection container, which is so much easier.

So the user of the code does not actually even know what kind if dependencies a class has – all of this because of the dependency injection container. So actually instead of breaking encapsulation we are driving it to a whole new level – each individual class does not get to decide what kind of object it needs – everything gets configured in the configuration of the container. This definitely does not break the encapsulation principle. It makes it hold even stronger.

As a side note I want to point out, that I am definitely against the point of view “If you let the developers to bad things, then they will”. If you don’t trust your developers you shouldn’t hire them in the first place. Treat all the of the developers as stars and they will be.

Happy dependent less programming!

Hello World!

February 26, 2008

Hello everyone!

This is my first blog post! This blog is going to be about software development problems that I encounter at work and their solutions. I am mostly working with the .NET platform and C#, but there will also be bunch of other stuff like C++ and its pitfalls, Java, VB, VB.NET and nifty gritty Windows Installer MSI tricks and a lot more.
I hope this will be a nice trip and I will be glad if this is helpful to someone.