Ver por etiquetas

Todas las etiquetas » Diseño » Arquitectura (RSS)
Peer2.net ( https://github.com/lontivero/peer2net ) es una librería muy liviana y sencilla de usar orientada a la creación de aplicaciones peer to peer en .net utilizando el protocolo tcp. El punto es que la programación con sockets, y en particular con tcp, introduce algunas complejidades que bien pueden abstraerse y que enumero a continuación: Desempeño : Actualmente existen tres alternativas para utilizar sockets en .net, cada uno con sus pros y contras: Llamadas...
Cuando comencé a programar en c# pensé que nunca más iba a volver a divertirme con algoritmos como los de administración de memoria, pero estaba equivocado! El hecho es que estoy trabajando en un proyecto ‘mascota’ en el que potencialmente cientos de sockets pueden estar enviando y recibiendo datos de manera asíncrona, potencialmente cientos o miles de veces por segundo. Posiblemente te preguntarás qué tiene que ver eso con la administración de la memoria, o más precisamente por qué necesitaría alguien...
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...
@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...
Por qué es necesario empujar tantos conceptos a la infaestructura como sea posible.
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.
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...
Luego de revisar los requerimientos de la aplicación en la que vengo trabajado estos últimos 6 meses,  tuve que pensar cómo plantear la arquitectura de la misma teniendo en cuenta lo siguiente: La aplicación es muy muy muy grande, eso era lo primero que saltaba a la vista en los requerimientos. Al día de hoy, esta cuenta con 1.119 vistas, 797 controladores y un número similar de modelos, entre otras cosas. El equipo iba a ser grande y la idea era que trabajaran lo más focalizados posible en...
A mi anterior entrada la titulé “Las plantillas T4 son basura” cosa que respondió más a mi estado de bronca contra éstas que a su verdadero valor como herramienta. Muchos me preguntaron sobre el por qué de tal calificación y la verdad es que ese por qué es demasiado largo de explicar pero voy a mostrar la punta del ovillo para que a quien le interese pueda descubrirlo por sí solo. Veamos un par de ejemplo muy sencillos, el primero...
En mi anterior entrada mostraba distintas alternativas que podíamos utilizar para volver al siguiente fragmento de código fácilmente testeable. Obviamente existe una infinidad de alternativas que no he abordado como los frameworks de aislamiento, los servidores de smtp que no envían los mails y muchas más. La idea aquí  es mostrar el por qué este código no es un duro de testear. Obviamente es porque tiene una dependencia con la clase SmtpClient la cual se comunica mediante un socket con el ambiente...
La creación de pruebas unitarias requiere al menos lo siguiente: Un framework de pruebas unitarias que debemos dominar. Por lo general son muy simples. Código testeable. Típicamente esto implica código susceptible de ser “aislado”. Nada que decir con respecto al primer punto. Ahora, en cuanto al segundo punto, ¿qué significa que el código pueda ser “aislado”?. Bueno, esto significa que sus dependencias deben poder ser reemplazadas. Esto lo logramos bien por medio de inyectarle sus dependencias o...
Voy a tomar prestado las palabras señal y ruido del campo de las telecomunicaciones para explicar una situación que nos afecta de cerca. Entendamos la palabra señal , en el contexto de esta entrada, como el mensaje, lo importante, lo esencial y como ruido lo indeseable, lo molesto, lo que encarece y entorpece al mensaje. La señal, o el mensaje en este caso, que deseamos transmitir, por lo general todos los que hemos estado en esto durante algún tiempo (y que nos hemos equivocado terriblemente una...
Desarrollo un sistema para la planificación, ejecución y seguimiento de encuestas en el que uno de los requerimientos es poder crear encuestas de manera sencilla y veloz. Además las mismas deben seguir un workflow (algo informal) de revisión. Otro dato importante es que el cliente diseña encuestas que van desde aquellas con solo algunas pocas preguntas hasta esas otras que nos tienen todo un domingo respondiendo acerca de alguna ginebra o algún nuevo centro comercial. Para rematar debo decir que...
Las pruebas unitarias debería ser así de cortas y claras: using System; using System.Collections.Generic; using System.Linq; using System.Text; using NUnit.Framework; using Losoft.Temo.Security.Authorization.Exceptions; namespace Losoft.Temo.Security.Authorization.Tests { [TestFixture] public class AdminGroupSpecs : TestsWithSecurable { [TestCase( "R" ), TestCase( "W" ), TestCase( "V" ), TestCase( "A" )] public void Will_Allow_All_Operation_To_Admin_Accounts...
En mi entrada Fluent Interfaces y TDD presentaba una prueba de concepto sobre un DSL interno que estaba desarrollando para encapsular varios detalles de la manipulación de documentos en el proyecto en el que trabajo actualmente. Luego de avanzar un tanto me doy con un problema muy común en la mayoría de las interfaces fluidas que he visto, a este patrón lo llamo sentencia única . Esto significa que una sentencia de un dsl interno no interactúa con otras del mismo. Veamos un ejemplo: Dh.Using.AnimalControl...
Hoy todos reconocemos el potencial que tiene (LOP) Language Oriented Programming, pero no solo eso sino que muchos ya están invirtiendo para hacerse con las ventajas prometidas por este paradigma(?). Muchos incluso diseñan la sintaxis de aquellos lenguajes que entienden, pueden hacerles alcanzar la productividad, calidad y mantenibilidad que buscan. Ahora bien, una vez decididos a crear el lenguaje (textual) propio para un dominio particular, hay que implementarlo. Aquí es donde deben estudiarse...
Imagina que encontramos un clase estática con varios métodos estáticos los cuales tienen una cantidad aberrante de parámetros. Queremos eliminarla pero nos damos con que está siendo usada en muchísimas partes ¿que hacemos? ¿Como lo harias vos?. Para hablar más concretamente veamos uno de esos métodos: public static void CreateActivityLog( string containerSourceId, string containerId, string action, string sourceId, string instanceId, string docNo, string notes, IFrameworkSecurityContext credentials...
Desarrollar con TDD al principio no es nada fácil pero luego se vuelve “la manera” de desarrollar. Ahora, no siempre hago TDD, si quiero probar algo tan solo tiro las lineas y listo pero, por otro lado, si quiero hacer algo bien por más que tenga algo de código hecho lo tiro y lo comienzo de nuevo con TDD (nunca he perdido mucho. Por el contrario, lo hago porque veo una diferencia). El asunto es que diseñé una interface fluida para encapsular todos los detalles indeseables de la manipulación de documentos...
Hace poco gravé un pequeños video en el que explicaba una realidad que he visto en muchos proyectos respecto de las pruebas unitarias. En síntesis lo que comentaba era que en esos proyectos, los beneficios de las pruebas unitarias no eran visibles mientras que los costos sí lo eran. En problema aparente era la calidad de las pruebas, pero en realidad, el problema de fondo es la estrategia de hacer las pruebas luego de terminado el código. Por lo general, los programadores escriben piezas de código...
Hace poco comencé un nuevo desarrollo y decidí grabar algunos videos de los cuales solo publiqué los primeros tres. Sucede que el hecho de saber que alguien me estaba mirando me hacía prestar mayor atención a mis palabras que al código que debía escribir. No obstante a ello, continué grabándome para tomar el tiempo y estudiarme. La primera parte de ese desarrollo está completado y estos son los números: 66 pruebas unitarias. 15 clases. (solo 4 centrales, el resto son datacontracts, excepciones y...
Más artículos Página siguiente >