Lucas Ontivero : Desarrollo

Deberían los testers arreglar bugs–Parte I

Lucas Ontivero — Thu, 15 Nov 2012 03:23:00 GMT

Esa es la pregunta que lanzé en el sitio Software Quality Assurance and Testing de StackExchange.com en cuyas respuestas pude ver que existe cierto desacuerdo entre la comunidad de testers sobre ese tema y si bien yo tengo una idea clara al respecto, lo que en verdad quería conocer eran las argumentaciones de aquellos que piensan que sí deberían arreglar defectos (algunos defectos) y aquellos que piensan que no deberían para así hacer una síntesis.

No obstante, al poco tiempo otro usuario inicia otro hilo en el que pregunta cuales son las principales responsabilidades de un tester en las que expone una pequeña lista de responsabilidades:

1) Analyzing the Requirements from the client
2) Participating in preparing Test Plans
3) Preparing Test Scenarios,test cases
4) Defect Tracking
5) Preparing Suggestion Documents to improve the quality of the application
6) Communication with the Test Lead / Test Manager
7) Conducting Review Meetings within the Team

Hay tantas cosas con las que no estoy de acuerdo con lo que leo en ese foro que voy a dejar plasmado aquí mi pensamiento. Para comenzar tengo que decir que para mi, la responsabilidad de todos los miembros de un equipo es exactamente la misma: contribuir tanto como sea posible al éxito del proyecto. Entonces, si bien las actividades, especialidades y orientaciones pueden ser distintas, la responsabilidad es la misma.

Ahora bien, si aceptamos esto como válido deberíamos entonces definir qué es un proyecto exitoso y qué no lo es. Para todos aquellos medio entrado en años (de profesión) como yo de seguro les sonará el cuentito llamado OTOBOS que dice que un proyecto exitoso es un proyecto “on time, on budget, on scope” y la verdad es que en los tiempos del los modelos predictivos, en los que el SDLC era por lo general en cascada, mantener al proyecto a lo largo del tiempo on time, on budget y on scope era cosa de magos, se creía que la clave estaba en el *control*. Pues bien, puede que me equivoque pero voy a darles *mi* definición de lo que es un proyecto exitoso:

“Un proyecto exitoso es aquel que nos otorga un alto retorno sobre la inversión a la vez que nos permite crear una relación de confianza con el cliente”

La segunda parte de esta definición habla de la satisfacción del cliente, y puesto que lo que este recibe no es otra cosa que software, deberíamos aclarar qué es un software exitoso para el cliente. Veamos, nuestros clientes no nos encargan el desarrollo de una solución porque no se les ocurran mejores cosas en que despilfarrar el dinero, sino que lo invierten en una herramienta que les permita cumplir con sus metas de negocio. Ya sea optimizando o agilizando la gestión de la compañia, diferenciandose de la competencia, fidelizando clientes, brindando nuevos servicios online o alguna otra ventaja, las empresas *invierten* en software y esperan un retorno de esa inversión. Entonces:

“Un software exitoso (para el cliente) es aquel que le permite cumplir con sus metas de negocios y por tal, le otorga el esperado retorno sobre la inversión”

Y es que de eso se trata y siempre se ha tratado, de dinero. Por lo tanto, la responsabilidad de *todos los miembros del equipo* (sí, testers incluidos) es contribuir a este éxito. Y para esto hace falta mucho más que control y responsabilidades estrictas y predeterminadas.

Continuará…

del.icio.us Tags: software testing,bug fixing,testers roles

Lo que espero de un buen desarrollador

Lucas Ontivero — Tue, 13 Nov 2012 04:15:00 GMT

El buen desarrollador, además de poseer conocimientos y experiencia superiores debe estar infectado por una pasión altamente contagiosa, de esa manera, tarde o temprano el equipo completo se verá contagiado en mayor o menor medida. Esto no es tan inusual, muchas veces nos encontramos con personas que se convierten en referentes no solo de sus equipos sino que también de otros equipos de la misma empresa y todos se benefician de sus conocimientos y su dedicación, especialmente la de enseñar, compartir conocimientos y experiencias… esas cosas que no se encuentran en los libros.

La mayor contribución de estos desarrolladores no suele plasmarse tanto en su código sino en la capacidad de hacer de otros, mejores desarrolladores. Y es que como la experiencia no se adquiere de los libros sino de los errores (no solo propios), es este tipo de desarrolladores el que puede salvar a los menos experimentados de cometerlos. Por último, y para ampliar el punto anterior, otra cualidad necesaria para lograr esto es el conocimiento profundo de la história del software, sus personalidades, sus aportes, sus pensamientos, sus aciertos y errores.

Cómo fallar en el desarrollo – distinguiendo lo importante de lo accesorio

Lucas Ontivero — Sun, 04 Nov 2012 03:38:00 GMT

Martin Fowler escribió un interesante artículo llamado TransMediaApplication en el cual explica un problema común que se presenta a la hora de desarrollar aplicaciones para distintos dispositivo. Creo que esta frase resume todo el artículo: A common mistake is to think of different apps for different delivery devices.

En mi experiencia este escenario no se presenta solo cuando se trata de aplicaciones que corren en distintos dispositivos sino que se presenta con mucha mayor frecuencia de lo que se cree. El caso es que lo que Martin Fowler describe es un caso muy particular de un problema mayor: no comprender de que se trata en parte la arquitectura.

Lo voy a explicar con un ejemplo. Imaginemos que una empresa de transporte de carga nos pide desarrollar un sistema de seguimiento de sus vehículos. Estos vehículos tienen rutas específicas por las que deben transitar y tienen además una velocidad máxima autorizada. Nuestro cliente quiere conocer la ubicación de cada uno de sus camiones y sus velocidades (entre otras miles de cosas) prácticamente en tiempo real o con una demora no mayor a 1 minuto.

Para esto, cada vehículo tiene incorporado algún tipo de dispositivo móvil con GPS (o alguna variante). Nuestro cliente quiere visualizar la posición de sus vehículos en un mapa (en principio, mapas de google) y quiere poder hacerlo desde su dispositivo móvil.

Ahora bien, si quien lee esto fuese el responsable del desarrollo de este sistema… ¿por donde comenzaría?. Muchas personas comienzan por interiorizarse sobre los distintos modelos de dispositivos móviles incorporados a los vehículos, comienzan a interiorizarse por los diferentes sistemas de coordenadas que manejan, por los distintos mecanismos de despacho de esas coordenadas, esto es, si tienen conexión a internet continua, si soportan mensajes SMS, si http, tcp o udp, por los servicios que soportan en cada uno de sus puertos, etc. Luego, continúan por estudiar las apis de google maps, los lenguajes en los que esas apis están disponibles y demás consideraciones sobre cómo trabajar con esos mapas. Por último posiblemente, querrán conocer desde que tipo de dispositivo móvil es que el cliente quiere poder consultar la información.

Todo lo anterior está mal! No quiero decir que no deba hacerse ya que tarde o temprano conocer estas cosas será muy necesario, pero está mal porque denota una falta de análisis reflexivo sobre qué es lo que se debe desarrollar y sobre qué es lo que el cliente (negocio) necesita. Veamos, en la descripción del problema existen varios elementos que debemos notar y sobre los que tenemos que reflexionar, estos son: seguimiento, rutas, posición, velocidad, vehículo, dispositivo móvil, GPS y mapa. Existen otros elementos mencionados directa o indirectamente, pero quiero focalizarme solo estos.

A estos elementos debemos agruparlos en dos categorías: esenciales y accidentales. Así, posición, ruta, velocidad y seguimiento son esenciales mientras que dispositivo móvil, GPS y mapa son accidentales. Vehículo, por su parte, es un sinsentido. Si bien por alguna razón, las descripciones de los problemas que nos proveen los clientes suelen abundar en elementos accidentales, es nuestra responsabilidad el identificarlos y catalogarlos como tales en primera instancia.

El sistema a desarrollar debe, en principio, ser totalmente independiente de consideraciones superfluas como el protocolo de comunicación por medio del cual recibirá la posición de los vehículos. Si lo hace mediante TCP, UDP, por mensajes SMS o por correo twitter no es relevante en principio. Tampoco lo es la manera en que la información será presentada, ni si los clientes corren en dispositivos móviles o en PCs de escritorio, sobre un web browser o una aplicación nativa. Todas estas cosas deberán abordarse en su momento pero es importante comprender que se debe esperar a que llegue ese momento.

¿Y mientras tanto qué? Bueno, mientras no llegue el momento de encarar los detalles debemos centrarnos en resolver el problema esencial: desarrollar el sistema de seguimiento. Esto es lo primero!

En el software como en la vida, no distinguir lo importante de lo accesorio es el camino seguro al fracaso.

del.icio.us Tags: software,arquitectura,desarrollo,diseño

Design patterns in the test of time: VISITOR

Lucas Ontivero — Tue, 30 Oct 2012 04:46:00 GMT

@Ayende ha comenzado una serie de post en lo que revisa algunos patrones de diseño (Go4) luego de transcurridos más de 18 años desde su formalización en el libro Design Patterns: Elements of Reusable Object-Oriented Software. Inspirado por esa serie, y por el hecho de que en mi última entrevista laboral me preguntaron sobre esto, voy a presentar una revisión sobre el patrón visitor.

Visitor en su forma clásica

La motivación detrás de este patrón es poder añadir funcionalidad a una estructura de datos sin necesidad de modificar las clases que conforman esa estructura. En otras palabras: separar las estructuras de datos de aquellos algoritmos que operan sobre ellas. Si vamos a la Wikipedia vamos a ver este diagrama:

Technorati Tags: Design,Pattern,Visitor

Como se ve, tiene referencias cíclicas, es decir, todos los CarElements deben implementar un método accept que recibe una referencia a un CarElementVisitor y todo CarElementVisitor matiene referencias a todos los tipos que implementan la interface CarElement. Esto es porque C# (el diagrama usa java) no posibilida doble dispatch y así, mediante estas referencias cíclicas es cómo se logra simularla.

Aparte del fuertísimo acoplamiento al que nos fuerza, tiene el inconveniente de ser un patrón que agrega bastante complejidad y que es poco legible debido a su “extraña” sintaxis. Así, si tuviésemos un AST y quisiésemos volverlo código mediante un visitor, nuestro código se vería así:

Pero si tratamos de seguir este código, y vamos directamente a la implementación de este método ‘Accept’ nos encontraremos con esto:

Y por último, si nos salteamos la abstracción IVisitor y vamos directamente a la implementación del método Visit del PrinterVisitor, nos encontramos con esto otro:

Si no conoces el patrón, posiblemente no comprendas este código (y tengamos en cuenta que nos hemos salteado las abstracciones!). Pero el motivo más frecuente por el que no se entiende, si es ese el caso, es porque es complejo.

Visitor alternativo

La propuesta que dejo no es mia, ni es nueva. Esta es una implementación muy popular en lenguajes dinámicos.

Partamos del mismo supuesto: tenemos un AST al que queremos transformar en un string. Lo primero que podemos cambiar es la sintaxis confuza del visitor clásico mediante el uso de un Extension Method, como sigue:

Ahora veamos cómo se ven los nodos de este árbol:

Si bien aquí tenemos una interface INode la cual no luce muy bien, la simplicidad de los nodos es evidente ya que no estamos forzando a implementar ningún método extraño, me refiero al método ‘Accept’. Peo vamos a ver la implementación:

Esta implementación es mucho menos compleja y legible, además de reducir notablemente el acoplamiento (los nodos no necesitan conocer al IVisitor ni implementar ningún método extra) lo que posibilita eliminar las referencias cíclicas.

Lucas Ontivero

C# Closures y tipos anónimos a la Javascript

Lucas Ontivero — Thu, 24 May 2012 05:13:28 GMT

Es C# realmente dinámico? Si hace Cuac es un pato, si hace lo mismo que un lenguaje dinámico es dinámico. Qué te dice este código:

Nivelando para abajo

Lucas Ontivero — Thu, 24 May 2012 03:44:00 GMT

Leía este post de Luis Ruiz Pavon acerca del comportamiento de los closures en el que Luis anima a responder cual es la salida de un bloque de código en el que se devuelve un array de expresiones lambdas que referencian a la variable utilizada para iterar dicho array (closures) y entonces veo este comentario de Eduard Tomàs i Avellana:

El link al que referencia Eduard pertenece al blog de Eric Lippert: Closing over the loop variable considered harmful, una vieja entrada que había leído en su oportunidad pero que desestimé porque nunca pensé que llegara a tomarse la decisión de introducir un breaking change en el lenguaje para solucionar algo que NO ESTÁ ROTO, repito, NO ESTÁ ROTO.

Está claro que introducir este tipo de cambios no le gusta a nadie, y que por lo tanto debe de haberse meditado, y mucho. Pero ¿qué es lo que anima semejante cosa? Es decir, si vamos a romperle el código a muchos programadores es porque pensamos que es lo mejor para todos, ¿o no?

Veamos, ¿quiénes pueden verse afectados? de seguro todos aquellos que entiendan lo que son los closures y comprendan el scope de las variables y, ¿quienes pueden verse beneficiados? pues todos aquellos que no entienden esto. Y es por eso que estoy en desacuerdo, porque lo que se intenta una vez más es hacer que el lenguaje sea el guardián de la correctitud del software y no el desarrollado.

En mi experiencia, es absolutamente imposible defenderse de un desarrollador que no sabe lo que hace.

ECMA Harmony y la conquista del mundo

Lucas Ontivero — Sun, 13 May 2012 00:13:45 GMT

Dicen que existe un plan para que javascript domine el mundo en los próximos años, y a decir verdad, y viendo las propuestas que se plasman en el draf del ECMA-262 sexta edición, creo que el plan aunque algo silencioso sigue a marcha firme.

Quiero mostrar aquellas propuestas que a mi me resultan más interesantes:

Strings

Lo bueno: se agregan métodos startsWith(), endsWith(), contains(), repeat(), toArray()

Lo malo: la interpolación de strings no forma parte del draft actual, esta feature permitiría crear string de manera más natural, como por ejemplo:

en lugar de usar las formas actuales:

Destructuring

Esta es una de mis preferidas y permitiría entre otras cosas que una función retorne más de un resultado:

Iterar las propiedades de los objetos de manera más natural:

y quien sabe cuantas cosas más!

Iterators

for-of para iterar sobre los valores de las propiedades en lugar de hacerlo sobre las propiedades es sí mismas.

Generators

Esto nos tienen que resultar familiar a todos, solo hace falta ver el yield para darse cuenta de cómo funciona. Exactamente como se hace en .Net. Ahora podríamos por agregarle al prototype una función where, por ejemplo, para evaluar un predicado contra cada uno de los elementos del iterador y listo, tendremos linq en ECMAScript. (pero mejor ver Array comprehension)

Lo mismo pero quizás más claro y conveniete puede realizarse con un Generator comprehension:

Lambdas

Aunque actualmente no forma parte del draft de la versión 6, la discusión está vida. No hay que explicar nada.

Array comprehension

¿Quien no entiende esto? es un generator que retorna los cuadrados de los números pares de numbers.

Let

Si bien la idea detrás de la sintaxis de javascript era parecerse a java, pocos lenguajes se parecen tan poco. El scope de las variables en javascript es la función y no el code block como en java. Let es justamente para limitar el scope al code block.

Estas son solo unas pocas de las propuestas que se discuten actualmente y que me han gustado más. Otras más importantes quizás sean las de modularidad del lenguaje, pragmas y API, pero a mi me gustan las que tratan sobre la expresividad del lenguaje y la verdad es que con estas y otras propuestas tomadas de ruby y python, ECMAScript va a dar un lindo paso en su plan de conquista del mundo.

Infraestructura

Lucas Ontivero — Tue, 17 Apr 2012 19:52:05 GMT

Por qué es necesario empujar tantos conceptos a la infaestructura como sea posible.

Cómo crear un Compact Framework (I)

Lucas Ontivero — Fri, 10 Feb 2012 21:17:46 GMT

Imaginemos los siguientes escenarios:

tenemos un gran framework super completo del cual queremos obtener una versión más pequeña para correr en dispositivos móviles, y tenemos que quitar ciertas características que el dispositivo no soporta. Además la idea del concepto de “Compact” Framework también hace referencia al tamaño, por lo que queremos eliminar todo el código del las características no soportadas.
queremos lanzar varias versiones de nuestra aplicación como Free Edition, Profesional Edition, Enterprise Edition, y no deseamos que en cada una de las ediciones solo vaya el código necesario para esa edición (y no todo).

¿Cómo lo hacemos?

La idea que propongo, si bien no es original ya que tengo entendido que .Net Compact Framework se ha realizado con una técnica similar, es simplemente identificar en los assemblies todos aquellos fragmentos de código (IL) que se utilizan para implementar las características deseadas y una vez conocido esto, eliminar el resto. Es decir, eliminar todos los métodos, propiedades, campos, eventos, tipos y demás elementos que no tomen parte en la realización de las características que queremos.

Por ejemplo:

En un procesador de texto tenemos 2 features: Save y Print. Y la interacción como se ve abajo.

Del diagrama queda claro que no todas las funcionalidades hacen uso de todos los tipos ni de todos los métodos ni de todas las propiedades, etc. Entonces, si solo quisiésemos permitir guardar un documento, sería seguro eliminar los tipos DocumentReader y Printer, verdad?

Esto es posible hacerlo reescribiendo los ensamblados con Mono.Cecil, solo hay que conocer algo de IL para hacer cosas sencillas aunque para hacerlo realmente bien hay que conocer IL a la perfección.

Veamos el código del ejemplo del cual queremos eliminar la feature que permite imprimir es documento.

Ahora bien, antes de continuar quiero mostrar el resultado de como queda el assembly antes y después de ser procesado:

Lo que se eliminó es la posibilidad de imprimir y por eso, en el assembly procesado no existe el método TargetClass.Print(), ni los field _reader y printer ya que estos solo eran usados por el método TargetClass.Print(). Los tipos Printer y DocumentReader también han sido eliminados ya que no eran usados por otro método más que el TargetClass.Print().

Por otra parte, todos los tipos, campos, propiedades y eventos que son utilizados por otras características, aún cuando sean utilizados además por el TargetClass.Print(), permanecen intactos. Para esto solo hace falta comprobar que la clase Document aún sigue allí (aunque modificada ya que la propiedad Title se ha quitado porque solo era relevante al imprimir).

Bien, la idea entonces es que una vez que conocemos cuales son los métodos que implementan las features que deseamos mantener, la técnica consiste en seguir todas y cada una de las llamadas que ese método realiza. Luego, hacer lo mismo con cada uno de estos de manera recursiva hasta tener la lista de todos los métodos que participan en la realización de la características deseada. Abajo puede verse el mecanismo:

Y con esto ya tenemos el listado de todos los métodos usados, ahora lo que hacemos es eliminar todos aquellos métodos que no se encuentren en la lista:

Esto elimina todos los métodos no usados incluyendo getters, setters, los add y remove de los eventos. Por esta razón es que de seguro nos quedan propiedades sin gettes ni setters y que por lo tanto tenemos que eliminar para que el ensamblado nos quede funcional.

Por último, si existen clases sin métodos, ni campos, ni propiedades ni eventos… la eliminamos también.

Como esto es solo una prueba de concepto, quizás cambie muchas cosas en el código, voy a continuar con la explicación en la siguiente entrada.

Patrón repetido en MVC. Mi propuesta

Lucas Ontivero — Wed, 08 Feb 2012 06:20:43 GMT

Cuando usamos ASP.MVC uno de los patrones que debemos respetar es el de “Un modelo entra, un modelo sale” y otro muy común es el de validar el modelo y si este no es válido devolverle la misma vista al usuario para que corrija los datos de entrada. Por esto es común ver el siguiente patrón:

¿Qué está mal aquí? ¿Lo ves?

Lo que está mal es que este patrón se repite en cada una de las acciones de cada uno de los controladores de cada una de las aplicaciones que hacemos con MVC Framework y eso huele muy pero muy mal (DRY).

Este es el tipo de casos en los que puede ayudarnos AOP, y MVC framework hace un trabajo espectacular al posibilitarnos implementar AOP mediante filtros. Entonces mi idea es que esto debería hacerse así:

Ahora sí el método hace lo que tiene que hacer, ni más ni menos. Para esto (y solo para demostrar mi punto) he creado el atributo ModelValidationAttribute (necesita un mejor nombre!) como sigue:

Y esto funciona a la perfección! Ojo, no recomiendo usarlo sin antes hacer una buena implementación ya que le faltan cosas al ViewResult como TempData entre otras (y el OnActionExecuted vacio tiene un olorcito medio feo – pero no es culpa mia! ¿por qué el creador de la interface IActionFilter me obliga a incumplir el contrato? ¿No serán 2 interfaces distintas [LSP]?)

Bueno, esto como les dije funciona a la perfección. La prueba:

Saludos.

10 consejos para que no te crackeen tan fácil

Lucas Ontivero — Sun, 05 Feb 2012 18:10:33 GMT

Crackear una aplicación tiene algo de arte y de ingenio pero crackear una aplicación .Net es demasiado sencillo para mi gusto, y representa un problema para la empresa o desarrollador que la comercializa y vive de mantener y mejorar el producto. Ya no vale eso de “total quien se va a dar cuenta”, eso no es válido para ninguna aplicación pero esto es aún peor cuando se trata de herramientas de desarrollo de software las cuales serán utilizadas por profesionales que conocen como pueden saltearse los sistemas de licencias.

Hoy, con todas las herramientas de que disponemos en .Net (ILSpy y sus addins de debugging, Cecil, RegSpy, entre otros) saltearse estas validaciones es demasiado sencillo. Por eso quiero hacer algunas pocas recomendaciones que si bien no pueden por si solas detener a quien se lo proponga, por lo menos le dificultará un poco la tarea. Esto es importante desde mi punto de vista ya que si debo invertir una semana para crackear una aplicación quizás me convenga comprarla.

Aquí van:

1. Firma los ensamblados. Esto hará que no puedan reemplazarlo por otro o reescribirlo; caso contrario lo único que debe hacer alguien para saltearse las validaciones es reescribir algún método y listo. Para ilustrar esto veamos un ejemplo, imaginemos que tenemos una clase encargada de verificar la licencia del usuario llamada LicenseChecker la cual tiene un método CheckLicense que retorna TRUE si la licencia es válida y FALSE en caso contrario. En este caso, solo bastaría con reescribir el método insertándole un return true. (ldc.i4.1 ret) Abajo puede verse lo ridículamente sencillo que es lograr esto con Cecil.

Del mismo modo, no guardes información valiosa en constantes publicas ya que de la misma manera, se puede modificar sus valores. Por ejemplo, imagina que en una clase LicenseConstants tenemos un field llamado TrialDays con un valor de 30 que se asigna en el constructor estático en la instrucción nro. 10. en este caso, lo más sencillo será sobrescribir el assembly para asignarle un valor mayor y así extender el período de prueba tanto como queramos. El código sería así:

2. Nombres de identificadores. Nada va a salvarte de ti mismo, si la clase que verifica la licencia se llama LicenseChecker, LicenseValidator o de alguna otra forma altamente sugestiva, cualquiera con medio dedo de frente comenzará por ahí. Simplemente buscará con Reflector o ILSpy la pablabra “License” y listo!
Recuerda que los ofuscadores no pueden cambiar los nombres de los identificadores que forman parte de la superficie pública porque de lo contrario el assembly quedaría inutilizable. Sabiendo esto, te darás cuenta que todo lo que suene altamente sugestivo no puede formar parte de la superficie pública.

3. Ofusca los ensamblados como parte del proceso de Build. Si bien esto tiene pros y contras, con esto no solo dificultas un poco la tarea de examinar el código mediante Reflector, ILSpy u otros sino que además proteges un poco el código de copias ya que la mayoría de estas herramientas permiten extraer el código fuente en proyectos compilables.

4. Strings. Los strings con mensajes que se muestran en la UI referidos a temas de licencias deben estar encriptados de alguna manera. Por ejemplo, si alguien quisiera romper con el componente de validación de licencias y ve que en la UI dice “Enter License Number:”, lo primero que hará será buscar ese string en los assemblies y una vez que lo encuentre se fijará en donde se usa, y desde allí llegará a donde quiera.

5. Encriptación. Encriptar datos no detendrá a nadie aunque sí hará más lento el proceso de cracking y quizás llegue a frustrar a la persona que intenta saltearse la licencia. Lo que hay que tener en cuenta es que no debe ser la clave pública fácil de encontrar. Otro punto aún más importante es que los métodos que encriptan y desencriptan no deben nunca estar en assemblies separados de donde se usan porque de lo contrario estos tendrán que ser públicos y con esto ya arruinamos todo. Es decir, nunca poner estos métodos en un assembly “Utils” con nombres tales como Encript y Decrypt y hacerlos públicos, de lo contrario, cualquiera creará un proyecto de consola, referenciará a ese assembly y buscará las en el registro aquellas claves creadas por la aplicación que se ven claramente como encriptadas. Es decir, aquellas que se ven como sigue “9L3a1IQLzZFOmlU/3GkYu5Dm1ijRA+”, todo el mundo sabe que ésta es una cadena que ha sido encriptada.

6. Registro de windows. Ya sea que el código esté o no ofuscado, los strings con las claves del registro no deben reconocerse fácilmente. Si en alguna parte tenemos un string que comienza con “HKCU\Software\”, ya está! Si además ponemos públicos los algoritmos de desencriptación ni siquiera será necesario buscar la clave de desencriptación, solo será necesario hacer algo así:

Luego modificamos el valor que obtuvimos por consola y lo encriptamos nuevamente (gracias a los métodos que nos brinda el mismo producto) y lo escribimos en el registro.

7. Períodos de prueba. La mayoría de los productos permiten ser usados por un período de prueba, este es uno de los puntos más débiles de casi todos los productos que conozco ya que para lograrlo, por lo general deben guardar la información de activación, días de prueba o fecha de finalización en alguna parte de nuestros equipos (por lo general, en el registro de windows). Suele ser muy sencillo manipular las claves del registro para que ese período de evaluación se extienda ad infinitum. Recuerda que quien intenta saltearse la licencia, tiene el código a su disposición por lo que encontrará la manera de burlar el mecanismo.

Ten en cuenta que puede espiarse la actividad que el sistema realiza en el registro al momento de aceptar la licencia de evaluación con lo que encontrar qué es lo que hay que modificar no es el problema sino el cómo hay que modificarla. Ahí es donde debe ponerse toda la inteligencia.

8. Datetime.Now. Restringe al máximo el uso de Datetime.Now para checkear las diferencias de días que le quedan antes de que expire el período de evaluación, ya que este devuelve la fecha del sistema y esta es modificable por el usuario. Es decir, le damos al usuario una variable que él puede modificar a su antojo. Por lo tanto verifica todos los casos posibles, piensa que el usuario puede cambiar la fecha del sistema al momento de la instalación, piensa en lo valores límites, piensa si la diferencia (DateTime.Now – InstallationDate) es positiva y si es negativa, piensa que lo más fácil para el que menos sabe será jugar con la fecha del sistema.

9. Prueba. Muchas empresas desarrollan sus sistemas de licencias y realizan pruebas funcionales sobre estas para comprobar su correcto funcionamiento. Esto es necesario pero es solo una prueba de caja negra; sobre estos sistemas deben realizarse pruebas de caja blanca y dedicar al menos un día de, al menos, uno de los mejores desarrolladores a probar si puede vulnerar el sistema.

10. Dedicarle el esfuerzo y la inteligencia necesaria. Si no querés que las instrucciones de cómo vulnerar tu sistema se encuentren al otro día de realizado el release accesibles en toda la internet, si no querés que los seriales estén por todos lados, si no querés perder ventas, entonces dedicale el tiempo, esfuerzo, inteligencia y recursos necesarios. Quizás te convenga contratar a un experto en el tema.

Código libre de NULLs

Lucas Ontivero — Thu, 02 Feb 2012 20:02:23 GMT

En este video explico los problemas que causan las referencias nulas en nuestro código y planteo cómo debemos crear un código libre de NULLs.

Autodisciplina al hacer check in

Lucas Ontivero — Fri, 27 Jan 2012 16:22:23 GMT

Cuando el build se rompe con demasiada frecuencia o permanece en ese estado por mucho tiempo, el equipo se ve impedido de avanzar cómodamente. Pero la razón principal por la que se rompen es sin dudas el descuido: no compilar antes de subir, no correr las pruebas antes de subir y no prestar la suficiente atención al mergear entre otras cosas. Esto es porque existe un exceso de confianza en los miembros del equipo.

Para ayudar a mitigar esto, en mi equipo anterior creé este premio semanal con el que nos hemos divertido mucho y la verdad es que me ha dado un resultado enorme hasta el punto que debí quitarlo cuando lo empecé a ganar yo!

Nota: usábamos CC.Net y SVN por lo que más que descansar en la herramienta, lo que logramos fue autodisciplica.

Difícil demostrar con números las ventajas de Pair Programming

Lucas Ontivero — Fri, 27 Jan 2012 05:29:31 GMT

ElBruno ha escrito un interesante artículo en su blog titulado “[#ALM] DEMOSTRANDO CON NÚMEROS PORQUÉ ES CONVENIENTE REALIZAR PAIR PROGRAMMING” en el que, mediante lo que considero un ejercicio de razonamiento, intenta demostrar el incremento que esta práctica puede generar en la productividad de un equipo con una configuración ficticia, aunque bastante común, de 2 Devs. Srs. y 4 Devs. Jrs. Recomiendo su lectura (y además, es condición necesaria para entender de que se habla en esta entrada).

En primer lugar debo aclarar que todo intento por ayudar a difundir, y animar a implementar, esta y otras prácticas es de agradecer e imitar. Además, y solo para dejar explícita mi posición acerca de esta práctica (Pair Programming), debo decir que estoy absolutamente de acuerdo con ella, incrementa la calidad, los diseños, la comunicación y el conocimiento del equipo como pocas prácticas lo hacen. Y además es más sociable y divertido mientras que eleva el compromiso.

Ahora, una vez aclarado esto, debo decir que a mi humilde entender ElBruno no ha acertado en su enfoque. ¿Por qué? Veamos, para demostrar la hipótesis, utiliza el siguiente ejemplo:

El problema con la argumentación es que todo el modelo cierra cuando existe una cantidad de desarrolladores juniors los cuales no pueden completar su trabajo sin quitarles tiempo a los desarrolladores seniors, de esta forma y en este contexto parece que la propuesta es una buena idea para maximizar la productividad. Lo curioso es que según el ejemplo, la mejor solución sería eliminar esos 4 factores de anti-capacity llamados juniors y así, con solo una fracción del costo, los 2 desarrolladores seniors podrían completar sus 2 unidades de trabajo diarias con lo que a la semana tendríamos 20 unidades de trabajo completas. Entonces, es la existencia de esos juniors la condición necesaria para que esto cierre.

No obstante creo que aquí se cumple una gran verdad: poner más desarrolladores, poco experimentados, no incrementa la velocidad del equipo; y como este modelo concuerda con las experiencias de la vida misma, podemos pensar que no está muy lejos de ser correcto.

Ahora, este mismo razonamiento no arroja los mismos resultados si el equipo tuviese otra configuración como por ejemplo si fuesen solamente 6 Devs. Srs. En este caso, si aplicamos el mismo razonamiento utilizado en el ejemplo, el resultado será que como nadie requiere ayuda de otro para terminar (o al menos idealmente), entonces tener a 2 Devs. Srs. en una misma máquina resultaría en una pérdida de la productividad.

Como Pair Programming es exactamente para, entre otras muchas cosas, incrementar la calidad y con esto reducir los costos, creo que esta argumentación podría habilitar a aquellos quienes desconocen la práctica, detractores por ignorancia, a jugar con modelos similares concentrándose en la economía evidente (para ver “si les conviene” o “no les conviene”) ignorando la disminución del costo a largo plazo que esta logra. Quizás, como todo el ejemplo cierra gracias a estos 4 devs. juniors alguien podría argumentar que su equipo no necesita de esta práctica ya que el mismo se compone solo de devs. seniors. Así las cosas, este argumento es de doble filo!

Otro motivo por el que este ejemplo no me parece el mejor es porque, en mi experiencia, Pair Programming funciona mucho mejor cuando ambos desarrolladores tienen conocimientos “equivalentes” y no tan bien cuando la diferencia de conocimientos es grande como entre un junior y un senior. En este último caso, el juniors casi siempre se limita a mirar (y en el mejor de los casos a aprender, que no es poco) pero difícilmente pueda darse la dinámica de cambiar con cierta frecuencia el teclado y los roles.

Por desgracia esta práctica es quizás la menos utilizada y esto se debe entre otras cosas a que es difícil de demostrar de manera “teórica” lo que la hace no muy evidente. Otro problema es que en varios papers de señores científicos que publican en la IEEE y la ACM se menciona que esta incrementa el time to market en entre un 15-20% y por eso es también que se hace mucho más difícil de justificar. En el tiempo de los resultados rápidos pocos quieren invertir a largo plazo.

Refactoring–Extract Method para separar validaciones de operaciones

Lucas Ontivero — Wed, 25 Jan 2012 19:55:59 GMT

Existen casos en los que es conveniente extraer un bloque de código en un nuevo método por razones de validaciones de entrada. Es decir, queremos sepaar el código de validaciones de entradas del código que realiza propiamente las operaciones con estas. En algunos casos esto además puede traernos algunos beneficios de performance. Esto es más claro en los métodos recursivos. Para ilustrar esto pongamos como ejemplo al clásico método que calcula el Factorial de N de manera recursiva:

Aquí el problema está en que el parámetro ‘n’ se valida en cada llamada pero la realidad es que esto no debería ser así ya que si ‘n’ es válido en la primera llamada este va a serlo también en todas las sucesivas invocaciones que se hacen de manera recursiva. Por este motivo es conveniente separar las validaciones y extraer el cálculo del factorial para llevarlo a otro método como sigue:

No es la performance lo que interesa aquí sino la separación conceptual de las validaciones y las operaciones, el incremento de la performance es solo un producto derivado de haber hecho esto.

[Video] Serie sobre excepciones–El rol de las interfaces

Lucas Ontivero — Tue, 24 Jan 2012 04:19:13 GMT

Esta es seguramente la última entrada sobre excepciones en la que explico el rol de la interfaces (con el usuario u otro tipo de clientes) en la captura, tratamiento y traducción de las excepciones.

Code Freeze–Explicando esta MALA práctica

Lucas Ontivero — Mon, 23 Jan 2012 06:05:26 GMT

Hace un par de días una amigo preguntó por esta práctica en twitter por lo que decidí dar una brevísima explicación en este video.

NOTA: a sugerencia de Rodrigo Corral he cambiado el título para que quede claro de entrada que en la inmensa mayoría de los casos esta es una mala práctica, cosa que entiendo he dejado bien claro en el video; aunque nunca se sabe. Creo además que la malas prácticas también necesitan ser explicadas ya que forman parte del vocabulario común y uno debe conocerlas.

[Video] Serie sobre excepciones – Explicando ejemplo del MSDN

Lucas Ontivero — Fri, 20 Jan 2012 06:00:07 GMT

En este video explico el por qué un ejemplo tomado del MSDN está mal y cómo debería de escribirse en cuanto a la manera en que trata las excepciones.

Excepciones – Un caso sobre los ejemplos del MSDN

Lucas Ontivero — Fri, 20 Jan 2012 05:25:31 GMT

Soy un convencido de que muchos de los malentendidos que existen en cuanto al manejo de excepciones en VB.Net y C# es por culpa de los malos ejemplos que siempre ha tenido el MSDN. Con solo invertir un par de segundos en google uno puede encontrar verdaderas aberraciones.. A modo de ejemplo solo pondré dos links y las capturas:

http://msdn.microsoft.com/en-us/library/system.net.dns.resolve(v=vs.110).aspx
Si Bien es cierto que los ejemplos han mejorado muchísimo, porque años antes eran un desastre, todavía siguen existiendo demasiados de estos ejemplos, ejemplos que son tomados por muchos desarrolladores como “bunas prácticas” ya que provienen de un sitio de la más alta confianza.

Otro ejemplo: http://msdn.microsoft.com/en-us/library/system.net.sockets.tcpclient(v=vs.110).aspx. Hay tantas cosas mal en este que da para pensar si estos ejemplos ayudan a los programadores o si por el contrario, los perjudica.

Creando un sistema de indexación para nuestros datos no estructurados en Sql

Lucas Ontivero — Wed, 11 Jan 2012 04:36:19 GMT

Introducción

Existen ocasiones en las que almacenar y organizar nuestros datos en una estructura tabular puede no ser lo ideal, en las que por conveniencia queramos guardar un conjunto de datos fuertemente relacionados en un sencillo xml pero a la vez necesitemos muchas de las características propias de SQL.

Si bien SQL Server nos permite guardar XML (con o sin esquema asociado) e indexarlo, estos índices son muchas veces demasiado grandes y algo lentos y, aunque funcionan obviamente muy bien, podríamos crear nuestro propio sistema de índices más livianos (y también indexar los xml no en tiempo real).

La idea

La idea es crear una delgadísima capa de acceso a datos que nos permita guardar documentos XMLs en la bases de datos utilizando procedimientos almacenados. Estos son básicamente 2: InsertDocument y UpdateDocumet. El objetivo es no solo insertar y actualizar los documentos sino también insertar y actualizar los índices que se hayan creado para los mismo.

Ejemplo

Imaginemos que deseamos guardar datos personales de personas, sus nombres, apellidos, datos de contacto, familiares y otros datos. Para ello usamos documentos XMLs como el que sigue:

Lo primero es crear y registrar la tabla en donde se guardarán los documentos XMLs, para esto utilizamos un procedimiento almacenado: CreateForm y que recibe el nombre de la tabla a crear:

Esto último crea una tabla y la registra dentro de la tabla Forms.

También queremos poder buscar dentro de estos documentos por Nombre, Edad y por el nombre del padre de las personas y por ello crearemos 3 indices mediante el procedimiento almacenado CreateIndex.

Esto último crea 3 tablas, una por cada índice y las registra en la tabla de índices (Indexes). Para la creación del nombre de estas tablas se una como convención NombreTabla_XpathNodo_Idx.

Y ahora si, una vez creados y registrados tanto la tabla como los índices, podemos comenzar a insertar y actualizar documentos. Por ejemplo, para insertar el documento que veíamos al inicio solo debemos invocar al procedimiento

Insertemos otro más:

Veamos cómo quedan los índices luego de insertado este registro:

Ahora podemos buscar los en las tablas de índices y obtener el/los id del/de los documento/s que contiene/n el valor buscado. ¿Pero que sucede si quisiera buscar por más de un valor/columna? Bueno, con estas tablas podemos crear una vista que las uniera mediante un join por DocumentId. Para eso utilizamos el procedimiento almacenado CreateSearchView como sigue:

Lo que crea la vista Personas_SearchView la cual puede utilizarse para búsquedas.

Ahora bien, puesto que el indexado es algo caro, podríamos configurar un Job para que indexe los registros por las noches o lo haga por lotes pequeños de registros o de alguna otra forma que nos permita mover el costo de procesamiento a otro lado o a otro momento. Para ello existe el procedimiento almacenado UpdateIndex el cual recibe como parámetro el nombre del indice a actualizar.

Conclusión

Bien, esta es solo una idea que puede utilizarse en algunos escenarios en los que debamos (o queramos) utilizar SQL mientras que a la vez almacenamos nuestros datos como XMLs sin esquemas las cual puede brindarnos algunas de las características propias de las bases de datos NoSql.

El código está acá.