Handling change from a management point of view.

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".

Red SOStenible

Red SOStenible

Consideramos imprescindible la retirada de la disposición final primera de la Ley de Economía Sostenible por los siguientes motivos:

1 -Viola los derechos constitucionales en los que se ha de basar un estado democrático en especial la presunción de inocencia, libertad de expresión, privacidad, inviolabilidad domiciliaria, tutela judicial efectiva, libertad de mercado, protección de consumidoras y consumidores, entre otros.

Monet 0.1.0-alfa

First released: Thu, 12/10/2009 - 12:36
Download: Monet-0.1.0a_0.zip
Size: 291.68 KB
md5_file hash: 928c22c15b2c67ed9b6395c5496ae3f3
Last updated: Thu, 12/10/2009 - 12:36

Versión alfa.

Soporte para hooks y servicios, intercepción automática y gestor de plugins.

Monet Plugins Library

Muchos sistemas de plugins están basados en la implementación de interfaces fijos que amplían la definición de un plugin permitiendo realizar una determinada cantidad de operaciones que en cualquier caso siempre es fija, de forma que, por ejemplo si un plugin proporciona un menu se define el interfaz IPluginMenu, si implementa un toolbar la interfaz IPluginToolbar y así sucesivamente para cada una de las funcionalidades que se pretende que un plugin pueda proporcionar.

El enfoque de Monet está orientado a permitir que cada plugin pueda definir servicios, utilizables por otros plugins, en ba

En defensa de los derechos fundamentales en Internet.

Ante la inclusión en el Anteproyecto de Ley de Economía sostenible de modificaciones legislativas que afectan al libre ejercicio de las libertades de expresión, información y el derecho de acceso a la cultura a través de Internet, los periodistas, bloggers, usuarios, profesionales y creadores de internet manifestamos nuestra firme oposición al proyecto, y declaramos que…

  1. Los derechos de autor no pueden situarse por encima de los derechos fundamentales de los ciudadanos, como el derecho a la privacidad, a la seguridad, a la presunción de inocencia, a la tutela judicial efectiva y a la libertad de expresión.
  2. La suspensión de derechos fundamentales es y debe seguir siendo competencia exclusiva del poder judicial. Ni un cierre sin sentencia. Este anteproyecto, en contra de lo establecido en el artículo 20.5 de la Constitución, pone en manos de un órgano no judicial -un organismo dependiente del ministerio de Cultura-, la potestad de impedir a los ciudadanos españoles el acceso a cualquier página web.
  3. La nueva legislación creará inseguridad jurídica en todo el sector tecnológico español, perjudicando uno de los pocos campos de desarrollo y futuro de nuestra economía, entorpeciendo la creación de empresas, introduciendo trabas a la libre competencia y ralentizando su proyección internacional.
  4. La nueva legislación propuesta amenaza a los nuevos creadores y entorpece la creación cultural. Con Internet y los sucesivos avances tecnológicos se ha democratizado extraordinariamente la creación y emisión de contenidos de todo tipo, que ya no provienen prevalentemente de las industrias culturales tradicionales, sino de multitud de fuentes diferentes.
  5. Los autores, como todos los trabajadores, tienen derecho a vivir de su trabajo con nuevas ideas creativas, modelos de negocio y actividades asociadas a sus creaciones. Intentar sostener con cambios legislativos a una industria obsoleta que no sabe adaptarse a este nuevo entorno no es ni justo ni realista. Si su modelo de negocio se basaba en el control de las copias de las obras y en Internet no es posible sin vulnerar derechos fundamentales, deberían buscar otro modelo.
  6. Consideramos que las industrias culturales necesitan para sobrevivir alternativas modernas, eficaces, creíbles y asequibles y que se adecuen a los nuevos usos sociales, en lugar de limitaciones tan desproporcionadas como ineficaces para el fin que dicen perseguir.
  7. Internet debe funcionar de forma libre y sin interferencias políticas auspiciadas por sectores que pretenden perpetuar obsoletos modelos de negocio e imposibilitar que el saber humano siga siendo libre.
  8. Exigimos que el Gobierno garantice por ley la neutralidad de la Red en España, ante cualquier presión que pueda producirse, como marco para el desarrollo de una economía sostenible y realista de cara al futuro.
  9. Proponemos una verdadera reforma del derecho de propiedad intelectual orientada a su fin: devolver a la sociedad el conocimiento, promover el dominio público y limitar los abusos de las entidades gestoras.
  10. En democracia las leyes y sus modificaciones deben aprobarse tras el oportuno debate público y habiendo consultado previamente a todas las partes implicadas. No es de recibo que se realicen cambios legislativos que afectan a derechos fundamentales en una ley no orgánica y que versa sobre otra materia.

NOTA: Este manifiesto fue redactado conjuntamente por periodistas, bloggers e internautas, en una maratoniana sesión durante la tarde-noche de ayer. Si estás de acuerdo, difúndelo por todas las vías que puedas.

Using weak references

Introduction

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.

UAC and Windows 7. Microsoft listens.

Not so long ago, kriptópolis published an article about a security vulnerability in Windows 7 UAC default configuration (in Spanish) which allowed every malware program to change UAC configuration without warning the user about it, to the point where it could be completely deactivated, and therefore endanger the whole system.

Initially on the Engineering Windows 7 blog said that:

Microsoft’s position that the reports about UAC do not constitute a vulnerability is because the reports have not shown a way for malware to get onto the machine in the first place without express consent

which, to tell you the truth, sounded more like a sad excuse than a real explanation

Luckly, in a late, but wise, movement, and after getting a lot of negative feedbacks, it seems they've changed their minds and have decided to, indeed, consider it a vulnerability:

we are going to deliver two changes to the Release Candidate that we’ll all see. First, the UAC control panel will run in a high integrity process, which requires elevation. That was already in the works before this discussion and doing this prevents all the mechanics around SendKeys and the like from working. Second, changing the level of the UAC will also prompt for confirmation.

These are excelent news. On one side because they're fixing the security vulnerability exposed by the previous working mode, and on the other because is refreshing to find Microsoft people finally answering and taking into account comments from their users.

Test Driven Development (update)

See, I've been reading Joel Spolsky blog for about two years now, and I've always considered all his opinions to be more than valuable. I could say every time he speaks, I nod :P

So, if you write an article criticizing Test+Driven+Development, which is one of the methodologies with most buzz nowadays, you expect a lot of people to just disagree or think you're nuts... after all, test driven development is cool, isn't it?.

That being said, when Joel and Jeff Atwood refer to the topics you have mentioned and basically confirm what you've already said... well, I must say I feel flattered. Mostly because these two have a big impact in the internet, secondly because I usually agree with what they say a hundred percent, and thirdly because ... it's cool to be right... or at least having popular people agree with you.

About what they say (is a transcript from one of their podcasts), well, what can I say? Just a little thing, in the end Jeff says:

...because what matters is what you deliver to the customer, and how happy the customer is with what you've delivered. There's many, many ways to get there.

Well, that's right but, what does it have to do with what we are talking? Every methodology is design having in mind that objective, everyone wants to deliver an exceptional product to the client; well actually everyone wants to make money out of delivering that exceptional product. So, of course there's many ways, what we are talking about is choosing the best way to do it, that's what methodologies provide, a way to do things, an structure for how to work.

In the end, methodologies are just part of the equation. Other parts include common sense to adapt to each situation, the appropriate set of tools and mainly, the people who work on the project. In that way, I'm not saying making unitary tests is bad, quite the contrary, is doing them for everything what is bad. Why? Because we're failing to use our common sense to tell us what should be tested and what doesn't need to.

And that's basically the problem with Test Driven Development, since tests drive the development you have to make them for everything that needs to be developed, otherwise they will not drive...

Test Driven Development

Lately, here and then, I'm hearing a lot about the so called Test Driven Development as a development methodology.

Let me explain how this works. The methodology is based on having the test drive the development of the application (hence the name), so that, our first step is, as usual, plan what the application needs to do, and then develop test for each one of the functions we are going to develop, so that, this way, will have a test for each function (don't get to excited with that...)

Next step will be obviously, developing the functionality that will be able to pass the test, and in that way, requirement done and tested ...

The technique description has some other steps and guides over how development must be performed on each step must be. The wikipedia page has more information for those interested (hopefully not many of you after reading this article)

SQL Injection explained

Introduction

The 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 anatomy

An 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:

string query = "SELECT Count(*) FROM Users WHERE Name='" +
                        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: