If you run or are part of any modern business this days, you'll know that, in order to keep going, one must adapt to the market, to the new technologies and so on. Some times, even when there's no significant advantage for a given technology from a technical point of view, the client is significantly more receptive to buy from the so called "state of the art" new thingy.
That means that, one way or another you'll have to evolve in order to handle the market and develop into new technologies, new ways to do things. You might be forced to migrate from desktop to web, from central database to a more scalable distributed schema.
Now, when that happens, how do you manage that change within your team? How are they going to take it?
Of course, there will be people that handle the new situation without problems or even gladly but you're gonna find people resist to change strongly and you should know the reasons why people use to reject change in order to try to change it.
Firstly people in general is risk avoider (with some "early adopter" exceptions). That is, people avoid risk and any change is a risk.
Secondly, people tend to be afraid of WHERE the change will put them. Look at it like this: a developer on your team will be thinking "if we change to xxx technology, how will that affect my career? How will it affect my chances to get a promotion or even get fired? They don't know the new technology, they don't want to get outdated or lose their position as experts or whatever in the "old ways".
A weak reference is tightly tied to the garbage collector concept, meaning its only present in garbage collected languages such as C# or Java.
In order to clarify weak reference we have to address (in simple terms) what is the garbage collector and the basics of how its works.
Basics of garbage collector
Traditional imperative languages has always have to handle memory for reference types, that way, whenever we wanted to get a hold on a new class or an structure of memory we needed to allocate it, which in turn reserved the space in the heap.
Then the memory is marked as used up so whenever we ask for another chunk of memory we don't get the same location. Pretty simple.
Obviously, at some point, we will stop needing the first chunk of memory, so we will need to tell the system that that part of the heap is now available, that's what is known as freeing the memory. And that's a problem that has been bugging computers programs for more than three decades. If we forget to release that memory, then it never gets freed, and so we never "recover" it to be able to use it. With time (or a very fast loop) we end up consuming all available memory, which lead us to a performance hit and ultimately to a program crash.
IntroductionThe SQL Injection attack exploits a vulnerability of the database access layer of an application. It can happen in any application, not only, as many people thinks, in web applications, although given the huge quantity of user consuming Internet applications as well as the "laziness" of some web developers using GET parameters, this type of attacks has become popular in the Net.
Attack anatomyAn SQL Injection based attack exploits a code structure where we are performing a query or a command in the database providing some user fetched parameters.
The problem arises where those parameters are not validated but just used by the programmer appending them into the relevant sections of the query, for example:
txtNombre.Text + "' AND Password = '" + txtPassword.Text + "'";
that query returns the number of user whose user name and password match the ones provided in the given text fields. The problem with an SQL Injection attack comes, not because the code is incorrect but because it is assuming the input parameters are correct, that is, is not taking into account the full range of possibilities. That way, if we give the following values for those fields:
Before we start
In this article there isn't a single line of code and it's not aimed at teaching the intricacies of multithreaded programming in any given programming language but to give a short introduction, focusing primarily on how and especially why and when multithreaded programming would be useful.
So, what is multithreaded programming?
Nowadays all operating systems (except maybe the educational ones) are multitasking operating systems. This means they can run multiple tasks or processes at the same time. This has not always been so, the ms-dos was a monotasking system which means that only one task could run on the system simultaneously.
Before rushing to explain multithreaded programming is desirable to review certain features common to operating systems.
Multitasking and multiprocessing. The Scheduler.
When we talk about multitasking operating systems we say they can run multiple tasks simultaneously in parallel. This is not entirely true, just multiprocessor systems (with more than one processor) can make real multitasking, in a system with one processor we talk about the illusion of multitasking.
In both cases a mechanism of the operating system called scheduler intervenes. The scheduler function is to administer the different tasks that are in execution and to decide when each task executes and - if it is applicable - the processor in which it will be executed. When a task is in execution it has the whole processor power available for itself, it doesn't share it with any other one. The same thing happens with memory space, the task that is executing has the whole available memory of the system.
So, in order for real multitasking or at least the sensation of it to take place, the tasks have to share the processor, that is to say, the task that is currently executing, will have to get out and leave the processor to another task which will take its place, this - for which the sheduler is also in charge - is called context switch and, among other things, implies a certain overload of resources (it is necessary to keep certain relative data to the process that comes out and to load other relative to the process that comes in).
On many occasions we want to save the state of an object so that we can regain that status at any time. A very simple example is when we are going to modify a number of parameters of the object and make some operation but want to store the state object the object was in order to be able to return to it in case of an exception.
In most of the objects there is a part of their state that is reflected in private variables. Contrary to what is normally thought a private field is not used to prevent anyone from modifying it (which is just a side effect) but to hide it from the programmer that uses the class, telling him that he hasn't have to be concerned about that field and should not take it into account, or depend on it on any sense. If we change these private variables to public, we would provide accessibility to manually store the object state but we would be violating the previous concept.
The pattern memento faces this problem by encapsulating the internal information of the object in another object, whose internal structure is, preferably, opaque to the outside.
The Façade pattern is a software pattern whose aim is to simplify or make more friendly the complexity associated with a software library.
Sometimes a library or set of libraries contain a set of features for performing various actions. If one looks at the vast majority of software projects, most of the calls the library receives are to the same functions or a combination thereof. That is, there are a lot of common requests that usually occur in 90% of cases and that meet the customer needs for the library. In these cases, it is convenient to create an object that simplifies the API of the library, combining certain processes and simplifying the API. Of course some programs will still want (and may) have access to the old API of the library to use some specialized functions but we will have been able to simplify the functionality of the most commonly used parts of the library.
The command pattern is a design pattern in which the objects represent actions that will be consumed by some consumer.
The command pattern is used in order to solve several types of problems in software design:
- Used as an interface simplification. Sometimes the parameter number of a method grows so much it gets unmanageable. Using the command pattern allows us to group the parameters into a unique object which will be then used by the function.
- Used as a command queue. Encapsulating each command in an object allow its processing in a sequential way by means of a queue, so that a worker process can work by extracting objects from that queue and processing them.
- Command history. Using objects as commands, and keeping this objects we can maintain a history with the most used commands and so, if needed, revert their effects.
- Command generalization. Occasionally the use of a command or several ones allows for the abstraction of that command into an abstract class which can be inherited from specific commands, allowing a given consumer to process commands which fulfill certain common properties independent of the command itself.
The idea after the Abstract Factory pattern is the notion about our program (or the client of a class we are providing) working with several products (as those in a factory) which have some given characteristics (for example we have bottled products and products in a tetrabrik). Our program is going to use those products performing a couple of actions over them (like putting the bottles in one truck and the tetrabriks in another one) without caring about who is actually providing him with the products.
There are a series of factories as well that will produce those products we are going to handle, one fabric makes juice, another one milk and another one makes sauce but each of them have bottles and tetrabrik products which our program handle. In the end, the basic concept is that our program (or client) doesn't care what's inside the bottel or who has produced it as long as it is a bottle.
The Adapter Pattern, also known sometimes as "wrapper" performs the function, as its name hints, of adapting (or wrapping) a given class merging the interface of that class and converting it in something closer to what we need.
In a lot of situations we have a class that does exactly what we need (or almost exactly) and fulfills all the requirements for other class to use it but, as it doesn't implement a given interface or inherit from a given class the operation can't be performed.
In a given portion of the code an instance implementing an interface or of a given class is expected. We wish to use a different class which fulfills all the requirements of the interface or the base class but which doesn't fulfill the interface implementation or the inheritance itself (for whatever reason that may be).
The following image (from the wikipedia) illustrates pretty well the general scheme of the adapter design pattern.
This article is just a brief introduction to the .NET technology going through its main characteristics and explaining briefly the intricacies of the CLR and the .NET assemblies so that, when we work with assembly references or use the System.Reflection namespace, we have at least a certain knowledge about what are we really doing. A great part of what I know about this topic comes from two books I'd recommend to anyone willing to have a more detailed view of the .NET technology.
- Plugin <em></em> Not Found Joe Duffy. I'd recommend dis book to '''start to understand the .NET concepts and intricacies''', that is, how does the CLR works, what's the CIL, what libraries does the framwork provides... (it's advisable to have some knowledge of C# as the examples are for the most part in that language, as well as have made at least one little program with C# and .NET)
- Plugin <em></em> Not Found Don Box. This is a more thorough book describing the fundamentals of .NET and the CLR itself at a lower level so, as Don Box himself warns in the preface it's not a "beginners guide"