Some online programming languages..

For the Code-Catas I'm organizing in the company, I found this site, which allows the users not only to choose a language among a lot of languages, but also to work with projects and files.

This was a "must have" because in the catas we wanted also to try design patterns, and good programming techniques, what sometimes means to use more than just one file.
The idea of using an online tool came because of licensing issues by installing  some languages in the laptops. There were not supposed to be used to develop productive code (code that will be sold) so buying a license just for that was a lot of money and time installing all the languages.

 The page I found is:

https://www.tutorialspoint.com/codingground.htm

Let's see how it work for our purposes!

A tool with a fool, it's still a tool ;)

Two weeks ago a colleague came to me extremely happy, jumping like a happy Bunny to ask me if I could use the only license of NDepend that we have in the firm to get the metrics and the graphics of his new code he was proud of. Eight months back in time, we bought this tool, because I downloaded a trial version that I tried for... well, now I don't remember if it was 14 days or a month. But I was quite satisfied with it, so I asked to get a license. And I was listened. ;)

But the funny part of this story is that at that time, when I first tried it, this colleague came to me (this time not like happy Bunny) a told me "Good programmers don't need tools. I don't mean to offend you, but a fool with a tool, it's still a fool."... Now he's asking if he can get his own license too.

The interesting part of this, it's not in fact to say that "people who lives in glass houses should never throw stones", but to point out the motivational change that I noticed in this person. When he decided to throw his code in a metric tool, he also started thinking about how to write his code better. how to architect his solution, and taking care about dependencies, death code, etc.

So, my conclusion is that when people see how good or bad his code actually is (in this case based on numeric metrics and graphics), they feel more motivated to do it better. Your quality doesn't live in the ether, you can actually see it! By the way, I must say that NDepend is a great tool, that I can fully recommend.

The Difference (and relationship) between MVC and MVP patterns

I wrote this post like one year ago, but I did it in spanish. Yet I'm trying to write also a little more in english. So here it goes.

I think this topic is normally a bit confusing due to the big amount of information that we can easily find in the internet and the short time we can spend to analyze all this information.

The MVC Pattern (Model-View-Controller) is a well-known design pattern which is being used all around the world. In fact, there's no one in the software development who hasn't hear about it. So I'm not gonna explain it. Nevertheless, not so well known is this other pattern called MVP (Model-View-Presenter), although it has gained more terrain in the last years.

At first view one can be tempted to think "Oh, they only changed the Controller of the MVC for the Presenter of the MVP, so it's almost the same thing, but with another name!".

Well.. nothing more far away from the truth! Absolutely not! So, what is it? What is the real difference between them? While I'm not gonna explain the MVP pattern in detail, because there is A LOT of information in internet, I would like to explain what is the relationship between these two patterns. How I see it.

First of all, let's quickly remember what the MVC is about: to separate an application into three conceptually-different parts, so he have:

• Model: makes reference to data or, better said, to representation of the information. Depending on how you interpret the pattern, the model can be directly bound to the persistence of this information. But in a wider interpretation, it can also mean the whole state of the system in a given moment. So, in its wider interpretation, we can say it embraces both the state of the system and its persistence.
• Controller: represents the business logic. The rules on which the systems run..
• View: represents the user interface.

Here it is worth to mention that I don't particularly agree with the separation between "Model" and "Controller", because I think often is kind of difficult -and expensive in terms of time- to totally exclude the model (the data) from the controller (the business logic i.e. the behaviour). However, I'm not saying it can't be done, but rather consider that there is actually a conceptual separaration between them, althought it might be unnecesary (this will be inherent to each situation and system).

Now let's briefly review the what the MVP pattern is about:

• Model: this model represents the business model. Violá! It's not the same as the model of the MVC, but rather this model includes both the representation of the data and the business logic. That's why we talk about a "Business Model". That is, this model invovles the Model and the Controller of the MVC together.
• Presenter: this is the director: on one hand it directs the events of the view to the model and on the other it updates the view with the information coming from the model. This concept does not exists directly in the MVC pattern. I mean directly, because is perfectly valid to affirm that this "Presenter" is a part of the "View" in the MVC pattern. That is, this is the logic that we are used to write into the MVC's View, no matter how basic it is!
• View: The View, according to the MVP, is the silliest and easy-to-write code that we have.  It's just about a "View" that knows his "Presenter", to whom it delegates absolutely everything that happens in it. This View makes nothing but to delegate. The user clicks, the "View" tells the "Presenter" where did the user click. Or the other way: the "Presenter" tell the "View" to fill a ComboBox, the "View" fills the Combo with the information provided. It just does not have business logic at all!

So having this information, if we analyze it a little, we come to the conclusion that both patterns are not mutually excludent. It is not about predicting "We're using the MVC pattern or the MVP pattern", but it could be interesting thinking in a combination of them. That might lead us to something called VPCM (View-Presenter-Controller-Model).

What?! Does it actually exists?! What are we talking about?

Nothing new, to be honest. Maybe the name it's new, it doesn't even exist. But that's not the point. The point is that we are breaking down the View of the MVC in two parts: a "View" who does nothing (but to delegate) and its "Presenter" who does everything for the view. Those are, the View and the Presenter of the MVP. Something like this:

Another way to see this, is the other way: we take the Model of the MVP and we break it down in two new pieces: a Controller (which has the business logic) and a Data Model (which represents the  information). That is, we've just get the Controller and the Model of the MVC pattern. It looks something like this:

As we can see after this analysis, they are NOT mutually excludent patterns: they complement each other! We could say that one emphasize
the Backend, and the other the Frontend. MVC and MVP respectively.

I would like to have some opinions about this analysis and its conclusion.
Cheers!

Mi experiencia en el Agile Open Camp 2016

Hace una semana comenzaba a terminar el AOC 2016, la segunda edición del Agile Open Camp que se celebra en Argentina desde el año pasado. Fui afortunado al poder participar. Quiero contar un poco lo que es o, más bien, lo que fue para mi.

Pero es difícil comenzar. Es dificil describir con palabras algo que te emociona, que toca tus sentidos mucho más allá del simple aprendizaje de la filosofía Agile. Porque no se ven exactamente Metodologías Ágiles; para eso ya está plagado internet de libros y artículos. Porque no te explican cómo implementar tal o cual cosa; para eso hay manuales. Vas a compartir.

Keynote de Juan Daza, a orillas del río.

En estos Open Camps, vivís tres días y medio aislado del mundo, solo en contacto con otras decenas de personas que buscan lo mismo que vos: compartir momentos y experiencias. El tronco temático es Agile, sí, pero vos podés compartir o escuchar lo que vos quieras. Vos podés aprender de Arduino, de  microservicios, de scrum, de bitcoins, nociones sobre el movimiento Slow, e incluso podés pedir que si alguien sabe, te enseñe a tocar guitarra. Hay también quienes se ofrecen para darte un taller de astronomía o eseñarte fotografía nocturna. Pero vos podés ofrecer o pedir lo que quieras.

Pero por supuesto hay mucho de Agile, experiencias, charlas, workshops, y una modalidad que me encantó que se llama "World Cafe", en la que se discuten temas en mini sesiones de 20 minutos. Y se vive en carne propia la magia de la auto-organización del evento. Vivir la experiencia de esta auto-organización no te lo da ningún libro, ningún curso, ninguna conferencia, ningún congreso. Acá cada uno es libre de participar en lo que quiera (y si es que quiere).

En medio del evento, de pronto podés conocer a alguien con quién te das cuenta que podés combinarte y dar un taller, gestar una idea que, quien te dice, germine con el tiempo para salir a la luz en forma de un emprendimiento, un proyecto, o simplemente conocer un buen amigo.

Auto-organizando talleres.

No menor es el hecho de que el evento se realiza (al menos hasta ahora) en diferentes lugares cercanos -pero no dentro- de la ciudad de San Carlos de Bariloche (Argentina), cuyos paisajes y tranquilidad, condimentan con el sabor mágico que hace falta para crear ese ambiente relajado e inspirador que lo caracteriza y lo hace tan especial, porque convengamos que no sería lo mismo hacer el este evento en el medio de la ciudad, con los ruidos y distracciones que abudan allí. Acá estás "obligado" a compartir con la misma gente todo el tiempo, y eso tiene un efecto impresionante.

En esta edición en particular, tuvimos la oportunidad de asistir a muchísimos talleres, jugar al fútbol, al paddle, hacer caminatas por la zona en medio de árboles y bordeando ríos, meditar, y hacer un fogón en medio de lo que fue la noche más silenciosa y estrellada de mi vida; con guitarras, chistes, charlas y un corderito que rebasaba absolutamente cualquier tipo de pretención que pudierámos tener.

Cronograma tentativo.

Lo importante, dicen algunos, no es sólo pasarla bien durante los días que dura el evento. Lo importante es que, además, el evento se detenga mágicamente en el tiempo dentro de cada uno de nosotros, adoptando la curiosa forma de la motivación y, de alguna manera, pase a formar parte los días subsiguientes, y los meses, y si es posible de la vida. Es decir, que produzca un cambio en nosotros, que nos llene de energía para poder comenzar una transformación como personas, mejorar las relaciones con los demás, generar confianza, y crecer.

Sigo sintiendo que no puedo aún expresar la magia que me dejó esta experiencia. Creo que si tengo que compararlo con algo para explicárselo a quien nunca fue, es como un retiro espiritual de agilidad. No soy creyente, pero es una comparación muy acertada, porque te quedás con esa hermosa sensación de "yo puedo -y voy- a cambiar el mundo".

Para terminar, quiero citar a Mauro Strione, uno de los organizadores principales del AOC, que expresa en lindas palabras, lo que muchos sentimos una vez que terminó el evento:

"Fueron tres días llenos de energía, motivación, compromiso, ganas... y sin obligar a nadie a nada, es más, todos vienen porque quieren, no porque los mandan de su empresa. La mayoría se lo pagan de su bolsillo..."

"No se si logro transmitir de qué se trata esto, quizás suene a secta o a que estamos locos. Solamente quiero advertir que cuando los geeks descubrimos el potencial de los ceros y unos de las computadoras, transformamos el mundo en pocos años, si ahora empezamos a entender a las personas y sus relaciones, sus sentimientos y motivaciones, y logramos combinarlos con esos ceros y unos... cuidado con lo que podemos lograr!"

Fotografía de las noches de Bariloche.

¿Qué es el NDVI, o Indice de Diferencia Normalizada de Vegetación?

Esta vez no voy a hablar de ningún concepto del software, y me permito divagar por otros ámbitos que no se le parecen demasiado, como es el tema del agro. No se parecen, pero están relacionados. ¿Por qué? Porque TODO, tarde o temprano, termina esclavizando al desarrollo de software para sobrevivir. Los informáticos, somos una espcie necesaria para la industria, nos guste o no.

Hace unos años, allá a madiados de de los setenta -si mal no recuerdo-, un científico se hallaba en su trabajo, ni más ni menos que la NASA, analizando imagenes satelitales del LandSAT (un satelite que tomaba fotografías areas de la Tierra). Su estudio se orientaba al análisis de la vegetación sobre la tierra.

Este señor, cuyo nombre era Compton Tucker, después de mucho analizar, y obtener resultados, escribió un paper llamado "Red and Photograghic Infrared Linear Combinations for Monitoring Vegetation", es decir: Combinaciones Lineales del Rojo e Infrarojo Fotográfico para Monitoreo de la Vegetación". De los resultados que obtuvo, nos vamos a ocupar en este post.

Aunque a simple vista puede sonar aburrido a quienes no son del palo de la agricultura -y similares-, lo que este señor encontró es sorprendente: Un árbol en buen estado de salud refleja muchísima luz infraroja, y muy poca luz roja. Pero si este árbol se enferma, entonces comienza a reflejar muchísima menos luz infraroja, casi en la misma cantidad que la luz roja. Y si se muere dicho árbol, entonces deja de irradiar luz infraroja, comparado con la luz roja. Todo esto tiene una explicación lógica, que está relacionada con la clorofila, pero por ahora no nos interesa.

Me permito tomar prestada una imagen de internet para ilustrar este concepto con imágenes, que siempre resulta más comprensible y entretenido:

Aunque está en inglés, es bastante simple:

• La hoja saludable (Healthy Leaf) refleja muchísismo la luz infraroja (NIR), y bastante luz verde y es por eso que un arbol sano se ve de color verde.
• La hoja estresada (Stressed Leaf) refleja muchísimo menos infrarojo, y un poco más de rojo y verde.
• La hoja muerta (Dead Leaf) refleja aún menos infrarojo que la estresada, y menos verde, por eso se ve más opaca y apagada.

A esta altura, tiene que estar clarísimo que nosotros los seres humanos NO podemos ver los rayos infrarojos, y por eso no nos damos cuenta si un arbol refleja más o menos luz infraroja. No señor, no podemos. Pero en nuestras casa, y a diario, contamos con una herramenta que SÍ distingue la luz infraroja: las cámaras de fotos digitales. Si alguna vez te preguntaste por qué yo no puedo ver la luz que emite un control remoto, pero cuando lo miro a través de una cámara de fotos sí puedo verla, ésta es la razón. El sensor de la cámara distingue la luz infraroja y la convierte en luz visible que puede variar entre blanco, violeta, o rosado. (TIP: esto se usa mucho para comprobar si un control remoto funciona, o no).

Volviendo al señor Compton, lo que hizo de interesante, fue describir algunos modelos que se basaban en relaciones matemáticas entre la luz roja y la luz infraroja, y que permiten comprobar el estado de salud de una vegetación.

De todas las que hizo, la fórmula que más le convenció, se llama NDVI (Normalized Difference Vegetation Index), o Índice de Diferencia Normalizada de Vegetación, y es la siguiente:

 dónde NIR representa la luz infrarroja, y Red -obviamente- la roja.

Esta fórmula nos da valores que se encuentran entre -1 y 1. Mientras más cercano al -1, peor es la salud de la planta, y mientras más cercano a 1, mejor es la salud de la planta. Los valores intermedios, corresponden a estados de estrés, aunque para comprender realmente el significado o el motivo de los números, es siempre conveniente consultar con un experto en el tema del agro.

Mediante la aplicación correcta de esta fórmula, que Compton utilizo con imagnes satelitales, podemos obtener nuevas imágenes que nos muestran el estado de la vegetación que hablamos recién. Aquí tenemos un ejemplo, pero con imagenes no-satelitales:

Primero, contamos con esta imagen normal tomada por una cámara común y corriente, y que puede también guardar los infrarojos:

Luego de aplicarle la fórmula del NDVI, obtenemos la siguiente imagen:

Donde podemos distinguir claramente qué parte de la vegetación está más saludable (la verde) y cual más seca (naranja). Y además, podemos distinguir perfectamente aquellas partes que no son vegetación (rojo).

Es sorprendente la claridad de la información que nos da la imagen! Esto se utiliza mucho con fotos aereas de cultivos, para encontrar problemas en el riego, o de otra indole que pueden estar afectando dichos cultivos. Es una forma relativamente económica y fiable, de la cual también se pueden llegar a encontrar patrones de problemas.

En este momento estoy desarrollando un software para que, dada una imágen, calcule la imágen NDVI correspondiente. De hecho, de estas imágenes que uso como ejemplo, la del NDVI fue calculada con mi software. Si bien el software está funcionando, aún debo pulir la interfaz de usuario, para hacerlo más amigable.

Esto es todo por ahora, más adelante presentaré este programa que permite automatizar el cálculo de NDVI, y en tiempos muy cortos.

Saludos!

Diferencia -y relación- entre los patrones MVC y MVP

Creo que este tema se presta un poco a confusión debido a la cantidad de información que existe en internet y el poco tiempo que disponemos para analizar toda esta información.

El patrón MVC (Modelo-Vista-Controlador) es muy utilizado y creo muy pocas personas del ambiente del desarrollo no lo conocen, por lo que no voy a hablar de este patrón.

Sin embargo, no tan famoso es éste otro patrón, que ha tomado un poco más de fuerza desde hace unos años, y sigue escalando: el patrón MVP. El patrón MVP hace referencia a: MODELO-VISTA-PRESENTADOR.

A simple vista, uno se siente tentado a pensar: "Ah! Cambiaron el Controlador del MVC por algo nuevo llamado Presentador, que debe hacer algo parecido pero con otro nombre.."

Ja! Nada más alejado de la realidad! Absolutamente no! Entonces, ¿qué es?

Si bien no voy explicar qué es, porque sería seguir agregando más información de lo mismo, y en google ya hay mucha y buena, yo quiero hablar sobre qué relación existe entre ambos patrones, y por ende, también hablar de cuál es la diferencia.

Primero que nada, recordemos rápidamente que la intención del MVC es separar una aplicación en tres partes fundamenales, pero de alguna manera relacionadas. Tenemos:

•  Modelo: que hace referencia a los datos o, mejor dicho, a la representación de la información. Según cómo se interprete el patrón, el modelo puede estar directamente ligado a la persistencia de dicha información. Sin mebargo, en una interpretación más amplia, puede abarcar también el estado del negocio en un momento dado. Es decir que, en su versión más amplia, el modelo es el estado del negocio y la persistenca de ese estado.
• Controlador: que representa la lógica del negocio. Las reglas que hacen al negocio.
• Vista: que representa la interfaz con el usuario.

Acá quiero aclarar que yo particularmente no estoy muy de acuerdo con la separación entre "Modelo" y "Controlador", porque pienso que muchas veces es dificil y costoso excluir totalmente al modelo (representación de los datos) de la lógica del negocio (o sea, del controlador). Sin embargo, no estoy diciendo que no se pueda hacer, o no se deba hacer, sino más bien que hay que considerar que existe una separación coneptual de ambas cosas, sin que esto implique necesariamente llevarla a cabo (aspecto que será inherente a cada situación).

Ahoa bien, si repasamos brevemente el MVP, nos encontramos con lo siguiente:

• Modelo: aquí el modelo representa el modelo del negocio. Voilá! No es lo mismo que el modelo del MVC, sino que este modelo incluye tanto la representación de los datos como la lógica del negocio: por eso hablamos de "modelo del negocio".  Es decir que este modelo abarca al Modelo y al Controlador del MVC juntos.
• Presentador: El presentador es quien dirige: por un lado los eventos de la vista hacia el modelo, y por otro lado actualiza la vista con las información provenientes del modelo. Este concepto no existe directamente dentro del patrón MVC. Digo "directamente" porque es perfectamente válido afirmar que este presentador es parte de la Vista del MVC. Es decir, es la lógica que le solemos poner a la vista, por más básica que sea!
• Vista: La vista, según el MVP, es lo más tonto y fácil del programar que hay. Se trata de una vita propiamente dicha que conoce a su presentador, a quién le delega absolutamente todo. Ella no hace nada, excepto delegar. Ocurre un click: le dice al presentador que se haga cargo del click. Asi de simple. Ocurre algún otro evento: le dice al presentador que se encargue de ese evento. Pero ella no procesa nada, no hace nada. Solo delega el trabajo al presentador.

Despues de analizar un poco esto, podemos llegar a la conclusión de que ambos patrones no son excluyentes. No es cuestión de decir Vamos a usar el MVC o el MVP, sino más bien, puede ser interesante pensar en una combinación de ambos. Algo así como un VPCM (Vista-Presentador-Controlador-Modelo).

Qué!? Eso no existe! De qué estamos hablando?

De nada nuevo, en realidad. Sólo estamos desglosando la Vista del MVC en dos partes: una vista que no hace nada, y su presentador que hace todo. Es decir, de la Vista del MVC obtenemos la Vista y el Presentador del MVP. Algo así:

 
Otra forma de verlo, es la inversa: agarramos el Modelo del MVP y los desglosamos en un controlador (con la lógica del negocio) y un modelo de datos (represetación de los datos). Es decir, del Modelo del MVP obtenemos el Controlador y el Modelo del MVC. Algo así:

Cómo podemos ver después de este análisis, NO son patrones mutuamente excluyentes: son complementarios. Por decirlo así, uno hace más hincapié en el back-end, y el otro en el front-end.
Me gustaría leer opiniones que aporten a este análisis y ésta conclusión.
 Saludos!

Programación Orientada a Aspectos. ¿Qué es? (Parte 1)

Para explicar la programación orientada a aspectos, quizás lo ideal sería comenzar con una breve descripción de la historia de la ingeniería de software, como lo hacen la mayoría de los artículos o PDFs que podemos encontrar en la web, pero como justamente la mayoría lo hace así, yo no. Quien quiera verlo así, busque en la web el tema y ahí van a tener mucho para leer (y no está demás). Pero yo prefiero comenzar yendo al grano.

La programación orientada a objetos trata la manera de modularizar "conceptos comunes" de software. Sin embargo, existen otros conceptos o asuntos que se extienden a lo largo de estos "conceptos comunes" y que no pueden ser modularizados con el diseño orientado a objetos. En un intento más de subsanar lo que la orientación a objetos no puede, aparece una nueva solución: la Programación Orientada a Aspectos (y su consecuente Diseño Orientado a Aspectos).

La programación orientada a aspectos se ha planteado como un nuevo paradigma de programación (con lo que no estoy de acuerdo), el cual consiste en separar los conceptos que entrecruzan varias clases y se extienden a lo largo de éstas, pero que no pertenecen a esas clase en sí mismas. Incluso, los conceptos pueden aparecer no sólo en varias clases, sino de una sola. Ahora la pregunta: ¿de qué tipo de conceptos hablamos? Pensemos como ejemplo, en una aplicación que requiere del registro (logging) de las acciones que realiza. Bien, estos registros "alguien" tiene que llevarlos a cabo, y es normal cargar a muchas clases con la responsabilidad de hacerlo cuando, seguramente, no sea la función principal de esas clases hacer dicha tarea. Como vemos, se trata de una misma funcionalidad (registrar acciones) que se encuentra entrecruzada en varias clases, pero que a la vez no es parte de ninguna.

Otro ejemplo, simple de entender, es el manejo de errores. Los errores hay que tratarlos sí o si en una aplicación. Pero, desde un punto de vista "purista" de objetos, no tenemos clases que traten los errores por sí solos. Siempre las clases que definen la funcionalidad de la aplicación van a tener que lidiar con los errores, y esa no es su función principal. En cierta forma, esto hace a dichas clases menos cohesivas. Un tercer ejemplo puede ser el manejo de la sincronización. Nuevamente, los objetos del negocio deben tratar la sincronización además de su función principal.

En todo los ejemplos estamos viendo que hay ciertos asuntos que no pertenecen al negocio pero que sin embargo, deben ser tratados. Y lo negativo de esto, es que según el paradigma de objetos, son los objetos del negocio quienes deben tratar estos asuntos y, como si fura poco que hagan tareas que no les corresponden, estas tareas se esparcen a lo largo de toda la aplicación, llevando a dispersar código y enredarlo por la misma (a esto último se llama Code Tangling y Code Scattering).

Entonces, para darle más sentido a la POA, veamos en qué se afecta el desarrollo de aplicaciones cuando surgen estos asuntos:

• Baja cohesión: las clases realizan tareas que no le corresponden específicamente a ellas.
• Baja reusabilidad: Cuando una clase trata un asunto que no le corresponde, esta clase probablemente sea difícil de re usar en otro sistema.
• Peor calidad de código: El código se complica, y cuesta más entenderlo y mantenerlo.
• Evolución dificultosa: Se vuelve más costoso que el sistema evoluciones al tener código disperso y enredado por toda la aplicación.

Estos asuntos son denominados "conceptos transversales". La POA viene para tratar de separar y encapsularlos en una aplicación y aislarlos para independizar a los objetos del negocio de éstos conceptos. Este aislamiento se encapsula en "aspectos".

Por lo tanto, la POA permite la separación de conceptos transversales a través de mecanismos que permiten abstraer y encapsular estos conceptos en un sistema. Un aspecto es la unidad que encapsula uno o más conceptos transversales, y que con la programación orientada a objetos no es posible diferenciarlo de forma clara.

La definición actual de aspecto dice: "Un aspecto es una unidad modular que se disemina por la estructura de otras unidades funcionales. Los aspectos existen tanto en la etapa de diseño como en la de implementación. Un aspecto de diseño es una unidad modular del diseño que se entremezcla en la estructura de otras partes del diseño. Un aspecto de programa o de código es una unidad modular del programa que aparece en otras unidades modulares del programa.”

La principal ventaja de la POA es que permite tratar la funcionalidad pura por un lado, y los aspectos por otro, de forma separada. Luego ambos se combinan con un tipo de programa llamado 'Weaver') para dar por resultado el sistema final.

Hay mucho más por hablar de POA aún. En la próxima parte (parte 2), voy a mostrar un ejemplo muy claro, para asentar toda esta teoría en algo más palpable, así que a no abandonar si esta pequeña introducción a resultado medio difícil de entender, en el ejemplo de la Parte 2 quedará muy claro de que se trata.

Install AspectJ in NetBeans 6.9.1

Versión en español

Hi. First, sorry my English, it's not my native languaje.
Second, after hours trying, I managed to compile with AspectJ in NetBeans 6.9.1
Now I'll show the way to make it possible. But I want to clarify that I wont install a NetBeans's plugin, but it is the way to make it possible to compile aspects in netbeans with AspectJ. Now, let's go on the steps:

1) Download the AspectJ Latest Stable Release, on this page.
2) Unzip de ".jar" file in the directory you like to put your libraries. It should not be in the proyect's lib directory, because you may want to use it in other projects too. You will unzip about 4 ".jar" files.
3) Create a project in netbeans, just a simple "Java Project".

Now listen, you have to follow the next steps in every new project you make:

4) Go to the project's propierties and in the libraries panel, select the "Add Jar/Folder". Now, select this files from the unzipped file:

• aspectjrt.jar
• aspectjtools.jar
• org.aspectj.matcher.jar

5) Once this files were added, you must edit the build.xml file created inside you project directory.
6) Between the tags <project> and </project> paste this code:

<taskdef classpath="/home/ignacio/NetBeansProjects/lib/aspectj/aspectjtools.jar"
     resource="org/aspectj/tools/ant/taskdefs/aspectjTaskdefs.properties"/>

<target name="aspectj">
  <echo level="info">--- aspectj (start) ---</echo>  
  <iajc destDir="${build.classes.dir}">
      <inpath>
        <pathelement location="/home/ignacio/NetBeansProjects/lib/aspectj/aspectjrt.jar"/>
        <pathelement location="${build.classes.dir}" />
      </inpath>
 <sourceroots>
  <pathelement location="${src.dir}"/>
 </sourceroots>
 <classpath>
  <pathelement location="${javac.classpath}"/>
  <pathelement location="${j2ee.platform.classpath}"/>
 </classpath>
  </iajc> 
  <echo level="info">--- build.xml by Ignacio Rigoni email: {name}.{lastname}@gmail.com ---</echo>
</target>

<target name="-post-compile" depends="aspectj"></target>

So the complete build.xml file can be like this:

<?xml version="1.0" encoding="UTF-8"?>

<project name="pruebaAspectJ_nb6.9.1" default="default" basedir=".">
    <description>Builds, tests, and runs the project pruebaAspectJ_nb6.9.1.</description>
    <import file="nbproject/build-impl.xml"/>

<taskdef classpath="/home/ignacio/NetBeansProjects/lib/aspectj/aspectjtools.jar"
     resource="org/aspectj/tools/ant/taskdefs/aspectjTaskdefs.properties"/>

<target name="aspectj">
  <echo level="info">--- aspectj (start) ---</echo>  
  <iajc destDir="${build.classes.dir}">
      <inpath>
        <pathelement location="/home/ignacio/NetBeansProjects/lib/aspectj/aspectjrt.jar"/>
        <pathelement location="${build.classes.dir}" />
      </inpath>
 <sourceroots>
  <pathelement location="${src.dir}"/>
 </sourceroots>
 <classpath>
  <pathelement location="${javac.classpath}"/>
  <pathelement location="${j2ee.platform.classpath}"/>
 </classpath>
  </iajc> 
  <echo level="info">--- build.xml by Ignacio Rigoni email: {name}.{lastname}@gmail.com ---</echo>
</target>

<target name="-post-compile" depends="aspectj"></target>
 
</project>

7) Now, modify the lines 7 and 14. In line 7 you must specify the "aspectjtools.jar" with the full path. This is where you unzipped aspectj. In line 14 you must do the same, but pointing to the "aspectjrt.jar" file.

8) That's all.

Considerations

1) Use the aspect{version}.jar file, no the aspectj{version}-src.jar file.
2) Be careful with the paths, it always cause problems!
3) I'm not shure, but may be possible that the other lines you added in build.xml could have errors. It worked fine for me, but may be it depends on the project, so if that causes a problem, you should check the dirs, and other possible error sources.

I wish this helps you! Please, come back and comment or suggest if you think this could be improved in any way.

Colorear código fuente en Bolgger con "Syntax HighLighter"

Esto si que me costo encontrarlo, y mas aun hacerlo funcionar. ¿Por que? Porque en la mayoria de las web esta mal explicado, como en esta.

Luego encontré cómo se configura blogger para que realmente funcione esto: es muy facil. Lo pasos son los siguientes:

1º) Modificamos la plantilla de Blogger.
Para esto vamos a Diseño -> Edición de HTML. Ahi buscamos la etiqueta </head>. Y justo una linea encima de esta agregamos el siguiente código:

<!--SYNTAX HIGHLIGHTER BEGINS-->
<link href='http://alexgorbatchev.com/pub/sh/current/styles/shCore.css' rel='stylesheet' type='text/css'/>
<link href='http://alexgorbatchev.com/pub/sh/current/styles/shThemeDefault.css' rel='stylesheet' type='text/css'/>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shCore.js' type='text/javascript'></script>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushCpp.js' type='text/javascript'></script>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushCSharp.js' type='text/javascript'></script>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushCss.js' type='text/javascript'></script>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushJava.js' type='text/javascript'></script>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushJScript.js' type='text/javascript'></script>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushPhp.js' type='text/javascript'></script>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushPython.js' type='text/javascript'></script>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushRuby.js' type='text/javascript'></script>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushSql.js' type='text/javascript'></script>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushVb.js' type='text/javascript'></script>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushXml.js' type='text/javascript'></script>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushPerl.js' type='text/javascript'></script>
<script language='javascript'>
SyntaxHighlighter.config.bloggerMode = true;
SyntaxHighlighter.config.clipboardSwf = 'http://alexgorbatchev.com/pub/sh/current/scripts/clipboard.swf';
SyntaxHighlighter.all();
</script>
<!--SYNTAX HIGHLIGHTER ENDS-->

2º) Verificar si todo anduvo bien haciendo click en "Ver Blog".

3º) Agregar el código fuente que quieras.
Para esto, cuando estamos editando una entrada, tenemos que hacer click en la pestaña que dice "Edicion de HTML" y ahi agregar las siguientes líneas:

<pre class="brush:java">
Aca va tu codigo en java
</pre>

Donde dice java, ponen el lenguaje que esten usando. Para ver una lista de lenguajes disponibles y como se nombran, vean este link.

Por ultimo, me gustaria recalcar algo. Conviene formatear el codigo fuente, al final de la edición del post, ya que si se hace cambiando el tipo de edición (de "Edicion de HTML" a "Redactar") se pierde el formato de saltos de lineas y espaciados del codigo fuente. Por lo tanto, recomiendo escribir el post completo, y al final poner todo el código fuente que se quiera.

Saludos!

Funciones estáticas de C

Esta tarde estaba mirando/modificando un código en lenguaje C. Me llamó la atención el uso de un puntero a función que referenciaba a una función estática. Me llamó a la atención porque si bien en el paradigma orientado a objetos los métodos estáticos tienen una importancia relevante, no pude hacer una relación inmediata sobre qué podía significar una función estática en la programación estructurada. Por esto es que me puse a buscar un poco, hasta dí con el significado.

Cuando definimos una función como estática en C, lo que realmente estamos haciendo es limitar a que solo las funciones que están definidas en el mismo archivo que la función estática puedan llamarla a ésta. Para verlo más claro, veamos los siguientes archivos:

//////////////////////////
// Archivo: funciones.h //
//////////////////////////

int sumar (int a, int b);
static int rest(int a, int b);
int restar(int a, int b);

//////////////////////////
// Archivo: funciones.c //
//////////////////////////

#include "funciones.h"

int sumar(int a, int b)
{
    return a+b;
}
static int rest (int a, int b)
{
    return a-b;
}
int restar (int a, int b)
{
    return rest(a,b);
}

/////////////////////
// Archivo: main.c //
/////////////////////

#include <stdio.h>
#include <stdlib.h>

int main()
{
    int a, b, c, d, e;

    a = 5;
    b = 7;

    c = sumar(a,b);
    d = restar(a,b); //CORECTO! :)
    e = rest(a,b);   //  ERROR! :(

    return 0;
}

La función rest() está definida como estática, esto quiere decir que solo las funciones sumar() y restar() pueden llamarla; pero main() -que está definida en otro archivo- no puede hacerlo, ya que no la "vé" directamente. (En esta página hay una forma interesante de saltear esta restricción para casos particulares, como por ejemplo, pruebas unitarias).

Puedo decir, sin intención de herir la susceptibilidad de los paradigmáticos, que las funciones estáticas de C vienen a ser las abuelas de los actuales modificadores private tan utilizados en la programación orientada a objetos, ya que ambos permiten el encapsulamiento de funcionalidad .

Luego sigo ahondando un poco más en el tema, ¡nos vemos!

EDIT: Artículo corregido.

Funciones 'inline' de C++: "Expansión en Línea"

Es realmente interesante todo lo que se puede aprender a partir de pequeñas dudas. La mía surgió por un motivo que no viene al caso, pero terminé interesándome por las funciones definidas en el estándar de C++ llamadas inline.

Las funciones inline han venido de alguna manera, a reemplazar las macros de preprocesador. No es que esta fuera la finalidad al crearlas (realmente no lo sé), pero la utilidad es básicamente la misma, aunque las funciones inline tienen ventajas sobre las macros.

Bueno, empecemos: ¿qué hace un función inline? Cuando declaramos una función con el calificador inline, el compilador intentará -llegado el momento- de colocar una copia del código de la función en el lugar de la llamada a dicha función en línea). Esto reduce la sobrecarga que se genera cuando llamamos a funciones, pero a costa de incrementar el tamaño del programa por el hecho de tener una copia de la función en cada lugar en que la llamamos.

Es lo mismo que logramos cuando utilizamos las macros de preprocesamiento para expandir código en línea. Acá se puede ver:

#include <iostream>

using namespace std;

#define macroCubo(x) (x)*(x)*(x)

inline int funcCubo(int x)
{
    return x*x*x;
}

int main(void)
{
    cout << endl << "Con macro: " << macroCubo(2+1);
    cout << endl << "Con inline: " << funcCubo(2+1);

    /*
        La linea 10 queda finalmente como:
            cout << endl << "Con macro: " << (2+1)*(2+1)*(2+1);
        La linea 11 queda finalmente como:
            cout << endl << "Con inline: " << 3*3*3;
    */
}

Aunque el resultado funcional es el mismo, existen diferencias entre los dos métodos:

• Las funciones inline, al ser como cualquier otra función, conlleva una verificación de tipo, cosa que no sucede con las macros, ya que se reemplazan "sin más".
• Las funciones inline no pueden utilizarse de forma sintácticamente incorrecta, ya que esto produciría un error de compilación. Con las macros, es posible sufrir ciertos efectos colaterales por mal uso.
• Las macros no puede ser depuradas, ya que para el precompilador son solo porciones de texto que deben reemplazarse donde se indique. El compilador puede informar un error, pero no podrá decir que se debe a una macro, ni a cual. Por el contrario, las funciones inline se puede depurar como cualquier otra función.
• Las macros reemplazan los argumentos con los parámetros sin evaluar (ver imagen de arriba). En cambio, las funciones evalúan los parámetros (si se tratá de una expresión matemática, por ejemplo, esta se resuelve y se pasa).
  

Cabe aclarar que no me gusta hablar de ventajas y desventajas, y remarco que son diferencias. Muchas veces lo que en ciertos contextos es ua ventaja, en otros puede no serlo o ser una desventaja.

Sobre el uso de las funciones en línea, vale aclarar algunas cositas:

• Cada vez que se modifica una función inline, es necesario recompilar todos los archivos que la utilizan (recordemos que se trata de copiar y pegar el cuerpo de la función; y si ésta se moficia, hay que volver a copiar y pegar).
• Se recomienda utilizar el calificador sólo en las funciones pequeñas (aunque tengo entendido que el compilador lo ignora si la función es relativamente grande).
• Existe una sobrecarga cuando se llama a una función cualquiera, la cual se evita utilizando funciones inline, mejorando el tiempo de ejecución.
  

Ahora quiero mencionar algunos aspectos importantes de las funciones en línea que es conveniente tener presentes al momento de diseñar un programa. Para el "programa típico" quizás no sean relevantes, pero para casos más extremos como sistemas embebidos o sistemas distribuídos, puede significar un costo importante de recursos.

Los aspectos a tener en cuenta son:

• Se reduce tiempo de ejecución, probablemente a costa de aumentar el tamaño del programa. Es necesario evaluar este punto si queremos, por ejemplo, programar sistemas embebidos ya que usualmente el espacio suele ser un factor crítico en estos.
• Las variables que se agregan por las funciones en línea pueden necesitar registros adicionales, y si no se dispone de suficientes, entonces se requerirá más accesos a memoria RAM, incrementando así el tiempo de ejecución.
• Si el código del programa crece demasiado, pueden superarse las limitaciones de recursos (como memoria RAM) y fallar el programa. Esto es importante sobre todo en sistemas de recursos más limitados, como embebidos, móviles, etc.
  

Bueno, supongo que aún pueden tenerse en cuenta algunos aspectos que no he mencionado acá, pero esto da algunas pautas de las consecuencias que puede haber con el uso de las funciones en línea, que pueden ayudar o perjudicar en las aplicaciones que hagamos.

Salutes!

CNEISI '10: Impresiones personales.

Acabo de volver del CNEISI 2010, realizado en la provincia de Santa Fé, y esta es mi impresión en rasgos generales.

La prvincia. No pude conocer mucho debido al poco tiempo que dura el congreso, pero lo poco que ví me encantó. El tiempo nos acompañó de muy buena manera, no hacía ni frío, ni calor. El río formaba un paisaje realmente hermoso y digno de ver, junto al puente "colgante" y desde la orilla odíamos ver el edificio del CONICET y la UNL al otro lado de la misma. También cruzamos a Entre Ríos para concoer Paraná, una ciudad que verdaderamente me encantó, no se, su estilo.. La verdad, quisiera haber tenido más tiempo para conocer ambos lugares un poco más.

El congreso en general. Bueno, este no me encantó desde ningún punto de vista. De hecho su organización me pareció muy pobre. Mi único punto de comparación es el CNEISI 2009 realizado en San Franciso (pvca de Córdoba), el cual me resultó mucho mejor armado.

Las charlas. Son los detalles los que hacen que un congreso sea bueno o malo. Los temas de las charlas me parecieron muy malos (con excpeciones), me arriesgo a decir que fueron casi "improvisados". Dar una charla sobbre "crackeo de contraseñas" es muy pobre... esta es información disponible en cualquier lugar de internet, no hay nada innovador en ello, es más, ¿quién no ha investigado y googleado sobre el crackeo de contraseñas alguna vez?. Otra cosa que noté, es que la empresas -en sus charlas- están ansiosas por presentar("vender") sus productos, sus sistemas... esto no llama, no sirve, esto no es de interés para un estudiante típico.
Como conclusión en las charlas tuve la impresión de que nos llenaron de información inútil, pero no nos muestran la importancia de meditarla. Y por esto mismo, quiero recalcar la charla "¿Me va a servir dentro de 20 años lo que estoy aprendiendo hoy?" que dio Santiago Ceria porque significó algo así como una "pausa en el tiempo", un "wait" para procesar un poco lo que había en el búffer, porque eso es más difícil de encontrar en internet, porque te hace dejar de reaccionar mecánicamente a la información y te hace pensar.. o eso fue lo que me produjo a mi. Esa charla, realmente me encantó.

La comida. Los pebetes con botella del almuerzo no estuvieron mal, teniendo en cuenta que son solo un brake para seuir en el congreso. Por ahi te quedabas como con ganas de comer un poco más, pero de última pasaba. Las cenas me parecieron muy malas, pésimas. La primera: ir a comer a un boliche y comer 6 porciones de pizza por 23 pesos es una gastada... y todavía peor si están frías y con la música a todo volúmen. La segunda cena fue más rica (pancitos con un poco de carne entre medio) pero realmente fue escasa. Nos quedamos con muchísimas hambre. Nuevamente la música a todo volúmen... no da para cenar, no podés conversar. Una cena no debería hacerse en un boliche. En esto, la facultad de San Francisco estuvo muchísimo mejor organizadas. Comidas realmente ricas, y en un ambiente agradable.

El hotel. No estuvo mal para ser que solo pasabamos allí las noches. El servicio no era el mejor, pero para los fines era adecuado. No pongo quejas en ello. Tampoco me siento del todo satisfecho.

A favor... Ló único que si puedo rescatar a favor, y en lo cual este congresó fue superior al anterior, fue la puntualidad. No fue 100% puntual, pero la demora fue de menos horas que el anterior. ¿Qué pasa con esto? Es fácil: cuando una delegación llega a destino luego de un largo viaje, quiere sí o sí ir al hotel y bañarse. No me parece que el hotel este acreditado desde ese mismo día. No me parece que haya que esperar 3 horas en la facultad hasta que nos acrediten en el congreso para recién podes ir al hotel. El problema, es que ni siquiera después se puede ir al hotel. Este es un aspecto que imagino tienen todos los congresos, pero realmente habría que mejorar.

Bueno, esa fue mi impresión general del congreso. De todas formas, la pasé muy bien y esperaremos al año que viene para volver a participar del mismo :)

Info del congreso: http://www.frsf.utn.edu.ar/cneisi2010/

Saludos!

Sincronizar carpetas para trabajar en RED

En este post quiero comentar un esquema -y un programa que permite implementarlo- para la sincronización de recursos que nos facilite el trabajo en red.

Hace tiempo que estaba buscando un buen programa para sincronizar carpetas con un servidor en internet. La finalidad era mantener mis archivos actualizados en cualquier equipo que yo quisiera, sin tener que copiarlos y mantener esa actualización "a mano".

Este problema se vio incrementado aún más, cuando comenzamos a hacer trabajos de campo en quipo en la facultad. Por ahi se necesita tener demasiados archivos al alcance de todo el equipo (de unas 10 personas en mi caso) y donde no resulta cómodo pasarse los archivos por mail, pendrives, o de alguna otra manera. Es decir, lo que se busca es que todo este al alcance de todos sin hacer esfuerzo.

Generalmente, cada intgrante del equipo tendra su propio equipo para trabajar (pc, portatil, etc) y dentro de su equipo tendrá un directorio para cada proyecto. ¡Que bueno si ese directorio puediera compartirse con el resto del equipo!

Bueno... de hecho, se puede: Windows XP lo permite. Pero hay una gran contra: sólo un equipo puede compartir su recurso (una carpeta por ejemplo), y todos los miembros tendrán que acceder a esa carpeta para leer o modificar archivos. Pero lo peor, es que ese equipo tendrá que estar encendido y conectado a la red cada vez que un integrante "remoto" quiera acceder a él para trabajar. Con esto desechamos el "compartir carpetas" de windows y lo enviamos a la papelera de reciclaje ;)

Después de probar bastante (y buscar muchisimo), di con un programa que hasta ahora no me da motivos de queja: Allways Sync. Es licencia freeware, muy fácil e intuitivo. Solo hay que tener claro qué es lo que se quiere hacer (como pasa siempre, ¿no? xD).

Ahora explico con un esquema cual era mi objetivo para trabajar:


El funcionamiento de este esquema es adecuado porque que cualquier equipo puede realizar modificaciones sobre sus carpetas. Estas carpetas se sincronizacn con el servidor -probablemente un servicio de FTP- y cada uno de los otros equipos, cuando se encienda -o si ya está encendido- sincronizará con el servidor y actualizará los archivos. Algo así:


Con este programa que mencioné esto es posible, e incluso el mismo software da muchas más posibilidades que no voy a describir pero están en la página del mismo.

Su configuración para este esquema es muy sencilla, básicamente:

Instalamos All Sync en cada equipo, y por cada equipo realizamos los siguientes pasos.

1. Seleccionamos el "origen" y el "destino". El origen será la carpeta de nuestro equipo que queremos mantener sincronizada con el "destino", que en este caso será el sitio FTP.
   
2. Configuramos el acceso al servidor FTP (servidor, usuario, password, etc).
3. Opcionalmente, podemos ir a las opciones de esta tarea y marcar la opción de que se realice una sincronización cada vez que se modifique algún archivo e incluso que se haga una sincronización cada cierto tiempo.
4. Listo!

Increiblemente, es asi de sencillo. Hay muchas más opciones, pero esas son las principales para este esquema.

Las ventajas principales son:

• No es necesario que un equipo en particular esté prendido para trabajar, ya que los datos están en el mismo equipo que los necesite.
• Si un equipo o el servidor falla y pierde sus archivos, existen copias en los otros equipos.
• Es posible trabajar remotamente sin necesidad de preocuparse por nada, excepto porder acceder a la red de comunicaciones (en este caso se supone que es internet).
• Aún sin una conexión, se puede realizar todos los cambios que se desee, y éstos se actualizaran en el resto de los nodos de trabajo (equipos, servidor, etc) cuando haya una conexión disponible.
  

La desventajas principales son:

• Se requiere una buena política de versionado y posiblemente backups para evitar que un equipo realice modifiaciones indeseables (borrado de archivos, actualizaciones erroneas, etc)
• Si no se cuenta con una conexión a la red de comunicaciones, no se pueden actualizar los archivos de forma indemdiata.

Espero que ésto les sea de utilidad.

¿Generalizacion o Inclusion? Esa es la cuestion.

Esta pregunta surgió en un curso de Diseño de Sistemas, en tanto la profesora pretendia poner a prueba los conocimientos conceptuales supuestamente adquiridos por los alumnos en el curso anterior de Analisis de Sistemas. Todos tiraban ideas, pero costo un buen tiempo entre los cincuenta alumnos llegar a una conclusion importante.

Podemos imaginarnos el siguiente diagrama de Casos de Uso. Si la descripcion del sistema dice que “los pacientes pueden internarse por obra social o de forma particular”, es casi evidente –intuitivo incluso- pensar en una especialización de un caso mas general denominado “Internar”. Algo así:

Esto a simple vista nos resulta correcto, aceptable y hasta tipico y seguimos adelante. Pero la pregunta que podria surgirnos es. ¿Por que especializamos? ¿Por que no incluimos? Es decir, ¿estaria mal el siguiente diagrama?

Que diferencia presenta con el anterior, si ambos pueden hacer exactamente lo mismo. Para asegurarnos de esto, recordemos que es una generalizacion y que es una inclusion.

Inclusion: Es una forma de interaccion, un caso de uso dado puede "incluir" otro. El primer caso de uso a menudo depende del resultado del caso de uso incluido. Esto es util para extraer comportamientos comunes desde multiples casos de uso a una descripcion individual, desde el caso de uso que lo incluye hasta el caso de uso incluido. El comportamiento del caso incluido es colocado dentro del comportamiento del caso de uso base. No hay parametros o valores de retorno.

Generalizacion: Un caso de uso dado puede estar en una forma especializada de un caso de uso existente. Esto se asemeja al concepto orientado a objetos de sub-clases. En la practica puede ser util generalizar comportamientos comunes, describirlos una vez, y enfrentarse a los detalles excepcionales en los casos de uso especializados. Entonces la Generalizacion es la actividad de identificar elementos en común entre conceptos y definir las relaciones de un concepto general y un concepto especializado. Es una manera de construir clasificaciones taxonomicas entre conceptos.

Ya tenemos definidos ambos tipos de relaciones. Las definiciones parecen indicar que estos conceptos son bastante diferentes el uno del otro, y, de hecho los son, pero ¿donde radica la diferencia en el ejemplo dado? Es posible implementar un sistema usando el modelo con generalizacion, y funcionaria de la misma manera que si se implementara el modelo de inclusion.

En el primero, el paciente va a internarse activando el CU “Internar”. Supongamos que el paciente tiene una obra social: entonces el C.U. que se activa es “Internar con Obra Social” aplicando los pasos generales de “Internar” y en el punto indicado se siguen los pasos que pertenecen a la especializacion que, en este caso, se es “Internar con Obra Social”.

En el segundo modelo, el paciente activa directamente el caso de uso “Internar con Obra Social”, el cual realizara los pasos referidos a una internación con obra social llamara al caso de uso “Internar” en el momento que deba realizar los pasos generales.
Como vemos, ambos funcionan sin problemas. La pregunta –insisto- es: ¿porque el segundo no se utiliza?

Dejo abierta la pregunta para quien quiera pensarlo un poco.
Saludos.

Sobrecarga de Propiedades en C#

Buenas noches! La verdad que se hizo larga la espera de este primer posteo temático. El laburo me tiene medio a full, y sumado a la facultad se complica un poco.

Pero en fin, pasemos al tema que quería tratar.

Entiendo que conocen lo que son las propiedades de C#. Si no es así, recomiendo apreneder eso primero. Vemos que las propiedes pueden ser muy útiles.

Para seguir, sabemos que el compilador de C#, transforma las propiedades en métodos para mantener la compatibilidad con los lenguajes .NET que no las soportan.

Por ejemplo, si tenemos la propiedad siguiente:

public int NumeroPositivo
{
    set  
    {
           if(value >= 0)
           num = value;
    }
    get 
    {
            return num;
    }
}

Lo que hace el compilador es generar algo como esto:

public set_NumeroPositivo(int value)
{
   if(value >= 0)
          num = value;
}
public int get_NumeroPositivo()
{
          return num;
}       

Entonces, como al fin y al cabo se generan dos métodos y la propiedad "se pierde" (por llamarlo de alguna manera), se me ocurrió que tal vez podría sobrecargar el método set_xxxx () para que se pueda cargar con diferentes tipos de valores. Para entender mi idea, les muestro como sería el proceso inverso:

Si tenemos los siguientes métodos:

public set_NumeroPositivo(string value)
{
   if(value == "uno")
          num = 1;
   if(value == "dos")
           nume = 2;

   //... etc etc...
}
public set_NumeroPositivo(int value)
{
   if(value >= 0)
          num = value;
}
public int get_NumeroPositivo()
{
          return num;
}

¡¡Mas allá de la poca funcionalidad que tenga esto!! Es solo un ejemplo, pero podría llegar a necesitarse usar algo asi. Bien, según esos métodos, nosotros podríamos pensar en que vienen de una propiedad. Es decir, realizamos el proceso inverso al que efectúa el compilador. Lo que podría llegar a quedarnos es lo siguiente:

public int NumeroPositivo
{
    set  
    {
           if(value >= 0)
           num = value;
    }
    get 
    {
            return num;
    }
}

public string NumeroPositivo
{
    set  
    {
           if(value == "uno")
           num = 1;
       if(value == "dos")
               num = 2;

       //.. etc etc..
     }
}

Digamos que para esta supuesta sobrecarga de propiedad, las condiciones serían:

* Que difiera el tipo de dato (en nuestro caso son int y string).
* Que no se implmente el bloque get en las sobrecargas.

Pregunté en muchos foros si era posible sobrecargar propiedades y me dijeron que no. Que usara métodos. Pero al fin y al cabo, usar métodos es volver al penúltimo código que mostré aquí. Bien, no se puede hacer entonces, pero ¡que bueno sería que se pudiera!

Me encotré con esta inquietud mientras revisaba un código medio feucho que tenía que re-codificar: Vi un método sobrecrgado que solo asignaba un valor a un campo privado. Y se podía tomar como enumeración o como string, pero al fin y al cabo era lo mismo. Y allí surgió mi pregunta.

Espero que no haya significado mucha pérdida de tiempo esto, debido a que es irrealizable. Solo quería mostrar la curiosidad.

Saludos.