Programate algo - Programming Blog/Blog de Programación

Spanish version / Versión en Español In C++, the Observer design pattern (also known as Publisher/Subscriber) is usually implemented as suggested in the bible of design patterns . This implementation requires that Observer and Observed implement the IObserver and IObserved interfaces, so that when Observed changes, all its registered Observers are notified. Needless to say, this can be done the same way in C#. However, this is not necessary since the Observer pattern is implemented in the C# language itself, with its delegates and events constructs. Suppose we want to use this to implement the MVC architecture pattern in our C# application. The MVC rationale says that View objects can reference Model objects, but not the other way around. So how does the model communicate with the view? Using the Observer Pattern. First, in our Model class, we must declare the Event which will be triggered when the Model changes. Then, we must define the delegate associated to this e

Versión en inglés / English version En C++, el patrón Observador (también conocido como Publisher/Subscriber) es usualmente implementado como se sugiere en la biblia de los patrones de diseño: Gang of Four Dicha implementación requiere que el observador y el observado implementen sendas interfaces, de modo que cuando el observado cambie, notifique a todos sus observadores. De más está decir que esto puede hacerse de la misma forma en C#, considerando que C# no permite herencia múltiple, pero sí la implementación de más de una interfaz. Sin embargo, puede decirse que en C# el patrón Observador viene implementado en el propio lenguaje, a través de los mecanismos de delegates y eventos. Supongamos el siguient caso genérico: tenemos una clase del modelo que es observada por una clase de la vista. El patrón MVC nos dice que la vista puede tener una referencia al modelo, pero la dependencia inversa es síntoma de mal diseño. Es ahí donde el patrón observador viene al rescate

Spanish version / Versión en Español The following is a (quite) short summary of this MSDN article Firstly, it is of vital importance to understand that a Garbage Collected environment such as Managed .NET is not immune to memory leaks. One of the reasons for this is the fact that .NET's Garbage Collector only disposes objects which are no longer referenced by any other object. Ergo, if an object's reference count does not reach zero because of a dangling reference, the GC won't save us. On the other hand, when we talk about .NET applications which run on Windows, said applications usually consume Operating System resources (bitmaps, thread handles, critical sections, etc). These should be, ideally, released as soon as they are no longer needed. The author of the MSDN article mentions a ninja technique to hunt down leaks: Nevertheless, he prefers using higher level tools, such as these Usual causes for memory leaks in .NET: Static referen

Versión en inglés / English version Lo siguiente es un (muy) breve resumen de un artículo de la MSDN: Artículo original En primer lugar, es vital entender que los lenguajes con recolector de basura como .NET no son inmunes a las pérdidas de memoria. Una de las razones de ello es que el recolector sólo libera memoria que ya no es referenciada: si el contador de referencias de un objeto no llega a cero porque dejamos una referencia colgada, el recolector no nos salvará. Por otro lado, cuando hablamos de aplicaciones .NET que corren en Windows, dichas aplicaciones suelen consumir diversos recursos del SO, que idealmente deben ser liberados apenas dejan de ser usados. El autor del artículo menciona una técnica "ninja" para eliminar pérdidas: The ninja way :) Aunque él prefiere usar herramientas de más alto nivel, como las mencionadas aquí: Herramientas Copantes Causas usuales de memory leaks en .NET: Referencias estáticas (atributos estáticos y

Spanish version / Versión en Español Why test an application? Because it's the best way to find defects in software. Testing does not guarantee the application is free of bugs, but it allows us to detect them. Testing helps us create a higher quality product. A well written test gives us confidence to refactor the code it tests; if we break it, the test will fail. 1 - A taxonomy of tests Unit tests: They test a code block in isolation from its environment (project, solution, package, etc). In their most purist form, unit tests should not access any external dependency such as the file system, databases, external web services, special hardware, etc. This can be achieved via various techniques that we'll look at in a later post. The main reasons for these restrictions are to have real isolation of the test unit, and keeping unit tests fast. Fast unit tests are important in order to keep the TDD cycle fast and productive; if we bog them down with I/O, they wil

Versión en inglés / English version Exordio para puristas Oh Madre Lengua Castellana, en nombre de la mano perdida del manco de Lepanto, perdónanos por las aberraciones que hemos de cometer en desmedro de tu ilustre prosapia bajo el estandarte de la jerga informática. Aparta tu justamente indignada mirada de palabrejas como "testear", "castear", "comitear" y engendros afines, rayanos en lo herético. Concédenos, al menos en esta ocasión, que lo importante es transmitir las ideas; un Rastrojero es tan bueno como un Lamborghini , en tanto lleve a sus pasajeros a destino de forma eficiente y eficaz. Sin más, con la conciencia impoluta, pasemos a lo que nos com pete : ¿Por qué testear una aplicación? Porque es la principal forma de encontrar defectos en el software . El testing no nos garantiza que el sistema testeado no tenga errores, pero nos permite encontrarlos. El testing nos permite elaborar un producto de mayor calidad. Un buen

Spanish version / Versión en Español HeEeLLoOo... Braaaaaaaaiinsss... Braaaaiiinnsss... (thump). Please allow me to introduce myself: My name is Darío Eduardo Ramos, I'm 24 years old; I'm currently studying Computing Engineering in the University of Buenos Aires and working as a C++ programmer at Meditech S.A . The idea behind this blog is to publish solutions to problems confronted during development, in order to share them with the sacrificed and never well pondered programming community. Maybe also tell some anecdotes, like getting whacked by a spectral manifestation of Stroustrup (I know he's not dead, it's just a figure of speech) because of writing a switch by type, or hearing laughing penguins when Visual Studio crashes. Kudos from Garín City! Spanish version / Versión en español

Versión en inglés / English version HoOoLaAa... Cereeebrooosss.... CereeeebrooOOss... (coscorrón). Me presento, soy Darío E. Ramos, tengo 24 años, soy estudiante de Ingeniería en Informática en la Universidad de Buenos Aires y trabajo como programador C++ en Meditech S.A . La onda de este blog es postear soluciones prácticas a problemas que surjan durante el desarrollo, para compartir con la sufrida y nunca bien ponderada comunidad programadora. Tal vez, además, contar alguna experiencia sobrenatural ocurrida en el ambiente laboral, como ser sopapeado por una aparición etérea de Stroustrup al escribir un switch por tipo, o escuchar pingüinitos risueños cuando se tilda el Visual Studio. Un saludo desde Garín City