DDD principles in a visual designer? Part 1

Yeah, boys, I’m crazy to think about applying DDD to an application like this, but I feel that being so purist has some great consequences to my designs, taking some benefits from this way of thinking  about development.

Domain-driven design, taking as it sounds, is to put the focus on the domain. Think about the domain and about how the model HAS TO BE. Let the rest flow as you need it. Everything should be subsidiary (although it will be important, too).   Take the true essence of the domain of it and make a model.

That model can be simple or incredibly complex, but you have a model and you can talk about it using concepts and relations that flow naturally from it. The model is self-contained and has to describe any substantial change of the domain it represents. You can talk about it as a whole!

That’s really cool.

But there are situations where the model is a bit strange. What if the model is not a common entity like a Person, a Bank Account or a Product? What if you have to deal with entities that are commonly attached to the UI, the layout or part of a document, like a Paragraph, a Rectangle, a Field…?

Leyendo imágenes desde streams

Imagina que te da por leer un array de bytes que sabes que es un PNG. Vale, estupendo. Ahora pones todo lo que sabes sobre la mesa y dices “esto está tirado, tío”. Que sí, que me lo creo, pero hay una cosa que fijo no sabes si cuando decodificas la imagen la estás leyendo desde un flujo:

Si el decoder de la imagen lo creas con la opción de BitmapCacheOption Default, la carga de la imagen será “lazy”, o sea, perezosa. No se cargará inmediatamente y si, como yo, eres un programador que suele cerrar los flujos cuando ya no los necesita (stream.Close o con un bloque “using”), en el momento en que va a cargar la imagen porque la necesita, el flujo está cerrado y la imagen no carga ni a la de 3.

En el ejemplo está bien claro, ¡majuelo!

 public static ImageSource FromArray(byte[] bytes)
        {
            using (var memoryStream = new MemoryStream(bytes))
            {
                var decoder = new PngBitmapDecoder(memoryStream, BitmapCreateOptions.PreservePixelFormat, BitmapCacheOption.OnLoad);
                BitmapSource bitmapFrame = decoder.Frames[0];                            
                return bitmapFrame;
            }
        }

Observa el BitmapCacheOption.OnLoad Winking smile Ahí flipamos en 16,7 millones de colores. NECESARIO SI EL STREAM SE CIERRAAAAAAAAA.

Desde el núcleo hasta las ventanitas

Solamente una reflexión. He notado que en mi código me gusta todo sólido, FUERTEMENTE TIPADO, que en la medida de lo posible, todo quede atado y bien atado.

Sin embargo, en la parte de la UI que representa el modelo me gusta poder elegir entre tipar o no hacerlo en absoluto. Hay situaciones en las que puede interesar indicar el contexto a nivel de tipo, otras veces no solamente no quiero, sino que me gusta que sea completamente dinámico.

A este respecto casa perfectamente C# + XAML + MVVM. Todo lo que se salga de esa concepción me resbala BIG TIME!

Programar en JavaScript es malo para la salud mental

DOLOR DE CABEZA2

“Está comprobado que los programadores HTML5 + JavaScript pierden masa encefálica a un ritmo de un 0,1% mensual.A medio y largo plazo acaban sufriendo parálisis y dificultades motoras”.

Algunos desarrolladores afirman preocupados que la nueva tendencia ha acabado convirtiendo a compañeros de profesión en verdaderos monos ahulladores, calificando la sintaxis de HTML5 como una burla a la inteligencia y un verdadero delito contra-natura.

Successfully applied Uncle Bob’s lessons

sticker,375x360I was absolutely tired of repeating myself when making the same calculations for both X and Y, Width, and Height. So, I contacted Robert C. Martin and got the answer a few months ago. At that moment, I felt almost the same as when I solved a difficult equation. And now I have put it to work, and POCOOOCK! It shouted like a little puppy.

TRIPLE HIT!

I still don’t like to pass 3 arguments to a  method, although it’s private. Fine cinnamon ;D

public class MarginBasedScalingStrategy : ScalingStrategy
    {

        public MarginBasedScalingStrategy(FrameworkElement element) : base(element) { }

        public override void ApplyDeltaHorizontal(double delta)
        {
            Element.Margin = ApplyDeltaToThickness(delta, Element.Margin, Hook);
        }

        public override void ApplyDeltaVertical(double delta)
        {
            Element.Margin = ApplyDeltaToThickness(delta, Element.Margin.Swap(), Hook.Swap()).Swap();
        }

        private Thickness ApplyDeltaToThickness(double delta, Thickness originalMargin, Point hookPoint)
        {
            var left = originalMargin.Left;
            var right = originalMargin.Right;

            var finalLeft = left + (delta * hookPoint.X);
            var finalRight = right + (delta * (1 - hookPoint.X));

            return new Thickness(finalLeft, 0, finalRight, 0);
        }
    }

Go, go, go!

Quercus Rotundifolia Empowered Code®

Se me va la cabeza. Layout nightmare!

Estoy ya loco perdido de tanto darle vueltas a la mocha por culpa de temas de los diseñadores. Hay un temario muy candente, y es que para hacer un buen diseñador de interfaces, el usuario tiene que coger el ratón y dar rienda suelta a su expresividad creando rectángulos y moñas diversas, pero chavales, la cosa no es nada sencilla.

El principal escollo que encuentro a la hora de crear un diseñador es la fuerte dependencia con la plataforma. 

El segundo y más aberronchante es el tema de que el usuario espera una respuesta lineal con respecto a los movimientos que realiza con los elementos de la pantalla. Es decir, que el tío se pone a arrastrar el borde de un elemento y espera que el tamaño del mismo crezca o decrezca siguiendo el la flechita del ratón, o sus dedos en un peculiar gesto “pinch to zoom”.

La historia es que para un modelo de composición de dimensiones absolutas, la cosa no es excesivamente compleja. Es el caso de algo estilo “canvas”. Un lienzo donde el usuario pelea con cajas situadas en una posición que no depende de ningún modo del resto. X=5 y en la posición 5 es donde se va a dibujar. No hay más.

Ahora, si estamos hablando de otro tipo de panel contenedor, la cosa es bastante más distinta. Tú llegas y sueltas un botón en un StackPanel y lo primero que notas es que el ancho de los hijos tiende a llenar el del panel, a no ser que se le dé un margen. Para modificar el tamaño de un hijo de este panel había que jugar con los parámetros Margin, Width y Height. Así podríamos posicionar al gusto cada elemento hijo.

Si el panel es distinto a un StackPanel, habría que tomar medidas distintas según fuese. ¡Ahí está la complejidad! Además el mismo resultado puede lograrse de varias formas, lo cual complica aún más si cabe la interacción.

Pero bueno, salvajes, veré qué puedo hacer. Es un reto personal que espero que sea tumbado en próximas sesiones de programación en casa. Sí, yo programo por ocio en casa, aunque el Call Of Duty me puede.

Bueno, voy a dejar esto, que tengo que darlo todo.