David G Technology Blog

Realidad Aumentada vs. Realidad Virtual vs. Realidad Mixta: Una Guía Introductoria

2018-03-16T07:09:00.000-03:00

A pesar de tener muchas cosas en común, VR, AR y MR no son lo mismo. Este artículo analiza los diferenciadores clave, las fuerzas impulsoras y los casos de uso de estas tres tecnologías relacionadas prometedoras.

La tecnología actual ha recorrido un largo camino desde los días de los discos de cartón fino de View-Master que contienen siete pares 3D estereoscópicos de pequeñas fotografías en color, hasta la realidad virtual de hoy y su primo cercano AR. De hecho, gracias a las grandes inversiones de gigantes como Facebook, Google, Samsung y muchos otros que apuestan a los retornos de alto valor, la realidad virtual y aumentada se está abriendo paso en nuestras fuentes de noticias cada vez con mayor frecuencia.

Reels de View-Master Disneyland, anuncio de 1963

En este artículo, comenzamos resaltando los matices entre VR, AR y MR, y luego realizamos un rápido viaje atrás en el tiempo para ver cómo evolucionó VR / AR. Finalmente, evaluamos cómo encajan en la realidad de hoy y cómo pueden afectar la del mañana.

¿Qué es la Realidad Virtual (VR)?

La Realidad Virtual o VR es una experiencia simulada e inmersiva proyectada por un dispositivo a la vista del usuario. Imagina caminar por el Champs-Elisée (París), mientras estás sentado en tu sótano en San Francisco. Todo lo que necesita es un auricular que lo proyecte a una simulación a través de un visor. Eso es exactamente lo que VR promete, y mucho más.

¿Cómo funciona la realidad virtual?

Daydream, auriculares VR

Algunos de ustedes recordarán que fue una experiencia emocionante usar el View-Master de Mattel, que se introdujo en la década de 1960. La realidad virtual de hoy es la versión moderna de ese efecto estereoscópico turístico: requiere un conjunto de lentes dentro de una ventana gráfica en un auricular y un dispositivo montado donde se almacena o se calcula la experiencia.

Tiltbrush por Google

Desde la observación pura hasta la inmersión completa, el rango de capacidades de realidad virtual varía según el dispositivo y el tipo de auricular utilizado. El uso de un control remoto en sincronización con los auriculares montados permite al usuario interactuar con objetos tridimensionales en el espacio, dentro de la experiencia, ya sea para juegos de realidad virtual o interfaces y aplicaciones virtuales.

La breve historia de la realidad virtual y su evolución a través del tiempo

Dejando de lado el tecnicismo de la realidad virtual por un momento, y centrándonos en la inmersiva experiencia de 360° que pretende proyectarnos, podríamos argumentar que la realidad virtual comenzó a partir de los “murales de 360 grados (o pinturas panorámicas) del siglo XIX, “como la Virtual Reality Society afirma en su History of Virtual Reality Pasamos de un simulador de vuelo temprano (1929) a la primera pantalla montada en la cabeza VR de Morton en 1960, a Neo experimentando todo el mundo como una simulación dentro de The Matrix en 1999.

¿Qué empresas lideran el mercado de realidad virtual hoy?

Avance rápido hasta 2014, donde Google inició un mercado masivo de auriculares DIY que utiliza un teléfono inteligente para impulsar la experiencia de realidad virtual: Google Cardboard. Samsung siguió el año siguiente con su Gear VR, y la nueva carrera para la realidad virtual estaba oficialmente activada. Oficialmente adquirido en junio de 2014, Oculus VR se unió a la familia de Facebook para acelerar su objetivo de dominación en el espectro de gama alta de los auriculares de realidad virtual.

¿Qué es la Realidad Aumentada (AR)?

Tal como lo sugiere su nombre, Augmented Reality, o AR, se agrega a nuestra percepción del mundo superponiendo gráficos generados por computadora, imágenes o un conjunto de datos interactivos.

Fuente: Apple WWDC 2017

¿Cómo funciona AR?

A partir de hoy, AR solo requiere un teléfono inteligente con una cámara y una aplicación AR. Dos elementos clave que lo hacen funcionar son la capacidad de la cámara para capturar el entorno a su alrededor mientras se mueve y el software que calcula y proyecta algunos elementos visuales o contenidos generados por computadora.

Un gran ejemplo de esto en acción es la reciente aplicación AR de IKEA que permite a cualquier persona imaginar cómo se sentiría cualquier habitación o espacio con algunos de los muebles de la marca.

Los Diseñadores y los arquitectos podrían beneficiarse claramente de esta nueva forma de crear objetos a escala de vida en un contexto de vida real. “Ahora, la tecnología ha alcanzado nuestra ambición. AR nos permite redefinir una vez más la experiencia de la venta minorista de muebles, en nuestra inquieta búsqueda de crear una mejor vida cotidiana para todos, en todas partes” dice Michael Valdsgaard, Líder de la Transformación Digital en Inter IKEA Systems.

Una breve historia de AR

Desde el lanzamiento del primer marcador virtual de línea amarilla durante un juego en vivo de la NFL en 1998 hasta la superposición de datos cartográficos para ayudar a las simulaciones de vuelo de la NASA, la realidad aumentada ha vivido fuera de la ciencia ficción durante muchas décadas.

En 1974, Myron Kruger combinó proyectores y cámaras de video en un entorno interactivo; fue el nacimiento de AR tal como lo conocemos hoy.

Más recientemente, AR dio un gran salto hacia una adopción más amplia en la WWDC 17 de Apple, cuando el desarrollo de AR se introdujo en las masas con ARKit, un marco de desarrollo para aplicaciones de realidad aumentada creadas para iPhones y iPads.

ARkit vs. ARCore - La lucha entre Apple y Google para la dominación AR

ARKit de Apple para iOS 11 promete democratizar el desarrollo de contenido de AR y el consumo masivo. Es una respuesta directa al ARCore de Google que tiene la ventaja de aprovechar su conocimiento de estar también en el espacio de realidad virtual, al contrario que Apple. Tanto el diseño de AR como los marcos de desarrollo prometen simplificar y acelerar el proceso de creación y poner la tecnología en manos de millones que ya usan teléfonos Android e iOS.

Dado que las aplicaciones de realidad aumentada aún son nuevas para el mercado masivo, es demasiado pronto para decir qué tan diferentes son estos kits de desarrollo, excepto que son específicos para sus propios sistemas operativos y públicos centrales.

Ahora que las dos compañías tecnológicas más destacadas -entre ellas, que controlan el 99% del mercado de teléfonos inteligentes- han hecho un movimiento tan público detrás de la realidad aumentada, deberíamos estar listos para ver cómo se trastornan las industrias, una vez más.

¿Qué pasa con la realidad mixta (MR)?

La realidad mixta es un híbrido de realidad virtual y AR, y tiene como objetivo ofrecer lo mejor de ambos mundos. Por ejemplo, mientras usa un auricular como VR, al ver a través de una ventana o vidrio translúcido, también proyecta imágenes en la parte superior de nuestro entorno.

Lo que hace que MR se destaque es su aspecto altamente interactivo y la representación realista de la proyección que agrega a nuestro entorno. En lugar de depender únicamente de los controles remotos o las pantallas de los teléfonos, podemos interactuar con el contenido inmersivo usando gestos naturales del cuerpo y de los dedos.

Apple y Google claramente lideran el camino en la tecnología de AR, pero el paisaje de MR de hoy favorece a Microsoft (HoloLens) y al enormemente financiado Magic Leap (hasta ahora solo una demostración de concepto).

Microsoft HoloLens y Magic Leap - Los dos reyes de la carrera de realidad mixta

Microsoft HoloLens

Microsoft HoloLens tecnología holográfica

A pesar de la falla comercial de Google Glass, Microsoft no rehuyó probar su propia “computadora holográfica” en el juego MR. El nombre “HoloLens” proviene de la experiencia central “que le permite interactuar con su contenido digital e interactuar con hologramas en el mundo que lo rodea”.

Magic Leap

Crédito: Magic Leap

Como uno de los emprendimientos pre-producto más financiados, esta empresa respaldada por Google es también uno de los proyectos más reservados de la industria tecnológica. El CEO de Magic Leap, Rony Abovitz lo llama “realidad cinematográfica: un cambio completo en la computación visual”. Esta empresa de tecnología de realidad mixta aborda el desafío de diseñar entornos interactivos aprovechando lo mejor de los sistemas de realidad virtual y aumentada.

Aunque todavía no se ha hecho público, las gafas holográficas utilizan la Señal de campo dinámico digitalizada, proyectando imágenes directamente en el ojo y “engañando” al cerebro haciéndole creer que es real. El resultado es una experiencia aumentada más rica y creíble.

¿Cómo están VR, AR y MR redefiniendo la forma en que vemos y experimentamos el mundo?

VR para entretenimiento y consumo de medios masivos

Uno de los ganadores obvios de la aparición de la realidad virtual es la industria del entretenimiento. Lego Star Wars 360 Experience es un ejemplo de gran adopción e implementación de la realidad virtual, haciendo posible que los espectadores experimenten la narración de una manera totalmente diferente.

Al anunciar el primer auricular independiente VR (que no requiere un teléfono o una computadora para adjuntarlo), el gigante tecnológico Facebook es a la ofensiva con su plan para democratizar la realidad virtual.

AR Reinventa Nintendo — Una empresa centenaria — Casi durante la noche

Con el explosivo éxito de Pokemon Go en 2016, el mundo tuvo su primera visión de cómo AR literalmente podía “mover” nuestra realidad al aumentarla con pequeños monstruos que entraban y salían de nuestras pantallas de teléfonos inteligentes.

Realidad mixta. Realidad fusionada? Sentimientos encontrados.

Con distinciones poco claras de sus primos VR y AR, la realidad mixta tiene dificultades para definir su futuro.

Al igual que VR, MR usa un auricular para iniciar la experiencia. Pero los dispositivos de realidad mixta son diferentes del hardware VR típico porque usan gafas translúcidas montadas como Google Glass que nos permiten mantenernos enraizados en el mundo real — la realidad virtual se mezcla con la realidad real.

Al igual que AR, MR superpone contenido digital y simulaciones además de lo que normalmente veríamos. Pero las experiencias de realidad mixta te permiten interactuar físicamente con la simulación de maneras que AR no puede … todavía. Y en lugar de depender solo de la pantalla de su teléfono, puede usar su cuerpo y los controladores remotos para interactuar con el entorno de forma más interactiva.

Mapa de realidad de acuerdo a Intel, quienes prefieren la “realidad combinada”, (Cortesía ExtremeTech)

The VR, AR, y MR Landscape in Numbers

Con el fin de realmente retomar y alcanzar una adopción más amplia, la tracción financiera será un indicador clave de la tracción tecnológica y experiencial.

Respaldado por inversionistas de alto perfil como Google Ventures de Alphabet, Alibaba y Andreessen Horowitz, Magic Leap lidera el juego de inversiones de MR con casi $ 2 mil millones en fondos de riesgo hasta la fecha.

Repasemos las principales inversiones en compañías clave de VR / AR en el mercado actual.

Consideraciones de diseño para las nuevas realidades

Diseñar para VR, AR y MR es similar a crear nuevas realidades. Este nuevo paradigma de creación de contenido inmersivo y multidimensional exige nuevas reglas y consideraciones. El diseño de realidad aumentada, virtual y mixta aprovecha las habilidades existentes que van desde diseño visual(3D, UI) hasta diseño de experiencia (UX, producto) y desarrollo, entre otros.

Desde una comprensión de la anatomía humana, la empatía, el diseño de sonido a visual y mucho más: cuando se trata de diseñar fuera del lienzo rectangular 2D estándar, las creatividades tienen un nuevo campo de juego.

3D y diseño visual

Los diseñadores de realidad virtual deben usar un enfoque completamente diferente y un conjunto de herramientas para crear experiencias e interfaces inmersivas. Más precisamente, tienen que pensar fuera de la pantalla 2D o en los rectángulos y en su lugar pensar en su lienzo creativo como un espacio ilimitado de 360°.

Todo se convierte en tridimensional, y en consecuencia, los diseñadores de realidad virtual colaboran mejor con los expertos en 3D y/o adquieren una comprensión básica de gráficos 3D utilizando WebGL y otras herramientas de código abierto.

El popular software de creación 3D incluye:

Unity3D (diseño + motor de juego)
Google VR Blocks
Blender 3D (libre, fuente abierta)

Comprender la escala y el posicionamiento

Crédito: HTC Vive space requirements

Las consideraciones de escala y posicionamiento para el diseño de realidad virtual y AR están vinculadas y se afectan entre sí. Por un lado, la distancia de un elemento del espectador afecta la legibilidad y la facilidad con la que uno puede interactuar con él. Por otro lado, la escala de un objeto dentro de la realidad simulada refleja cuán grande / pequeño, o lejano/cerca estaría el mismo objeto en el mundo real.

Seguimiento y movimiento

Crédito: Oculus Rift Touch Controllers

El concepto de seguimiento de movimiento está vinculado al hardware y software virtual, aumentado y de realidad mixta que se utiliza. Por ejemplo, aunque Google Cardboard permite principalmente el seguimiento de movimiento básico desde el acelerómetro del teléfono, el auricular más reciente Google Daydream VR viene con un control remoto que le permite señalar las cosas e impulsar las interacciones dentro del espacio virtual.

En el extremo superior del espectro, los sistemas inmersivos como Oculus Rift y HTC Vive permiten un movimiento más receptivo sistemas de seguimiento y controladores interactivos.

Diseñar para rastreadores de movimiento y controladores requiere una buena comprensión de los gestos humanos naturales y de la capacidad física. Hacer esto bien ayuda a mejorar el efecto de inmersión.

Tomando señales de disciplinas más tradicionales

Fuente: Mike Alger

No es necesario reinventar la rueda cuando se trata de diseñar para AR/VR/MR. Al igual que cuando hicimos la transición de la impresión a la web, podemos tomar muchas claves y aplicar muchos principios de formas de arte más tradicionales.

Por ejemplo, la teoría del color, las reglas de composición y las mejores prácticas de iluminación aún se aplican a los nuevos medios. Debido a que sigue siendo el mundo real el que estamos tratando de emular y experimentar en un contexto diferente, al aprovechar las nuevas tecnologías, los principios fundamentales de las artes visuales pueden aprovecharse al diseñar las nuevas realidades que estamos construyendo.

Principios de animación y transición

Fuente: The Illusion of Life

Lo mismo ocurre con los principios de animación: el efecto de transición y el movimiento en una realidad virtual ganan mucha credibilidad cuando se aplican los 12 principios de animación (nada menos que por Disney). Repasemos brevemente:

Squash and Stretch: Expandir y comprimir un objeto para simular el peso y el volumen en movimiento.
Anticipación: Un indicador de que una acción importante está a punto de llevarse a cabo.
Puesta en escena: Tener una intención clara en cada estado / posición de un objeto.
En línea recta y pose a pose: Primero se definen los estados de inicio y fin y luego se rellena el espacio.
Acción de seguimiento y superposición: Cuando muchas piezas en movimiento se detienen, no todas se detienen a la vez.
Lento de entrada y desaceleración: A.k.a. efecto de relajación - ir despacio, luego rápido, luego lento.
Arco: En pocas palabras, agregando un poco de agitación en la mayoría de los movimientos.
Acción secundaria: Agregar a una acción principal para reforzarla o complementarla.
Sincronización: Usando velocidad o latencia para simular física o escala de tiempo.
Exageración: Acentuar movimientos específicos para ayudar a enfatizar algo.
Dibujos sólidos: Hacer que las cosas se vean más tridimensionales.
Apelación: Este principio requiere características interesantes y atractivas.

Herramientas y recursos

Con el objetivo de democratizar estas tecnologías emergentes y estimular un espíritu de co-creación, muchas empresas comparten sus marcos de diseño y desarrollo con el mundo. Estos son algunos recursos clave para comenzar con realidades virtuales, aumentadas y mezcladas:

Facebook Design – VR resources
Apple – ARkit
Microsoft HoloLens Mixed Reality – MR Kits

El futuro de las realidades aumentadas, virtuales y mixtas

AR ha mostrado una tasa de adopción más amplia si consideramos el éxito mundial del éxito de Pokemon Go. Hoy en día, todo lo que se necesita para experimentar la realidad aumentada es un teléfono inteligente con un sistema operativo actualizado, una cámara decente y una aplicación AR. No hay costo de entrada, y tenemos todo el mundo como nuestro lienzo.

La reciente entrada de Apple en el juego AR promete impulsar aún más las tendencias de realidad aumentada. Tim Cook ha expresado su posiciónal respecto: “Claramente hay algunas cosas geniales para la realidad virtual, pero en mi opinión no es profunda. profundo.”

A pesar de una historia más larga que AR o MR, la realidad virtual parece tener un problema de audiencia, principalmente por el alto costo de adopción de un auricular VR decente, la incomodidad física con el uso prolongado y la falta de casos concretos de uso de la tecnología.

“¿Cómo funciona la realidad virtual?” es una pregunta que a menudo escuchamos en línea, así como en eventos de realidad virtual. No obstante, muchos sectores podrían usar la tecnología para crear nuevas oportunidades. Por ejemplo, realidad virtual en la industria automotriz muestra algunas posibilidades interesantes.

Por último, la realidad mixta es la combinación perfecta de realidad real, aumentada y virtual. “Las aplicaciones son infinitas”, dice Avegant CEO Joerg Tewes. Él reflexiona sobre cómo diseñadores e ingenieros podrían manipular directamente modelos 3D con sus manos. “La realidad mixta permite a las personas interactuar directamente con sus ideas en lugar de pantallas o teclados”, agrega.

El mundo está a punto de ampliar sus fronteras con contenido inmersivo en 3D y el mundo digital como nunca antes. Es una oportunidad única para diseñadores, ingenieros y empresas para unirse a la revolución.

Por: Tidjane Tall

Articulo vía: Toptal

Conviértete en un Diseñador de Clase Mundial al Hacer del Mundo tu Oficina

2018-01-09T07:00:00.000-03:00

El gran diseño tiene la habilidad de guiarnos perfectamente a un resultado encantador. Abarca toda una experiencia cuando interactuamos con un producto o servicio. El gran diseño parece simple, pero es solo a través de una profunda comprensión de las personas y la decisión de desafiar la complejidad que se logra un gran diseño.

Los viajes nos ayudan a desentrañar esa complejidad al dar una nueva perspectiva a las ideas, así como a ayudarnos a experimentar problemas que afectan el mundo a escala global, o incluso esos pequeños detalles que podríamos perder mientras estamos sentados en una oficina normal. Un vuelo retrasado o cómo se rocía el chocolate en el café en esa nueva ciudad revela mucho acerca de la excelente experiencia del usuario y cómo diseñar la emoción. Los viajes ayudan a comprender ecosistemas completos y brindan una visión general completa de cómo estos toques a menudo pasados por alto pueden cambiar por completo un estado de ánimo, crear una sonrisa y construir una marca. Las mejores marcas son las que tienen empatía y saben exactamente para quién existen y cómo ofrecer algo que a esas personas les importa.

Toma Airbnb, por ejemplo. Diseñaron un ecosistema de experiencia completo para satisfacer la alegría al comprender el recorrido del usuario desde todas las perspectivas, superando las expectativas desde el principio al agregar detalles como la fotografía profesional gratuita; y durante los primeros días, literalmente se sumergieron en la experiencia del usuario durmiendo en los pisos de sus primeros adoptantes para comprender el problema que les apasionaba resolver desde todos los ángulos. Los diseñadores deben experimentar los puntos débiles, así como el placer de la solución final para entregar realmente un trabajo de primer nivel, y eso es lo que el viaje hace por usted.

Experimentar el mundo y aplicar nuevas ideas

Ver el mundo puede hacernos diseñadores más productivos. Estar en el camino significa que no siempre podemos estar en línea. Esta desconexión periódica forzada ayuda a mantener el foco, porque simplemente no hay tiempo para las distracciones en línea cuando cada segundo cuenta. Recordando momentos en los que la productividad se intensificó, me llevo a los momentos intermedios cuando repentinamente me sentí entusiasmado por sacar mi portátil al aire, debido a la forma en que el sol golpeó el monitor frente a mí durante mi vuelo y me había recordado este optimismo futurista que se prestaba perfectamente al cambio de marca en el que estaba trabajando. Con productividad adicional, obtenemos soluciones más rápido y con menos estrés. Estamos haciendo nuestras propias mentes y los productos de nuestros clientes un favor. Además, se ha descubierto que viajar realmente puede hacernos más felices y más saludables.

Las soluciones de diseño mejoran a medida que comprendemos más sobre las personas, el mundo y cómo interactuamos con la tecnología. A veces son las pequeñas cosas en las ciudades que nos dan grandes ideas y nuevos enfoques para la resolución de problemas. Por lo general, cuanto más oscuro es el desafío, más emocionante es el aprendizaje y la aplicación del insight. Estar en ciudades nuevas y ver cómo las personas usan la tecnología para facilitar sus vidas nos ayuda a diseñar soluciones de diseño cultural y contextualmente relevantes. Fue solo después de vivir en Berlín por un tiempo que nuestro equipo entendió cómo los locales usaban la tecnología, así como su actitud hacia ella. En ese momento, estábamos diseñando una alarma interactiva que lo despertaba con contenido de audio en vivo y reproducía su música favorita.

Después de extensas investigaciones y pruebas realizadas por los usuarios, descubrimos que las personas tendían a apagar sus teléfonos inteligentes y su wifi durante la noche, lo que obviamente significaba que nuestro enfoque del desafío había cambiado significativamente. Comenzamos a construir una experiencia que ya no dependía de una conexión a Internet para funcionar. En San Francisco, es fácil olvidar que no todos tienen el último teléfono inteligente en sus bolsillos y que solo el 42.3% del mundo está en línea. Pero también en San Francisco o Seúl podemos ver un futuro perfectamente conectado, donde el contenido es contextual y relevante e incluso desbloquear un nuevo espacio de oficina apenas accesible. Es tan importante sumergirse en lo último en tendencias de diseño e interacción como experimentar sistemas completamente fuera de línea. Toma mPesa, lo cual permite a los africanos enviar y recibir dinero con solo un teléfono móvil básico. No se requiere una cuenta bancaria, conexión o transacciones en papel.

Es una perspectiva global que nos da una visión local.

Mejorando la experiencia global del usuario con su perspectiva personal

Sentarse en el metro en Melbourne es toda una experiencia. Es lo opuesto al sistema de transporte altamente eficiente y compacto en Taipei, donde todo se sentía automatizado y puntual. En Melbourne, la infraestructura en expansión de la ciudad hace que los viajes sean largos, y además el estilo de vida relajado hace que el metro sea una experiencia social. No es raro entablar una conversación con la persona sentada a tu lado.

En ciudades rápidas como Taipei, Londres y Nueva York, la socialización parece invasiva. Los viajeros se absorben en sus auriculares e interfaces y usan su tecnología para crear su propia barrera personal. Comprender las diferencias regionales mejora nuestro proceso de diseño ayudándonos a comprender qué tecnología utilizan las personas y nos hace conscientes de sus comportamientos existentes. Una aplicación que entrega alimentos a pedido funcionaría perfectamente en un lugar donde la conveniencia, la salud y la eficiencia son importantes, como en Palo Alto o San Francisco. Sin embargo, puede ser un fracaso total en ciudades como Taipei, donde comer es una experiencia social y comunitaria, impulsada por streetfood y la disponibilidad local.

Paul Graham articula la manera mágica en que las ciudades afectan nuestros cada momento:

“Una ciudad te habla principalmente por accidente, en cosas que ves a través de las ventanas, en las conversaciones que escuchas. No es algo que tienes que buscar, sino algo que no puedes apagar”.

Es la forma en que las nuevas experiencias dan forma a lo que somos como humanos y como diseñadores que viajan facilita. Los viajes ofrecen un rico intercambio cultural y contaminación cruzada de ideas para conectarnos con la diversidad. Estar en un lugar nuevo es como ser un lienzo en blanco para la experiencia, y tener una mente abierta generalmente conduce a generar las mejores ideas y ejecutar los diseños más frescos. Pensar en nuestros pies sacándonos de nuestras zonas de confort nos da nuevos conocimientos.

Un diseñador puede aprender mucho de la publicidad

Una vez, se encontró una perspectiva completamente nueva, aparentemente de la nada. Me desperté especialmente temprano una mañana para tomar un vuelo de Santiago a Atlanta, y me había encontrado en el aeropuerto mucho antes de que partiera el vuelo. Con tiempo para matar, terminé hablando con una mujer amable que estaba en un viaje por el mundo. Ella me contó sobre su fascinación con la publicidad que estaba en los metros en cada ciudad que visitó. Ella había dicho que aprendió más sobre las ciudades a través de la forma en que se anunciaban los productos.

“Hay mucho por descubrir sobre los roles de género, las aspiraciones y los sueños con solo mirar los anuncios en el metro. En Santiago, por ejemplo, hay anuncios de lencería de diosas latinas vestidas escasamente junto a avisos sobre dietas”.

Ella decía cómo estos afectan esa voz de las ciudades que pareciera gritar de forma silenciosa y nos ayudan a entender qué motiva a las personas.

De hecho, la publicidad puede proporcionar pistas culturales que ayuden a los diseñadores a mantenerse al día con las últimas tendencias, así como a proporcionar información sobre lo que motiva a una ciudad. Me senté en la parte posterior de un Uber y conté las vallas publicitarias que se alzaban orgullosas y altas a lo largo de la desolada autopista durante el viaje de El Valle a San Francisco. Visualmente escaso, noté una campaña publicitaria que tenía una sola línea: “pregúntale a su desarrollador”, con un pequeño logotipo rojo Twillio en la parte inferior. La implicación fue clara. Los no desarrolladores tendrían que pedirle a alguien más “conocedor” que ellos que entienda la cartelera.

Este es solo un ejemplo de lo que revela una campaña sobre lo que impulsa a San Francisco. Los desarrolladores son claramente respetados y están en una posición de influencia, y la ubicación y el contenido de la cartelera muestran que hay un claro grupo demográfico que habita la ciudad, que consiste en negocios y tecnología. Ciertamente, nunca había visto una valla publicitaria que anunciara algo nuevo o relacionado con la tecnología en Santiago, donde el contenido estaba impulsado por aspiraciones bastante diferentes. A menudo veía anuncios de Becks o Corona que representaban hombres jóvenes y atados con una botella en la mano y algunas mujeres hermosas de fondo disfrutando de una cerveza en la “Playa”. Fue la actitud despreocupada que reveló mucho sobre las aspiraciones de estilo de vida de la cultura, haciendo hincapié en la amistad, la belleza y la calidad de vida. La dirección artística del anuncio mostraba un destello de lente soleado, una tendencia actualmente evidente en la publicidad y el cine.

Manteniéndose al tanto de las tendencias de diseño fresco

El diseño plano ha sido otra tendencia de larga data en diseño de interfaz, superando el eskeumorfismo (popularizado por Apple), y lentamente se ha estado infiltrando en la publicidad clásica de maneras interesantes . Especialmente en ciudades como Londres, París y Nueva York, donde las estrategias de campaña integradas digitales son primordiales para el éxito de una campaña.

De hecho, esta campaña para McDonalds muestra tanto el diseño plano como los efectos de destello de la lente. Un simple anuncio impreso ya no lo corta, y la ideación de una campaña creativa ahora se denomina con ternura como “#hashtagthinking”, donde se deben tener en cuenta las estrategias completas en y fuera de línea. Son estas ciudades donde a menudo se establecen tendencias creativas, inspirándose en el arte, la moda y la cultura. Una vez que las tendencias creativas alcanzan la popularidad de la corriente principal, generalmente provocada por su ingreso al hogar gracias a las industrias de publicidad y cinematografía, cuentan una historia visual de lo que es importante para una cultura.

Mantenernos en contacto con las tendencias publicitarias nos convierte en mejores diseñadores porque:

Somos capaces de identificar tendencias en diseños y productos
Podemos entender mejor lo que motiva una cultura
Podemos aprender de la claridad de la voz en campañas efectivas
Somos capaces de entender estrategias claras en la comunicación

Estéticamente hablando, hay un montón de valor que los viajes pueden agregar a su trabajo de diseño simplemente experimentando nuevos lugares. Creo que estar en una nueva ubicación puede ayudar a terminar con el estancamiento que incluso los mejores diseñadores enfrentan ocasionalmente. Al intercambiar lo familiar con nuevas imágenes, sonidos, sabores y olores, nos volvemos más receptivos al mundo que nos rodea, encendemos y percibimos las cosas con ojos y mentes nuevos. Al usar nuevas partes de nuestros cerebros y el hecho de que estamos a la expectativa, también es más probable que abordemos los problemas de forma diferente o que lleguemos a conclusiones alternativas simplemente porque estamos más conectados con el mundo en ese momento. A veces está en los detalles de nuestro nuevo entorno: la forma en que la arquitectura en Melbourne te hace soñar con la geometría y te anima a reconsiderar la cuadrícula del último diseño del sitio web, o la forma en que el cabello negro de esa chica brilló al sol con tonos azulados recordándole agregar profundidad a su trabajo.

La exploración es una gran parte del diseño y nos ayuda a obtener resultados innovadores y breves. Del mismo modo, explorar el mundo significa que, al comprender los problemas mundiales, las culturas y sentirse inspirado por las nuevas ubicaciones, podemos traducir efectivamente esas nuevas ideas en diseños que deleiten a los clientes y a las personas que utilizan su solución.

Por: Danielle Reid

Artículo vía: Toptal

Malas Prácticas en el Diseño de la Base de Datos: ¿Estás Cometiendo estos Errores?

2017-12-21T07:30:00.000-03:00

Cada vez que como desarrollador, se te asigna una tarea basada en el código existente, debes enfrentar muchos desafíos. Uno de esos desafíos—la mayoría de las veces el más exigente, implica la comprensión del modelo de datos de una aplicación.

Normalmente te enfrentas a tablas, vistas, columnas, valores, procedimientos almacenados, funciones, restricciones y desencadenantes confusos que tardan mucho tiempo en tener sentido para ti. Y una vez que lo tienen, comienzas a notar muchas maneras de mejorar y aprovechar la información almacenada.

Si eres un desarrollador experimentado, es probable que también notes cosas que podrían haberse hecho mejor al principio, es decir, defectos de diseño.

En este artículo aprenderás sobre algunas de las malas prácticas de diseño de bases de datos comunes, por qué son malas y cómo puedes evitarlas.

Mala Práctica N° 1: Ignorar el Propósito de la Data

Los datos se almacenan para ser consumidos más tarde y el objetivo siempre es almacenarlos y recuperarlos de la manera más eficiente. Para lograr esto, el diseñador de la base de datos debe saber de antemano qué representarán los datos, cómo se va a adquirir y a qué velocidad, cuál será su volumen operativo (es decir, cuántos datos se esperan) y, finalmente, cómo se usará.

Por ejemplo, un sistema de información industrial donde los datos se recopilan manualmente todos los días no tendrá el mismo modelo de datos que un sistema industrial, donde la información se genera en tiempo real. ¿Por qué? Porque es muy diferente manejar cientos o miles de registros por mes en comparación con gestionar millones de ellos en el mismo período. Los diseñadores deben tener consideraciones especiales para mantener la eficiencia y la usabilidad de la base de datos si los volúmenes de datos van a ser grandes.

Pero, por supuesto, el volumen de datos no es el único aspecto a considerar ya que el propósito de los datos también afecta el nivel de normalización, la estructura de datos, el tamaño del registro y la implementación general de todo el sistema.

Por lo tanto, conocer a fondo el propósito del sistema de datos que creará conduce a consideraciones sobre la elección del motor de la base de datos, las entidades a diseñar, el tamaño y formato del registro y las políticas de administración del motor de la base de datos.

Ignorar estos objetivos conducirá a diseños defectuosos en sus aspectos básicos, aunque sean correctos estructural y matemáticamente.

Mala Práctica N° 2: Mala Normalización

Diseñar una base de datos no es una tarea determinista; dos diseñadores de bases de datos pueden seguir todas las reglas y principios de normalización para un problema determinado y, en la mayoría de los casos generarán diferentes diseños de datos. Esto es inherente a la naturaleza creativa de la ingeniería de software. Sin embargo, hay algunas técnicas de análisis que tienen sentido en cada instancia y seguirlas es la mejor manera de acceder a una base de datos que rinde al máximo.

A pesar de esto, a menudo nos enfrentamos con bases de datos que fueron diseñadas sobre la marcha, sin seguir las reglas más básicas de normalización. Tenemos que tenerlo claro: cada base de datos debe, al menos, normalizarse a la tercera forma normal ya que es el diseño que mejor representará a sus entidades y cuyo rendimiento se equilibrará mejor entre consultas e inserción-actualización-eliminación de registros.

Si te encuentras con tablas que no cumplen con 3NF, 2NF, o hasta 1NF, considera rediseñar estas tablas. El esfuerzo que inviertas para hacerlo valdrá la pena en muy corto plazo.

Mala Práctica N° 3: Redundancia

Muy relacionado con el punto anterior ya que uno de los objetivos de normalización es reducirlo, la redundancia es otra mala práctica que aparece muy a menudo.

Los campos y tablas redundantes son una pesadilla para los desarrolladores ya que requieren lógica de negocios para mantener actualizada gran parte de la misma información. Esto es una sobrecarga que puede evitarse si las reglas de normalización se siguen al pie de la letra. Aunque a veces puede parecer necesaria la redundancia, debe utilizarse sólo en casos muy específicos y debe estar claramente documentada para poder tenerse en cuenta en futuros desarrollos.

Los efectos negativos típicos de la redundancia son un aumento innecesario del tamaño de la base de datos, los datos son propensos a la inconsistencia y disminuye la eficiencia de la base de datos pero—más importante—podría llevar a una corrupción en la data.

Mala Práctica No. 4: Integridad Referencial Mala (Restricciones)

La integridad referencial es una de las herramientas más valiosas que proporcionan los motores de base de datos para mantener la calidad de los datos en su mejor forma. Si no se implementan restricciones o muy pocas restricciones desde la etapa de diseño, la integridad de los datos tendrá que depender totalmente de la lógica de negocios, lo que la hace susceptible a errores humanos.

Mala Práctica N° 5: No Aprovechar las Características del Motor de Base de Datos

Cuando estás usando un motor de base de datos, tienes una poderosa pieza de software para tus tareas de manejo de datos que simplificará el desarrollo del software y garantizará que la información sea siempre correcta, segura y utilizable. Un Motor de Base de Datos proporciona servicios como:

Vistas que proporcionan una manera rápida y eficiente de ver tus datos, por lo general desincronizándolos para fines de consulta sin perder la corrección de los datos.
Índices que ayudan a acelerar las consultas en las tablas.
Funciones agregadas que ayudan a analizar información sin programación.
Transacciones o bloques de oraciones que alteran los datos que se ejecutan y comprometen o cancelan (retrotraen) si ocurre algo inesperado, manteniendo así la información en un estado permanentemente correcto.
Bloqueos que mantienen los datos seguros y correctos mientras se ejecutan las transacciones.
Procedimientos almacenados que proporcionan funciones de programación para permitir tareas complejas de administración de datos.
Funciones que permiten cálculos sofisticados y transformaciones de datos.
Restricciones que ayudan a garantizar la exactitud de los datos y evitar errores.
Disparadores que ayudan a automatizar las acciones cuando ocurren eventos en los datos.
Comando optimizador (planificador de ejecución) que se ejecuta bajo el capó, asegurando que cada frase se ejecuta en su mejor momento y manteniendo los planes de ejecución para futuras ocasiones. Ésta es una de las mejores razones para usar vistas, procedimientos almacenados y funciones ya que sus planes de ejecución se mantienen permanentemente en el Motor de Base de Datos.

No conocer o ignorar estas capacidades llevará el desarrollo a un camino extremadamente incierto y seguramente a errores y problemas futuros.

Mala Práctica N° 6: Claves Primarias Compuestas

Este es un punto de controversia ya que muchos diseñadores de bases de datos hablan hoy sobre el uso de un campo generado automáticamente como ID principal como la clave principal en lugar de un compuesto definido por la combinación de dos o más campos. Esto se define actualmente como la “mejor práctica” y, personalmente, tiendo a estar de acuerdo con ella.

Sin embargo, esto es solo una convención y por supuesto, el Motor de Base de Datos permite la definición de claves primarias compuestas, que muchos diseñadores piensan que son inevitables. Por lo tanto, al igual que con la redundancia, las claves primarias compuestas son una decisión de diseño.

Sin embargo, ten en cuenta que si esperas que tu tabla con una clave primaria compuesta tenga millones de filas, el índice que controla la clave compuesta puede crecer hasta un punto en el que el rendimiento de la operación CRUD está muy degradado. En ese caso, es mucho mejor usar una clave primaria ID simple que tenga un índice lo suficientemente compacto y establezca las restricciones de Motor de Bases de Datos necesarias para mantener la singularidad.

Mala Práctica N° 7: Mala Indexación

A veces tendrás una tabla que necesitas consultar por muchas columnas. A medida que la mesa crezca, notarás que los SELECT en estas columnas se ralentizan. Si la tabla es lo suficientemente grande, pensarás lógicamente, en crear un índice en cada columna que uses para acceder a esta tabla pero notarás casi de inmediato que el rendimiento de los SELECT mejora, pero INSERT, UPDATE y DELETE caen. Esto por supuesto se debe al hecho de que los índices deben mantenerse sincronizados con la tabla, lo que significa una sobrecarga masiva para el Motor de Base de Datos. Este es un caso típico de indexación excesiva que puedes resolver de muchas maneras; por ejemplo, tener solo un índice en todas las columnas diferentes a la clave principal que utilizas para consultar la tabla, ordenar estas columnas de las más utilizadas a las menos puede ofrecer un mejor rendimiento en todas las operaciones de CRUD que un índice por columna.

Por otro lado, tener una tabla sin índice en las columnas que se utilizan para consultarlo conducirá, como todos sabemos, a un bajo rendimiento en SELECTs.

Además, la eficiencia del índice depende a veces del tipo de columna; los índices en columnas INT muestran el mejor rendimiento posible pero los índices en VARCHAR, DATE o DECIMAL (si llega a tener sentido) no son tan eficientes. Esta consideración puede incluso llevar a rediseñar tablas a las que se debe acceder con la mejor eficiencia posible.

Por lo tanto, la indexación es siempre una decisión delicada ya que demasiada indexación puede ser tan mala como muy poca y porque el tipo de datos de las columnas a indexar tiene una gran influencia en el resultado final.

Mala Práctica N° 8: Convenciones de Nomenclatura Deficiente

Esto es algo con lo que los programadores siempre luchan cuando se enfrentan a una base de datos existente: entendiendo qué información está almacenada en ella por los nombres de tablas y columnas porque a menudo no hay otra manera.

El nombre de la tabla debe describir qué entidad contiene y cada nombre de columna debe describir qué parte de la información representa. Esto es fácil, pero comienza a ser complicado cuando las tablas tienen que relacionarse entre sí. Los nombres comienzan a ensuciarse y, lo que es peor, si hay convenciones de nombres confusas con normas ilógicas (como, por ejemplo, “el nombre de la columna debe tener 8 caracteres o menos”). La consecuencia final es que la base de datos se vuelve ilegible.

Por lo tanto, una convención de nomenclatura siempre es necesaria si se espera que la base de datos perdure y evolucione con la aplicación que apoya y aquí hay algunas pautas para establecer una versión concisa, simple y legible:

Sin limitaciones en el tamaño del nombre de tabla o columna. Es mejor tener un nombre descriptivo que un acrónimo que nadie recuerde o entienda.
Los nombres que son iguales tienen el mismo significado. Evita tener campos que tengan el mismo nombre pero con diferentes tipos o significados; esto será confuso tarde o temprano.
A menos que sea necesario, no seas redundante. Por ejemplo, en la tabla “Artículo”, no es necesario tener columnas como “Nombre del elemento”, “Precio del artículo” o nombres similares; “Nombre” y “Precio” son suficientes.
Ten cuidado con las palabras reservadas para el Motor de Base de Datos. Si una columna debe llamarse “Índice”, que es una palabra reservada de SQL, intenta utilizar una diferente como “NúmeroÍndice.”
Si se apega a la regla de la clave primaria simple (autogenerado único entero), asígnale el nombre “Id” en cada tabla.
Si se une a otra tabla, define la clave foránea necesaria como un entero, llamado “Id” seguido del nombre de la tabla unida (ej., IdItem).
Si se nombran restricciones, usa un prefijo que describa la restricción (por ejemplo, “PK” o “FK”), seguido del nombre de la tabla o tablas involucradas. Por supuesto, el uso de guiones bajos (“_”) con moderación ayuda a que las cosas sean más legibles.
Para nombrar índices, usa el prefijo “IDX” seguido del nombre de la tabla y la columna o columnas del índice. Además, usa “ÚNICO” como prefijo o sufijo si el índice es único y subraya cuando sea necesario.

Hay muchas pautas de nombres de bases de datos en Internet que arrojarán más luz sobre este aspecto tan importante del diseño de la base de datos pero con estos pasos básicos, al menos puedes acceder a una base de datos legible. ¡Lo importante aquí no es el tamaño o la complejidad de las pautas de nomenclatura sino su coherencia al seguirlas!

Algunas Observaciones Finales

El diseño de la base de datos es una combinación de conocimiento y experiencia; la industria del software ha evolucionado mucho desde sus inicios. Afortunadamente, hay suficiente conocimiento disponible para ayudar a los diseñadores de bases de datos a lograr los mejores resultados.

Hay buenas directrices en el diseño de base de datos en todo el internet, así como malas prácticas y cosas que evitar en el diseño de la base de datos. Solo elije y mantenlo.

Y no lo olvides, es sólo a través de la experimentación, los errores y los éxitos que se aprende así que adelante y comienza ahora.

Por: Fernando Martinez Artículo vía: Toptal

Piensa S.M.A.R.T. Para Definir Objetivos Comerciales Para Tu Próximo Proyecto De UX

2017-11-30T07:30:00.000-03:00

Objetivos de negocio claros significan una ejecución precisa y eficiente. El inteligente. El marco (específico, medible, procesable, realista y basado en el tiempo) puede ser una clave para el éxito de tu diseño.

Muchos diseñadores de UX piensan que su objetivo principal es crear una experiencia de usuario deliciosa o un diseño elegante, pero ese no debería ser el enfoque principal. Los diseñadores necesitan pensar más allá de los simples píxeles. Deben adoptar una perspectiva comercial, pensar estratégicamente, considerar los objetivos principales y diseñar tanto para los usuarios como para los objetivos comerciales.

Al leer el brief del cliente, a menudo encontramos que los objetivos del negocio y los requisitos no están claramente formulados. O bien obtenemos cosas salidas de Clients from Hell, sufrimos falta de comunicación o enfrentamos expectativas poco realistas y poco claras. Escuchamos solicitudes vagas, como, “Queremos que un nuevo sitio web atraiga más visitantes” o “Necesitamos una aplicación muy atractiva”. Como resultado, nos cuesta mucho identificar los objetivos primarios del diseño. Es un deber profesional del diseñador evaluar y planificar todas las necesidades del proyecto, así como los resultados esperados.

Un gran diseñador de UX es un pensador avanzado que no solo se conforma con ejecutar el diseño, sino que se esfuerza por obtener resultados óptimos. Un gran proyecto de diseño siempre debe comenzar analizando el informe del cliente para encontrar puntos de dolor que potencialmente podrían llevar a todo el proyecto en la dirección equivocada. Y finalmente, ambas partes deben acordar los entregables clave a lo largo de todo el compromiso.

¿Por Qué El Pensamiento Y La Planificación Siempre Deben Venir Antes Del Diseño?

Como aprenderemos en este artículo, el framework S.M.A.R.T. evita el desperdicio y maximiza la eficiencia. Los buenos diseñadores siempre están orientados a los resultados; aclaran los requisitos y las metas, manejan las expectativas y trazan un plan claro antes de comenzar a diseñar. Es la mejor manera de optimizar sus esfuerzos y asegurarse de que el proyecto se mantenga en buen camino.

Hacer preguntas vitales desde el principio y hacer una investigación preliminar son pasos clave en el camino. Por ejemplo, ¿necesitamos diseñar un sitio web o una aplicación móvil?.

Es importante pensar de manera proactiva y separar lo bueno de lo imprescindible. Un cliente puede pensar que necesita una aplicación móvil repleta de características complicadas, pero un análisis diligente de los objetivos de negocio podría demostrar que un sitio web simple y receptivo sería suficiente.

Cómo Pensar S.M.A.R.T. Durante un Proceso de Diseño

En su libro Principios, Ray Dalio, uno de los inversores y emprendedores más exitosos del mundo, define los principios como “formas de lidiar exitosamente con la realidad para obtener lo que quiero salir de la vida “. Él enfatiza la idea de un enfoque sistemático y medible para casi todo lo que una empresa, equipo o persona aborda en la vida y el trabajo. Los sentimientos intestinales por sí solos pueden obstaculizar una comunicación buena, clara y saludable; por eso los sistemas y los marcos son tan valiosos.

Para un proyecto de diseño exitoso, sugerimos framework S.M.A.R.T. de referencia. Fue desarrollado por el consultor de negocios George Doran en 1981. Pensó que enfocando la atención en lo específico, mensurable, alcanzable, objetivos realistas y oportunos proporciona la disciplina que ayudará a las personas y equipos a mejorar sus posibilidades de éxito.

El inteligente. acrónimo significa: específico, medible, procesable, realista y basado en el tiempo.

Exploremos cada aspecto de este marco, y cómo se aplica a los proyectos de diseño.

S - Specific (Específico)

Cada objetivo debe estar claramente definido. Se específico y no dejes espacio para la interpretación engañosa.

“Queremos más visitantes” podría significar demasiadas cosas:

El cliente estaría satisfecho con 2,000 visitantes / mes.
El cliente espera más de 30,000 visitantes.
El cliente estaría contento con un aumento del 20%.

No deberíamos tener que jugar un juego de adivinanzas basado en solicitudes vagas. Un objetivo no específico puede llevarnos a un agujero de conejo y causar mucha frustración. Para evitar eso, debemos hacer tantas preguntas como sea necesario hasta que tengamos claridad sobre qué es exactamente lo que se requiere.

Por el contrario, “Necesitamos un aumento del 20% en nuestros visitantes mensuales del sitio web” es específico y no deja espacio para la interpretación.

M - Mensurable (Mesurable)

“Sin datos, eres solo otra persona con una opinión”. - W. Edwards Deming

El diseño no es arte. Las ideas clave deberían informar la información de entrada, y la salida debería ser medible.

“Queremos que nuestros usuarios se sientan más felices” es un objetivo hermoso y noble, pero la felicidad es un valor subjetivo que es difícil de medir.

“Queremos que nuestros usuarios aumenten sus donaciones en un 30%” es mensurable, porque el cliente puede verificar los montos de donación en un sitio web.

En caso de duda, los diseñadores deben hacer algunas pruebas A/B para comparar diseños alternativos. soluciones y optimizar el resultado final.

A - Actionable (Accionable)

Una vez que tenemos un objetivo claro y mensurable, necesitamos los medios para ejecutarlo correctamente.

“Queremos que nuestra audiencia lea los artículos de nuestro blog por completo” no es muy procesable, al menos desde una perspectiva de diseño de UX. Podríamos rastrear las páginas vistas y el tiempo invertido en una página determinada, pero no podemos obligar a los usuarios a leer cada palabra. En este caso, sería mejor sugerir contenido y optimización SEO antes de discutir una solución de diseño.

“Queremos aumentar la participación del usuario en los artículos del blog” es más procesable. Podemos diseñar soluciones para cumplir con ese objetivo: botones para votar el artículo o el autor, formularios para dejar comentarios, una nueva sección de comentarios, etc.

R - Realistic (Realista)

Un objetivo realista debe estar a su alcance, sin apuntar a la luna.

“Queremos que cada visitante en nuestro sitio se registre” es un objetivo muy ambicioso. Lo mismo aplica para “Queremos que diseñe un sitio web para que nuestra startup convierta 100.000 visitantes por día”. ¿Tienen una sólida estrategia de marketing? ¿Contrataron a un hacker de crecimiento para ayudarlos a alcanzar una expectativa tan alta?

Los diseñadores deben tener en cuenta los números y las métricas que esperan los clientes. Por ejemplo, si bien, “esperamos que una tasa de conversión del 10% para este nuevo sitio de comercio electrónico” parezca alcanzable, si tenemos en cuenta que la tasa de conversión promedio para el comercio electrónico es de 2.95%, en realidad es bastante ambicioso.

T - Time-based (Basado en Tiempo)

El tiempo lo es todo. Vincula todos los objetivos a una unidad de tiempo específica.

“Queremos aumentar el tráfico del sitio en un 10%” no tiene un límite de tiempo. Necesitamos saber cuánto tiempo tenemos para lograr ese objetivo. Los números y las proyecciones importan — evaluarlos por adelantado es esencial para manejar las expectativas.

“Queremos adquirir 1,000 usuarios mensualmente durante los próximos seis meses” es muy específico, mensurable, procesable, realista y oportuno. Además, saber cuánto tiempo tenemos que hacer el trabajo que conduce al resultado deseado es esencial. Nos permite ser conscientes de los recursos y las prioridades para mantenernos eficientes a medida que se desarrolla el proyecto.

Usando S.M.A.R.T. con Clientes

Los diseñadores deben analizar cada informe con sus clientes y conducirlos a una conversación en profundidad sobre cómo traducir las expectativas en objetivos alcanzables. Este es un proceso continuo para construir un fuerte marco de comunicación y confianza en ambos lados.

El enfoque Pensamiento de diseño de IDEO explica cómo “pensar como un diseñador puede transformar la forma en que las organizaciones desarrollan productos, servicios, procesos y estrategias”. Es por eso que la comunicación clara y la empatía son clave para aplicar el framework S.M.A.R.T. junto con el cliente y todos los interesados.

Usando S.M.A.R.T. con tu Equipo de Diseño

El framework S.M.A.R.T. es para los diseñadores lo que es un plano para los arquitectos. Estos últimos no comienzan a construir una casa sin una evaluación clara del campo y consideraciones de diseño. Para alcanzar los objetivos comerciales clave, los equipos de diseño deberían alinearse detrás de los objetivos y los medios comunes -más allá de su próxima oportunidad de Dribbble- donde el diseño resuelve el problema tangible tanto para el cliente como para el usuario final.

En la práctica, los objetivos de SMART se pueden enmarcar como historias de usuario o ser incluso más específicos con historias de trabajo como explica Alan Klement. “Como usuario, quiero ser feliz” no es así S.M.A.R.T. Por el contrario, “como usuario, quiero buscar el contenido de un libro y filtrar mis resultados a través de categorías y etiquetas” es muy específico y procesable, y es un gran ejemplo de S.M.A.R.T. objetivo.

Más allá de S.M.A.R.T.

El Google Design Sprint es una gran demostración de lo valioso que es usar un “proceso de prueba de batalla” cuando se diseña en un equipo “para responder preguntas comerciales críticas a través de diseñar, crear prototipos y probar ideas con los clientes “.

Si el proyecto incluye el enfoque y el desarrollo de productos digitales, te sugerimos que eches un vistazo a esta introducción a la gestión de proyectos Agile desde Paul Barnes.

Por: Mateo Di Pascale
Artículo vía: Toptal

Ciberseguridad: Lo que Todo CEO y CFO Debe Saber

2017-11-23T07:30:00.000-03:00

Resumen Ejecutivo

Costos de Ciberseguridad

En 2017, el costo promedio de una violación de datos es de 7.35 millones de dólares. Los costos incluyen desde detección, contención y recuperación hasta interrupción del negocio, pérdida de ingresos y daños al equipo. Una infracción cibernética también puede arruinar la reputación de una empresa o la buena voluntad de los clientes.

Las empresas con los más altos niveles de innovación empresarial tienen ataques más costosos . La adquisición o desinversión de una empresa puede aumentar el costo del delito cibernético en un 20% mientras que el lanzamiento de una nueva aplicación significativa aumentó el costo en un 18%.

24% de las infracciones afectó organizaciones financieras, seguidas de la salud y el sector público.

El costo para las empresas financieras es el más alto de todas las industrias, perdiendo un promedio de 16.5 millones de dólares en 2013.

Las pequeñas empresas están conscientes, pero no están listas

En el último año, los piratas informáticos han incumplido la mitad de todas las pequeñas empresas de Estados Unidos. En la encuesta de 2013 del Ponemon Institute, el 75% de los encuestados no tenía un plan formal de respuesta a incidentes de ciberseguridad. El 66% de los encuestados no confiaban en la capacidad de su organización para recuperarse de un ataque.

Una encuesta de 2017 de la empresa de ciberseguridad Manta indicó que una de cada tres pequeñas empresas no tiene las herramientas para protegerse.

En 2013, el 88% de los ataques iniciados contra las compañías de FS tienen éxito en menos de un día. Sin embargo, solo el 21% de estos se descubren en un día y en el período posterior al descubrimiento, solo el 40% de ellos se restauran en un plazo de un día.

Ataques de Alto Perfil en Empresas Financieras

Ataque Contra Seis Bancos Estadounidenses (2012):Banco de América, JPMorgan Chase, Citigroup, el Banco de EE.UU., Wells Fargo y PNC fueron objetivos en una ola de ataques computarizados por un grupo que decía tener ataduras del Medio Oriente. Estos eran ataques DDoS, donde los hackers sobrecargaron tanto las páginas web de los bancos hasta hacer que éstas dejaran de funcionar.

JPMorgan (2014): Alrededor de 83 millones de cuentas se vieron bajo peligro por los hackers. Irónicamente, JPMorgan gasta 250 millones de dólares en seguridad de computadoras al año. La fuente de la brecha fue que basic: El banco no empleó una autenticación de doble factor.

SWIFT (2016): La Sociedad para las Telecomunicaciones Financieras Interbancarias Mundiales (*SWIFT*), un consorcio internacional de más de 11,000 bancos que facilitan las transferencias transfronterizas, fue hackeada. El Bangladesh Bank, uno de los usuarios de la red *SWIFT*, fue hackeado por la cantidad de 81 millones de dólares.

Prevención y Soluciones de Ciberseguridad

Inteligencia en Tiempo Real. Cuanto más tiempo lleve identificar un truco, mucho más será el costo de sus consecuencias. Con solo 60 segundos de notificación de un compromiso, los costos resultantes podrían ser reducidos al 40%.

Ciberseguro. Las aseguradoras generalmente limitan su capacidad a 5 y 100 millones por cliente. Para Octubre de 2016, sólo el 29% de los negocios de Estados Unidos había comprado un ciberseguro. Sin embargo, se estima que el mercado general de ciberseguros será de 20 billones de dólares para el 2025, subiendo de 3.25 billones de dólares hoy.

Programas de recompensas *Bug Bounty*. Las organizaciones pagan a personas ajenas (" hackers amistosos") para notificarles sobre fallas de seguridad. Las compañías que van desde Google y Dropbox hasta AT&T y LinkedIn ya han adoptado esta práctica.

Intro

“Piensa en la [ciberseguridad] más como seguridad y protección en carreteras y automóviles. El automóvil no ha cambiado realmente en los últimos 30 años, pero tiene mucha seguridad incorporada y no es nada atractivo hasta el momento en que te salva la vida. Tienes partes ocultas – bolsas de aire – y pedacitos que están ahí para recordarte que estés a salvo como cinturones de seguridad… Parte de esto se trata de buen comportamiento y buena actitud, parte de la seguridad física para recordarte que existe un riesgo y parte de ella se prepara para salvarte.”

– Sian John, Estratega Senior de Ciberseguridad en Symantec

Lo admitiremos. La ciberseguridad no es sexy. Sin embargo, en la era digital de la actualidad, la ciberseguridad se ha vuelto cada vez más crítica para las grandes corporaciones y las pequeñas empresas emergentes por igual. Hoy, lo que está en juego es más alto que nunca, como “cada compañía se ha convertido en una compañía de tecnología.” La tecnología se ha convertido en algo más que un complemento de las operaciones de una empresa, y en muchos casos, los activos que viven en su red son sus operaciones principales. Esto se ve agravado por el hecho de que los hacks se están volviendo comunes debido al aumento en el uso de dispositivos móviles e internet de las cosas, así como al creciente ecosistema de ciberdelincuentes.

Este artículo describe los tipos de ciberdelincuentes, tácticas de cibercrimen y factores contribuyentes. La pieza también incluye soluciones tangibles que las empresas pueden usar para protegerse. Las soluciones incluyen protecciones tecnológicas y componentes humanos. Por ejemplo, el liderazgo debe reconocer la ciberseguridad como un problema comercial estratégico y no solo como un “problema de TI”. Además, algunas de las soluciones más efectivas son bastante básicas, como la educación de los empleados o la autenticación de doble factor para los usuarios.

¿Qué es un cibercrimen?

En pocas palabras, un cibercrimen es un crimen con algún tipo de aspecto informático o cibernético. Puede tomar forma en una variedad de formatos y de individuos o grupos con diferentes factores de motivación. Las amenazas cibernéticas son fundamentalmente riesgos asimétricos donde pequeños grupos de individuos pueden causar cantidades, desproporcionadamente, grandes de daño.

Categorías de Ciberdelincuentes

Grupos del crimen organizado con motivación financiera: La mayoría de estos grupos se encuentran en Europa del Este
Los actores del estado nacional: Personas que trabajan directa o indirectamente para que su gobierno robe información delicada e interrumpa las capacidades de los enemigos. En general, son los atacantes cibernéticos más sofisticados, con 30% viniendo de China.
Grupos de activistas o “hacktivistas”: No suelen robar el dinero. Están promocionando su religión, política o causa; quieren impactar reputaciones o impactar clientes.
Persona con información privilegiada: Estos son los empleados “desilusionados, chantajeados o incluso demasiado serviciales” que operan desde dentro de una compañía. Sin embargo, no pueden involucrarse en actividades cibercriminales intencionalmente; algunos simplemente pueden tomar una lista de contactos o un documento de diseño sin darse cuenta del daño que podría causar.

La edad promedio de un cibercriminal es 35 años y el 80% de los piratas informáticos criminales están afiliados con el crimen organizado. En resumen, las personas eligen esto como una profesión.

Tácticas Cibercriminales

Los cibercriminales utilizan métodos estáticos y dinámicos para cometer sus crímenes. Vamos a profundizar.

Denegación de Servicio Distribuido (DDoS)

Un ataque DDoS intenta interrumpir el servicio de una red. Los atacantes envían grandes volúmenes de datos o tráfico a través de la red hasta que se sobrecarga y deja de funcionar. El tráfico entrante que inunda a la víctima proviene de muchas fuentes diferentes, posiblemente cientos de miles. Esto hace posible detener el ataque al bloquear una sola dirección IP y hace que sea difícil distinguir el tráfico legítimo del tráfico de ataque.

Suplantación de Identidad

A menudo se presenta como una solicitud de datos de un tercero confiable, ataques de suplantación de identidadse envían por correo electrónico y piden a los usuarios que hagan clic en un enlace e ingresen sus datos personales. A menudo involucra manipulación psicológica, invocando la urgencia o el miedo, engañando a personas desprevenidas para que entreguen información confidencial.

Hay un par de factores relacionados. En primer lugar, los correos electrónicos de phishing se han vuelto sofisticados y con frecuencia se parecen a solicitudes legítimas de información. En segundo lugar, la tecnología de phishing ahora le está dando licencia a los ciberdelincuentes, incluidos los servicios de phishing bajo demanda y kits de phishing listos para usar. Quizás lo más preocupante es el hecho de que los servicios web oscuros han permitido a los cibercriminales refinar sus campañas y habilidades. De hecho, los correos electrónicos de phishing tienen seis veces más probabilidades de ser cliqueados que los correos electrónicos de marketing de consumo habitual.

Malware

Malware, abreviación de “software maligno,” está diseñado para obtener acceso o dañar una computadora. El malware es un término general para una serie de ciberamenazas que incluye Trojanos, virus, y gusanos. A menudo se introduce en un sistema a través de archivos adjuntos de correo electrónico, descargas de software o vulnerabilidades del sistema operativo.

Mal uso del Privilegio Interno

Mientras que los infiltrados maliciosos que filtran información a WikiLeaks reciben toda la prensa y la gloria, un escenario más común es que un empleado promedio u oportunista o un consumidor secretamente toma datos confidenciales con la esperanza de cobrar en algún momento (60% de las veces). A veces, los empleados se ponen un poco curiosos y hacen algo de fisgoneo (17%). La información personal y los registros médicos (71%) están destinados a delitos financieros, como el robo de identidad o el fraude en la devolución de impuestos, pero a veces es simplemente por chismes.

Revisores de Tarjetas Físicas

Estos ataques incluyen implantar fisicamente en un activo que lee los datos de banda magnética de una tarjeta de pago (por ejemplo, cajeros automáticos, bombas de gasolina, terminales TPV). Es relativamente rápido y fácil llevar a cabo un ataque como este, con el potencial de un rendimiento relativamente alto—y también es un tipo de acción popular (8%).

Consecuencias y Costos de la Ciberseguridad

Costos a la Empresa

Hace tres años, el Wall Street Journal estimaba que el costo del cibercrimen en los Estados Unidos era de 100 billones de dólares. Otros informes estimaron que la cifra era tanto como diez veces más alto que esto. En 2017, el costo promedio de una violación de datos es de 7.35 millones de dólares, en comparación con 5.85 millones en 2014. Los costos incluyen todo desde detección, contención y recuperación ante la interrupción del negocio, la pérdida de ingresos y el daño al equipo. Más allá de las preocupaciones monetarias, una brecha cibernética también puede arruinar elementos intangibles, como la reputación de una empresa o la buena voluntad de los clientes.

Curiosamente, las empresas con los niveles más altos de innovación empresarial a menudo tienen ataques más costosos. Una “innovación empresarial” podría ser cualquier cosa, desde una adquisición o desinversión hasta la entrada en un nuevo mercado geográfico. Se demostró que una adquisición o desinversión de una empresa aumenta el costo del delito cibernético un 20% mientras que el lanzamiento de una nueva aplicación significativa aumentó el costo un 18%.

Para las empresas de servicios financieros, los costos posteriores a una violación de la seguridad se pueden atribuir a la interrupción del negocio, la pérdida de información, la pérdida de ingresos y otros costos.

La Ciberseguridad se Pronuncia para la Industria de Servicios Financieros

La desafortunada verdad es que, aunque ninguna industria es inmune, los problemas de ciberseguridad son particularmente pronunciados para los servicios financieros. De acuerdo con el Informe de Investigaciones de Violación de Datos de Verizon 2017, el 24% de las infracciones afectaron a las organizaciones financieras (la industria más importante), seguidas por la atención médica y el sector público. En comparación, en 2012, la industria ocupó el tercer lugar después de las industrias de defensa y servicios públicos y energía. Más allá de la frecuencia, el costo para las empresas financieras es el más alto de todas las industrias, perdiendo un promedio de 16.5 millones en 2013.

En servicios financieros, el tipo más común de violación cibernética involucró ataques DDoS. Y, como para todos los ataques DDoS, la industria financiera fue golpeada con más fuerza.

Falsos Hackings de Servicios Financieros

Ataque Contra Seis Bancos Estadounidenses (2012)

En 2012, seis importantes bancos estadounidenses (Banco de América, JPMorgan Chase, Citigroup, Banco de Estados Unidos, Wells Fargo y PNC) fueron objetivos principales en una ola de ataques informáticos por un grupo que reclama vínculos en Medio Oriente. Los ataques causaron apagones y demoras en Internet en la banca en línea, lo que resultó en clientes frustrados que no podían acceder a sus cuentas o pagar facturas en línea.

Estos fueron ataques DDoS, donde los hackers abrumaron los sitios web de los bancos hasta el punto de cierre. Los ataques también utilizaron botnets, redes de computadoras infectadas que hacen la licitación de criminales. A veces, las botnets se conocen como “computadoras zombies” que obedecen los comandos de una “botnet principal”. Desafortunadamente, estos pueden ser alquilados a través de mercados negros o prestados por delincuentes o gobiernos.

JPMorgan (2014)

En el verano de 2014, en la mayor brecha de seguridad de un banco estadounidense hasta la fecha, los nombres, direcciones, números de teléfono y direcciones de correo electrónico de alrededor de 83 millones de cuentas fueron comprometidos por los piratas informáticos. Irónicamente, JPMorgan gasta alrededor de 250 millones de dólares en seguridad informática cada año. La violación de 2014 no fue el resultado de un esquema sofisticado. El ataque no usó un ataque de día cero, el nuevo error de software que se vende a millones en el mercado negro. Tampoco utilizó el malware que los piratas informáticos en Corea del Norte emplearon en su ataque cibernético de Sony. Por el contrario, la fuente del problema era básico: El banco no empleó una autenticación de doble factor, que es una capa adicional de seguridad cuando los usuarios inician sesión para acceder a los datos o a una aplicación. El equipo de seguridad de JPMorgan se olvidó de actualizar uno de sus servidores de red con el doble sistema de contraseña—eso es todo lo necesario.

Sistema de Pago SWIFT (2016)

En febrero de 2016, la Sociedad para las Telecomunicaciones Financieras Interbancarias Mundiales (SWIFT), un consorcio internacional de más de 11,000 bancos que facilita las transferencias transfronterizas, fue hackeada. El Bangladesh Bank, un usuario de la red SWIFT, fue hackeado por la cantidad de 81 millones de dólares. Solo una pequeña porción se recuperó antes de que el Banco de la Reserva Federal de Nueva York bloqueara 30 transacciones más, eso podría haber transferido 850 millones de dólares adicionales.

Estos ataques muestran que las redes de pago son tan confiables como su enlace más débil. Muchos en la industria no fueron sorprendidos por el ataque. De acuerdo con Justin Clarke-Salt, cofundador de Gotham Digital Science, una compañía de ciberseguridad, los ataques explotaron una debilidad en el sistema: que no todas las instituciones protegen el acceso a SWIFT de la misma manera. Después de todo, “los atacantes a menudo atacan a personas que son más fáciles de atacar… Tan lejos de lo que sabemos que se ha informado públicamente, se han dirigido en gran medida a instituciones financieras más pequeñas. Esto es probablemente porque tienen controles menos sofisticados”.

¿Son Pequeñas o Grandes las Empresas más Vulnerables?

Aunque las noticias a menudo cubren los ataques a las corporaciones más grandes (Target, Yahoo, Home Depot, Sony), las pequeñas empresas no_son_inmunes. En los últimos 12 meses, los piratas informáticos han violado la mitad de todas las pequeñas empresas en los Estados Unidos, de acuerdo con el Informe sobre Ciberseguridad del Estado de SMB 2016.

Por un lado, algunos argumentan que las empresas más pequeñas pueden no ser capaces de recuperarse de un ciberataque**. **Según Sian John, estratega senior de seguridad cibernética en Symantec, las empresas golpearon con una experiencia de seguridad un “golpe masivo de reputación y financiero” para las empresas en el año posterior, antes de volver a la normalidad. Ella cuestionó: “Si eres una empresa más pequeña, ¿puedes sobrevivir a ese chapuzón?”

Por otro lado, otros argumentan que las pequeñas empresas tienen una ventaja: “Una gran empresa es más vulnerable que una pequeña empresa: tienen grandes conjuntos de datos y cientos de personas tienen que tener acceso … si estás en el extremo más pequeño de la escala, ser inteligente con respecto a los procesos de negocio y comprender dónde podrían explotarse esos procesos comerciales es más fácil que para una gran organización,” declaró Richard Horne, socio en PricewaterhouseCoopers.

Desafíos de Ciberseguridad

Factores que Contribuyen al Aumento en el Cibercrimen

Ha Surgido una Camada “Corporativa” de Ciberdelincuentes

Los ciberdelincuentes están adoptando las mejores prácticas corporativas para aumentar la eficacia de sus ataques. Algunos de los delincuentes más emprendedores están vendiendo o licenciando herramientas de piratería para delincuentes menos sofisticados. Por ejemplo, los delincuentes profesionales han estado vendiendo tecnología de día cero a los delincuentes en el mercado abierto, donde rápidamente se convierten en productos básicos. Las pandillas también ofrecen ransomware como servicio, el cual congela los archivos de la computadora hasta que la víctima cumple con las demandas monetarias, y luego toma una parte del dinero por proporcionar la licencia.

Ahora hay un ecosistema completo de recursos para que los ciberdelincuentes aprovechen. “Los grupos avanzados de ataque criminal ahora se hacen eco de los conjuntos de habilidades de los atacantes del estado-nación. Tienen amplios recursos y un personal técnico altamente capacitado que opera con tal eficiencia que mantienen un horario comercial normal e incluso toman los fines de semana y las vacaciones… incluso están viendo atacantes criminales de bajo nivel crear operaciones de call center para aumentar el impacto de sus estafas,” dijo Kevin Haley, director de Symantec.

Seguridad de los Proveedores de Terceros

Si un tercero es pirateado, su empresa corre el riesgo de perder datos de negocios o comprometer la información del empleado. Por ejemplo, la brecha de datos de Target en 2013 que comprometió 40 millones de cuentas de los clientes, fueron el resultado del robo de las credenciales de la red de un proveedor externo de calefacción y aire acondicionado. Un estudio de 2013 indicó que el 63% de las investigaciones de violación de datos de ese año estaban vinculadas a un componente de terceros.

Mayor Uso de Tecnologías Móviles por Parte de los Clientes

Debido a un número creciente de objetivos en línea, la piratería se ha vuelto más fácil que nunca. En la banca de consumo, el uso de dispositivos móviles y aplicaciones se ha disparado. De acuerdo a un estudio de 2014 de Bain & Company, el móvil es el canal bancario más utilizado en 13 de 22 países y comprende el 30% de todas las interacciones a nivel mundial. Además, los consumidores han adoptado sistemas de pago móvil. Para los bancos que compiten con nuevas empresas de Fintech, la conveniencia del cliente seguirá siendo importante. Puede que tengan que analizar las posibles pérdidas por fraude con pérdidas derivadas de una experiencia de usuario más inconveniente. Algunas instituciones están utilizando la autenticación avanzada para enfrentar estos riesgos de seguridad adicionales, lo que permite a los clientes acceder a sus cuentas a través de voz y reconocimiento facial.

Proliferación de Internet de las Cosas (IoT)

El Internet de las Cosas (IoT) está dedicado a la idea de que una amplia gama de dispositivos, incluidos electrodomésticos, vehículos y edificios, se pueden interconectar. Por ejemplo, si tu alarma suena a las 7:00 a.m., podría notificar automáticamente a tu cafetera para comenzar a preparar café para ti. IoT gira en torno a la comunicación máquina a máquina; es móvil, virtual y ofrece conexiones instantáneas. Actualmente hay más de mil millones de dispositivos de IoT en uso, se espera que el número sea más de 50 billones para el 2020. El problema es que muchos dispositivos inteligentes más baratos a menudo carecen de la infraestructura de seguridad adecuada. Cuando cada tecnología tiene un alto riesgo, el riesgo crece exponencialmente cuando se combina.

Conciencia de Ciberseguridad vs. Disposición para Dirigirse

A pesar de los titulares sobre seguridad cibernética y sus amenazas, sigue habiendo una brecha entre la conciencia de las empresas y su disposición a abordarla. En el último año, los piratas informáticos han infringido la mitad de todas las pequeñas empresas de Estados Unidos. En la encuesta de 2013 del Ponemon Institute, el 75% de los encuestados indicaron que no tenían un plan formal de respuesta a incidentes de ciberseguridad. 66% de los encuestados no confiaban en la capacidad de su organización para recuperarse de un ataque. Aún más, una encuesta de 2017 de la empresa de ciberseguridad Manta indicó que una de cada tres pequeñas empresas no tiene las herramientas para protegerse.

Tácticamente hablando, las compañías de servicios financieros tienen mucho que mejorar en términos de detección y respuesta a los ataques. En 2013, 88% de los ataques iniciado contra las compañías de FS tienen éxito en menos de un día. Sin embargo, solo el 21% de estos se descubren en un día y en el período posterior al descubrimiento, solo el 40% de ellos se restauran en un plazo de un día.

Las Soluciones de Seguridad Cibernética Requieren un Enfoque Multifacético

No existe una solución “única para todos” para la ciberseguridad. Sin embargo, en general las soluciones deben incluir tanto tecnología sofisticada como componentes más “humanos”, como la capacitación de los empleados y la priorización en la sala de juntas.

Inteligencia Accionable Contra Amenazas

Inteligencia en Tiempo Real:

La inteligencia en tiempo real es una poderosa herramienta para prevenir y contener ataques cibernéticos. Cuanto más tiempo lleve identificar un truco, más costosas sus consecuencias. Un estudio de 2013 por el Ponemon Institute reveló que los ejecutivos de TI creen que con menos de 10 minutos de notificación previa de una violación de seguridad, es tiempo suficiente para desactivar la amenaza. Con solo 60 segundos de notificación de un compromiso, los costos resultantes podrían ser reducidos al 40%.

De acuerdo con James Hatch, director de servicios cibernéticos en BAE Systems, “Detectar [un ataque cibernético] desde el principio es la clave… Podría ser la diferencia entre perder el 10% de sus [computadoras] y el 50%”. Lamentablemente, en realidad, en promedio se necesitan empresas más de siete meses para descubrir un ataque malicioso.

Acciones Complementarias:

Las empresas pueden tomar varias medidas tácticas más pequeñas para protegerse. Éstas incluyen:

Promulgando una estrategia de defensa de varias capas. Asegúrate de que cubra toda tu empresa, todos los puntos finales, dispositivos móviles, aplicaciones y datos. Donde sea posible, utiliza el cifrado y la autenticación de dos o tres factores para el acceso a la red y a los datos.
Realizar una evaluación de proveedor de terceros o crear acuerdos de nivel de servicio con terceros:Implementa una política de “privilegios mínimos” con respecto a quién y a qué otros pueden acceder. Acostúmbrate a revisar el uso de credenciales con terceros. Incluso podrías dar un paso más con un acuerdo de nivel de servicio (SLA), que contractualmente obliga a los terceros a cumplir con las políticas de seguridad de tu empresa. Tu SLA debe otorgarle a tu empresa el derecho de auditar el cumplimiento por parte de un tercero.
Datos de Respaldo Continuos. Esto puede ayudar a salvaguardar contra el ransomware, que congela los archivos de la computadora hasta que la víctima cumpla con las demandas monetarias. Una copia de seguridad de datos puede ser algo crítico si tus computadoras o servidores se bloquean porque no tendrías que pagar por el acceso a tus datos.
Parches con Frecuencia. Un parche de software es una actualización de código en el software existente. A menudo son soluciones temporales entre lanzamientos completos de software. Un parche puede corregir un error de software, abordar una nueva vulnerabilidad de seguridad, solucionar problemas de estabilidad del software o instalar nuevos controladores.
** Aplicaciones de software de lista blanca.** La Aplicación lista blanca evitaría que las computadoras instalen software no aprobado. Esto permite a los administradores tener mucho más control.

Seguro Anti-hacker

Una tendencia emergente es el seguro anti-hacker, o ciberseguro. Su alcance varía según los proveedores, pero generalmente protege contra las brechas y pérdidas de seguridad. Las aseguradoras generalmente limitan su capacidad a entre 5 y 100 millones de dólares por cliente. A partir de octubre de 2016, sólo 29% de los negocios de Estados Unidos había comprado un ciberseguro. Sin embargo, se estima que el mercado general de ciberseguro será de 20 billones en 2025, de 3,25 billones de dólares en la actualidad. Las aseguradoras son optimistas, estimando que las primas se triplicarán en los próximos años.

Para que una organización determine cuánto seguro cibernético necesita, debería medir su riesgo cibernético. Debe comprender cómo sus activos se ven afectados por un ciberataque y cómo priorizarlos.

Programas Bug Bounty

Otra idea nueva en la industria es algo llamado programa de bonificación de errores, donde una organización paga a los de afuera (“hackers amistosos”) para notificarlo de fallas de seguridad. Empresas que van de Google y Dropbox a AT&T y LinkedIn ya han adoptado esta práctica.

No Olvides el Componente Humano

Un “problema IT” se convierte un problema de negocios estratégico. Para muchos CEO y CFO, hackear puede ser frustrante porque no entienden al enemigo. De acuerdo con Richard Anderson, presidente del Instituto de Administración de Riesgo, “Todavía hay mucha gente sentada a horcajadas sobre compañías más grandes que aún la consideran como algo que los geeks cuidan, en lugar de ser un asunto de negocios”. Sin embargo, como las estadísticas han demostrado que, esto no podría estar más alejado de la realidad.

Un Papel blanco de Deloitte sugiere crear un equipo dedicado de administración de amenazas cibernéticas y crear una “cultura consciente del riesgo cibernético”. También se recomienda que las organizaciones designen a un director de seguridad de la información (CISO). Por ejemplo, ni JPMorgan ni Target tenía CISO cuando fueron violadas en 2014 y 2013, respectivamente.

Volver a lo básico: capacitación de empleados. Las infracciones de datos a menudo son el resultado de las debilidades psicológicas de los humanos. Por lo tanto, es fundamental educar a tus empleados sobre las señales de advertencia de violaciones de seguridad, prácticas seguras (tener cuidado al abrir archivos adjuntos de correo electrónico, dónde están navegando) y cómo responder a una posible adquisición.

Últimos Pensamientos

Una refutación común a la creciente atención a los peligros de la seguridad cibernética es: “¿Entonces qué?, ¿se supone que debemos dejar de innovar por temor a los ataques?” La respuesta es, no exactamente. Sin embargo, podría ser útil para las empresas ver la ciberseguridad como una cuestión de ética. Es decir, la ciberseguridad no debería ser simplemente una cuestión de tecnología sino también de moralidad. Después de todo, ¿es ético crear y vender tecnología que deje a los consumidores vulnerables? Con Silicon Valley “una cultura de crece o muere” y, a veces, una cultura miope, es probable que esta actitud sea impopular.

Sin embargo, hay un precedente en otros sectores. Por ejemplo, la American Medical Association y American Bar Association requieren que los profesionales sigan sus respectivos códigos éticos. Los médicos deben comprometerse al Juramento hipocrático, uno de los documentos vinculantes más antiguos de la historia, que ordena que los médicos prometan proteger a sus pacientes. Del mismo modo, los abogados siguen unas Reglas Modelo de Conducta Profesional, donde juran proteger y respetar a sus clientes.

Todos haríamos bien en recordar que aunque la tecnología puede aparecer y desaparecer, lo correcto y lo incorrecto nunca cambia.

UNDERSTANDING THE BASICS

What is cybersecurity all about?

Put simply, a cybercrime is a crime with some kind of computer or cyber aspect to it. It can take shape in a variety of formats, and from individuals or groups with different motivating factors. Cyber threats are asymmetrical risks in that a few individuals can cause disproportionately large amounts of damage.

What are the different types of cybercrime?

Cybercrime includes 1) DDoS attacks, where attackers overload a network until it's non-functional; 2) phishing, which are emails asking users to enter their personal data; 3) malware, a host of cyber threats designed to damage computers; and 4) physical card skimmers, which read magnetic stripe data from a card.

Por: Melissa Lin
Artículo via: Toptal

Cómo Implementar un Diseño de Interfaz de Usuario Perfecto para iOS

2017-11-03T07:54:00.000-03:00

Probablemente hayas escuchado la frase “diseño píxel-perfecto” innumerables veces, sin siquiera considerar lo que significa, o lo que debería significar. En los últimos meses, existe la posibilidad de que hayas oído hablar del declive del concepto de diseño perfecto para píxeles, pero hay un pequeño problema con esas afirmaciones, especialmente cuando se trata del diseño de la interfaz de usuario de iOS.

A saber, la definición de diseño perfecto para píxeles no está tallada en piedra como la mayoría de las pautas de UI de iOS. Las personas lo interpretan de diferentes maneras, de ahí el problema: la perfección del píxel puede parecer inaceptable para algunos, pero otros seguirán usando el principio en los próximos años, aunque con un nombre diferente. Es sobre todo un problema de nomenclatura.

¿Qué es el diseño de UI píxel-perfecto?

Como no existe una definición clara de la perfección del píxel, mi comprensión del concepto de diseño perfecto en píxeles es que todo está hecho para maximizar la nitidez y la fidelidad. Una vez que se implementa el diseño, se ve idéntico en cualquier pantalla de iPhone sin artefactos o problemas de ningún tipo.

La creación de una interfaz de usuario de aplicación de iOS perfecta para píxeles significa que está creando un diseño con píxeles en mente e implementando exactamente el mismo diseño en la pantalla, hasta cada píxel en el diseño al que se hace referencia, al tiempo que se asegura de que se adapte de forma receptiva a otros dispositivos.

Pero, ¿Por Qué El Diseño Píxel-Perfecto?

Los Diseñadores de UI hacen todo lo posible para crear interfaces que sean fáciles de percibir e interactuar. El deber profesional del desarrollador es respetar el trabajo del diseñador e implementar la interfaz exactamente como se entregó.

Con aplicaciones que no son perfectas para píxeles, es probable que los usuarios no experimenten ningún problema importante que les impida usar y disfrutar la aplicación, pero las aplicaciones perfectas para píxel definitivamente se ven más nítidas, más limpias y más consistentes.

Debido a la naturaleza altamente competitiva de la App Store de Apple, todos los detalles que mejoran la apariencia general y la experiencia del usuario son bienvenidos. Puede ayudar a diferenciar tu aplicación y hacerla más visible, y por lo tanto más rentable.

Esta guía de diseño de UI de iOS rápida te guiará en el proceso desde la etapa de diseño básico hasta la implementación, desde la perspectiva del diseñador y del desarrollador.

Creando un Diseño de UI para iOS

Empecemos. Las aplicaciones de píxeles perfectos, obviamente, comienzan como diseños perfectos para píxeles, y todos sabemos de dónde provienen estos días.

Herramientas Esenciales de Diseño de iOS

Creo que soy acertado al decir que Sketch se ha convertido en el estándar de facto para los diseñadores de UI/UX móviles y web. Si bien Adobe XD es una alternativa prometedora, se queda atrás de Sketch en términos de popularidad.

A continuación, elegiremos el tamaño de mesa de trabajo. Hoy en día, tenemos dispositivos iOS con diferentes tamaños de pantalla y proporciones y tenemos que elegir un tamaño para crear nuestro diseño. Gracias a Auto Layout, se adaptará sin problemas a otros tamaños de pantalla. Si es necesario, puedes crear diferentes variaciones de diseño para diferentes Clases de Tamaño.

La única pregunta real aquí es: ¿Cómo debe el diseñador compartir información sobre la adaptación de diseños para diferentes pantallas con el desarrollador?

Afortunadamente, no hay necesidad de anotar las especificaciones para cada uno, ya que el Complemento de diseño automático para Sketch se encargará de eso. El diseñador simplemente necesita establecer el diseño automático deseado, exportar a diferentes tamaños de pantalla con un clic, y el desarrollador entenderá cómo colocar restricciones de diseño y asegurarse de que todo se ve bien, ya sea en un iPhone X o en el viejo iPhone 5.

Nota: Desde la versión 44, el equipo de Sketch ha mejorado drásticamente los controles de cambio de tamaño, brindando a los usuarios más poder y control sobre cómo deberían comportarse las capas cuando se cambia el tamaño de sus padres.

Configurando tu Diseño

Eso suena genial, pero todavía no hemos elegido el tamaño que usaremos para crear nuestro diseño. Según las estadísticas de iOS de David Smith, el 57% de todos los usuarios de iPhone dependen de pantallas de 4.7 pulgadas, introducidas en el iPhone 6/6s y posteriormente utilizadas en el iPhone 7 e incluso el iPhone 8 recientemente lanzado.

Estoy seguro de que ya está familiarizado con las pantallas de 4.7 pulgadas de Apple, pero en caso de que no sea una persona de números, estamos hablando de pantallas de 750x1334 píxeles con 326 píxeles por pulgada (PPI). Esta es la pantalla Retina estándar y en el código tendremos la mitad de la resolución. Por lo tanto, le sugiero que comience con 375x667 píxeles.

A continuación, debemos asegurarnos de que nuestro diseño de UI de iOS maximice la nitidez. Para alcanzar este objetivo, debes activar pixel fitting:

Aquí hay un ejemplo de un rectángulo simple con y sin ajuste de píxeles:

Usa Round: Full Pixels cuando edites objetos vectoriales:

Obviamente, estos son solo los conceptos básicos, y para ver de cerca los elementos de UI de iOS con píxeles perfectos en Sketch, debe consulta el tutorial oficial.

Siéntete libre de usar animaciones vectoriales complejas, porque un desarrollador puede jugar fácilmente usando la biblioteca Lottie. Puedes reproducir animaciones Adobe After Effects en un dispositivo móvil sin sufrir ningún artefacto de escala. Simplemente proporcione el archivo JSON al desarrollador y listo.

Usa el perfil de color sRGB tanto como sea posible. Si sRGB no es suficiente en pantallas de gama amplia, deberás proporcionar colores o elementos gráficos (uno sRGB y otro con perfil de color incrustado). La información detallada sobre los perfiles de color está disponible en las pautas de HID de Apple si lo necesitas.

Código Personalizado para Resultados Perfectos para Píxeles

¡Estupendo! Ahora sabemos lo suficiente como para crear un diseño perfecto para píxeles. ¿Cómo lo compartimos con el desarrollador? Obviamente necesitamos llegar a nuestra caja de herramientas.

Elegir las Herramientas Correctas

Hay herramientas increíblemente útiles para compartir el trabajo del diseñador con los desarrolladores: Zeplin. Simplemente utilízalo y el desarrollador tendrá casi toda la información necesaria para garantizar que tu diseño de interfaz de usuario funcione: recursos gráficos, fuentes y colores utilizados en el diseño, el texto y mucho más. Casi lo único que el diseñador puede necesitar proporcionar en este momento son los archivos de fuentes, en caso de que usen fuentes que no están incluidas en iOS.

Otra herramienta genial es PaintCode, que puede generar código a partir de imágenes vectoriales. PaintCode usa tus rutas SVG y datos de color para generar clases Swift u ObjC. Con PaintCode, puedes usar expresiones, variables, etc. para crear estados pasivos/activos de sus botones, estados arriba/abajo, texto dinámico, animación de variables y mucho más.

Obviamente tendrás que confiar en Xcode y en algunas herramientas de desarrollo de iOS estándar, pero lo veremos más adelante.

Es extremadamente útil si tienes que actualizar dinámicamente solo una parte específica de un elemento de diseño, por ejemplo, cambiar el color base de un fondo degradado en el icono de chat. Y, como una ventaja adicional, tu aplicación perderá peso.

Ok, el desarrollador finalmente tiene todo lo que necesitan, entonces, ¿cómo implementamos perfectamente el diseño de píxel perfecto (perdón por el juego de palabras)?

Configuración y Sincronización de tus Herramientas

Con Zeplin, debería obtener casi todo lo que necesitas, siempre que el diseñador lo configure todo correctamente. Si algo se pasa por alto o no está claro, Zeplin ofrece una función de comentarios efectiva, que permite al diseñador y al desarrollador identificar y resolver problemas potenciales rápidamente. Incluso si todo se hace correctamente, los comentarios se pueden utilizar para comentarios y pequeñas mejoras.

Sin embargo, como todos sabemos, las cosas no siempre salen según lo planeado, por lo que a veces el desarrollador tendrá que elegir un color, incluso si el diseñador proporcionó la paleta de colores utilizada en la aplicación.

Para hacer esto correctamente, necesitas sincronizar sus herramientas:

Establece su perfil de color de pantalla en sRGB: ve a Preferencias de sistema - Pantallas - Color y elija sRGB IEC61966-2.1.
En Digital Color Meter, o cualquier otra herramienta de selección de color, elija mostrar en sRGB.
Verifique que el perfil de color en la paleta de colores Xcode esté configurado en Device RGB.

Nota: _Las imágenes pueden tener un perfil de color incrustado. Si este es el caso, deberás adaptar sus herramientas a este perfil si deseas obtener el color correcto de esta imagen. Afortunadamente, esto debería ser una excepción, y no debería experimentar tales casos con demasiada frecuencia.

En Xcode 9, recuerde Preserve Vector Data cuando sea necesario. Si bien aumentará el tamaño de la aplicación, esto también te permitirá usar su imagen para cualquier tamaño de pantalla. Sin embargo, en iOS 10 y versiones anteriores del sistema operativo móvil de Apple, las imágenes _ no se ampliarán_ utilizando los datos vectoriales adicionales.

En cambio, las versiones anteriores del sistema operativo usarán mecanismos de escalado heredados y le dejarán con una imagen borrosa cuando se escala más allá del tamaño original. Puedes consultar la documentación oficial de Apple para obtener información adicional sobre este tema en particular.

Finalmente, el desarrollador deberá asegurarse de que los tamaños y distancias coincidan con el diseño original lo más fielmente posible. Si hay información cuestionable en Zeplin, puede medir las distancias entre los diferentes componentes de la UI de iOS con variaciones en las reglas de la pantalla. Uno de ellos es xScope, una regla en pantalla con muchas características prácticas.

Traer tu diseño de UI de iOS a la vida

Cuando se trata de implementar el diseño de UI de iOS, hay algunos enfoques para elegir: Guión gráfico, XIB y código personalizado.

Storyboard - Visualiza las pantallas y la navegación entre ellos, pero no hay opciones para heredar un diseño de un controlador en otro.
XIBs - Visualiza una pantalla o su parte, fácil de heredar. Antes de Xcode 9, no había opción de usar guías de diseño superior / inferior, mientras que en Xcode 9 podemos usar Safe Area.
Código - Por mucho, la opción más flexible, pero no proporciona visualización inmediata.

Para los guiones gráficos, deberás dividir el diseño en flujos, por ejemplo, LoginFlow.storyboard, SettingsFlow.storyboard o NewsFeedFlow.storyboard. De esa forma, mantendrás tus storyboards ligeros.

Agrupa elementos de UI en bloques. Esto simplifica el soporte para todas las restricciones. No seas perezoso y coloca vistas con nombre en orden, ya que aparecen en la pantalla de arriba hacia abajo. Ten en cuenta que la parte inferior se mostrará sobre la superior. Esto te ayudará a encontrar diferentes vistas más rápido.

Consulta el siguiente ejemplo para elementos agrupados y no agrupados:

Si tienes varios objetos alineados a la izquierda/derecha, no los alinees con el borde con desplazamiento. El mejor enfoque es alinearse con el elemento anterior o implementar una vista especial ffset con una restricción de ancho. Si necesitas cambiar el desplazamiento en algún momento en el futuro, esto lo hará algo más fácil.

Para usar colores en IB, puedes preparar una paleta en la parte inferior de Xcode Color Picker.

Nota: Si la versión mínima de iOS de su aplicación es 11, puede usar la opción “Colores nombrados” en el Catálogo de elementos.

Para terminar

Eso es. Ahora solo tenemos que enviar el resultado al equipo de control de calidad, verificar que todo esté en orden y ¡voilà! Nuestra aplicación perfecta para píxeles está lista.

El objetivo de este artículo fue proporcionar un ejemplo lineal y simple de diseño de UI de iOS perfecto para píxeles, obteniendo los mejores resultados en el menor tiempo posible. La colaboración entre los diseñadores y desarrolladores de UI no siempre es así de simple y sin fricciones, pero ese es un problema para otro artículo.

UNDERSTANDING THE BASICS

What is "pixel perfect"?

Pixel perfect means that a design maximizes sharpness and is implemented to deliver maximum fidelity in the actual product. Creating pixel-perfect apps means you are creating designs that are implemented to look identical on different devices, down to the last pixel.

How did the pixel perfect concept emerge?

Wait, this is 2017, don’t we have tools that take care of this?

Is the pixel-perfect approach suitable for all projects?

Por: Roman Stetsenko

Artículo vía: Toptal

El Futuro del Diseño UI Sin Botones

2017-10-24T23:38:00.000-03:00

¿Qué son los Botones y Realmente los Necesitamos?

Desde el inicio de las interfaces de usuario gráficas, hemos usado botones. Considera que el GUI original del Xerox PARC tiene 44 años, y aún así nuestras interfaces aún se ven bastante parecidas a eso.Recientemente trace la historia de los estilos de botones creando la líneas de tiempo de Dribbble. Aunque los botones evolucionaron en sintonía con las tendencias actuales y junto con la tecnología, su origen se inspira sin duda en objetos reales del pasado.

Esquina inferior derecha – Sears First Electric Buzzer 1897 Catálogo de Otoño

Durante más de una década, hemos estado creando dispositivos sin una interfaz física que no dependen del toque humano, pero que pueden ser activados por voz o gesto. ¿Por qué persistimos en la creación de formas con las que interactuar que se basan en los objetos familiares que nos rodean? ¡La forma de un botón digital sigue siendo modelada en las herramientas y los mecanismos que desarrollamos en el siglo XIX!

Hemos creado dispositivos electrónicos completamente nuevos, inteligentes — podemos manejarlos en casi cualquier forma que elijamos, pero por pereza o fuerza de hábito, seguimos obligando a nuestros usuarios a hacer clic en una pequeña área complicada sólo unos pocos píxeles de ancho .

Es hora de hacer algo al respecto — es hora de pensar sin botones.

UI Sin Botones – Donde Todo Interactúa

Una “utopía sin botones”, es un concepto en el que cualquier intento de aferrarse a más de 130 años de la forma en que las cosas siempre se han hecho está completamente destrozado. El futuro es ahora - debemos seguir adelante y despojarnos de las soluciones anticuadas de nuestros predecesores.

¿Es posible imaginarnos una interfaz completamente libre de botones? ¿Algo tan intuitivo, que sólo con mirarlo, sabrá cómo actuar? Ya no necesita ser sólo en nuestra imaginación — estas interfaces ya existen.

Microsoft HoloLens: HoloTour

¿Podemos, de una vez por todas, eliminar el venerado botón? Micrófonos, cámaras, pantallas táctiles, vibraciones, acelerómetros, giroscopios, GPS, realidad ampliada, realidad virtual — la lista continúa — y todo esto manejado desde tu smartphone o PC. Ya no hay ninguna razón para seguir forzando a sus usuarios a presionar ese pequeño rectángulo.

Eliminemos los Botones en las UIs

¿Has leído Type Design?— el diseñador de Toptal Michael Abehsera hace las preguntas: ¿dónde están las interfaces desprovistas de cualquier elemento gráfico? ¿Por qué lo único que importa es el contenido? Muchos de ustedes preguntaron: “¿Qué pasa con los botones?” Ya no los necesitamos, vamos a eliminarlos completamente.

Aquí hay un par de ideas interesantes:

Facebook acaba de preguntar, “¿Cuál es tu estado de ánimo?” No hay necesidad de ** presionar un botón ** para contestar — utilizar su voz — sólo decirle que se sienta bien y la cabeza para la playa. A continuación, arrastre el texto que Facebook reconoce de su respuesta a donde desea que aparezca.

Buscar por voz Neel Raj

¿Le has puesto ‘me gusta’ un artículo de Medium? Hace un tiempo en Medium podrías simplemente “recomendar” un artículo. Hoy hacemos clic en “aplausos”. Sólo “aplaudir”. ¿Qué pasa si no hay necesidad de hacer clic en este pequeño botón extraño, y sólo literalmente aplaudimos?

Concepto sin botones por Wojciech Dobry (...No lo tomes demasiado en serio.)

¿Qué pasa con algunas acciones más complejas? Tal como un pago en una tienda en línea. Arrastrar y soltar un elemento en el carrito de la compra, deslizar para proceder a la comprobación y, a continuación, confirmar con su huella digital. Pan comido.

ASOS - Animacón de añadir al carrito por Zachary Zhao

Piensa en Contenido y en Toda la Pantalla

Comencemos con las superficies que actualmente toca para realizar una acción. Dado que la gran mayoría de las interfaces gráficas de usuario modernas son pantallas de pantalla táctil — a menudo manejado con nuestros pulgares — es lógico que tales interfaces estarán con nosotros durante mucho tiempo. Y definitivamente tendremos esa necesidad irresistible de tocar — el tacto es nuestra sensación más importante después de todo. Tocar la superficie nos da una sensación de acción real, de control. ¿Cómo sería, que en vez de hacer clic en un punto en particular, le enseñáramos a nuestros usuarios a interactuar con la superficie en su totalidad?

Veamos cómo lo hace Instagram:

Navegación de una Historia de Instagram

¿Alguna vez has visto un botón que te permite navegar por una historia de Instagram y volver a la historia anterior? Probablemente no, porque todo lo que necesita hacer es tocar el borde izquierdo de la pantalla para que esto suceda.

Los usuarios han llegado a esperar nuevas formas de interactuar con nuestros productos digitales, ya menudo no implica un botón. Las tarjetas responden en todas sus superficies; haciendo clic en cualquier palabra, esperamos encontrar su definición; al tocar imágenes, esperamos alguna acción. Los usuarios ya están acostumbrados al hecho de que áreas enteras responden al tacto.

Reconocimiento de Gestos

Entendemos muy bien los gestos porque son naturales para nosotros y reflejados en nuestras acciones físicas. En la actualidad, casi todas las aplicaciones las utilizan para acelerar la navegación; podemos doblar una foto en lugar de presionarla como un botón; podemos deslizar para navegar por la galería, o pellizcar para ampliar cualquier contenido.

Virgil Pana

Interfaces de Usuario por Ramotion & Jarek Berecki

Hacemos gestos no sólo en pantallas táctiles planas — los gestos también se realizan en los espacios AR y VR, donde podemos navegar con todo nuestro cuerpo.

Gestures on HoloLens by Microsoft

Clay VR Gesture Reconocimiento en iPhone

Interfaces de Voz

Siri, Cortana, Alexa y Google Assistant están en funcionamiento. Muchos argumentan que las interfaces de voz son el futuro — es difícil no estar de acuerdo como sus usos potenciales son más allá del número. Podemos controlar vehículos, edificios inteligentes y máquinas simplemente hablando con ellos, tal como hablamos con una persona real. Con la inteligencia artificial y la máquina de aprendizaje, las máquinas son ahora capaces de entender nuestro lenguaje con más precisión. Ya no nos limitamos a pronunciar cuidadosamente “hechizos mágicos”; podemos hablar en frases completas.

Ok, Google...

Usando el habla, podemos moverse libremente en el mundo de las transferencias de dinero. Actualmente, Siri te permite transferir dinero a través de PayPal a otra persona usando sólo una solicitud rápida: “Siri, envía $ 200 a XYZ mediante PayPal”. No hay botones — la única confirmación y chequeo de seguridad requerido es Touch ID.

Acciones Físicas, Dispositivos Conectados y Reconocimiento de Vídeo

¿Sonríe para pagar? ¡Claro que sí! Alibaba y KFC lanzaron conjuntamente un sistema que le permite pagar simplemente sonriendo a la cámara — sin botones para presionar. El sistema funciona en el reconocimiento facial y ahora está disponible en China.

This is just one of the potential uses. Our devices are already equipped with a whole host of sensors, and can monitor your entire body. Nothing is preventing you from using one finger to perform any action on your smartphone.

Otro ejemplo de una acción física que acelerará la desaparición de los botones es simplemente estar cerca del dispositivo. Echemos un vistazo al iWatch, por ejemplo — sólo es necesario conectarlo con tu computadora portátil y esperar para desbloquear tu MacBook. Los dispositivos usables se pueden utilizar para confirmar nuestra identidad, así como predecir inteligentemente nuestras necesidades en función de la ubicación y los datos del sensor. Gracias a ellos, ya podemos evitar el uso de botones en muchas interfaces.

No olvidemos las tecnologías que han estado ampliamente disponibles durante varios años. Uno es el giroscopio — disponible en casi todos los teléfonos inteligentes, pero rara vez se utiliza en las interfaces. Arriba, puede ver interfaces experimentales creadas por Patryk Adaś.

El Futuro del Diseño UI

Con tantas opciones disponibles, ahora es posible olvidarse del uso de botones rectangulares típicos para que los usuarios interactúen. Con la tecnología actual, tenemos la capacidad de crear interfaces completamente nuevas que pueden:

Ahorre tiempo a los usuarios
Prevenir errores, resbalones y errores, y
Compensar cualquier acción accidental

Interfaces conceptuales por Cosmin Capitan and Ramotion

Ha llegado el momento — la tecnología nos lo está adelantando. Nosotros los diseñadores DEBEMOS perseguirlo… ¡y asegurarnos de ponernos al día!

Por: Wojciech Dobry, Poland

Artículo vía: Toptal

Flujo Máximo y el Problema de Asignación Lineal

2017-10-13T06:37:00.000-03:00

Aquí hay un problema: Tu empresa asigna a los contratistas para cumplir los contratos. Miras tus listas y decides qué contratistas están disponibles para un contrato de un mes y revisas tus contratos disponibles para ver cuáles son para tareas de un mes de duración. Dado que sabes con qué eficacia cada contratista puede cumplir cada contrato, ¿cómo asignar a los contratistas para maximizar la eficacia general para ese mes?
Este es un ejemplo del problema de asignación, y el problema se puede resolver con el clásico algoritmo húngaro.

El algoritmo húngaro (también conocido como el algoritmo de Kuhn-Munkres) es un algoritmo de tiempo polinomico, el cual maximiza la ponderación de peso en un gráfico bipartito ponderado. Aquí, los contratistas y los contratos pueden ser modelados como un gráfico bipartito, con su efectividad como el peso de los bordes entre el contratista y los nodos de contrato.
En este artículo, aprenderás sobre una implementación del algoritmo húngaro que utiliza el algoritmo Edmonds-Karp para resolver el problema de asignación lineal. También aprenderás cómo el algoritmo de Edmonds-Karp es una ligera modificación del Ford-Fulkerson y la importancia de esta modificación.

El Problema de Flujo Máximo

El problema de flujo máximo en sí mismo se puede describir informalmente como el problema de mover algo de fluido o gas, a través de una red de tuberías desde una única fuente hasta un único terminal. Esto se hace con la suposición de que la presión en la red es suficiente para asegurar que el fluido o gas no pueda permanecer en cualquier longitud de tubería o instalación de tuberías (los lugares donde se reúnen diferentes longitudes de tubería).
Al realizar ciertos cambios en el gráfico, el problema de asignación puede convertirse en un problema de flujo máximo.

Preliminares

Las ideas necesarias para resolver estos problemas surgen en muchas disciplinas matemáticas y de ingeniería, a menudo conceptos similares son conocidos por diferentes nombres y expresados de diferentes maneras (por ejemplo, matrices de adyacencia y listas de adyacencia). Dado que estas ideas son bastante esotéricas, se hacen elecciones sobre la forma en que estos conceptos se definirán generalmente para cualquier entorno determinado.
Este artículo no asumirá ningún conocimiento previo más allá de una pequeña teoría introductoria de conjuntos.
Las implementaciones en este post representan los problemas como grafos dirigidos (dígrafo).

Digrafo

Un digrafo tiene dos atributos, setOfNodes y setOfArcs. Ambos de estos atributos son conjuntos (colecciones desordenadas). En los bloques de código en este post, estoy usando Python frozenset, pero ese detalle no es particularmente importante.

DiGraph = namedtuple('DiGraph', ['setOfNodes','setOfArcs'])

(Nota: Este y todos los demás códigos de este artículo están escritos en Python 3.6.)

Nodos

Un nodo n está compuesto de dos atributos:

n.uid: Un identificador único.
Esto significa eso para cualquier de los dos nodos x y y,

x.uid != y.uid

n.datum: Esto representa cualquier objeto de datos.

Node = namedtuple('Node', ['uid','datum'])

Arco

Un arco a está compuesto de tres atributos:

a.fromNode: Éste es un nodo, como lo definimos arriba.
a.toNode: Éste es un nodo, como lo definimos arriba.
a.datum: Este representa cualquier objeto de data.

Arc = namedtuple('Arc', ['fromNode','toNode','datum'])

El set de arcos en el dígrafo representa una relación binaria en los nodos en el dígrafo. La existencia del arco a implica que existe una relación entre a.fromNode y a.toNode.
En un gráfico dirigido (en oposición a un gráfico no dirigido), la existencia de una relación entre a.fromNode y a.toNode no implican que una relación similar entre a.toNode y a.fromNode existe.
Esto se debe a que en un gráfico no dirigido, la relación que se expresa no es necesariamente simétrica.

DíGrafos

Nodos y arcos pueden usarse para definir un dígrafo, pero por conveniencia, en los algoritmos siguientes, se representará un dígrafo usando como un diccionario.
Aquí hay un método que puede convertir la representación gráfica anterior en una representación de diccionario similar a ésta:

def digraph_to_dict(G):
   G_as_dict = dict([])
   for a in G.setOfArcs:
       if(a.fromNode not in G.setOfNodes):
           err_msg = 'There is no Node {a.fromNode.uid!s} to match the Arc from {a.fromNode.uid!s} to {a.toNode.uid!s}'.format(**locals())
           pdg(G)
           raise KeyError(err_msg)
       if(a.toNode not in G.setOfNodes):
           err_msg = 'There is no Node {a.toNode.uid!s} to match the Arc from {a.fromNode.uid!s} to {a.toNode.uid!s}'.format(**locals())
           pdg(G)
           raise KeyError(err_msg)
       G_as_dict[a.fromNode] = (G_as_dict[a.fromNode].union(frozenset([a]))) if (a.fromNode in G_as_dict) else frozenset([a])
   for a in G.setOfArcs:
       if(a.fromNode not in G.setOfNodes):
           err_msg = 'There is no Node {a.fromNode.uid!s} to match the Arc from {a.fromNode.uid!s} to {a.toNode.uid!s}'.format(**locals())
           raise KeyError(err_msg)
       if a.toNode not in G_as_dict:
           G_as_dict[a.toNode] = frozenset([])
   return G_as_dict

Y aquí hay otro que lo convierte en un diccionario de diccionarios, otra operación que será útil:

def digraph_to_double_dict(G):
   G_as_dict = dict([])
   for a in G.setOfArcs:
       if(a.fromNode not in G.setOfNodes):
           err_msg = 'There is no Node {a.fromNode.uid!s} to match the Arc from {a.fromNode.uid!s} to {a.toNode.uid!s}'.format(**locals())
           raise KeyError(err_msg)
       if(a.toNode not in G.setOfNodes):
           err_msg = 'There is no Node {a.toNode.uid!s} to match the Arc from {a.fromNode.uid!s} to {a.toNode.uid!s}'.format(**locals())
           raise KeyError(err_msg)
       if(a.fromNode not in G_as_dict):
            G_as_dict[a.fromNode] = dict({a.toNode : frozenset([a])})
       else:
           if(a.toNode not in G_as_dict[a.fromNode]):
               G_as_dict[a.fromNode][a.toNode] = frozenset([a])
           else:
               G_as_dict[a.fromNode][a.toNode] = G_as_dict[a.fromNode][a.toNode].union(frozenset([a]))

   for a in G.setOfArcs:
       if(a.fromNode not in G.setOfNodes):
           err_msg = 'There is no Node {a.fromNode.uid!s} to match the Arc from {a.fromNode.uid!s} to {a.toNode.uid!s}'.format(**locals())
           raise KeyError(err_msg)
       if a.toNode not in G_as_dict:
           G_as_dict[a.toNode] = dict({})
   return G_as_dict

Cuando el artículo habla de un dígrafo como lo representa el diccionario, mencionará G_as_dict para hacerle referencia.
A veces es de ayuda tomar un nodo de un dígrafo G hasta su uid (identificador único):

def find_node_by_uid(find_uid, G):
   nodes = {n for n in G.setOfNodes if n.uid == find_uid}
   if(len(nodes) != 1):
       err_msg = 'Node with uid {find_uid!s} is not unique.'.format(**locals())
       raise KeyError(err_msg)
   return nodes.pop()

Al identificar gráficos, a veces las personas usan los términos nodo y vértice para referirse al mismo concepto; esto mismo se dice de los términos arco y borde.
Hay dos representaciones gráficas in Python, ésta la cual usa diccionarios y otra la cual usa objetos para representar gráficos. La representación en este post se encuentra entre estas dos representaciones comunes.
Esta es mi representación de un dígrafo. Hay muchas como ésta, pero ésta es la mía.

Caminos y Vías

Deja que S_Arcs sea una secuencia definitiva (colección ordenada) de arcos en un dígrafo G tanto que si a es cualquier arco en S_Arcs excepto por el último, y b sigue a a en la secuencia, entonces debe haber un nodo n = a.fromNode en G.setOfNodes como a.toNode = b.fromNode.
Comenzando desde el primer arco en S_Arcs, y continuando hasta el último arco en S_Arcs, recolecta (en el orden encontrado) todos los nodos n como los definimos arriba entre cada dos arcos consecutivos en S_Arcs. Marca la colección ordenada de nodos coleccionados durante esta operación S_{Nodes}.

def path_arcs_to_nodes(s_arcs):
   s_nodes = list([])
   arc_it = iter(s_arcs)
   step_count = 0
   last = None
   try:
       at_end = False
       last = a1 = next(arc_it)
       while (not at_end):
           s_nodes += [a1.fromNode]
           last = a2 = next(arc_it)
           step_count += 1
           if(a1.toNode != a2.fromNode):
               err_msg = "Error at index {step_count!s} of Arc sequence.".format(**locals())
               raise ValueError(err_msg)
           a1 = a2
   except StopIteration as e:
       at_end = True

   if(last is not None):
       s_nodes += [last.toNode]

   return s_nodes

Si cualquier nodo aparece más de una vez en la secuencia S_Nodes entonces llama a S_Arcs un Camino por dígrafo G.
De otro modo, llama S_Arcs una vía de list(S_Nodes)[0] a list(S_Nodes)[-1] en el dígrafo G.

Nodo Fuente

Llama al nodo s un nodo fuente en dígrafo G si s está en G.setOfNodes y G.setOfArcs no contiene arco a como a.toNode = s.

def source_nodes(G):
   to_nodes = frozenset({a.toNode for a in G.setOfArcs})
   sources = G.setOfNodes.difference(to_nodes)
   return sources

Nodo Terminal

Llama al nodo t un nodo terminal en el dígrafo G si t está en G.setOfNodes y G.setOfArcs no contiene arco a como a.fromNode = t.

def terminal_nodes(G):
   from_nodes = frozenset({a.fromNode for a in G.setOfArcs})
   terminals = G.setOfNodes.difference(from_nodes)
   return terminals

Cortes y Cortes s-t

Un corte cut de un dígrafo G conectado es un subset de arcos desde G.setOfArcs el cual parte el set de nodos G.setOfNodes en G. G está conectado si cada nodo n en G.setOfNodes tiene al menos un arco a en G.setOfArcs como n = a.fromNode o n = a.toNode, pero no a.fromNode != a.toNode.

Cut = namedtuple('Cut', ['setOfCutArcs'])

La definición de arriba se refiere al subset de arcos, pero también puede definir una partición de los nodos de G.setOfNodes.
Para las funciones predecessors_of y successors_of, n es un nodo en el set G.setOfNodes de dígrafo G, y cut es un corte de G:

def cut_predecessors_of(n, cut, G):
   allowed_arcs   = G.setOfArcs.difference(frozenset(cut.setOfCutArcs))
   predecessors   = frozenset({})
   previous_count = len(predecessors)
   reach_fringe   = frozenset({n})
   keep_going     = True
   while( keep_going ):
       reachable_from = frozenset({a.fromNode for a in allowed_arcs if (a.toNode in reach_fringe)})
       reach_fringe   = reachable_from
       predecessors   = predecessors.union(reach_fringe)
       current_count  = len(predecessors)
       keep_going     = current_count -  previous_count > 0
       previous_count = current_count
   return predecessors

def cut_successors_of(n, cut, G):
   allowed_arcs   = G.setOfArcs.difference(frozenset(cut.setOfCutArcs))
   successors     = frozenset({})
   previous_count = len(successors)
   reach_fringe   = frozenset({n})
   keep_going     = True
   while( keep_going ):
       reachable_from = frozenset({a.toNode for a in allowed_arcs if (a.fromNode in reach_fringe)})
       reach_fringe   = reachable_from
       successors     = successors.union(reach_fringe)
       current_count  = len(successors)
       keep_going     = current_count -  previous_count > 0
       previous_count = current_count
   return successors

Deja que cut sea un corte del dígrafo G.

def get_first_part(cut, G):
   firstPartFringe = frozenset({a.fromNode for a in cut.setOfCutArcs})
   firstPart = firstPartFringe
   for n in firstPart:
       preds = cut_predecessors_of(n,cut,G)
       firstPart = firstPart.union(preds)
   return firstPart

def get_second_part(cut, G):
   secondPartFringe = frozenset({a.toNode for a in cut.setOfCutArcs})
   secondPart = secondPartFringe
   for n in secondPart:
       succs= cut_successors_of(n,cut,G)
       secondPart = secondPart.union(succs)
   return secondPart

cut es un corte del dígrafo G si:

(get_first_part(cut, G).union(get_second_part(cut, G)) == G.setOfNodes) y (len(get_first_part(cut, G).intersect(get_second_part(cut, G))) == 0)

cut es llamado un corte x-y si (x in get_first_part(cut, G)) y (y in get_second_part(cut, G) ) y (x != y). Cuando el nodo x en un corte x-y cut es un nodo fuente y el nodo y en el corte x-y es un nodo terminal, luego este corte es llamado un corte s-t.

STCut = namedtuple('STCut', ['s','t','cut'])

Redes de Flujo

Puedes usar un dígrafo G para representar una red de flujo.
Asigna cada nodo n, donde n está en G.setOfNodes un n.datum que es un FlowNodeDatum:

FlowNodeDatum = namedtuple('FlowNodeDatum', ['flowIn','flowOut'])

Asigna cada arco a, donde a es un G.setOfArcs y a.datum que es un FlowArcDatum.

FlowArcDatum = namedtuple('FlowArcDatum', ['capacity','flow'])

flowNodeDatum.flowIn y flowNodeDatum.flowOut son números reales positivos.
flowArcDatum.capacity y flowArcDatum.flow también son números reales positivos.
Por cada nodo nodo n en G.setOfNodes:

n.datum.flowIn = sum({a.datum.flow for a in G.Arcs if a.toNode == n})
n.datum.flowOut = sum({a.datum.flow for a in G.Arcs if a.fromNode == n})

El Dígrafo G ahora representa a la red de flujo.
El flujo de G se refiere al flujo a.flow para todos los arcos a en G.

Flujos Factibles

Deja que el dígrafo G represente una red de flujo.
La red de flujo representada por G tiene flujos factibles si:

Por cada nodo n en G.setOfNodes excepto por nodos fuentes y nodos terminal: n.datum.flowIn = n.datum.flowOut.
Por cada arco a in G.setOfNodes: a.datum.capacity <= a.datum.flow.

La Condición 1 es llamada contención de conservación.
La Condición 2 es llamada contención de capacidad.

Capacidad de Corte

La capacidad de corte de un corte s-t stCut con un nodo fuente s y un nodo terminal t de una red de flujo representada por un dígrafo G es:

def cut_capacity(stCut, G):
   part_1 = get_first_part(stCut.cut,G)
   part_2 = get_second_part(stCut.cut,G)
   s_part = part_1 if stCut.s in part_1 else part_2
   t_part = part_1 if stCut.t in part_1 else part_2
   cut_capacity = sum({a.datum.capacity for a in stCut.cut.setOfCutArcs if ( (a.fromNode in s_part) and (a.toNode in t_part) )})
   return cut_capacity

Corte de Capacidad Mínima

Deja que stCut = stCut(s,t,cut) sea un corte s-t de una red de flujo representada por un dígrafo G.
stCut es el corte de capacidad mínima de la red de flujo representada por G si no hay otro corte s-t stCutCompetitor en esta red de flujo como:

   cut_capacity(stCut, G) < cut_capacity(stCutCompetitor, G)

Despojando los Flujos

Me gustaría referirme al dígrafo que sería el resultado de tomar un dígrafo G y borrar todos los datos de flujo de todos los nodos en G.setOfNodes y también todos los arcos en G.setOfArcs.

def strip_flows(G):
   new_nodes= frozenset( (Node(n.uid, FlowNodeDatum(0.0,0.0)) for n in G.setOfNodes) )
   new_arcs = frozenset([])
   for a in G.setOfArcs:
       new_fromNode = Node(a.fromNode.uid, FlowNodeDatum(0.0,0.0))
       new_toNode     = Node(a.toNode.uid, FlowNodeDatum(0.0,0.0))
       new_arc            = Arc(new_fromNode, new_toNode, FlowArcDatum(a.datum.capacity, 0.0))
       new_arcs          = new_arcs.union(frozenset([new_arc]))
   return DiGraph(new_nodes, new_arcs)

Problema de Flujo Máximo

Una red de flujo representada como un dígrafo G, un nodo fuente s en G.setOfNodes y un nodo terminal t en G.setOfNodes, G puede representar un problema de flujo máximo si:

(len(list(source_nodes(G))) == 1) and (next(iter(source_nodes(G))) == s) and (len(list(terminal_nodes(G))) == 1) and (next(iter(terminal_nodes(G))) == t)

Marca esta representación:

MaxFlowProblemState = namedtuple('MaxFlowProblemState', ['G','sourceNodeUid','terminalNodeUid','maxFlowProblemStateUid'])

Donde sourceNodeUid = s.uid, terminalNodeUid = t.uid, y maxFlowProblemStateUid es un identificador para la instancia del problema.

Solución de Flujo Máximo

Deja que maxFlowProblem represente un problema de flujo máximo. La solución al problema maxFlowProblem puede ser representado por una red de flujo representada como un dígrafo H.
El Dígrafo H es una solución factible para el problema de flujo máximo en la entrada python maxFlowProblem si:

strip_flows(maxFlowProblem.G) == strip_flows(H).
H es una red de flujo y tiene flujos factibles.

Si en adición a 1 y 2:

No puede haber otra red de flujo representada por el dígrafo K como strip_flows(G) == strip_flows(K) y find_node_by_uid(t.uid,G).flowIn < find_node_by_uid(t.uid,K).flowIn.

Entonces H también es una solución óptima para maxFlowProblem.
En otras palabras, una solución de flujo máximo factible puede representarse con un dígrafo, que:

Es idéntico al dígrafo G del correspondiente problema de flujo máximo con la excepción del flujo n.datum.flowIn, n.datum.flowOut y el flujo a.datum.flow de cualquiera de los nodos y arcos pueden ser diferentes.
Representa una red de flujo que tiene flujos factibles.

Y, puede representar una solución óptima de flujo máximo si adicionalmente:

El flowIn para el nodo que corresponde al nodo terminal en el problema de flujo máximo es lo más grande posible (cuando las condiciones 1 y 2 siguen estando satisfechas).

Si dígrafo H representa una solución de flujo máximo : find_node_by_uid(s.uid,H).flowOut = find_node_by_uid(t.uid,H).flowIn this follows from the flujo máximo, teorema del corte mínimo (tratado abajo). Informalmente, dado que se supone que H tiene flujos viables esto significa que el flujo no puede ser ‘creado’ (con excepción del nodo fuente s) nor ‘destruído’ (con la excepción del nodo terminal t) al cruzarse con cualquier (otro) nodo (constricciones de conservación).
Dado que un problema de flujo máximo contiene sólo un nodo fuente s y un único nodo terminal t, todo flujo ‘creado’ en s debe ser ‘destruido’ en t o la red de flujo no tiene flujos factibles (la constricción de conservación hubiese sido violada).
Deja que el dígrafo H represente una solución de flujo máximo factible; el valor anterior se llama Valor de Flujo s-t de H.
Permite:

mfps=MaxFlowProblemState(H, maxFlowProblem.sourceNodeUid, maxFlowProblem.terminalNodeUid, maxFlowProblem.maxFlowProblemStateUid)

Esto significa que mfps es un estado sucesor de maxFlowProblem, lo que significa que mfps es exactamente como maxFlowProblem con la excepción de que los valores de a.flow para los arcos a en maxFlowProblem.setOfArcs puede ser diferente de a.flow para los arcos a en mfps.setOfArcs.

def get_mfps_flow(mfps):
   flow_from_s = find_node_by_uid(mfps.sourceNodeUid,mfps.G).datum.flowOut
   flow_to_t      = find_node_by_uid(mfps.terminalNodeUid,mfps.G).datum.flowIn

   if( (flow_to_t - flow_from_s) > 0):
       raise Exception('Infeasible s-t flow')
   return flow_to_t

Esta es una visualización de un mfps junto con su maxFlowProb asociado. Cada arco a en la imagen tiene una etiqueta, estas etiquetas son a.datum.flowFrom/a.datum.flowTo, cada nodo n en la imagen tiene una etiqueta y estas etiquetas son n.uid {n.datum.flowIn / a.datum.flowOut}.

Flujo de Corte

Deja que mfps represente un estado de problema MaxFlowProblemState y deja que stCut represente un corte de mfps.G. El flujo de corte stCut está definido así:

def get_stcut_flow(stCut,mfps):
   s = find_node_by_uid(mfps.sourceNodeUid, mfps.G)
   t = find_node_by_uid(mfps.terminalNodeUid, mfps.G)
   part_1 = get_first_part(stCut.cut,mfps.G)
   part_2 = get_second_part(stCut.cut,mfps.G)
   s_part = part_1 if s in part_1 else part_2
   t_part = part_1 if t in part_1 else part_2
   s_t_sum = sum(a.datum.flow for a in mfps.G.setOfArcs if (a in stCut.cut.setOfCutArcs) and (a.fromNode in s_part) )
   t_s_sum = sum(a.datum.flow for a in mfps.G.setOfArcs if (a in stCut.cut.setOfCutArcs) and (a.fromNode in t_part) )
   cut_flow = s_t_sum - t_s_sum
   return cut_flow

corte de flujo s-t es la suma de los flujos de la partición que contiene el nodo fuente para la partición que contiene el nodo terminal menos la suma de los flujos de la partición que contiene el nodo terminal para la partición que contiene el nodo fuente.

Flujo Máximo, Corte Mínimo

Que maxFlowProblem represente un problema de flujo máximo y que la solución a maxFlowProblem sea representada por una red de flujo representada como dígrafo H.
Sea minStCut el corte de capacidad mínimo de la red de flujo representado por maxFlowProblem.G.
Debido a que en el flujo de flujo máximo el flujo se origina en un solo nodo fuente y termina en un único nodo terminal y, debido a las restricciones de capacidad y las restricciones de conservación, sabemos que todo el flujo que entra a maxFlowProblem.terminalNodeUid debe cruzar cualquier corte s-t, en particular debe cruzar minStCut. Esto significa:

get_flow_value(H, maxFlowProblem) <= cut_capacity(minStCut, maxFlowProblem.G)

Solución del Problema de Flujo Máximo

La idea básica para resolver un problema de flujo máximo maxFlowProblem es comenzar con una solución de flujo máximo representada por dígrafo H. Tal punto de partida puede ser H = strip_flows(maxFlowProblem.G).
The task is then to use H and by some greedyla modificación de los valores a.datum.flow de algunos arcos a en H.setOfArcs para producir otra solución de flujo máximo representada por dígrafo K de modo que K no puede todavía representar una red de flujo con flujos viables y get_flow_value(H, maxFlowProblem) < get_flow_value(K, maxFlowProblem). Mientras este proceso continúe, la calidad (get_flow_value(K, maxFlowProblem)) de la solución de flujo máximo (K) encontrada, recientemente, es mejor que cualquier otra solución de flujo máximo que se haya encontrado. Si el proceso llega a un punto en el que sabe que ninguna otra mejora es posible, el proceso puede terminar y devolverá la solución de flujo máximo óptimo.
La descripción anterior es general y omite muchas pruebas tales como, si tal proceso es posible o cuánto tiempo puede tomar, voy a dar algunos detalles más y el algoritmo.

El Teorema de Flujo Máximo, Corte Mínimo

Del libro Flows in Networks de Ford y Fulkerson, la declaración del Teorema de Flujo Máximo, Corte Mínimo (Theorem 5.1) es:

Para cualquier red, el valor de flujo máximo de s a t es igual a la capacidad de corte mínima de todos los cortes que separan s y t.

Utilizando las definiciones en este post, que se traduce en:
La solución a un maxFlowProblem representado por una red de flujo representada como dígrafo H es óptima si:

get_flow_value(H, maxFlowProblem) == cut_capacity(minStCut, maxFlowProblem.G)

Me gusta esta prueba del teorema y Wikipedia tiene otro.
El el teorema de flujo máximo, corte mínimo se utiliza para demostrar la corrección y la integridad del método de Ford-Fulkerson.
También daré una prueba del teorema en la sección después de vías de aumento.

El Método de Ford-Fulkerson y el Algoritmo de Edmonds-Karp

CLRS define el método Ford-Fulkerson (sección 26.2) así:

FORD-FULKERSON-METHOD(G, s, t):
initialize flow f to 0
while there exists an augmenting path p in the residual graph G_f augment flow f along

Gráfico Residual

El Gráfico Residual de una red de flujo representada como el dígrafo “G” puede representarse como un dígrafo G_f:

ResidualDatum = namedtuple('ResidualDatum', ['residualCapacity','action'])

def agg_n_to_u_cap(n,u,G_as_dict):
   arcs_out = G_as_dict[n]
   return sum([a.datum.capacity for a in arcs_out if( (a.fromNode == n) and (a.toNode == u) ) ])

def agg_n_to_u_flow(n,u,G_as_dict):
   arcs_out = G_as_dict[n]
   return sum([a.datum.flow for a in arcs_out if( (a.fromNode == n) and (a.toNode == u) ) ])

def get_residual_graph_of(G):
   G_as_dict = digraph_to_dict(G)
   residual_nodes = G.setOfNodes
   residual_arcs = frozenset([])

   for n in G_as_dict:
       arcs_from = G_as_dict[n]
       nodes_to = frozenset([find_node_by_uid(a.toNode.uid,G) for a in arcs_from])

       for u in nodes_to:
           n_to_u_cap_sum  = agg_n_to_u_cap(n,u,G_as_dict)
           n_to_u_flow_sum = agg_n_to_u_flow(n,u,G_as_dict)
           if(n_to_u_cap_sum > n_to_u_flow_sum):
               flow = round(n_to_u_cap_sum - n_to_u_flow_sum, TOL)
               residual_arcs = residual_arcs.union( frozenset([Arc(n,u,datum=ResidualDatum(flow, 'push'))]) )
           if(n_to_u_flow_sum > 0.0):
               flow = round(n_to_u_flow_sum, TOL)
               residual_arcs = residual_arcs.union( frozenset([Arc(u,n,datum=ResidualDatum(flow, 'pull'))]) )
   return DiGraph(residual_nodes, residual_arcs)

agg_n_to_u_cap(n,u,G_as_dict) regresan a la suma de a.datum.capacity para los arcos en el subset de G.setOfArcs donde el arco a está en el subset si a.fromNode = n y a.toNode = u.
agg_n_to_u_cap(n,u,G_as_dict) regresa la suma de a.datum.flow para todos los arcos en el subset de G.setOfArcs donde el arco a está en el subset si a.fromNode = n y a.toNode = u.

En resumen, el gráfico residual G_f representa ciertas acciones que se pueden realizar en el dígrafo ` G`.
Cada par de nodos n, u en G.setOfNodes de la red de flujo representada por dígrafo G puede generar 0,1 o 2 arcos en el gráfico residual G_f de ‘G`.

El par n, u no genera arcos en G_f si no hay arco a en G.setOfArcs tal como a.fromNode = n y a.toNode = u.
El par n, u genera el arco a en G_f.setOfArcs donde a representa un arco etiquetado como un flujo de impulso desde n a u a = Arco (n, u, datum = ResidualNode (n_to_u_cap_sum - n_to_u_flow_sum)) si n_to_u_cap_sum> n_to_u_flow_sum.
El par n, u genera el arco a en G_f.setOfArcs donde a representa un arco etiquetado como un pull stream arc de n a u a = Arco (n, u, datum = ResidualNode (n_to_u_cap_sum - n_to_u_flow_sum)) si n_to_u_flow_sum> 0.0.

Cada push flow arc en G_f.setOfArcs representa la acción de añadir un total de flujo x <= n_to_u_cap_sum - n_to_u_flow_sum a arcos en el subconjunto de G.setOfArcs donde el arc a está en el subconjunto si a.fromNode = n y a.toNode = u.
Cada arco de flujo de tracción en G_f.setOfArcs representa la acción de sustraer un total de flujo x <= n_to_u_flow_sum a arcos en el subconjunto de G.setOfArcs donde arco a está en el subconjunto si a.fromNode = n y a.toNode = u.

Realizar una acción individual como empuja o hala desde G_f en los arcos aplicables en G podría generar una red de flujo sin flujos factibles porque las constricciones de capacidad o constricciones de conservación podrían ser violado en la red de flujo generada.
He aquí una visualización del gráfico residual del ejemplo anterior de visualización de una solución de flujo máximo, en la visualización cada arco a representa a.residualCapacity.

Vía en Aumento

Deja que maxFlowProblem sea un problema de flujo máximo, y deja que G_f = get_residual_graph_of (G) sea el gráfico residual de maxFlowProblem.G.
Una vía en aumento augmentingPath para maxFlowProblem es cualquier vía desde find_node_by_uid(maxFlowProblem.sourceNode,G_f) a find_node_by_uid(maxFlowProblem.terminalNode,G_f).
Resulta que una ruta de aumento augmentingPath se puede aplicar a una solución de flujo máximo representada por el dígrafo H generando otra solución de flujo máximo representada por el dígrafo K donde get_flow_value (H, maxFlowProblem) <valor de get_flow (K, maxFlowProblem) si H no es óptimo.
Aquí ves como:

def augment(augmentingPath, H):
   augmentingPath = list(augmentingPath)
   H_as_dict = digraph_to_dict(H)
   new_nodes = frozenset({})
   new_arcs = frozenset({})
   visited_nodes  = frozenset({})
   visited_arcs = frozenset({})

   bottleneck_residualCapacity = min( augmentingPath, key=lambda a: a.datum.residualCapacity ).datum.residualCapacity
   for x in augmentingPath:
       from_node_uid = x.fromNode.uid if x.datum.action == 'push' else x.toNode.uid
       to_node_uid = x.toNode.uid   if x.datum.action == 'push' else x.fromNode.uid
       from_node = find_node_by_uid( from_node_uid, H )
       to_node = find_node_by_uid( to_node_uid, H )
       load = bottleneck_residualCapacity if x.datum.action == 'push' else -bottleneck_residualCapacity

       for a in H_as_dict[from_node]:
           if(a.toNode == to_node):
               test_sum = a.datum.flow + load
               new_flow = a.datum.flow
               new_from_node_flow_out = a.fromNode.datum.flowOut
               new_to_node_flow_in = a.toNode.datum.flowIn

               new_from_look = {n for n in new_nodes if (n.uid == a.fromNode.uid)}
               new_to_look = {n for n in new_nodes if (n.uid == a.toNode.uid)  }
               prev_from_node = new_from_look.pop() if (len(new_from_look)>0) else a.fromNode
               prev_to_node = new_to_look.pop()   if (len(new_to_look)>0)   else a.toNode
               new_nodes = new_nodes.difference(frozenset({prev_from_node}))
               new_nodes = new_nodes.difference(frozenset({prev_to_node}))

               if(test_sum > a.datum.capacity):
                   new_flow = a.datum.capacity
                   new_from_node_flow_out = prev_from_node.datum.flowOut - a.datum.flow + a.datum.capacity
                   new_to_node_flow_in    = prev_to_node.datum.flowIn - a.datum.flow + a.datum.capacity
                   load = test_sum - a.datum.capacity
               elif(test_sum < 0.0):
                   new_flow = 0.0
                   new_from_node_flow_out = prev_from_node.datum.flowOut - a.datum.flow
                   new_to_node_flow_in    = prev_to_node.datum.flowIn - a.datum.flow
                   load = test_sum
                else:
                   new_flow = test_sum
                   new_from_node_flow_out = prev_from_node.datum.flowOut - a.datum.flow + new_flow
                   new_to_node_flow_in    = prev_to_node.datum.flowIn - a.datum.flow + new_flow
                   load = 0.0

               new_from_node_flow_out = round(new_from_node_flow_out, TOL)
               new_to_node_flow_in    = round(new_to_node_flow_in, TOL)
               new_flow               = round(new_flow, TOL)

               new_from_node = Node(prev_from_node.uid, FlowNodeDatum(prev_from_node.datum.flowIn, new_from_node_flow_out))
               new_to_node   = Node(prev_to_node.uid, FlowNodeDatum(new_to_node_flow_in, prev_to_node.datum.flowOut))
               new_arc       = Arc(new_from_node, new_to_node, FlowArcDatum(a.datum.capacity, new_flow))

               visited_nodes = visited_nodes.union(frozenset({a.fromNode,a.toNode}))
               visited_arcs  = visited_arcs.union(frozenset({a}))
               new_nodes     = new_nodes.union(frozenset({new_from_node, new_to_node}))
               new_arcs      = new_arcs.union(frozenset({new_arc}))

   not_visited_nodes = H.setOfNodes.difference(visited_nodes)
   not_visited_arcs  = H.setOfArcs.difference(visited_arcs)

   full_new_nodes = new_nodes.union(not_visited_nodes)
   full_new_arcs  = new_arcs.union(not_visited_arcs)
   G = DiGraph(full_new_nodes, full_new_arcs)

   full_new_arcs_update = frozenset([])
   for a in full_new_arcs:
       new_from_node = a.fromNode
       new_to_node   = a.toNode
       new_from_node = find_node_by_uid( a.fromNode.uid, G )
       new_to_node   = find_node_by_uid( a.toNode.uid, G )
       full_new_arcs_update = full_new_arcs_update.union( {Arc(new_from_node, new_to_node, FlowArcDatum(a.datum.capacity, a.datum.flow))} )

   G = DiGraph(full_new_nodes, full_new_arcs_update)

   return G

En lo anterior, TOL es un valor de tolerancia para redondear los valores de flujo en la red. Esto es para evitar la cascada de imprecisión de los cálculos de punto flotante. Así, por ejemplo, usé ‘TOL = 10` para redondear a 10 dígitos significativos.
Deja K = augment (augmentingPath, H), entonces K representa una solución de flujo máximo factible para maxFlowProblem. Para que la afirmación sea verdadera, la red de flujo representada por K debe tener flujos factibles (no violar la restricción de capacidad o la restricción de conservación. Aquí está el por qué: En el método anterior, cada nodo añadido a la nueva red de flujo representado por dígrafo K es una copia exacta de un nodo de dígrafo H o un nodo n que ha tenido el mismo número añadido a su n.datum.flowIn como su n.datum.flowOut. Esto significa que la restricción de conservación se cumple en “K” siempre que se cumpla en “H”. La restricción de conservación se satisface porque comprobamos explícitamente que cualquier arco nuevo a en la red tiene a.datum.flow <= a.datum.capacity; por lo tanto, siempre y cuando los arcos del conjunto H.setOfArcs que fueron copiados sin modificar en K.setOfArcs no violen la restricción de capacidad, entonces K no viola la restricción de capacidad.
También es cierto que get_flow_value (H, maxFlowProblem) <get_flow_value (K, maxFlowProblem) si H no es óptimo.
Aquí está el porqué: Para un aumento de ruta augmentingPath existe en el dígrafo la representación del gráfico residual G_f de un problema de flujo máximo maxFlowProblem entonces el último arco a en augmentingPath debe ser un arco ‘push’ y debe tener a.toNode == maxFlowProblem.terminalNode. Una ruta de aumento se define como una que termina en el nodo terminal del problema de flujo máximo para el cual es una ruta de aumento. De la definición del gráfico residual, está claro que el último arco en una vía de aumento en ese gráfico residual debe ser un arco “push” porque cualquier arco “pull” b en la vía de aumento tendrá b.toNode == maxFlowProblem.terminalNode y b.fromNode! = maxFlowProblem.terminalNode desde la definición de vía. Además, a partir de la definición de vía, está claro que el nodo terminal sólo se modifica una vez con el método augment. Así augment modifica maxFlowProblem.terminalNode.flowIn exactamente una vez y aumenta el valor de maxFlowProblem.terminalNode.flowIn porque el último arco en augmentingPath debe ser el arco que causa la modificación en maxFlowProblem.terminalNode.flowIn durante augment. Desde la definición de augment, ya que se aplica a arcos ‘push’, el maxFlowProblem.terminalNode.flowIn sólo se puede aumentar, no disminuir.

Algunas Pruebas de Sedgewick y Wayne

El libro Algorithms, cuarta edición de Robert Sedgewich y Kevin Wayne tiene algunas pruebas maravillosas y cortas (páginas 892-894) que serán útiles. Los recrearé aquí, aunque utilizaré el lenguaje que se ajuste a las definiciones anteriores. Mis etiquetas para las pruebas son las mismas que en el libro de Sedgewick.
Propuesta E: Para cualquier dígrafo H que representa una solución de flujo máximo factible a un problema de flujo máximo maxFlowProblem, para cualquier stCut get_stcut_flow(stCut,H,maxFlowProblem) = get_flow_value(H, maxFlowProblem).
Prueba: Deja

stCut=stCut(maxFlowProblem.sourceNode,maxFlowProblem.terminalNode,set([a for a in H.setOfArcs if a.toNode == maxFlowProblem.terminalNode]))

. Proposición E se mantiene por stCut directamente desde la definición de valor de flujo s-t. Supongamos que allí deseamos mover un nodo n desde la partición s (get_first_part(stCut.cut, G)) y en la partición (get_second_part(stCut.cut, G)), para hacer esto necesitamos cambiar stCut.cut, lo cual podría cambiar stcut_flow = get_stcut_flow(stCut,H,maxFlowProblem) e invalidar proposition E. Sin embargo, veamos cómo el valor de stcut_flow cambiará a medida que hagamos este cambio. El nodo n está en equilibrio, lo que significa que la suma de flujo en nodo n es igual a la suma de flujo de ésta (esto es necesario para que H represente una solución factible).
Nota que todo el flujo que es parte de stcut_flow entrando en node n entra en él desde la partición s (el flujo entrando a node n desde la partición t que lo hace directa o indirectamentefrom no habría sido contado en el valor stcut_flow porque está yendo en la dirección errónea basándonos en la definición). Observa que todo el flujo que es parte del stcut_flow que entra al nodo n lo introduce desde la partición s (el flujo que entra al nodo n desde la partición t directa o indirectamente no se han contado en el valor stcut_flow porque está dirigiendo la dirección incorrecta basada en la definición).
Además, todo el flujo que sale n eventualmente fluirá (directa o indirectamente) hacia el nodo terminal (demostrado anteriormente). Cuando movemos el nodo n en la partición t, todo el flujo que entra n desde la partición s debe ser añadido al nuevo valor stcut_flow; sin embargo, todo el flujo que sale n debe ser restado del nuevo valor stcut_flow; la parte del flujo que se dirige directamente a la partición t se resta, ya que este flujo es ahora interno a la nueva partición t y no se cuenta como stcut_flow.
La parte del flujo desde la posición n en nodos de la partición s también debe ser restada de stcut_flow: Después de que n se mueva hacia la partición t, estos flujos serán dirigidos desde la posición partición t y en la partición s y por lo tanto no se debe tener en cuenta en el stcut_flow, ya que estos flujos eliminan la entrada en la partición s y debe ser reducido por la suma de estos flujos, y el flujo de salida de la partición s en la partición-t (donde todos los flujos de st deben terminar) debe ser reducido en la misma cantidad. Como el nodo n estaba en equilibrio antes del proceso, la actualización habrá agregado el mismo valor al nuevo valor stcut_flow al restarse, dejando la proposición E clara después de la actualización. La validez de la proposición E luego se sigue en la inducción sobre el tamaño de la partición t.
Aquí hay algunos ejemplos de redes de flujo para ayudar a visualizar los casos menos obvios donde la propuesta E se mantiene; en la imagen, las áreas rojas indican la partición s, las áreas azules representan la partición t, y los arcos verdes indican un corte s-t **. En la segunda imagen, el flujo entre **nodo A y nodo B aumenta mientras que el flujo en nodo terminal t no cambia.

Corolario: Ningún valor de flujo de corte s-t puede exceder la capacidad de corte s-t.
Proposición F. (teorema de flujo máximo y corte mínimo): Deja que f sea un flujo s-t. Las siguientes 3 condiciones son equivalentes:

Existe un corte s-t cuya capacidad es igual al valor del flujo f.
f es un flujo máximo.
No hay vía de aumento con respecto a f.

La condición 1 implica la condición 2 por el corolario. La condición 2 implica la condición 3 porque la existencia de una trayectoria aumentadora implica la existencia de un flujo con valores mayores, contradiciendo la máxima de “f”. La condición 3 implica la condición 1: Sea C_s el conjunto de todos los nodos que se pueden alcanzar desde s con un aumento de ruta en el gráfico residual. Sea C_t los arcos restantes, entonces t debe estar en C_t (según nuestra suposición). Los arcos que cruzan de C_s a C_t forman entonces un corte s-t que contiene solamente arcos a donde a.datum.capacity = a.datum.flow o a.datum.flow = 0.0. De no ser así, los nodos conectados por un arco con la capacidad residual restante a C_s estarían en el conjunto C_s ya que entonces habría un aumento de vía desde s a un nodo. El caudal a través del corte de s-t es igual a la capacidad de corte de s-t (ya que los arcos de C_s a C_t tienen caudal igual a la capacidad) y también al valor de la flujo s-t (por proposición E).
Esta afirmación del teorema de flujo máximo, min corte implica la declaración anterior de Flows in Networks.
Corolario (propiedad de integralidad): Cuando las capacidades son enteras, existe un flujo máximo de valor entero, y el algoritmo Ford-Fulkerson lo encuentra.
Prueba: Cada vía de aumento incrementa el flujo por un entero positivo, el mínimo de las capacidades no utilizadas en los arcos de empuje y los flujos en los arcos de tracción, todos los cuales son siempre enteros positivos.
Esto justifica la descripción del método Ford-Fulkerson de CLRS. El método consiste en seguir encontrando incrementando rutas y aplicando augment a la última maxFlowSolution encontrando mejores soluciones, hasta no más incrementando ruta, lo que significa que la última solución de flujo máximo es óptimo.

De Ford-Fulkerson a Edmonds-Karp

Las preguntas restantes con respecto a la resolución de problemas de flujo máximo son:

¿Cómo deben construirse caminos de aumento?
¿Terminará el método si usamos números reales y no números enteros?
¿Cuánto tiempo tomará terminar (si lo hace)?

El algoritmo Edmonds-Karp especifica que cada ruta de aumento se construye mediante una búsqueda de amplitud (BFS) del gráfico residual; resulta que esta decisión del punto 1 también obligará al algoritmo a terminar (punto 2) y permite que el tiempo asintótico y la complejidad del espacio a ser determinados.
Primero, aquí hay una implementación BFS:

def bfs(sourceNode, terminalNode, G_f):
   G_f_as_dict = digraph_to_dict(G_f)
   parent_arcs = dict([])
   visited = frozenset([])
   deq = deque([sourceNode])
   while len(deq) > 0:
       curr = deq.popleft()
       if curr == terminalNode:
           break
       for a in G_f_as_dict.get(curr):
           if (a.toNode not in visited):
               visited = visited.union(frozenset([a.toNode]))
               parent_arcs[a.toNode] = a
               deq.extend([a.toNode])
   path = list([])
   curr = terminalNode
   while(curr != sourceNode):
       if (curr not in parent_arcs):
           err_msg = 'No augmenting path from {} to {}.'.format(sourceNode.uid, terminalNode.uid)
           raise StopIteration(err_msg)
       path.extend([parent_arcs[curr]])
       curr = parent_arcs[curr].fromNode
   path.reverse()

   test = deque([path[0].fromNode])
   for a in path:
       if(test[-1] != a.fromNode):
           err_msg = 'Bad path: {}'.format(path)
           raise ValueError(err_msg)
       test.extend([a.toNode])

   return path

Utilicé un deque del módulo de colecciones de python.
Para responder a la pregunta 2, voy a parafrasear otra prueba de Sedgewick y Wayne: Proposición G. El número de caminos de incremento necesarios en el algoritmo Edmonds-Karp con nodos N y arcos es como máximo NA/2. Prueba: Cada ruta de aumento tiene un arco de cuello arco - un arco que se suprime del gráfico residual porque corresponde bien a un arco de empuje que se llena a capacidad o un arco de tracción a través del cual el flujo se convierte en 0. Cada vez que un arco se convierte en un cuello de botella arco, la longitud de cualquier trayecto de aumento a través de él debe aumentar en un factor de 2. Esto es porque cada nodo en una ruta puede aparecer sólo una vez o no en absoluto (de la definición de ruta) ya que las rutas se están explorando desde la más corta ruta a lo más largo que significa que por lo menos un nodo más debe ser visitado por la siguiente ruta que atraviesa el cuello de botella nodo que significa un adicional de 2 arcos en el camino antes de llegar en el nodo. Puesto que el trayecto de incremento es de longitud como máximo N, cada arco puede tener como máximo N/2, trayectos de incremento, y el número total de trayectos de incremento es como máximo NA/2.

El algoritmo Edmonds-Karp se ejecuta en O(NA^2). Si a lo sumo los caminos NA/2 serán explorados durante el algoritmo y explorar cada trayectoria con BFS es N+A entonces el término más significativo del producto y por lo tanto el complejidad asintótica O(NA^2).
Deja que mfp sea un maxFlowProblemState.

def edmonds_karp(mfp):
   sid, tid = mfp.sourceNodeUid, mfp.terminalNodeUid
   no_more_paths = False
   loop_count = 0
   while(not no_more_paths):
      residual_digraph = get_residual_graph_of(mfp.G)
      try:
          asource = find_node_by_uid(mfp.sourceNodeUid, residual_digraph)
          aterm   = find_node_by_uid(mfp.terminalNodeUid, residual_digraph)
          apath   = bfs(asource, aterm, residual_digraph)
          paint_mfp_path(mfp, loop_count, apath)
          G = augment(apath, mfp.G)
          s = find_node_by_uid(sid, G)
          t = find_node_by_uid(tid, G)
          mfp = MaxFlowProblemState(G, s.uid, t.uid, mfp.maxFlowProblemStateUid)
          loop_count += 1
      except StopIteration as e:
          no_more_paths = True
   return mfp

La versión anterior es ineficiente y tiene peor complejidad que O(NA^2) ya que construye una nueva solución de flujo máximo y una nueva gráfica residual cada vez (en vez de modificar los dígrafos existentes a medida que avanza el algoritmo). Para llegar a una solución O(NA^2) verdadera el algoritmo debe mantener tanto el digrafo que representa el estado de problema de flujo máximo y su asociado ** gráfico residual. Por tanto, el algoritmo debe evitar repetir innecesariamente **arcos y nodos y actualizar sus valores y valores asociados en el gráfico residual sólo cuando sea necesario.
Para escribir un algoritmo Edmonds Karp más rápido, reescribí varios fragmentos de código de lo anterior. Espero que pasar por el código que generó un nuevo digrafo fue útil en la comprensión de lo que está pasando. En el algoritmo rápido, uso algunos trucos nuevos y estructuras de datos de Python que no quiero detallar. Voy a decir que a.fromNode y a.toNode ahora son tratados como cadenas y uids a nodos. Para este código, deje que mfps sea un maxFlowProblemState

import uuid

def fast_get_mfps_flow(mfps):
   flow_from_s = {n for n in mfps.G.setOfNodes if n.uid == mfps.sourceNodeUid}.pop().datum.flowOut
   flow_to_t   = {n for n in mfps.G.setOfNodes if n.uid == mfps.terminalNodeUid}.pop().datum.flowIn

   if( (flow_to_t - flow_from_s) > 0.00):
       raise Exception('Infeasible s-t flow')
   return flow_to_t

def fast_e_k_preprocess(G):
   G = strip_flows(G)
   get = dict({})
   get['nodes'] = dict({})
   get['node_to_node_capacity'] = dict({})
   get['node_to_node_flow'] = dict({})
   get['arcs'] = dict({})
   get['residual_arcs'] = dict({})

   for a in G.setOfArcs:
       if(a.fromNode not in G.setOfNodes):
           err_msg = 'There is no Node {a.fromNode.uid!s} to match the Arc from {a.fromNode.uid!s} to {a.toNode.uid!s}'.format(**locals())
           raise KeyError(err_msg)
       if(a.toNode not in G.setOfNodes):
           err_msg = 'There is no Node {a.toNode.uid!s} to match the Arc from {a.fromNode.uid!s} to {a.toNode.uid!s}'.format(**locals())
           raise KeyError(err_msg)
       get['nodes'][a.fromNode.uid] = a.fromNode
       get['nodes'][a.toNode.uid]   = a.toNode
       lark = Arc(a.fromNode.uid, a.toNode.uid, FlowArcDatumWithUid(a.datum.capacity, a.datum.flow, uuid.uuid4()))
       if(a.fromNode.uid not in get['arcs']):
           get['arcs'][a.fromNode.uid] = dict({a.toNode.uid : dict({lark.datum.uid : lark})})
       else:
           if(a.toNode.uid not in get['arcs'][a.fromNode.uid]):
               get['arcs'][a.fromNode.uid][a.toNode.uid] = dict({lark.datum.uid : lark})
           else:
               get['arcs'][a.fromNode.uid][a.toNode.uid][lark.datum.uid] = lark

   for a in G.setOfArcs:
       if a.toNode.uid not in get['arcs']:
           get['arcs'][a.toNode.uid] = dict({})

   for n in get['nodes']:
       get['residual_arcs'][n] = dict()
       get['node_to_node_capacity'][n] = dict()
       get['node_to_node_flow'][n] = dict()
       for u in get['nodes']:
           n_to_u_cap_sum  = sum(a.datum.capacity for a in G.setOfArcs if (a.fromNode.uid == n) and (a.toNode.uid == u) )
           n_to_u_flow_sum = sum(a.datum.flow     for a in G.setOfArcs if (a.fromNode.uid == n) and (a.toNode.uid == u) )

           if(n_to_u_cap_sum > n_to_u_flow_sum):
               flow = round(n_to_u_cap_sum - n_to_u_flow_sum, TOL)
               get['residual_arcs'][n][u] = Arc(n,u,ResidualDatum(flow, 'push'))
           if(n_to_u_flow_sum > 0.0):
               flow = round(n_to_u_flow_sum, TOL)
               get['residual_arcs'][u][n] = Arc(u,n,ResidualDatum(flow, 'pull'))

           get['node_to_node_capacity'][n][u] = n_to_u_cap_sum
           get['node_to_node_flow'][n][u]     = n_to_u_flow_sum

   return get

def fast_bfs(sid, tid, get):
   parent_of   = dict([])
   visited     = frozenset([])
   deq         = coll.deque([sid])
   while len(deq) > 0:
       n = deq.popleft()
       if n == tid:
           break
       for u in get['residual_arcs'][n]:
           if (u not in visited):
               visited = visited.union(frozenset({u}))
               parent_of[u] = get['residual_arcs'][n][u]
               deq.extend([u])
   path = list([])
   curr = tid
   while(curr != sid):
       if (curr not in parent_of):
           err_msg = 'No augmenting path from {} to {}.'.format(sid, curr)
           raise StopIteration(err_msg)
       path.extend([parent_of[curr]])
       curr = parent_of[curr].fromNode
   path.reverse()
   return path

def fast_edmonds_karp(mfps):
   sid, tid = mfps.sourceNodeUid, mfps.terminalNodeUid
   get = fast_e_k_preprocess(mfps.G)
   no_more_paths, loop_count = False, 0
   while(not no_more_paths):
      try:
          apath   = fast_bfs(sid, tid, get)
          get = fast_augment(apath, get)
          loop_count += 1
      except StopIteration as e:
          no_more_paths = True
   nodes = frozenset(get['nodes'].values())
   arcs = frozenset({})
   for from_node in get['arcs']:
       for to_node in get['arcs'][from_node]:
           for arc in get['arcs'][from_node][to_node]:
               arcs |= frozenset({get['arcs'][from_node][to_node][arc]})

   G = DiGraph(nodes, arcs)
   mfps = MaxFlowProblemState(G, sourceNodeUid=sid, terminalNodeUid=tid, maxFlowProblemStateUid=mfps.maxFlowProblemStateUid)
   return mfps

He aquí una visualización de cómo este algoritmo resuelve el ejemplo red de flujo desde arriba. La visualización muestra los pasos que se reflejan en el digrafo G que representa la red de flujo más actualizada y como se reflejan en el gráfico residual de esa red de flujo . Los caminos de aumento en el gráfico residual se muestran como rutas rojas, y el digrafo que representa el problema el conjunto de nodos y arcos afectados por un dado la ruta de aumento se resalta en verde. En cada caso, resaltaré las partes del gráfico que se cambiarán (en rojo o verde) y luego mostraré el gráfico después de los cambios (sólo en negro).

Aquí hay otra visualización de cómo este algoritmo resolviendo un ejemplo diferente red de flujo. Observe que éste usa números reales y contiene varios arcos con los mismos valores fromNode y toNode.
Observa también que debido a que los Arcos con un ‘pull’ ResidualDatum pueden ser parte de la Vía en Aumento, los nodos afectados en el DíGrafo de la Red de Flujo_no pueden estar en un camino en G!.

Gráficos Bipartitos

Supongamos que tenemos un digrafo G, G es bipartito si es posible particionar los nodos en G.setOfNodes en dos conjuntos (part_1 and part_2) tal que para cualquier arco a en G.setOfArcs no puede ser verdad que a.fromNode en part_1 y a.toNode en part_1. Tampoco puede ser verdad que a.fromNode en part_2 y a.toNode en part_2.
En otras palabras, G es bi-partición si puede dividirse en dos conjuntos de nodos de tal manera que cada arco debe conectar un nodo en un conjunto a un nodo en el otro conjunto.

Pruebas Bipartitas

Supongamos que tenemos un digrafo G, queremos probar si es bi-partición. Podemos hacer esto en O(|G.setOfNodes|+|G.setOfArcs|) por codicioso color de la gráfica en dos colores.
Primero, necesitamos generar un nuevo digrafo H. Este gráfico tendrá tendrá el mismo conjunto de nodos como G, pero tendrá más arcos que G. Cada arco a en G creará 2 arcos en H; el primer arco será idéntico a a, y el segundo arco invierte al director de a ( b = Arc(a.toNode,a.fromNode,a.datum)).

Bipartition = coll.namedtuple('Bipartition',['firstPart', 'secondPart', 'G'])
def bipartition(G):
   nodes = frozenset(G.setOfNodes
   arcs  = frozenset(G.setOfArcs)
   arcs = arcs.union( frozenset( {Arc(a.toNode,a.fromNode,a.datum) for a in G.setOfArcs} ) )
   H = DiGraph(nodes, arcs)
   H_as_dict = digraph_to_dict(H)
   color = dict([])
   some_node = next(iter(H.setOfNodes))
   deq = coll.deque([some_node])
   color[some_node] = -1
   while len(deq) > 0:
       curr = deq.popleft()
       for a in H_as_dict.get(curr):
           if (a.toNode not in color):
               color[a.toNode] = -1*color[curr]
               deq.extend([a.toNode])
           elif(color[curr] == color[a.toNode]):
               print(curr,a.toNode)
               raise Exception('Not Bipartite.')

   firstPart  = frozenset( {n for n in color if color[n] == -1 } )
   secondPart = frozenset( {n for n in color if color[n] == 1 } )

   if( firstPart.union(secondPart) != G.setOfNodes ):
       raise Exception('Not Bipartite.')

   return Bipartition(firstPart, secondPart, G)

Coincidencias y Coincidencias Máximas

Supongamos que tenemos un digrafo G y matching es un subconjunto de arcos de G.setOfArcs. matching es un matching si para dos digrafo a y b en matching: len(frozenset( {a.fromNode} ).union( {a.toNode} ).union( {b.fromNode} ).union( {b.toNode} )) == 4. En otras palabras, ningún arco en una coincidencia comparte un nodo.
La coincidencia matching, es una coincidencia máxima si no hay ninguna otra concordancia alt_matching en G tanto que len(matching) < len(alt_matching). En otras palabras, matching es una coincidencia máxima Si es el set más largo de arcos en G.setOfArcs que todavía satisface la definición de combinación (la adición de cualquier arco que no esté ya en la coincidencia romperá la combinación definición).
Una combinación máxima matching es una combinación perfecta si para cada nodo n en G.setOfArcs existe un arco a en matching donde a.fromNode == n or a.toNode == n.

Combinación Bi-Particionada Máxima

Una combinación bi-particionada máxima es una combinación máxima en un digrafo G que es bi-particionado.
Dado que G es bi-particionado, el problema de encontrar una combinación máxima bipartita se puede transformar en un problema de flujo máximo solucionable con el algoritmo de Edmonds-Karp y entonces el acoplamiento bipartito máximo puede ser recuperado del solución al problema de flujo máximo.
Deja que bipartition sea una bi-partición de G.
Para ello, necesito generar un nuevo digrafo (H) con algunos nuevos nodos (H.setOfNodes) y algunos arcos nuevos (H.setOfArcs). H.setOfNodes contiene todos los nodos en G.setOfNodes y dos nodos más, s (un nodo fuente) y t (un nodo terminal).
H.setOfArcs contendrá un arco por cada G.setOfArcs. Si un arco a es un G.setOfArcs y a.fromNode está en bipartition.firstPart y a.toNode está en bipartition.secondPart y luego incluye a en H (agregando un FlowArcDatum(1,0)).
Si a.fromNode es una bipartition.secondPart y a.toNode es una bipartition.firstPart, luego incluye Arc(a.toNode,a.fromNode,FlowArcDatum(1,0)) en H.setOfArcs.
La definición de un gráfico bi-particionado asegura que ningún arco conecte cualquier nodo donde ambos nodos están en la misma partición. H.setOfArcs también contiene un arco de nodo s a cada nodo en bipartition.firstPart. Por último, H.setOfArcs contiene un arco cada node en bipartition.secondPart un nodo t. a.datum.capacity = 1 por todas las a en H.setOfArcs.
Primera partición de los nodos en G.setOfNodes los dos sets (part1 and part2) separados tanto que ningún arco en G.setOfArcs se dirige desde un conjunto al mismo conjunto (esta partición es posible porque G está bi-particionado). A continuación, agregue todos los arcos en G.setOfArcs los cuales están dirigidos de la part1 a la part2 hacia H.setOfArcs. A continuación, cree un único nodo fuente s y un único nodo terminal t y cree más arcos
Luego, construye un maxFlowProblemState.

def solve_mbm( bipartition ):
   s = Node(uuid.uuid4(), FlowNodeDatum(0,0))
   t = Node(uuid.uuid4(), FlowNodeDatum(0,0))

   translate = {}
   arcs = frozenset([])
   for a in bipartition.G.setOfArcs:
       if ( (a.fromNode in bipartition.firstPart) and (a.toNode in bipartition.secondPart) ):
           fark = Arc(a.fromNode,a.toNode,FlowArcDatum(1,0))
           arcs = arcs.union({fark})
           translate[frozenset({a.fromNode.uid,a.toNode.uid})] = a
       elif ( (a.toNode in bipartition.firstPart) and (a.fromNode in bipartition.secondPart) ):
           bark = Arc(a.toNode,a.fromNode,FlowArcDatum(1,0))
           arcs = arcs.union({bark})
           translate[frozenset({a.fromNode.uid,a.toNode.uid})] = a
   arcs1 = frozenset( {Arc(s,n,FlowArcDatum(1,0)) for n in bipartition.firstPart } )
   arcs2 = frozenset( {Arc(n,t,FlowArcDatum(1,0)) for n in bipartition.secondPart } )
   arcs = arcs.union(arcs1.union(arcs2))

   nodes = frozenset( {Node(n.uid,FlowNodeDatum(0,0)) for n in bipartition.G.setOfNodes} ).union({s}).union({t})
   G = DiGraph(nodes, arcs)
   mfp = MaxFlowProblemState(G, s.uid, t.uid, 'bipartite')
   result = edmonds_karp(mfp)

   lookup_set = {a for a in result.G.setOfArcs if (a.datum.flow > 0) and (a.fromNode.uid != s.uid) and (a.toNode.uid != t.uid)}
   matching = {translate[frozenset({a.fromNode.uid,a.toNode.uid})] for a in lookup_set}

   return matching

Cubierta Mínima de Nodo

Una cubierta de nodo en un dígrafo G es un conjunto de nodos (cover) proveniente de G.setOfNodes tanto que para cualquier arco a de G.setOfArcs esto debe ser verdad: (a.fromNode en cubierta) o (a.toNode en cubierta).
Una cubierta de nodo mínima es el set más pequeño de nodos en la grífica que sigue siendo una cubierta de nodo. El teorema de König indica que en un gráfico bi-particionado, el tamaño de la coincidencia máxima en ese gráfico es igual al tamaño de la cubierta de nodo mínima, y sugiere cómo la cubierta del nodo puede recuperarse de una coincidencia máxima:
Supongamos que tenemos la bi-partición bipartition y la coincidencia máxima matching. Define un nuevo digrafo H, H.setOfNodes=G.setOfNodes, los arcos en H.setOfArcs son la unión de dos sets.
El primer set de arcos a en matching, con el cambio que si a.fromNode in bipartition.firstPart y a.toNode en bipartition.secondPart entonces a.fromNode y a.toNode son intercambiados en el acro creado le dan a tales arcos un atributo a.datum.inMatching = True para indicar que se derivaron de arcos en una coincidencia.
El segundo conjunto es arcos a NO en matching, con el cambio que si a.fromNode en bipartition.secondPart y a.toNode en bipartition.firstPart entonces a.fromNode y a.toNode se intercambian en el arco creado (da a tal arco un atributo a.datum.inMatching = False).
A continuación, ejecute una primera búsqueda de profundidad (DFS) a partir de cada nodo n en bipartition.firstPart que no es n == a.fromNode ni n == a.toNodes para cualquier arco a en matching. Durante el DFS, algunos nodos son visitados y otros no (almacene esta información en un campo n.datum.visited). La cubierta de nodo mínima es la unión de los nodos {a.fromNode para a en H.setOfArcs si ((a.datum.inMatching) y (a.fromNode.datum.visited))} y los nodos {a.fromNode para a en H.setOfArcs si (a.datum.inMatching) y (no a.toNode.datum.visited)}.
Esto puede demostrarse que conduce desde una coincidencia máxima a una cubierta de nodo mínima por una prueba por contradicción, tomar un arco a que supuestamente no estaba cubierto y considerar todos los cuatro casos sobre si a.fromNode y a.toNode pertenecen (ya sea como toNode o fromNode) a cualquier arco en coincidencia matching. Cada caso lleva a una contradicción debido al orden en que DFS visita nodos y el hecho de que matching es un matching máximo.
Supongamos que tenemos una función para ejecutar estos pasos y devolver el conjunto de nodos que comprende la cubierta de nodo mínima cuando se le da el digrafo G, y la coincidencia máxima matching:

ArcMatchingDatum = coll.namedtuple('ArcMatchingDatum', ['inMatching' ])
NodeMatchingDatum = coll.namedtuple('NodeMatchingDatum', ['visited'])

def dfs_helper(snodes, G):
   sniter, do_stop = iter(snodes), False
   visited, visited_uids = set(), set()
   while(not do_stop):
       try:
           stack = [ next(sniter) ]
           while len(stack) > 0:
               curr = stack.pop()
               if curr.uid not in visited_uids:
                   visited = visited.union( frozenset( {Node(curr.uid, NodeMatchingDatum(False))} ) )
                   visited_uids = visited.union(frozenset({curr.uid}))
                   succ = frozenset({a.toNode for a in G.setOfArcs if a.fromNode == curr})
                   stack.extend( succ.difference( frozenset(visited) ) )
       except StopIteration as e:
           stack, do_stop = [], True
   return visited

def get_min_node_cover(matching, bipartition):
   nodes = frozenset( { Node(n.uid, NodeMatchingDatum(False)) for n in bipartition.G.setOfNodes} )
   G = DiGraph(nodes, None)
   charcs = frozenset( {a for a in matching if ( (a.fromNode in bipartition.firstPart) and (a.toNode in bipartition.secondPart) )} )
   arcs0 = frozenset( { Arc(find_node_by_uid(a.toNode.uid,G), find_node_by_uid(a.fromNode.uid,G), ArcMatchingDatum(True) ) for a in charcs } )
   arcs1 = frozenset( { Arc(find_node_by_uid(a.fromNode.uid,G), find_node_by_uid(a.toNode.uid,G), ArcMatchingDatum(True) ) for a in matching.difference(charcs) } )
   not_matching = bipartition.G.setOfArcs.difference( matching )
   charcs = frozenset( {a for a in not_matching if ( (a.fromNode in bipartition.secondPart) and (a.toNode in bipartition.firstPart) )} )
   arcs2 = frozenset( { Arc(find_node_by_uid(a.toNode.uid,G), find_node_by_uid(a.fromNode.uid,G), ArcMatchingDatum(False) ) for a in charcs } )
   arcs3 = frozenset( { Arc(find_node_by_uid(a.fromNode.uid,G), find_node_by_uid(a.toNode.uid,G), ArcMatchingDatum(False) ) for a in not_matching.difference(charcs) } )
   arcs = arcs0.union(arcs1.union(arcs2.union(arcs3)))

   G = DiGraph(nodes, arcs)
   bip = Bipartition({find_node_by_uid(n.uid,G) for n in bipartition.firstPart},{find_node_by_uid(n.uid,G) for n in bipartition.secondPart},G)
   match_from_nodes = frozenset({find_node_by_uid(a.fromNode.uid,G) for a in matching})
   match_to_nodes = frozenset({find_node_by_uid(a.toNode.uid,G) for a in matching})
   snodes = bip.firstPart.difference(match_from_nodes).difference(match_to_nodes)
   visited_nodes = dfs_helper(snodes, bip.G)
   not_visited_nodes = bip.G.setOfNodes.difference(visited_nodes)

   H = DiGraph(visited_nodes.union(not_visited_nodes), arcs)
   cover1 = frozenset( {a.fromNode for a in H.setOfArcs if ( (a.datum.inMatching) and (a.fromNode.datum.visited) ) } )
   cover2 = frozenset( {a.fromNode for a in H.setOfArcs if ( (a.datum.inMatching) and (not a.toNode.datum.visited) ) } )
   min_cover_nodes = cover1.union(cover2)
   true_min_cover_nodes = frozenset({find_node_by_uid(n.uid, bipartition.G) for n in min_cover_nodes})

   return min_cover_nodes

El Problema de Asignación Lineal

El problema de asignación lineal consiste en encontrar una máxima coincidencia de pesos en un gráfico bipartito ponderado.
Problemas como el que aparece al comienzo de este post pueden expresarse como un problema de asignación lineal. Dado un conjunto de trabajadores, un conjunto de tareas, y una función que indica la rentabilidad de una asignación de un trabajador a una tarea, queremos maximizar la suma de todas las asignaciones que hacemos; esto es un problema de asignación lineal.
Supongamos que el número de tareas y los trabajadores son iguales, aunque voy a demostrar que esta suposición es fácil de quitar. En la implementación, represento pesos de arco con un atributo a.datum.weight para un arco a.

WeightArcDatum = namedtuple('WeightArcDatum', [weight])

Algoritmo Kuhn-Munkres

El Algoritmo de Kuhn-Munkres resuelve el problema de asignación lineal. Una buena implementación puede tomar tiempo O(N^{4}), (donde N es el número de nodos en el digrafo que representa el problema). Una implementación que es más fácil de explicar toma O (N ^ {5}) (para una versión que regenera digrafos) y O (N ^ {4}) para (para una versión que mantiene los digrafos). Esto es similar a las dos implementaciones diferentes del algoritmo Edmonds-Karp.
Para esta descripción, sólo estoy trabajando con gráficos bipartitos completos (aquellos donde la mitad de los nodos están en una parte de la bi-partición y la otra mitad en la segunda parte). En el trabajador, la motivación de la tarea significa que hay tantos trabajadores como tareas.
Esto parece una condición significativa (¿qué sucede si estos conjuntos no son iguales?), Pero es fácil solucionar este problema; Hablo de cómo hacerlo en la última sección.
La versión del algoritmo descrito aquí utiliza el concepto útil de arcos de peso cero. Desafortunadamente, este concepto sólo tiene sentido cuando estamos resolviendo una minimización (si en vez de maximizar los beneficios de nuestras asignaciones de tareas de trabajadores, en vez de eso minimizamos el costo de tales asignaciones).
Afortunadamente, es fácil convertir un problema de asignación lineal máximo en un problema de asignación lineal mínimo estableciendo cada uno de los pesos de arco a en M-a.datum.weight donde M=max({a.datum.weight for a in G.setOfArcs}). La solución al problema de maximización original será idéntica a la solución minimizando el problema después de que se cambien los pesos de arco. Así que para el resto, supongamos que hacemos este cambio.
El algoritmo Kuhn-Munkres resuelve ponderación de peso mínima en un gráfico bi-particionado ponderado por una secuencia de concordancias máximas en gráficos no ponderados bipartitos. Si a encontramos una concordancia perfecta en la representación del digrafo del problema de asignación lineal y si el peso de cada arco en la coincidencia es cero, entonces hemos encontrado la ponderación de peso mínimo ya que esta coincidencia sugiere que todos nodos en el digrafos han sido emparejado por un arco con el menor costo posible ( ningún coste puede ser inferior a 0, basado en definiciones anteriores).
Ningún otro arcos se puede agregar a la coincidencia (ya que todos nodos ya están emparejados) y no arcos debe ser eliminado de la coincidente porque cualquier posible reemplazo arco tendrá al menos un valor de peso tan grande.
Si encontramos una coincidencia máxima del subgrafo de G que contiene sólo arcos de peso cero, y no es una concordancia perfecta, no tenemos una solución completa (ya que la combinación no es perfecta). Sin embargo, podemos producir un nuevo digrafo H cambiando los pesos de arcos en G.setOfArcs de manera que aparezcan nuevos 0-peso arcos y la solución óptima de «H» es la misma que la solución óptima de «G». Dado que garantizamos que al menos un arco de peso cero se produce en cada iteración, garantizamos que llegaremos a un coincidencia perfecta en no más de |G.setOfNodes|^{2}=N^{2} en tales iteraciones.
Supongamos que en la bi-partición bipartition, bipartition.firstPart contiene nodos representando trabajadores, y bipartition.secondPart representa nodos que al mismo tiempo representa pruebas.
El algoritmo comienza generando un nuevo digrafo H. H.setOfNodes = G.setOfNodes. Algunos arcos en H son nodos n generados en bipartition.firstPart. Cada nodo n genera un arco b en H.setOfArcs por cada arco a en bipartition.G.setOfArcs donde a.fromNode = n or a.toNode = n, b=Arc(a.fromNode, a.toNode, a.datum.weight - z) donde z=min(x.datum.weight for x in G.setOfArcs if ( (x.fromNode == n) or (x.toNode == n) )).
Más arcos en H se generan por nodos n en bipartition.secondPart. Cada uno de estos nodos n genera un arco b en H.setOfArcs por cada arco a en bipartition.G.setOfArcs donde a.fromNode = n o a.toNode = n, b=Arc(a.fromNode, a.toNode, ArcWeightDatum(a.datum.weight - z)) donde z=min(x.datum.weight for x in G.setOfArcs if ( (x.fromNode == n) or (x.toNode == n) )).
KMA: Luego, forma un nuevo digrafo K compuesto sólo de los arcos de peso cero de H, y los nodos incidente en esos arcos. Forma una bipartition en los nodos en K, luego usa solve_mbm( bipartition ) para obtener una combinación máxima (matching) en K. Si matching es una combinación perfecta en H (los arcos en matching son incidente en todos los nodos en H.setOfNodes) entonces matching es una solución óptima para problema de asignación lineal.
De lo contrario, si matching no es perfecto, genera la cubierta de nodo mínima de K usando node_cover = get_min_node_cover(matching, bipartition(K)). Luego, define z=min({a.datum.weight for a in H.setOfArcs if a not in node_cover}). Define nodes = H.setOfNodes,

arcs1 = {Arc(a.fromNode,a.toNode,ArcWeightDatum(a.datum.weigh-z)) for a in H.setOfArcs if ( (a.fromNode not in node_cover) and (a.toNode not in node_cover)}

arcs2 = {Arc(a.fromNode,a.toNode,ArcWeightDatum(a.datum.weigh)) for a in H.setOfArcs if ( (a.fromNode not in node_cover) != (a.toNode not in node_cover)}

arcs3 = {Arc(a.fromNode,a.toNode,ArcWeightDatum(a.datum.weigh+z)) for a in H.setOfArcs if ( (a.fromNode in node_cover) and (a.toNode in node_cover)}

. El != símbolo en la expresión anterior actúa como un operador XOR. Luego arcs = arcs1.union(arcs2.union(arcs3)). Luego, H=DiGraph(nodes,arcs). Regresa a la marca KMA. El algoritmo continúa hasta que se produce una combinación perfecta. Esta combinación es también la solución al problema de asignación lineal.

def kuhn_munkres( bipartition ):
   nodes = bipartition.G.setOfNodes
   arcs = frozenset({})

   for n in bipartition.firstPart:
       z = min( {x.datum.weight for x in bipartition.G.setOfArcs if ( (x.fromNode == n) or (x.toNode == n) )} )
       arcs = arcs.union( frozenset({Arc(a.fromNode, a.toNode, ArcWeightDatum(a.datum.weight - z)) }) )

   for n in bipartition.secondPart:
       z = min( {x.datum.weight for x in bipartition.G.setOfArcs if ( (x.fromNode == n) or (x.toNode == n) )} )
       arcs = arcs.union( frozenset({Arc(a.fromNode, a.toNode, ArcWeightDatum(a.datum.weight - z)) }) )

   H = DiGraph(nodes, arcs)

   assignment, value = dict({}), 0
   not_done = True

   while( not_done ):
       zwarcs = frozenset( {a for a in H.setOfArcs if a.datum.weight == 0} )
       znodes = frozenset( {n.fromNode for n in zwarcs} ).union( frozenset( {n.toNode for n in zwarcs} ) )
       K = DiGraph(znodes, zwarcs)
       k_bipartition = bipartition(K)
       matching = solve_mbm( k_bipartition )
       mnodes = frozenset({a.fromNode for a in matching}).union(frozenset({a.toNode for a in matching}))
       if( len(mnodes) == len(H.setOfNodes) ):
           for a in matching:
               assignment[ a.fromNode.uid ] = a.toNode.uid
           value = sum({a.datum.weight for a in matching})
           not_done = False
       else:
           node_cover = get_min_node_cover(matching, bipartition(K))
           z = min( frozenset( {a.datum.weight for a in H.setOfArcs if a not in node_cover} ) )
           nodes = H.setOfNodes
           arcs1 = frozenset( {Arc(a.fromNode,a.toNode,ArcWeightDatum(a.datum.weigh-z)) for a in H.setOfArcs if ( (a.fromNode not in node_cover) and (a.toNode not in node_cover)} )
           arcs2 = frozenset( {Arc(a.fromNode,a.toNode,ArcWeightDatum(a.datum.weigh)) for a in H.setOfArcs if ( (a.fromNode not in node_cover) != (a.toNode not in node_cover)} )
           arcs3 = frozenset( {Arc(a.fromNode,a.toNode,ArcWeightDatum(a.datum.weigh+z)) for a in H.setOfArcs if ( (a.fromNode in node_cover) and (a.toNode in node_cover)} )
           arcs = arcs1.union(arcs2.union(arcs3))
           H = DiGraph(nodes,arcs)

   return value, assignment

Esta implementación es O(N^{5}) porque genera una nueva combinación máxima matching en cada iteración; similar a las dos implementaciones anteriores de Edmonds-Karp este algoritmo puede ser modificado para que siga la pista de la coincidencia y la adapte inteligentemente a cada iteración. Cuando esto se hace, la complejidad se convierte en O(N^{4}). Una versión más avanzada y más reciente de este algoritmo (que requiere algunas estructuras de datos más avanzadas) puede ejecutarse en O (N ^ {3}). Detalles de la implementación más sencilla anterior y la implementación más avanzada se puede encontrar en esta publicación que motivó este blog.
Ninguna de las operaciones sobre los pesos del arco modifica la asignación final devuelta por el algoritmo. Por eso: Dado que nuestros gráficos de entrada son siempre gráficos completos bi-particionados, una solución debe asignar cada nodo en una partición a otro nodo en la segunda partición, a través del arco entre estos dos nodos. Observe que las operaciones realizadas en los pesos de arco nunca cambian el orden (ordenado por peso) de los arcos incidentes en ningún nodo particular.
Por lo tanto, cuando el algoritmo termina en un perfecta y completa bi-partición coincidente, cada nodo se le asigna un peso cero al arco, ya que el orden relativo de los arcos de que nodo no ha cambiado durante el algoritmo y dado que un arco de peso cero es el arco más barato posible y el complemento bipartito completo perfecto garantiza que existe un arco para cada nodo. Esto significa que la solución generada es de hecho la misma que la solución del problema de asignación lineal original sin ninguna modificación de pesos de arco.

Asignaciones no Balanceadas

Parece que el algoritmo es bastante limitado, ya que como se describe, opera sólo en gráficos bipartitos completos (aquellos donde la mitad de los nodos están en una parte de la bi-partición y la otra mitad en el segundo parte). En el trabajador, la motivación de la tarea significa que hay tantos trabajadores como tareas (parece bastante limitante).
Sin embargo, hay una transformación fácil que elimina esta restricción. Supongamos que hay menos trabajadores que tareas, agregamos algunos trabajadores ficticios (lo suficiente para hacer que el gráfico resultante sea un gráfico bipartito completo). Cada trabajador ficticio tiene un arco dirigido del trabajador a cada una de las tareas. Cada uno de estos arco tiene peso 0 (colocándolo en una coincidencia no da ningún beneficio adicional). Después de este cambio el gráfico es un gráfico bipartito completo que podemos resolver. No se inicia ninguna tarea asignada a un trabajador ficticio.
Supongamos que hay más tareas que los trabajadores. Añadimos algunas tareas ficticias (suficiente para hacer que el gráfico resultante sea un gráfico bi-particionado completo). Cada tarea ficticia tiene un arco dirigido de cada trabajador a la tarea ficticia. Cada uno de estos arco tiene un peso de 0 (colocándolo en una coincidencia no da ningún beneficio adicional). Después de este cambio el gráfico es un gráfico bi-particionado completo que podemos resolver. Cualquier trabajador asignado a la tarea ficticia no es empleado durante el período.

Ejemplo de asignación lineal

Por último, vamos a hacer un ejemplo con el código que he estado usando. Voy a modificar el ejemplo de problema de aquí. Tenemos 3 tareas: necesitamos limpiar el baño, barrer el piso, y lavar las ventanas.
Los trabajadores disponibles son Alice, Bob, Charlie y Diane. Cada uno de los trabajadores nos da el salario que requieren por tarea. Aquí están los salarios por trabajador:

	Clean the Bathroom	Sweep the Floor	Wash the Windows
Alice	$2	$3	$3
Bob	$3	$2	$3
Charlie	$3	$3	$2
Diane	$9	$9	$1

Si queremos pagar la menor cantidad de dinero, pero todavía obtener todas las tareas realizadas, ¿quién debe hacer qué tarea? Comienza introduciendo una tarea ficticia para que el digrafo que representa el problema bipartito.

	Clean the Bathroom	Sweep the Floor	Wash the Windows	Do Nothing
Alice	$2	$3	$3	$0
Bob	$3	$2	$3	$0
Charlie	$3	$3	$2	$0
Diane	$9	$9	$1	$0

Suponiendo que el problema está codificado en un digrafo, entonces kuhn_munkres( bipartition(G) ) resolverá el problema y devolverá la asignación. Es fácil verificar que la asignación óptima (costo más bajo) costará $ 5.
He aquí una visualización de la solución que el código anterior genera:

Eso es todo . Ya sabes todo lo que necesitas saber sobre el problema de asignación lineal.

Puedes encontrar todo el código de este artículo en GitHub.

Por: Dmitri Ivanovich Arkhipov

Artículo vía: Toptal

Diseño Anticipatorio: Cómo Crear Experiencias de Usuarios Mágicos

2017-10-01T16:24:00.001-03:00

Esta mañana la canción “This Magic Moment” de The Drifters apareció en mi cabeza sin ninguna razón aparente.

Esas inquietantes redes neuronales en nuestro cerebro hacen cosas divertidas. Hacen que aparentemente conceptos y pensamientos no relacionados se conectan.

Golpeándome la frente me dije: “Pero, por supuesto …”

Recientemente he estado pensando en esos momentos mágicos en UX que suceden cuando interactuamos con nuestros dispositivos o servicios digitales. Encontramos momentos perfectos, cuando todo cae en su lugar, exactamente en el camino correcto, exactamente en el momento adecuado, como si fuera mágico. Podría ser en tu banco, en tu coche, una máquina expendedora, o en tu teléfono.

Creo que la era del diseño anticipatorio está aquí, o al menos a nuestro alcance.

Nuestras GUIs limitadas están cambiando como resultado de la evolución de las tecnologías y los métodos de entrada. Es una evolución orgánica, natural - ¡ por supuesto, ya estamos hablando con nuestros dispositivos!

Por ejemplo, mientras conducimos podríamos decir: “Llama a Anna.” Le pedimos a Siri que inicie un cronómetro o que las películas estén jugando cerca. Y le pedimos a Alexa que toque música o nos ordene el café. Sin embargo, las metáforas y los elementos gráficos establecidos hace más de cuatro décadas no han cambiado mucho.

El Pasado

Ten en cuenta que la GUI original de Xerox PARC tiene 44 años, pero nuestras interfaces de usuario todavía se ven muy bien.

La estación de trabajo Xerox Star introdujo el primer sistema operativo de interfaz gráfica de usuario (GUI) comercial en 1973

Hoy en día, todavía estamos viendo pantallas bidimensionales y en su mayoría utilizan teclados y ratones para la entrada, dispositivos diseñados para métodos de interacción optimizados para ordenadores, no para humanos.

Las máquinas con las que interactuamos - ordenadores portátiles, escritorios, tablets, móviles , máquinas expendedoras, etc., diseñados y construidos con modelos mentales y tecnologías que son sistemas heredados del pasado.

Es como si estuviéramos utilizando modelos de interacción de la era de Los Picapiedras en un mundo de Los Supersónicos. Todavía dependen de mucha interacción de los usuarios (entrada) para pasar al siguiente paso y mostrar información útil (salida).

¿Qué es el diseño anticipatorio?

La aplicación del diseño anticipatorio es más importante que nunca si las empresas digitales son para simplificar y facilitar el curso de nuestras vidas digitales.

A la luz de esto, ¿qué es el diseño anticipatorio?

Es de salida, sin mucha necesidad de entrada.

Un mundo donde nuestras máquinas de computación están diseñadas para los métodos de interacción optimizados para los seres humanos, no para las computadoras. Un mundo digital donde nos movemos de la intención del usuario que es determinista a probabilística.

Aaron Shapiro de Hugedefine el diseño anticipatorio como un método para simplificar los procesos respondiendo a las necesidades un paso por delante de las decisiones del usuario, es decir, respondiendo a las necesidades de los usuarios que aún no han expresado.

El diseño anticipado en su forma más fina va mucho más allá de la personalización.

Por ejemplo, Netflix que muestra películas para ver en función de tus preferencias y el historial para la personalización. Con un diseño anticipado, la interfaz cambia realmente en el momento en que estás interactuando con una aplicación.

An example of personalization-not anticipatory design.

El diseño anticipatorio significaría -en el caso de las compras en línea, por ejemplo- que el sistema conocería y personalizaría una experiencia en la medida en que se sentiría como una mano mágica guiando tu experiencia. En realidad, cambiaría la interfaz de usuario al instante, eliminaría cualquier información extraña y sólo presentaría las opciones más relevantes de manera oportuna, sencilla y eficiente.

Esto no es demasiado difícil de lograr hoy.

Digamos que alguien está comprando una guitarra muy cara en guitarcenter.com. Al momento de pagar el sitio presentaría automágicamente “enviar a la tienda para ser recoger” como una opción por defecto porque sabe al observar el comportamiento pasado de otros usuarios comprando guitarras caras, estos preferirían recogerlas en la tienda más cercana.

Para otro ejemplo, vamos a fingir que estás comprando una camisa en Amazon.

Amazon ya personaliza toda una serie de cosas para ti y debe saber tu tamaño y las preferencias de color ya que has comprado camisas en el sitio antes.

Al ir a la página de detalles del producto, podría pre-seleccionar tu tamaño, y mostrar las de color azul marino, blancas y a cuadros en primer lugar, y no poner importancia en los rosados y amarillos, y no obligarte a seleccionar tu tamaño cada vez que veas distintas camisas.

¿Por qué?

La promesa del diseño anticipatorio es la eliminación de la fricción y un aumento en la eficiencia que mejoraría en gran medida las experiencias de los usuarios y, a su vez, impactaría en los resultados. La gente vuelve a los productos y servicios que ofrecen lo que quieren cuando lo desean.

Nuestras interacciones diarias con sistemas digitales han alcanzado una escala sin precedentes. Sin embargo, muchas de estas interacciones se sofocan con fricción y sentimientos subsiguientes de frustración.

Hay una necesidad real de personalización y en una escala mayor que deleitaría a los usuarios, y simplificar sus vidas.

Toma las máquinas expendedoras de billetes de autoservicio (ó ATMs), donde los viajeros pueden recargar tarjetas de viajero.

Todavía están diseñados para ser mudos - impulsados por la entrada del usuario en el que todo el mundo se toma a través de la misma plétora frustrante de opciones.

Uno podría fácilmente imaginar un sistema mucho mejorado, más personalizado, donde el historial de recarga podría ser almacenado en su tarjeta.

En lugar de un sinnúmero de solicitudes de entrada: selecciona esta opción primero, luego selecciona esta otra opción, y así sucesivamente, toda la interacción podría comenzar con la inserción de la tarjeta que siempre se quiere recargar y el sistema inmediatamente mostraría: “Hola, ¿te gustaría volver a llenar esta tarjeta con $ 20, usando tu Mastercard? “

El siguiente paso sería pagar y terminar la operación.

Se reduciría el tiempo necesario para recargar las tarjetas por lo menos en un 75 por ciento, aumentar la eficiencia, mover a la gente más rápido y, posteriormente, hacerlos más satisfechos.

Esto ya es posible, pero no sé de una sola máquina de venta de billetes que haga esto.

Una interfaz de usuario "tonto" que requiere una gran cantidad de entrada frente a uno que es "anticipatorio"?

Interfaces del futuro.

Cuando la IA se vuelve más penetrante, un mayor grado de personalización permitirá un mayor nivel de diseño anticipatorio.

Basado en todo tipo de seguimiento de comportamiento autorizado por el usuario - historiales de compra, preferencias, etc., el sistema lo reconocería y, con un alto grado de certeza, predecirá cuál podría ser tu próxima elección.

La falta de diseño anticipatorio es sorprendente dado que las tecnologías existen hoy en día que haría que hacerlo no es tan difícil.

Algunas empresas ya están practicando las primeras formas de diseño anticipatorio. Dos ejemplos son Google Now y Uber.

Google Now

La aplicación Google Now es una de las evoluciones más ambiciosas del software de búsqueda de Google.

La idea es simple: predecir lo que desearás o necesitarás saber antes de saber que lo necesitas o deseas, y servirlo en un formato de tarjeta fácil de leer.

Las capacidades de minería de datos de Google son insuperables. Sabe quién eres, y puede mostrar tarjetas con información personalizada, información de localización, como eventos de calendario, clima local, noticias, precios de las acciones, vuelos, pases de embarque, hoteles, fotos cerca y mucho más. También le dice cuánto tiempo le llevará a llegar a casa del trabajo, basado en las condiciones actuales del tráfico.

Si Google no cree que necesites algo en este momento, no se mostrará. Es la encarnación del diseño anticipatorio.

Uber

En la aplicación Uber, cuando tomas un viaje en algún lugar, proporcionará un botón de retorno en un lanzamiento posterior de la aplicación porque hay un 90 por ciento de posibilidades de que quieras volver a tu destino original. No es necesario especificar los lugares de recogida y entrega. Y eso es brillante.

La aplicación Uber ofrece a los usuarios un atajo rápido para "Volver" cuando se inicia poco después de completar un viaje

The times they are a-changin'.

Las cosas evolucionan a métodos naturales de interacción.

En un futuro no muy lejano, nuestra entrada será más fácil.

Vamos a tener realidad aumentada y virtual con métodos de interacción, como la voz, el seguimiento de los gestos, el seguimiento de los ojos y el habla. Google ya está trabajando en ello. Se llama Proyecto Soli.

Los métodos de diseño anticipados, asistidos por la IA y el aprendizaje automático, ofrecerán experiencias en un nivel completamente mejor.

¿Cómo ponemos en juego el diseño anticipatorio?

No hay varita mágica para pronunciar “abracadabra”, así que ¿cómo diseñamos para esos momentos mágicos ahora? ¿Cuáles son los pasos que podemos tomar hoy para entregar esos momentos mágicos, usando el diseño anticipatorio?

Algoritmos sofisticados y personalizados en el trabajo en Metromile crean una sensación de anticipación e increíblemente útil para los clientes (evitar entradas de estacionamiento)

Hasta que tengamos algoritmos predictivos increíblemente sofisticados, IA completamente desarrollada y aprendizaje de máquinas, las empresas pueden extraer datos existentes para oportunidades de personalización, reduciendo así los posibles puntos de dolor y barreras.

También pueden participar plenamente en el proceso de diseño centrado en el usuario, emplear investigaciones profundas, extensas pruebas de usuario y herramientas de uso, como una biblioteca de software de código abierto, para la inteligencia de la máquina, como Tensorflow.

Las investigaciones profundas nos ofrecerán una observación mucho-contextual quizás o estudios etnográficos- donde podamos observar lo que los usuarios están dispuestos a hacer de momento a momento en su flujo. Podríamos mapear estos viajes de usuario paso a paso, y diseñar la interacción en consecuencia.

El resultado ideal de la aplicación de la minería de datos y la personalización, junto con los métodos de diseño centrados en el usuario, crearía experiencias fluidas y sin precedentes anticipación que agradaría a los clientes y generar lealtad por tener las cosas aparecen como por arte de magia.

Se avanzaría el estado del arte de la experiencia del usuario y crear una situación de ganar-ganar tanto para empresas y usuarios, ofreciendo una mayor satisfacción del cliente que repercute positivamente en la línea de fondo.

Por: Miklos Philips
Artículo vía: Toptal

Angular vs. React: ¿Cuál es Mejor Para el Desarrollo Web?

2017-09-24T23:53:00.000-03:00

Hay innumerables artículos por ahí debatiendo si React o Angular es la mejor opción para el desarrollo web. ¿Necesitamos otro?

La razón por la que escribí este artículo es porque ninguno de los artículos ya publicados –aunque contienen grandes ideas– van en profundidad para un práctico desarrollador de front-end para decidir cuál puede satisfacer sus necesidades.

En este artículo, aprenderás cómo Angular y React apuntan a resolver problemas front-end similares aunque con filosofías muy diferentes, y si elegir uno o el otro es simplemente una cuestión de preferencia personal. Para compararlos, vamos a construir la misma aplicación dos veces, una vez con Angular y luego otra vez con React.

Anuncio Intempestivo de Angular

Hace dos años, escribí un artículo sobre React Ecosystem. Entre otros puntos, el artículo argumentaba que Angular había sido víctima de la “muerte por el anuncio previo”. En aquel entonces, la elección entre Angular y casi cualquier otra cosa era fácil para cualquiera que no quisiera que su proyecto funcionara con un marco obsoleto. Angular 1 era obsoleto, y Angular 2 ni siquiera estaba disponible en versión alfa.

En retrospectiva, los temores eran más o menos justificados. Angular 2 cambió dramáticamente e incluso pasó por una reescritura importante justo antes del lanzamiento final.

Dos años más tarde, tenemos Angular 4 con una promesa de estabilidad relativa de aquí en adelante.

¿Y ahora qué?

Angular vs. Reaccionar: Comparando Manzanas y Naranjas

Algunas personas dicen que comparar React y Angular es como comparar las manzanas con las naranjas. Mientras que uno es una biblioteca que se ocupa de opiniones, el otro es un framework completo.

Por supuesto, la mayoría de los Desarrolladores React añadirán algunas librerías a React para convertirlo en un framework completo. Por otra parte, el flujo de trabajo resultante de esta pila a menudo sigue siendo muy diferente de Angular, por lo que la comparabilidad sigue siendo limitada.

La mayor diferencia radica en la administración estatal. Angular viene con el enlace de datos incluido, mientras que React hoy en día suele ser aumentado por Redux para proporcionar flujo de datos unidireccional y trabajar con datos inmutables. Esos son enfoques opuestos en su propio derecho, y las discusiones incontables ahora están encendiendo si la unión mutable/de datos es mejor o peor que inmutable/unidireccional.

Un Campo de Juego Nivelado

Como React es famoso más fácil de hackear, he decidido, con el propósito de esta comparación, construir una configuración de React que refleja Angular razonablemente cerca para permitir la comparación de lado a lado de fragmentos de código.

Algunas características angulares que se destacan pero no se encuentran en Reaccionar por defecto son:

Feature	Angular package	React library
Data binding, dependency injection (DI)	@angular/core	MobX
Computed properties	rxjs	MobX
Component-based routing	@angular/router	React Router v4
Material design components	@angular/material	React Toolbox
CSS scoped to components	@angular/core	CSS modules
Form validations	@angular/forms	FormState
Project generator	@angular/cli	React Scripts TS

Enlace de Datos

La vinculación de datos es discutiblemente más fácil de comenzar que el enfoque unidireccional. Por supuesto, sería posible ir en dirección completamente opuesta, y usar Redux o mobx-state-tree con React, y ngrx con Angular. Pero eso sería un tema para otro post.

Propiedades Calculadas

Mientras que el funcionamiento se refiere, los adquiridores llanos en Angular están simplemente fuera de la pregunta mientras que se llaman en cada procesamiento. Es posible utilizar BehaviorSubject de RsJS, que realiza el trabajo.

Con React, es posible usar @computed de MobX, que logra el mismo objetivo, con una API algo mejor.

Inyección de Dependencia

La inyección de dependencia es un poco polémica porque va en contra del actual paradigma React de programación funcional e inmutabilidad. Como resulta, algún tipo de inyección de dependencia es casi indispensable en entornos de enlace de datos, ya que ayuda con el desacoplamiento (y, por lo tanto, burla y pruebas) donde no hay una arquitectura de capa de datos independiente.

Una ventaja más de DI (apoyado en Angular) es la capacidad de tener diferentes ciclos de vida de diferentes tiendas. La mayoría de los paradigmas actuales de React utilizan algún tipo de estado de aplicación global que mapea diferentes componentes, pero por mi experiencia, es demasiado fácil introducir errores al limpiar el estado global en el desmontaje de componentes.

Tener una tienda que se crea en el montaje de componentes (y estar perfectamente disponible para los hijos de este componente) parece ser realmente útil, ya menudo se pasa por alto el concepto.

Fuera de la caja en Angular, pero muy fácilmente reproducible con MobX también.

Enrutamiento

El enrutamiento basado en componentes permite a los componentes gestionar sus propias rutas secundarias en lugar de tener una configuración de enrutador global grande. Este enfoque finalmente lo ha hecho a react-router en la versión 4.

Material Design

Siempre es bueno comenzar con algunos componentes de alto nivel, y el diseño de materiales se ha convertido en algo así como una opción predeterminada universalmente aceptada, incluso en proyectos que no son de Google.

He elegido deliberadamente React Toolbox sobre el recomendado Material UI, ya que la interfaz de usuario de material tiene serias auto-confesados problemas de rendimiento con su CSS-en-línea, que planean resolver en la próxima versión.

Además, PostCSS/cssnext fue utilizado en React Toolbox y está empezando a reemplazar Sass/LESS de todos modos.

CSS con Alcance

Las clases CSS son algo así como las variables globales. Existen numerosos enfoques para la organización de CSS para evitar conflictos (incluyendo BEM), pero hay una clara corriente tendencia en el uso de bibliotecas que ayudan a procesar CSS para evitar esos conflictos sin la necesidad de un desarrollador front-end para elaborar elaborados sistemas de nombres CSS.

Validación de Formularios

Las validaciones de formulario son una característica no trivial y muy ampliamente utilizada. Es bueno tener los cubiertos por una librería para evitar la repetición de código y errores.

Generador de Proyecto

Tener un generador CLI para un proyecto es sólo un poco más conveniente que tener que clonar chapas de calderas de GitHub.

La Misma Aplicación, Construída Dos Veces

Así que vamos a crear la misma aplicación en React y Angular. Nada espectacular, solo un Shoutboard que permite a cualquiera publicar mensajes en una página común.

Puedes probar las aplicaciones aquí:

Si deseas tener todo el código fuente, puedes obtenerlo desde GitHub:

Observará que también hemos utilizado TypeScript para la aplicación React. Las ventajas de la comprobación de tipos en TypeScript son evidentes. Y ahora, con un mejor manejo de las importaciones, async/espera y propagación de descanso finalmente llegaron a TypeScript 2, y deja a Babel/ES7/Flow en el polvo.

Además, vamos a agregar Apollo Client a ambos porque queremos usar GraphQL. Quiero decir, REST es genial, pero después de una década aproximadamente, se hace viejo.

Bootstrap y Enrutamiento

Primero, echemos un vistazo a los puntos de entrada de ambas aplicaciones.

Angular

const appRoutes: Routes = [
  { path: 'home', component: HomeComponent },
  { path: 'posts', component: PostsComponent },
  { path: 'form', component: FormComponent },
  { path: '', redirectTo: '/home', pathMatch: 'full' }
]
 
@NgModule({
  declarations: [
    AppComponent,
    PostsComponent,
    HomeComponent,
    FormComponent,
  ],
  imports: [
    BrowserModule,
    RouterModule.forRoot(appRoutes),
    ApolloModule.forRoot(provideClient),
    FormsModule,
    ReactiveFormsModule,
    HttpModule,
    BrowserAnimationsModule,
    MdInputModule, MdSelectModule, MdButtonModule, MdCardModule, MdIconModule
  ],
  providers: [
    AppService
  ],
  bootstrap: [AppComponent]
})

@Injectable()
export class AppService {
  username = 'Mr. User'
}

Básicamente, todos los componentes que queremos utilizar en la aplicación necesitan ir a declaraciones. Todas las librerías de terceros a las importaciones y todas las tiendas globales a los proveedores. Los componentes de los hijos tienen acceso a todo esto, con la oportunidad de agregar más cosas locales.

React

const appStore = AppStore.getInstance()
const routerStore = RouterStore.getInstance()
 
const rootStores = {
  appStore,
  routerStore
}
 
ReactDOM.render(
  <Provider {...rootStores} >
    <Router history={routerStore.history} >
      <App>
        <Switch>
          <Route exact path='/home' component={Home as any} />
          <Route exact path='/posts' component={Posts as any} />
          <Route exact path='/form' component={Form as any} />
          <Redirect from='/' to='/home' />
        </Switch>
      </App>
    </Router>
  </Provider >,
  document.getElementById('root')
)

El componente <Provider/> se utiliza para la inyección de dependencia en MobX. Guarda las tiendas en el contexto para que los componentes de React puedan inyectarlas posteriormente. Sí, el contexto de React puede (discutiblemente) ser utilizado con seguridad.

La versión de React es un poco más corta porque no hay declaraciones de módulo - por lo general, es sólo importar y ya está listo para usar. A veces este tipo de dependencia dura no es deseado (en pruebas), por lo que para las tiendas singleton globales, tuve que usar este GoF patrón de vieja década:

export class AppStore {
  static instance: AppStore
  static getInstance() {
    return AppStore.instance || (AppStore.instance = new AppStore())
  }
  @observable username = 'Mr. User'
}

Angular’s Router es inyectable, por lo que puede ser utilizado desde cualquier lugar, no sólo los componentes. Para lograr lo mismo en reaccionar, usamos el paquete mobx-react-router e inyectamos el routerStore.

Resumen: Hacer bootstrapping en ambas aplicaciones es bastante sencillo. React tiene una ventaja que es más simple, usando sólo importaciones en lugar de módulos, pero, como veremos más adelante, esos módulos pueden ser muy útiles. Hacer semifallos manualmente es un poco molesto. En cuanto a la sintaxis de la declaración de enrutamiento, JSON vs JSX es sólo una cuestión de preferencia.

Enlaces y Navegación Imperativa

Así que hay dos casos para cambiar una ruta. Declarativamente, utilizando elementos <a href...>, e imperativamente, llamando directamente a la API de enrutamiento (y, por tanto, de ubicación).

Angular

<h1> Shoutboard Application </h1>
<nav>
  <a routerLink="/home" routerLinkActive="active">Home</a>
  <a routerLink="/posts" routerLinkActive="active">Posts</a>
</nav>
<router-outlet></router-outlet>

Angular Router detecta automáticamente qué routerLink está activo, y pone una clase apropiadarouterLinkActive en ella, para que pueda ser estilizada.

El enrutador utiliza el elemento especial <router-outlet> para representar cualquier ruta de acceso actual. Es posible tener muchos ‘`, mientras profundizamos en los subcomponentes de la aplicación.

@Injectable()
export class FormService {
  constructor(private router: Router) { }
  goBack() {
    this.router.navigate(['/posts'])
  }
}

El módulo de enrutador puede ser inyectado a cualquier servicio (mitad-mágicamente por su tipo TypeScript), la declaración private lo almacena en la instancia sin necesidad de asignación explícita. Utilice el método navigate para cambiar las URL.

React

import * as style from './app.css'
// …
  <h1>Shoutboard Application</h1>
  <div>
    <NavLink to='/home' activeClassName={style.active}>Home</NavLink>
    <NavLink to='/posts' activeClassName={style.active}>Posts</NavLink>
  </div>
  <div>
    {this.props.children}
  </div>

React Router también puede establecer la clase de enlace activo con activeClassName.

Aquí no podemos proporcionar el nombre de la clase directamente porque se ha hecho único por el compilador de módulos CSS, y tenemos que usar el ayudante style. Hablaremos sobre eso más tarde.

Como se ha visto anteriormente, React Router utiliza el elemento <Switch> dentro de un elemento <App>. Como el elemento <Switch>simplemente envuelve y monta la ruta actual, significa que las sub-rutas del componente actual son simplemente this.props.children. Así que es componible también.

export class FormStore {
  routerStore: RouterStore
  constructor() {
    this.routerStore = RouterStore.getInstance()
  }
  goBack = () => {
    this.routerStore.history.push('/posts')
  }
}

El paquete mobx-router-store también permite una fácil inyección y navegación.

Resumen: Ambos enfoques de enrutamiento son bastante comparables. Angular parece ser más intuitivo, mientras que React Router tiene un poco más fácil de componer.

Inyección de Dependencia

Ya se ha demostrado que es beneficioso separar la capa de datos de la capa de presentación. Lo que estamos tratando de lograr con DI es hacer que los componentes de las capas de datos (aquí denominados modelo/tienda/servicio) sigan el ciclo de vida de los componentes visuales y, por lo tanto, permitan hacer una o varias instancias de dichos componentes sin necesidad de tocar globales estado. Además, debería ser posible mezclar y combinar datos compatibles y capas de visualización.

Ejemplos en este artículo son muy simples, por lo que todas las cosas DI puede parecer exceso, pero viene muy bien a medida que crece la aplicación.

Angular

@Injectable()
export class HomeService {
  message = 'Welcome to home page'
  counter = 0
  increment() {
    this.counter++
  }
}

Así que cualquier clase se puede hacer @inyectable, y sus propiedades y métodos puestos a disposición de los componentes.

@Component({
  selector: 'app-home',
  templateUrl: './home.component.html',
  providers: [
    HomeService
  ]
})
export class HomeComponent {
  constructor(
    public homeService: HomeService,
    public appService: AppService,
  ) { }
}

Al registrar el HomeService aproviders del componente, lo ponemos a disposición de este componente exclusivamente. No es un semifallo ahora, pero cada instancia del componente recibirá una nueva copia, fresca en el montaje del componente. Eso significa que no hay datos obsoletos de uso previo.

Por el contrario, el AppService se ha registrado en elapp.module (ver arriba), por lo que es un semifallo y se mantiene igual para todos los componentes, aunque la duración de la aplicación. Ser capaz de controlar el ciclo de vida de los servicios de los componentes es un concepto muy útil, pero poco apreciado.

DI funciona asignando las instancias de servicio al constructor del componente, identificadas por tipos TypeScript. Además, las palabras clave public asignan automáticamente los parámetros athis, de modo que ya no necesitamos escribir esas líneas aburridas this.homeService = homeService.

<div>
  <h3>Dashboard</h3>
  <md-input-container>
    <input mdInput placeholder='Edit your name' [(ngModel)]='appService.username' />
  </md-input-container>
  <br/>
  <span>Clicks since last visit: {{homeService.counter}}</span>
  <button (click)='homeService.increment()'>Click!</button>
</div>

Sintaxis de la plantilla de Angular, sin duda bastante elegante. Me gusta el atajo [()], que funciona como un enlace de datos de 2 vías, pero bajo el capó, en realidad es un atributo vinculante + evento. Como dicta el ciclo de vida de nuestros servicios, homeService.counter va a reiniciarse cada vez que naveguemos lejos de/home, pero el appService.username permanece, y es accesible desde cualquier lugar.

React

import { observable } from 'mobx'
 
export class HomeStore {
  @observable counter = 0
  increment = () => {
    this.counter++
  }
}

Con MobX, necesitamos agregar el decorador @observable a cualquier propiedad que queramos hacer observable.

@observer
export class Home extends React.Component<any, any> {
 
  homeStore: HomeStore
  componentWillMount() {
    this.homeStore = new HomeStore()
  }
 
  render() {
    return <Provider homeStore={this.homeStore}>
      <HomeComponent />
    </Provider>
  }
}

Para gestionar el ciclo de vida correctamente, necesitamos hacer un poco más de trabajo que en el ejemplo Angular. Envolvemos el HomeComponentdentro de unProvider, que recibe una nueva instancia de HomeStore en cada montaje.

interface HomeComponentProps {
  appStore?: AppStore,
  homeStore?: HomeStore
}
 
@inject('appStore', 'homeStore')
@observer
export class HomeComponent extends React.Component<HomeComponentProps, any> {
  render() {
    const { homeStore, appStore } = this.props
    return <div>
      <h3>Dashboard</h3>
      <Input
        type='text'
        label='Edit your name'
        name='username'
        value={appStore.username}
        onChange={appStore.onUsernameChange}
      />
      <span>Clicks since last visit: {homeStore.counter}</span>
      <button onClick={homeStore.increment}>Click!</button>
    </div>
  }
}

HomeComponent utiliza el decorador @observer para escuchar los cambios en las propiedades @observable.

El mecanismo bajo-la-capucha de esto es bastante interesante, así que vamos a pasar por esto brevemente aquí. El decorador @observablereemplaza una propiedad en un objeto con getter y setter, lo que le permite interceptar llamadas. Cuando se llama a la función render de un componente aumentado @observador, las propiedades getters se llaman y mantienen una referencia al componente que las llama.

A continuación, cuando se llama a setter y se cambia el valor, se llaman las funciones render de los componentes que utilizaron la propiedad en el último procesamiento. Ahora, los datos sobre qué propiedades se utilizan donde se actualizan, y todo el ciclo puede comenzar de nuevo.

Un mecanismo muy simple, y bastante performant también. Más explicación en profundidad aquí.

El decorador @inyectar 'se utiliza para inyectar instanciasappStoreyhomeStoreen los accesorios deHomeComponent. En este punto, cada una de esas tiendas tiene un ciclo de vida diferente.appStorees el mismo durante la vida de la aplicación, perohomeStore` es recién creado en cada navegación a la ruta “/home”.

La ventaja de esto es que no es necesario limpiar las propiedades manualmente, como ocurre cuando todas las tiendas son globales, lo cual es doloroso si la ruta es alguna página de “detalle” que contiene datos completamente diferentes cada vez.

Resumen: Como la gestión del ciclo de vida del proveedor en una característica inherente de la DI de Angular, es, por supuesto, más simple lograrlo allí. La versión de React es también utilizable pero implica mucho más boilerplate.

Propiedades Calculadas

React

Comencemos con Reaccionar en éste, tiene una solución más directa.

import { observable, computed, action } from 'mobx'
 
export class HomeStore {
import { observable, computed, action } from 'mobx'
 
export class HomeStore {
  @observable counter = 0
  increment = () => {
    this.counter++
  }
  @computed get counterMessage() {
    console.log('recompute counterMessage!')
    return `${this.counter} ${this.counter === 1 ? 'click' : 'clicks'} since last visit`
  }
}

Así que tenemos una propiedad calculada que se une a counter y devuelve un mensaje correctamente pluralizado. El resultado de counterMessagese almacena en caché y se vuelve a calcular sólo cuandocounter cambia.

<Input
  type='text'
  label='Edit your name'
  name='username'
  value={appStore.username}
  onChange={appStore.onUsernameChange}
/>
<span>{homeStore.counterMessage}</span>
<button onClick={homeStore.increment}>Click!</button>

Luego, hacemos referencia a la propiedad (y el método increment) de la plantilla JSX. El campo de entrada se controla mediante la vinculación a un valor y permite que un método de `appStore ‘maneje el evento de usuario.

Angular

Para lograr el mismo efecto en Angular, necesitamos ser un poco más inventivos.

import { Injectable } from '@angular/core'
import { BehaviorSubject } from 'rxjs/BehaviorSubject'
 
@Injectable()
export class HomeService {
  message = 'Welcome to home page'
  counterSubject = new BehaviorSubject(0)
  // Computed property can serve as basis for further computed properties
  counterMessage = new BehaviorSubject('')
  constructor() {
    // Manually subscribe to each subject that couterMessage depends on
    this.counterSubject.subscribe(this.recomputeCounterMessage)
  }
 
  // Needs to have bound this
  private recomputeCounterMessage = (x) => {
    console.log('recompute counterMessage!')
    this.counterMessage.next(`${x} ${x === 1 ? 'click' : 'clicks'} since last visit`)
  }
 
  increment() {
    this.counterSubject.next(this.counterSubject.getValue() + 1)
  }
}

Necesitamos definir todos los valores que sirven como base para una propiedad calculada como un BehaviorSubject. La propia propiedad calculada es también un BehaviorSubject, porque cualquier propiedad calculada puede servir como entrada para otra propiedad calculada.

Por supuesto, RxJS puede hacer mucho más que sólo esto, pero eso sería un tema para un artículo completamente diferente. El inconveniente menor es que este uso trivial de RxJS para las propiedades calculadas es un poco más detallado que el ejemplo reactivo, y es necesario administrar las suscripciones manualmente (como aquí en el constructor).

<md-input-container>
  <input mdInput placeholder='Edit your name' [(ngModel)]='appService.username' />
</md-input-container>
<span>{{homeService.counterMessage | async}}</span>
<button (click)='homeService.increment()'>Click!</button>

Tenga en cuenta cómo podemos hacer referencia al sujeto RxJS con el |asíncrona . Eso es un toque agradable, mucho más corto que la necesidad de suscribirse en sus componentes. El componente input es impulsado por la directiva [(ngModel)]. A pesar de mirar extraño, es realmente bastante elegante. Sólo un azúcar sintáctico para la vinculación de datos de valor a appService.username y el valor de asignación automática del evento de entrada del usuario.

Resumen: Las propiedades calculadas son más fáciles de implementar en React/MobX que en Angular/RxJS, pero RxJS podría proporcionar algunas características de FRP más útiles, que podrían apreciarse más tarde.

Plantillas y CSS

Para mostrar cómo las pilas de plantillas entre sí, vamos a utilizar el componente de mensajes que muestra una lista de mensajes.

Angular

@Component({
  selector: 'app-posts',
  templateUrl: './posts.component.html',
  styleUrls: ['./posts.component.css'],
  providers: [
    PostsService
  ]
})
 
export class PostsComponent implements OnInit {
  constructor(
    public postsService: PostsService,
    public appService: AppService
  ) { }
 
  ngOnInit() {
    this.postsService.initializePosts()
  }
}

Este componente sólo conecta HTML, CSS y servicios inyectados y también llama a la función para cargar los mensajes de la API en la inicialización. AppService es un semifallo definido en el módulo de aplicación, mientras quePostsService es transitorio, con una instancia nueva creada en cada componente de tiempo creado. El CSS que se hace referencia desde este componente tiene un ámbito de este componente, lo que significa que el contenido no puede afectar a nada fuera del componente.

<a routerLink="/form" class="float-right">
  <button md-fab>
    <md-icon>add</md-icon>
  </button>
</a>
<h3>Hello {{appService.username}}</h3>
<md-card *ngFor="let post of postsService.posts">
  <md-card-title>{{post.title}}</md-card-title>
  <md-card-subtitle>{{post.name}}</md-card-subtitle>
  <md-card-content>
    <p>
      {{post.message}}
    </p>
  </md-card-content>
</md-card>

En la plantilla HTML, hacemos referencia principalmente a componentes de Material Angular. Para tenerlos disponibles, era necesario incluirlos en las importaciones app.module (véase más arriba). La directiva *ngFor se utiliza para repetir el componente md-card para cada puesto.

Local CSS:

.mat-card {
  margin-bottom: 1rem;
}

El CSS local sólo aumenta una de las clases presentes en el componente md-card.

Global CSS:

.float-right {
  float: right;
}

Esta clase se define en el archivo global style.css para que esté disponible para todos los componentes. Se puede hacer referencia en la forma estándar, class =" float-right ".

Compiled CSS:

.float-right {
  float: right;
}
.mat-card[_ngcontent-c1] {
    margin-bottom: 1rem;
}

En CSS compilado, podemos ver que el CSS local ha sido delimitado al componente renderizado mediante el selector de atributos [_ngcontent-c1]. Cada componente Angular representado tiene una clase generada como ésta para fines de alcance CSS.

La ventaja de este mecanismo es que podemos referenciar clases normalmente, y el alcance se maneja “bajo el capó”.

React

import * as style from './posts.css'
import * as appStyle from '../app.css'
 
@observer
export class Posts extends React.Component<any, any> {
 
  postsStore: PostsStore
  componentWillMount() {
    this.postsStore = new PostsStore()
    this.postsStore.initializePosts()
  }
 
  render() {
    return <Provider postsStore={this.postsStore}>
      <PostsComponent />
    </Provider>
  }
}

En React, de nuevo, necesitamos usar el método Provider para hacer que la dependencia de PostsStore sea “transitoria”. También importamos estilos CSS, denominados style y appStyle, para poder utilizar las clases de esos archivos CSS en JSX.

interface PostsComponentProps {
  appStore?: AppStore,
  postsStore?: PostsStore
}
 
@inject('appStore', 'postsStore')
@observer
export class PostsComponent extends React.Component<PostsComponentProps, any> {
  render() {
    const { postsStore, appStore } = this.props
    return <div>
      <NavLink to='form'>
        <Button icon='add' floating accent className={appStyle.floatRight} />
      </NavLink>
      <h3>Hello {appStore.username}</h3>
      {postsStore.posts.map(post =>
        <Card key={post.id} className={style.messageCard}>
          <CardTitle
            title={post.title}
            subtitle={post.name}
          />
          <CardText>{post.message}</CardText>
        </Card>
      )}
    </div>
  }
}

Naturalmente, JSX se siente mucho más JavaScript-y que las plantillas HTML de Angular, que puede ser una buena o mala cosa dependiendo de sus gustos. En lugar de la directiva *ngFor, usamos el constructomap para iterar sobre los posts.

Ahora bien, Angular podría ser el marco que promociona a TypeScript más, pero en realidad es JSX donde TypScript realmente brilla. Con la adición de módulos CSS (importados anteriormente), realmente convierte la codificación de su plantilla en zen de código. Cada cosa es revisada. Componentes, atributos, incluso clases CSS (appStyle.floatRight ystyle.messageCard, ver más abajo). Y, por supuesto, la naturaleza delgada de JSX fomenta la división en componentes y fragmentos un poco más que las plantillas de Angular.

Local CSS:

.messageCard {
  margin-bottom: 1rem;
}

Global CSS:

.floatRight {
  float: right;
}

Compiled CSS:

.floatRight__qItBM {
  float: right;
}
 
.messageCard__1Dt_9 {
    margin-bottom: 1rem;
}

Como puede ver, el cargador de CSS Módulos postfixes cada clase CSS con un postfix aleatorio, que garantiza la singularidad. Una forma sencilla de evitar conflictos. A continuación, las clases se hacen referencia a través de los objetos importados del paquete web. Un inconveniente posible de esto puede ser que no se puede crear un CSS con una clase y aumentarlo, como lo hicimos en el ejemplo Angular. Por otro lado, esto puede ser realmente una buena cosa, porque le obliga a encapsular estilos correctamente.

Resumen: Personalmente, me gusta JSX un poco mejor que las plantillas Angular, sobre todo debido a la terminación del código y el tipo de control de apoyo. Eso realmente es una característica asesina. Angular ahora tiene el compilador AOT, que también puede detectar algunas cosas, la finalización de código también funciona para alrededor de la mitad de las cosas allí, pero no es casi tan completo como JSX/TypeScript.

GraphQL - Cargando Datos

Así que hemos decidido utilizar GraphQL para almacenar datos para esta aplicación. Una de las maneras más fáciles de crear el back-end de GraphQL es usar algún BaaS, como Graphcool. Así que eso es lo que hicimos. Básicamente, sólo define modelos y atributos, y su CRUD es bueno para ir.

Código Común

Como parte del código relacionado con GraphQL es 100% igual para ambas implementaciones, no lo repetimos dos veces:

const PostsQuery = gql`
  query PostsQuery {
    allPosts(orderBy: createdAt_DESC, first: 5)
    {
      id,
      name,
      title,
      message
    }
  }
`

GraphQL es un lenguaje de consulta dirigido a proporcionar un conjunto más rico de funcionalidad en comparación con los puntos finales RESTful clásicos. Vamos a diseccionar esta consulta en particular.

PostsQuery es sólo un nombre para esta consulta a la referencia posterior, se puede nombrar nada.
allPosts es la parte más importante - hace referencia a la función para consultar todos los registros con el modelo `Post`. Este nombre fue creado por Graphcool.
orderBy y first son parámetros de la función allPosts. createdAt es uno de los Post atributos del modelo. first: 5 significa que devolverá sólo los primeros 5 resultados de la consulta.
id, name, title, y message son los atributos del modelo Post que queremos ser incluidos en el resultado. Otros atributos serán filtrados.

Como ya puedes ver, es bastante potente. Echa un vistazo a esta página para familiarizarse más con las consultas de GraphQL.

interface Post {
  id: string
  name: string
  title: string
  message: string
}
 
interface PostsQueryResult {
  allPosts: Array<Post>
}

Sí, como buenos ciudadanos de TypeScript, creamos interfaces para los resultados de GraphQL.

Angular

@Injectable()
export class PostsService {
  posts = []
 
  constructor(private apollo: Apollo) { }
 
  initializePosts() {
    this.apollo.query<PostsQueryResult>({
      query: PostsQuery,
      fetchPolicy: 'network-only'
    }).subscribe(({ data }) => {
      this.posts = data.allPosts
    })
  }
}

La consulta GraphQL es un RxJS observable, y nos suscribimos a ella. Funciona un poco como una promesa, pero no es así, por lo que no tenemos suerte con async/await. Por supuesto, todavía hay toPromise, pero no parece ser el camino Angular de todas formas. Establecemos fetchPolicy: 'network-only' porque en este caso, no queremos almacenar en caché los datos, sino refetch cada vez.

React

export class PostsStore {
  appStore: AppStore
 
  @observable posts: Array<Post> = []
 
  constructor() {
    this.appStore = AppStore.getInstance()
  }
 
  async initializePosts() {
    const result = await this.appStore.apolloClient.query<PostsQueryResult>({
      query: PostsQuery,
      fetchPolicy: 'network-only'
    })
    this.posts = result.data.allPosts
  }
}

La versión de React es casi idéntica, pero como apolloClient aquí usa promesas, podemos aprovechar la sintaxisasync / await. Existen otros enfoques en React que sólo “graban” las consultas GraphQL a componentes de orden superior, pero me pareció mezclar la capa de datos y presentación a tad demasiado.

En resúmen: Las ideas de la RxJS suscribirse vs async/await son realmente lo mismo.

GraphQL - Guardando Datos

Código Común

Una vez más, algo de código GraphQL relacionado:

const AddPostMutation = gql`
  mutation AddPostMutation($name: String!, $title: String!, $message: String!) {
    createPost(
      name: $name,
      title: $title,
      message: $message
    ) {
      id
    }
  }
`

El propósito de las mutaciones es crear o actualizar registros. Por lo tanto, es beneficioso para declarar algunas variables con la mutación, ya que son la forma de cómo pasar los datos en ella. Así que tenemos las variables name,title y message, escritas como String, que necesitamos llenar cada vez que llamemos a esta mutación. La función createPost, de nuevo, está definida por Graphcool. Especificamos que las claves del modelo Post tendrán valores de las variables de mutación de salida, y también que queremos que elid del Post recién creado sea enviado a cambio.

Angular

@Injectable()
export class FormService {
  constructor(
    private apollo: Apollo,
    private router: Router,
    private appService: AppService
  ) { }
 
  addPost(value) {
    this.apollo.mutate({
      mutation: AddPostMutation,
      variables: {
        name: this.appService.username,
        title: value.title,
        message: value.message
      }
    }).subscribe(({ data }) => {
      this.router.navigate(['/posts'])
    }, (error) => {
      console.log('there was an error sending the query', error)
    })
  }
 
}

Cuando llamamos apollo.mutate, necesitamos proporcionar la mutación que llamamos y las variables también. Obtenemos el resultado en la función de devolución de llamada subscribe y usamos el` roteador ‘inyectado para navegar de nuevo a la lista de correos.

React

export class FormStore {
  constructor() {
    this.appStore = AppStore.getInstance()
    this.routerStore = RouterStore.getInstance()
    this.postFormState = new PostFormState()
  }
 
  submit = async () => {
    await this.postFormState.form.validate()
    if (this.postFormState.form.error) return
    const result = await this.appStore.apolloClient.mutate(
      {
        mutation: AddPostMutation,
        variables: {
          name: this.appStore.username,
          title: this.postFormState.title.value,
          message: this.postFormState.message.value
        }
      }
    )
    this.goBack()
  }
 
  goBack = () => {
    this.routerStore.history.push('/posts')
  }
}

Muy similar a lo anterior, con la diferencia de más “manual” la inyección de dependencia, y el uso de async/await.

En resúmen: Una vez más, no hay mucha diferencia aquí. suscribirse vs async / await es básicamente todo lo que difiere.

Formularios

Queremos lograr los siguientes objetivos con los formularios de esta aplicación:

Enlace de datos de campos a un modelo
Mensajes de validación para cada campo, varias reglas
Soporte para comprobar si todo el formulario es válido

React

export const check = (validator, message, options) =>
  (value) => (!validator(value, options) && message)
 
export const checkRequired = (msg: string) => check(nonEmpty, msg)
 
export class PostFormState {
  title = new FieldState('').validators(
    checkRequired('Title is required'),
    check(isLength, 'Title must be at least 4 characters long.', { min: 4 }),
    check(isLength, 'Title cannot be more than 24 characters long.', { max: 24 }),
  )
  message = new FieldState('').validators(
    checkRequired('Message cannot be blank.'),
    check(isLength, 'Message is too short, minimum is 50 characters.', { min: 50 }),
    check(isLength, 'Message is too long, maximum is 1000 characters.', { max: 1000 }),
  )
  form = new FormState({
    title: this.title,
    message: this.message
  })
}

Por lo tanto, la librería formstate funciona de la siguiente manera: para cada campo de su formulario, define un FieldState. El parámetro pasado es el valor inicial. La propiedad validators toma una función, que devuelve “false” cuando el valor es válido, y un mensaje de validación cuando el valor no es válido. Con las funciones de check' ycheckRequired`, todo puede parecer muy declarativo.

Para tener la validación de toda la forma, es beneficioso también envolver esos campos con una instancia FormState, que a continuación, proporciona la validez agregada.

@inject('appStore', 'formStore')
@observer
export class FormComponent extends React.Component<FormComponentProps, any> {
  render() {
    const { appStore, formStore } = this.props
    const { postFormState } = formStore
    return <div>
      <h2> Create a new post </h2>
      <h3> You are now posting as {appStore.username} </h3>
      <Input
        type='text'
        label='Title'
        name='title'
        error={postFormState.title.error}
        value={postFormState.title.value}
        onChange={postFormState.title.onChange}
      />
      <Input
        type='text'
        multiline={true}
        rows={3}
        label='Message'
        name='message'
        error={postFormState.message.error}
        value={postFormState.message.value}
        onChange={postFormState.message.onChange}
      />

La instancia FormState proporciona propiedades value, onChange y error, que se pueden utilizar fácilmente con cualquier componente front-end.

      <Button
        label='Cancel'
        onClick={formStore.goBack}
        raised
        accent
      /> &nbsp;
      <Button
        label='Submit'
        onClick={formStore.submit}
        raised
        disabled={postFormState.form.hasError}
        primary
      />
 
    </div>
 
  }
}

Cuando form.hasError estrue, mantenemos el botón deshabilitado. El botón Enviar envía el formulario a la mutación GraphQL presentada anteriormente.

Angular

En Angular, vamos a utilizar FormService y FormBuilder, que son partes del paquete @angular/forms.

@Component({
  selector: 'app-form',
  templateUrl: './form.component.html',
  providers: [
    FormService
  ]
})
export class FormComponent {
  postForm: FormGroup
  validationMessages = {
    'title': {
      'required': 'Title is required.',
      'minlength': 'Title must be at least 4 characters long.',
      'maxlength': 'Title cannot be more than 24 characters long.'
    },
    'message': {
      'required': 'Message cannot be blank.',
      'minlength': 'Message is too short, minimum is 50 characters',
      'maxlength': 'Message is too long, maximum is 1000 characters'
    }
  }

First, let’s define the validation messages.

  constructor(
    private router: Router,
    private formService: FormService,
    public appService: AppService,
    private fb: FormBuilder,
  ) {
    this.createForm()
  }
 
  createForm() {
    this.postForm = this.fb.group({
      title: ['',
        [Validators.required,
        Validators.minLength(4),
        Validators.maxLength(24)]
      ],
      message: ['',
        [Validators.required,
        Validators.minLength(50),
        Validators.maxLength(1000)]
      ],
    })
  }

Usando FormBuilder, es muy fácil crear la estructura del formulario, aún más sucintamente que en el ejemplo React.

  get validationErrors() {
    const errors = {}
    Object.keys(this.postForm.controls).forEach(key => {
      errors[key] = ''
      const control = this.postForm.controls[key]
      if (control && !control.valid) {
        const messages = this.validationMessages[key]
        Object.keys(control.errors).forEach(error => {
          errors[key] += messages[error] + ' '
        })
      }
    })
    return errors
  }

Para obtener mensajes de validación vinculables en el lugar correcto, necesitamos realizar algún procesamiento. Este código se toma de la documentación oficial, con algunos pequeños cambios. Básicamente, en FormService, los campos guardan referencia sólo a errores activos, identificados por nombre de validador, por lo que necesitamos emparejar manualmente los mensajes requeridos a los campos afectados. Esto no es totalmente un inconveniente; por ejemplo, se presta más fácilmente a la internacionalización.

  onSubmit({ value, valid }) {
    if (!valid) {
      return
    }
    this.formService.addPost(value)
  }
 
  onCancel() {
    this.router.navigate(['/posts'])
  }
}

Una vez más, cuando el formulario es válido, los datos pueden ser enviados a la mutación GraphQL.

<h2> Create a new post </h2>
<h3> You are now posting as {{appService.username}} </h3>
<form [formGroup]="postForm" (ngSubmit)="onSubmit(postForm)" novalidate>
  <md-input-container>
    <input mdInput placeholder="Title" formControlName="title">
    <md-error>{{validationErrors['title']}}</md-error>
  </md-input-container>
  <br>
  <br>
  <md-input-container>
    <textarea mdInput placeholder="Message" formControlName="message"></textarea>
    <md-error>{{validationErrors['message']}}</md-error>
  </md-input-container>
  <br>
  <br>
  <button md-raised-button (click)="onCancel()" color="warn">Cancel</button>
  <button
    md-raised-button
    type="submit"
    color="primary"
    [disabled]="postForm.dirty && !postForm.valid">Submit</button>
  <br>
  <br>
</form>

Lo más importante es hacer referencia al formGroup que hemos creado con FormBuilder, que es la asignación [formGroup] = 'postForm'. Los campos dentro del formulario están enlazados al modelo de formulario a través de la propiedad formControlName. Nuevamente, desactivamos el botón “Enviar” cuando el formulario no es válido. También debemos agregar el check sucio, porque aquí, el formulario no sucio puede ser inválido. Queremos que el estado inicial del botón esté “habilitado”.

En resúmen: Este enfoque de las formas en React y Angular es bastante diferente en los frentes de validación y de plantilla. El enfoque Angular implica un poco más de “magia” en lugar de un enlace directo, pero, por otro lado, es más completo.

Tamaño del Lote

Oh, una cosa más. La producción redujo los tamaños de paquetes de JS, con ajustes por defecto de los generadores de aplicación: notablemente Tree Shaking en React y AOT compilación en Angular.

Angular: 1200 KB
React: 300 KB

Bueno, no hay mucha sorpresa aquí. Angular siempre ha sido el más voluminoso.

Cuando se utiliza gzip, los tamaños bajan a 275kb y 127kb respectivamente.

Sólo ten en cuenta que estas son básicamente todas las librerías de proveedores. La cantidad de código de aplicación real es mínima por comparación, lo que no es el caso en una aplicación del mundo real. Allí, la proporción sería probablemente más parecida a 1:2 que 1:4. Además, cuando empieces a incluir muchas librerías de terceros con React, el tamaño del paquete también tiende a crecer con bastante rapidez.

Flexibilidad de las bibliotecas frente a la robustez del marco

Así que parece que no hemos sido capaces (¡de nuevo!) para dar una respuesta clara sobre si Angular o React es mejor para el desarrollo web.

Resulta que los flujos de trabajo de desarrollo en React y Angular pueden ser muy similares, dependiendo de las bibliotecas que elegimos para usar React with. Entonces es principalmente una cuestión de preferencia personal.

Si te gustan las pilas ya hechas, la poderosa inyección de dependencia y el plan para usar algunas golosinas de RxJS, eligió Angular.

Si te gusta jugar y construir tu propia pila, te gusta la simplicidad de JSX y prefieres propiedades computables más simples, selecciona React / MobX.

Una vez más, puede obtener el código fuente completo de la aplicación de este artículo aquí y aquí.

O, si prefieres ejemplos más grandes, y de RealWorld:

Primero, Elige tu Paradigma de Programación

La programación con React/MobX es en realidad más similar a Angular que con React/Redux. Hay algunas diferencias notables en las plantillas y el manejo de dependencias, pero tienen el mismo paradigma mutable/data binding.

React / Redux con su paradigma inmutable/unidireccional es una bestia completamente diferente.

No te dejes engañar por la pequeña huella de la librería de Redux. Puede ser pequeña, pero es un framework de todos modos. La mayoría de las mejores prácticas de Redux hoy se centran en el uso de librerías compatibles con redux, como Redux Saga para el código asíncrono y la búsqueda de datos, Redux Form para la gestión de formularios, Reselect para selectores memorizados (valores calculados de Redux). y Recompose, entre otros, para una gestión del ciclo de vida más fina. Además, hay un cambio en la comunidad Redux de Immutable.js a Ramda o lodash/fp, que funcionan con objetos JS sencillos en lugar de convertirlos.

Un buen ejemplo de Redux moderno es el bien conocido React Boilerplate. Es una pila de desarrollo formidable, pero si lo echas un vistazo, es realmente muy, muy diferente de todo lo que hemos visto en este post hasta ahora.

Siento que Angular está recibiendo un poco de tratamiento injusto de la parte más vocal de la comunidad de JavaScript. Muchas personas que expresan su insatisfacción con ella probablemente no aprecian el cambio inmenso que ocurrió entre el antiguo AngularJS y Angular de hoy. En mi opinión, es un marco muy limpio y productivo que tomaría el mundo por la tormenta si hubiera aparecido 1-2 años antes.

Sin embargo, Angular está ganando un punto de apoyo sólido, especialmente en el mundo corporativo, con grandes equipos y necesidades de estandarización y soporte a largo plazo. O para decirlo de otra manera, Angular es la forma en que los ingenieros de Google piensan que el desarrollo web debe hacerse, si eso sigue siendo así.

En cuanto a MobX, se aplica una evaluación similar. Realmente genial, pero no se aprecia mucho.

En conclusión: antes de elegir entre React y Angular, elige primero tu paradigma de programación.

mutable/enlace de datos ó inmutable/unidireccional, ese parece ser el problema real.

UNDERSTANDING THE BASICS

Is React a framework?

React is a JavaScript library for building user interfaces. It deals with the views and lets you choose the rest of your front-end architecture. However, a strong library ecosystem has developed around it, allowing you to build a complete framework around React by adding a few libraries to it.

How do I implement computed properties in Angular?

Por: Tomas Holas
Artículo vía: Toptal

Un Comienzo con Microservicios: Un Tutorial de Dropwizard

2017-09-10T22:12:00.000-03:00

Todos somos testigos de un aumento en la popularidad de las arquitecturas de microservicios. En una arquitectura de microservicios, Dropwizard ocupa un lugar muy importante. Es un marco para la creación de servicios web RESTful o, para ser más específicos, un conjunto de herramientas y frameworks para la creación de servicios web RESTful.

Permite a los desarrolladores un arranque más rápido del proyecto. Esto te ayuda a empaquetar tus aplicaciones, para que se puedan desplegar fácilmente en un entorno de producción como servicios independientes. Si alguna vez has estado en una situación en la que necesitas arrancar un proyecto en el framework Spring, por ejemplo, probablemente sabes lo doloroso que puede ser.

Con Dropwizard, solo se trata de añadir una dependencia de Maven.

En este blog, te guiaré a través del proceso completo de escribir un simple servicio Dropwizard RESTful. Cuando terminemos, tendremos un servicio para operaciones básicas de CRUD en “partes”. Realmente no importa que es “parte”; puede ser cualquier cosa, pero fue lo primero que se me ocurrió.

Almacenaremos la data en una base de datos MySQL, usando JDBI para consultarla y usaremos los siguientes endpoints:

GET /parts -to retrieve all parts from DB
GET /part/{id} to get a particular part from DB
POST /parts -to create new part
PUT /parts/{id} -to edit an existing part
DELETE /parts/{id} -to delete the part from a DB

Usaremos OAuth para autenticar nuestro servicio y luego agregarle algunas pruebas de unidad

Bibliotecas Dropwizard Predeterminadas

En lugar de incluir todas las bibliotecas necesarias para crear un servicio REST por separado y configurar cada una de ellas, Dropwizard lo hace por nosotros. Aquí está la lista de bibliotecas que vienen predeterminadas con Dropwizard:

Jetty: Necesitarás HTTP para ejecutar una aplicación web. Dropwizard incorpora el contenedor servlet Jetty para ejecutar aplicaciones web. En lugar de implementar tus aplicaciones en un servidor de aplicaciones o servidor web, Dropwizard define un método principal que invoca al servidor Jetty como un proceso autónomo. A partir de ahora, Dropwizard recomienda sólo ejecutar la aplicación con Jetty; otros servicios web como Tomcat no son oficialmente compatibles.
Jersey: Jersey es una de las mejores implementaciones API de REST en el mercado. Además, sigue la especificación estándar de JAX-RS y es la implementación de referencia para la especificación JAX-RS. Dropwizard utiliza Jersey como el marco predeterminado para la creación de aplicaciones web RESTful.
Jackson: Jackson es el estándar de facto para el manejo del formato JSON. Es una de las mejores API de asignación de objetos para el formato JSON.
Métricas: Dropwizard tiene su propio módulo de métricas para exponer las métricas de la aplicación a través de los endpoints HTTP.
Guava: Además de estructuras de data inmutables y altamente optimizadas, Guava proporciona un número creciente de clases para acelerar el desarrollo en Java.
Logback y Slf4j: Estos dos se utilizan para mejorar los mecanismos de registro.
Freemarker y Mustache: La elección de motores de plantilla para su aplicación es una de las decisiones clave. El motor de plantilla elegido tiene que ser más flexible para escribir mejores secuencias de comandos. Dropwizard utiliza motores de plantilla Freemarker y Mustache, los cuales son bien conocidos y populares, para la construcción de las interfaces de usuario.

Aparte de la lista anterior, hay muchas otras bibliotecas como Joda Time, Liquibase, Apache HTTP Client y Hibernate Validator utilizadas por Dropwizard para la creación de servicios REST.

Configuración Maven

Dropwizard apoya, de manera oficial, a Maven. Incluso si puedes usar otras herramientas de compilación, la mayoría de las guías y documentación utilizan Maven, así que también lo usaremos aquí. Si no estás familiarizado con Maven, puedes consultar este tutorial Maven.

Este es el primer paso para crear tu aplicación Dropwizard. Agrega la siguiente entrada en el archivo pom.xmlde Maven:

<dependencies>
 <dependency>
   <groupId>io.dropwizard</groupId>
   <artifactId>dropwizard-core</artifactId>
   <version>${dropwizard.version}</version>
 </dependency>
</dependencies>

Antes de añadir la entrada anterior, puedes añadir dropwizard.versión como se muestra a continuación:

<properties>
 <dropwizard.version>1.1.0</dropwizard.version>
</properties>

Eso es todo. Ya terminaste de escribir la configuración de Maven. Esto descargará todas las dependencias necesarias para tu proyecto. La versión actual de Dropwizard es 1.1.0, así que la estaremos usando en esta guía.

Ahora podemos pasar a escribir nuestra primera aplicación Dropwizard real.

Definir Clase de Configuración

Dropwizard almacena configuraciones en archivos YAML. Vas a necesitar el archivo configuration.yml en la carpeta raíz de la aplicación. Este archivo se deserializará a una instancia de la clase de configuración de tu aplicación y se validará. El archivo de configuración de tu aplicación es la subclase de la clase de configuración de Dropwizard (io.dropwizard.Configuration).

Vamos a crear una clase configuración simple:

import javax.validation.Valid;
import javax.validation.constraints.NotNull;

import com.fasterxml.jackson.annotation.JsonProperty;

import io.dropwizard.Configuration;
import io.dropwizard.db.DataSourceFactory;

public class DropwizardBlogConfiguration extends Configuration {
 private static final String DATABASE = "database";

 @Valid
 @NotNull
 private DataSourceFactory dataSourceFactory = new DataSourceFactory();

 @JsonProperty(DATABASE)
 public DataSourceFactory getDataSourceFactory() {
   return dataSourceFactory;
 }

 @JsonProperty(DATABASE)
 public void setDataSourceFactory(final DataSourceFactory dataSourceFactory) {
   this.dataSourceFactory = dataSourceFactory;
 }
}

El archivo de configuración YAML se vería así:

database:
 driverClass: com.mysql.cj.jdbc.Driver
 url: jdbc:mysql://localhost/dropwizard_blog
 user: dropwizard_blog
 password: dropwizard_blog 
 maxWaitForConnection: 1s
 validationQuery: "SELECT 1"
 validationQueryTimeout: 3s
 minSize: 8
 maxSize: 32
 checkConnectionWhileIdle: false
 evictionInterval: 10s
 minIdleTime: 1 minute
 checkConnectionOnBorrow: true

La clase anterior se deserializará del archivo YAML y colocará los valores del archivo YAML en este objeto.

Definir una Clase de Aplicación

Ahora debemos ir y crear la clase de aplicación principal. Esta clase reunirá todos los paquetes, llevará la aplicación y la pondrá en funcionamiento para tu uso.

A continuación se muestra un ejemplo de una clase de aplicación en Dropwizard:

import io.dropwizard.Application;
import io.dropwizard.auth.AuthDynamicFeature;
import io.dropwizard.auth.oauth.OAuthCredentialAuthFilter;
import io.dropwizard.setup.Environment;

import javax.sql.DataSource;

import org.glassfish.jersey.server.filter.RolesAllowedDynamicFeature;
import org.skife.jdbi.v2.DBI;

import com.toptal.blog.auth.DropwizardBlogAuthenticator;
import com.toptal.blog.auth.DropwizardBlogAuthorizer;
import com.toptal.blog.auth.User;
import com.toptal.blog.config.DropwizardBlogConfiguration;
import com.toptal.blog.health.DropwizardBlogApplicationHealthCheck;
import com.toptal.blog.resource.PartsResource;
import com.toptal.blog.service.PartsService;

public class DropwizardBlogApplication extends Application<DropwizardBlogConfiguration> {
 private static final String SQL = "sql";
 private static final String DROPWIZARD_BLOG_SERVICE = "Dropwizard blog service";
 private static final String BEARER = "Bearer";

 public static void main(String[] args) throws Exception {
   new DropwizardBlogApplication().run(args);
 }

 @Override
 public void run(DropwizardBlogConfiguration configuration, Environment environment) {
   // Datasource configuration
   final DataSource dataSource =
       configuration.getDataSourceFactory().build(environment.metrics(), SQL);
   DBI dbi = new DBI(dataSource);

   // Register Health Check
   DropwizardBlogApplicationHealthCheck healthCheck =
       new DropwizardBlogApplicationHealthCheck(dbi.onDemand(PartsService.class));
   environment.healthChecks().register(DROPWIZARD_BLOG_SERVICE, healthCheck);

   // Register OAuth authentication
   environment.jersey()
       .register(new AuthDynamicFeature(new OAuthCredentialAuthFilter.Builder<User>()
           .setAuthenticator(new DropwizardBlogAuthenticator())
           .setAuthorizer(new DropwizardBlogAuthorizer()).setPrefix(BEARER).buildAuthFilter()));
   environment.jersey().register(RolesAllowedDynamicFeature.class);

   // Register resources
   environment.jersey().register(new PartsResource(dbi.onDemand(PartsService.class)));
 }
}

Lo que hicimos anteriormente es anular el método de ejecución de Dropwizard. En este método, estamos instanciando una conexión de DB (Base de datos), registrando nuestro chequeo de salud personalizado (hablaremos de eso más adelante), inicializando la autenticación OAuth para nuestro servicio y finalmente, registrando un recurso Dropwizard.

Todo esto se explicará más adelante.

Define una Clase de Representación

Ahora tenemos que empezar a pensar en nuestra REST API y cuál será la representación de nuestro recurso. Tenemos que diseñar el formato JSON y la clase de representación correspondiente que se convierte al formato JSON deseado.

Veamos el formato JSON de muestra para este ejemplo de clase de representación simple:

{
 "code": 200,
 "data": {
   "id": 1,
   "name": "Part 1",
   "code": "PART_1_CODE"
 }
}

Para el formato JSON anterior, crearemos la clase de representación de la siguiente manera:

import org.hibernate.validator.constraints.Length;

import com.fasterxml.jackson.annotation.JsonProperty;

public class Representation<T> {
 private long code;

 @Length(max = 3)
 private T data;

 public Representation() {
   // Jackson deserialization
 }

 public Representation(long code, T data) {
   this.code = code;
   this.data = data;
 }

 @JsonProperty
 public long getCode() {
   return code;
 }

 @JsonProperty
 public T getData() {
   return data;
 }
}

Esto es POJO de una manera muy simple.

Definición de una Clase de Recursos

Un recurso es en lo que se basan los servicios REST. No es nada más que un URI de endpoint para acceder al recurso en el servidor. En este ejemplo, tendremos una clase de recurso con pocas anotaciones para el mapeo de URI de solicitud. Dado que Dropwizard utiliza la implementación JAX-RS, definiremos la ruta URI utilizando la anotación @Path.

Aquí te muestro una clase de recurso para nuestro ejemplo de Dropwizard:

import java.util.List;

import javax.annotation.security.RolesAllowed;
import javax.validation.Valid;
import javax.validation.constraints.NotNull;
import javax.ws.rs.DELETE;
import javax.ws.rs.GET;
import javax.ws.rs.POST;
import javax.ws.rs.PUT;
import javax.ws.rs.Path;
import javax.ws.rs.PathParam;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;

import org.eclipse.jetty.http.HttpStatus;

import com.codahale.metrics.annotation.Timed;
import com.toptal.blog.model.Part;
import com.toptal.blog.representation.Representation;
import com.toptal.blog.service.PartsService;

@Path("/parts")
@Produces(MediaType.APPLICATION_JSON)
@RolesAllowed("ADMIN")
public class PartsResource {
 private final PartsService partsService;;

 public PartsResource(PartsService partsService) {
   this.partsService = partsService;
 }

 @GET
 @Timed
 public Representation<List<Part>> getParts() {
   return new Representation<List<Part>>(HttpStatus.OK_200, partsService.getParts());
 }

 @GET
 @Timed
 @Path("{id}")
 public Representation<Part> getPart(@PathParam("id") final int id) {
   return new Representation<Part>(HttpStatus.OK_200, partsService.getPart(id));
 }

 @POST
 @Timed
 public Representation<Part> createPart(@NotNull @Valid final Part part) {
   return new Representation<Part>(HttpStatus.OK_200, partsService.createPart(part));
 }

 @PUT
 @Timed
 @Path("{id}")
 public Representation<Part> editPart(@NotNull @Valid final Part part,
     @PathParam("id") final int id) {
   part.setId(id);
   return new Representation<Part>(HttpStatus.OK_200, partsService.editPart(part));
 }

 @DELETE
 @Timed
 @Path("{id}")
 public Representation<String> deletePart(@PathParam("id") final int id) {
   return new Representation<String>(HttpStatus.OK_200, partsService.deletePart(id));
 }
}

Puedes ver como todos los endpoints realmente se definen en esta clase.

Registro de un Recurso

Volvería ahora a la clase de aplicación principal. Puedes ver al final de esa clase que hemos registrado nuestro recurso para ser inicializado con la ejecución del servicio. Tenemos que hacerlo con todos los recursos que podamos tener en nuestra aplicación. Éste es el fragmento de código responsable de eso:

// Register resources
   environment.jersey().register(new PartsResource(dbi.onDemand(PartsService.class)));

Capa de Servicio

Para un manejo de excepciones adecuado y la capacidad de ser independiente del motor de almacenamiento de data, introduciremos una clase de servicio de “capa-media”. Esta es la clase que llamaremos desde nuestra capa de recursos, sin importar lo que está subyacente. Es por eso que tenemos esta capa en particular entre capas de recursos y DAO. Ésta es nuestra clase de servicio:

import java.util.List;
import java.util.Objects;

import javax.ws.rs.WebApplicationException;
import javax.ws.rs.core.Response.Status;

import org.skife.jdbi.v2.exceptions.UnableToExecuteStatementException;
import org.skife.jdbi.v2.exceptions.UnableToObtainConnectionException;
import org.skife.jdbi.v2.sqlobject.CreateSqlObject;

import com.toptal.blog.dao.PartsDao;
import com.toptal.blog.model.Part;

public abstract class PartsService {
 private static final String PART_NOT_FOUND = "Part id %s not found.";
 private static final String DATABASE_REACH_ERROR =
     "Could not reach the MySQL database. The database may be down or there may be network connectivity issues. Details: ";
 private static final String DATABASE_CONNECTION_ERROR =
     "Could not create a connection to the MySQL database. The database configurations are likely incorrect. Details: ";
 private static final String DATABASE_UNEXPECTED_ERROR =
     "Unexpected error occurred while attempting to reach the database. Details: ";
 private static final String SUCCESS = "Success...";
 private static final String UNEXPECTED_ERROR = "An unexpected error occurred while deleting part.";

 @CreateSqlObject
 abstract PartsDao partsDao();

 public List<Part> getParts() {
   return partsDao().getParts();
 }

 public Part getPart(int id) {
   Part part = partsDao().getPart(id);
   if (Objects.isNull(part)) {
     throw new WebApplicationException(String.format(PART_NOT_FOUND, id), Status.NOT_FOUND);
   }
   return part;
 }

 public Part createPart(Part part) {
   partsDao().createPart(part);
   return partsDao().getPart(partsDao().lastInsertId());
 }

 public Part editPart(Part part) {
   if (Objects.isNull(partsDao().getPart(part.getId()))) {
     throw new WebApplicationException(String.format(PART_NOT_FOUND, part.getId()),
         Status.NOT_FOUND);
   }
   partsDao().editPart(part);
   return partsDao().getPart(part.getId());
 }

 public String deletePart(final int id) {
   int result = partsDao().deletePart(id);
   switch (result) {
     case 1:
       return SUCCESS;
     case 0:
       throw new WebApplicationException(String.format(PART_NOT_FOUND, id), Status.NOT_FOUND);
     default:
       throw new WebApplicationException(UNEXPECTED_ERROR, Status.INTERNAL_SERVER_ERROR);
   }
 }

 public String performHealthCheck() {
   try {
     partsDao().getParts();
   } catch (UnableToObtainConnectionException ex) {
     return checkUnableToObtainConnectionException(ex);
   } catch (UnableToExecuteStatementException ex) {
     return checkUnableToExecuteStatementException(ex);
   } catch (Exception ex) {
     return DATABASE_UNEXPECTED_ERROR + ex.getCause().getLocalizedMessage();
   }
   return null;
 }

 private String checkUnableToObtainConnectionException(UnableToObtainConnectionException ex) {
   if (ex.getCause() instanceof java.sql.SQLNonTransientConnectionException) {
     return DATABASE_REACH_ERROR + ex.getCause().getLocalizedMessage();
   } else if (ex.getCause() instanceof java.sql.SQLException) {
     return DATABASE_CONNECTION_ERROR + ex.getCause().getLocalizedMessage();
   } else {
     return DATABASE_UNEXPECTED_ERROR + ex.getCause().getLocalizedMessage();
   }
 }

 private String checkUnableToExecuteStatementException(UnableToExecuteStatementException ex) {
   if (ex.getCause() instanceof java.sql.SQLSyntaxErrorException) {
     return DATABASE_CONNECTION_ERROR + ex.getCause().getLocalizedMessage();
   } else {
     return DATABASE_UNEXPECTED_ERROR + ex.getCause().getLocalizedMessage();
   }
 }
}

La última parte de ésta es en realidad una implementación de control de salud, de la que hablaremos más adelante.

Capa DAO, JDBI y Mapper

Dropwizard es compatible con JDBI e Hibernate. Es un módulo Maven separado, por lo que primero vamos a agregarlo como una dependencia, así como el conector MySQL

<dependency>
 <groupId>io.dropwizard</groupId>
 <artifactId>dropwizard-jdbi</artifactId>
 <version>${dropwizard.version}</version>
</dependency>
<dependency>
 <groupId>mysql</groupId>
 <artifactId>mysql-connector-java</artifactId>
 <version>${mysql.connector.version}</version>
</dependency>

Para un simple servicio CRUD, personalmente prefiero JDBI, ya que es más sencillo y mucho más rápido de implementar. He creado un esquema simple de MySQL con una tabla solamente para ser utilizada en nuestro ejemplo. Puedes encontrar el script init para el esquema dentro del origen. JDBI ofrece escritura simple de preguntas, usando anotaciones tales como @SqlQuery para la lectura y @SqlUpdate para escribir data. Aquí está nuestra interfaz DAO:

import java.util.List;

import org.skife.jdbi.v2.sqlobject.Bind;
import org.skife.jdbi.v2.sqlobject.BindBean;
import org.skife.jdbi.v2.sqlobject.SqlQuery;
import org.skife.jdbi.v2.sqlobject.SqlUpdate;
import org.skife.jdbi.v2.sqlobject.customizers.RegisterMapper;

import com.toptal.blog.mapper.PartsMapper;
import com.toptal.blog.model.Part;

@RegisterMapper(PartsMapper.class)
public interface PartsDao {

 @SqlQuery("select * from parts;")
 public List<Part> getParts();

 @SqlQuery("select * from parts where id = :id")
 public Part getPart(@Bind("id") final int id);

 @SqlUpdate("insert into parts(name, code) values(:name, :code)")
 void createPart(@BindBean final Part part);

 @SqlUpdate("update parts set name = coalesce(:name, name), code = coalesce(:code, code) where id = :id")
 void editPart(@BindBean final Part part);

 @SqlUpdate("delete from parts where id = :id")
 int deletePart(@Bind("id") final int id);

 @SqlQuery("select last_insert_id();")
 public int lastInsertId();
}

Como puedes ver, es bastante simple. Sin embargo, necesitamos asignar nuestros conjuntos de resultados de SQL a un modelo, lo cual se hace mediante el registro de una clase mapper. Aquí está nuestra clase mapper:

import java.sql.ResultSet;
import java.sql.SQLException;

import org.skife.jdbi.v2.StatementContext;
import org.skife.jdbi.v2.tweak.ResultSetMapper;

import com.toptal.blog.model.Part;

public class PartsMapper implements ResultSetMapper<Part> {
 private static final String ID = "id";
 private static final String NAME = "name";
 private static final String CODE = "code";

 public Part map(int i, ResultSet resultSet, StatementContext statementContext)
     throws SQLException {
   return new Part(resultSet.getInt(ID), resultSet.getString(NAME), resultSet.getString(CODE));
 }
}

Y nuestro modelo:

import org.hibernate.validator.constraints.NotEmpty;

public class Part {
 private int id;
 @NotEmpty
 private String name;
 @NotEmpty
 private String code;

 public int getId() {
   return id;
 }

 public void setId(int id) {
   this.id = id;
 }

 public String getName() {
   return name;
 }

 public void setName(String name) {
   this.name = name;
 }

 public String getCode() {
   return code;
 }

 public void setCode(String code) {
   this.code = code;
 }

 public Part() {
   super();
 }

 public Part(int id, String name, String code) {
   super();
   this.id = id;
   this.name = name;
   this.code = code;
 }
}

Chequeo de Salud de Dropwizard

Dropwizard ofrece soporte nativo para la comprobación de la salud. En nuestro caso, probablemente vamos a comprobar si la base de datos está funcionando antes de decir que nuestro servicio es saludable. Lo que hacemos es realizar alguna acción sencilla de Base de Datos, como obtener partes de la Base de Datos y manejar los resultados potenciales (exitosos o excepciones).

Aquí está nuestra implementación de chequeo de salud en Dropwizard:

import com.codahale.metrics.health.HealthCheck;
import com.toptal.blog.service.PartsService;

public class DropwizardBlogApplicationHealthCheck extends HealthCheck {
 private static final String HEALTHY = "The Dropwizard blog Service is healthy for read and write";
 private static final String UNHEALTHY = "The Dropwizard blog Service is not healthy. ";
 private static final String MESSAGE_PLACEHOLDER = "{}";

 private final PartsService partsService;

 public DropwizardBlogApplicationHealthCheck(PartsService partsService) {
   this.partsService = partsService;
 }

 @Override
 public Result check() throws Exception {
   String mySqlHealthStatus = partsService.performHealthCheck();

   if (mySqlHealthStatus == null) {
     return Result.healthy(HEALTHY);
   } else {
     return Result.unhealthy(UNHEALTHY + MESSAGE_PLACEHOLDER, mySqlHealthStatus);
   }
 }
}

Adición de Autenticación

Dropwizard admite la autenticación básica y OAuth. Aquí, te mostraré cómo proteger tu servicio con OAuth. Sin embargo, debido a la complejidad, he omitido una estructura de Base de Datos subyacente y sólo mostraré cómo se desarrolla. Implementar a escala completa no debería ser un problema a partir de aquí. Dropwizard tiene dos interfaces importantes que necesitamos implementar.

El primero es Authenticator. Nuestra clase debe implementar el método authenticate, que debe comprobar si el identificador de acceso dado es válido. Así que yo llamaría esto como una primera puerta a la aplicación. Si se da con éxito, debería dar como resultado un principal. Este principal es nuestro usuario real con su rol. Éste es importante para otra interfaz de Dropwizard que necesitamos implementar. Éste es el Authorizer y es responsable de comprobar si el usuario tiene suficientes permisos para acceder a un determinado recurso. Por lo tanto, si regresas y revisas nuestra clase de recursos, verás que requiere el rol de administrador para acceder a sus endpoints. Estas anotaciones también pueden ser por método. El soporte de autorización Dropwizard es un módulo Maven separado, por lo que debemos agregarlo a dependencias:

<dependency>
 <groupId>io.dropwizard</groupId>
 <artifactId>dropwizard-auth</artifactId>
 <version>${dropwizard.version}</version>
</dependency>

Aquí están las clases de nuestro ejemplo que realmente no hacen nada inteligente pero es un esqueleto para una autorización de OAuth a gran escala:

import java.util.Optional;

import io.dropwizard.auth.AuthenticationException;
import io.dropwizard.auth.Authenticator;

public class DropwizardBlogAuthenticator implements Authenticator<String, User> {
 @Override
 public Optional<User> authenticate(String token) throws AuthenticationException {
   if ("test_token".equals(token)) {
     return Optional.of(new User());
   }
   return Optional.empty();
 }
}

import java.util.Objects;

import io.dropwizard.auth.Authorizer;

public class DropwizardBlogAuthorizer implements Authorizer<User> {
 @Override
 public boolean authorize(User principal, String role) {
   // Allow any logged in user.
   if (Objects.nonNull(principal)) {
     return true;
   }
   return false;
 }
}

import java.security.Principal;

public class User implements Principal {
 private int id;
 private String username;
 private String password;

 public int getId() {
   return id;
 }

 public void setId(int id) {
   this.id = id;
 }

 public String getUsername() {
   return username;
 }

 public void setUsername(String username) {
   this.username = username;
 }

 public String getPassword() {
   return password;
 }

 public void setPassword(String password) {
   this.password = password;
 }

 @Override
 public String getName() {
   return username;
 }
}

Pruebas de Unidad en DropWizard

Vamos a agregar algunas pruebas de unidad a nuestra aplicación. Me atengo a probar partes específicas del código de Dropwizard, en nuestro caso: Representación y Recurso. Necesitaremos agregar las siguientes dependencias a nuestro archivo Maven:

<dependency>
 <groupId>io.dropwizard</groupId>
 <artifactId>dropwizard-testing</artifactId>
 <version>${dropwizard.version}</version>
</dependency>
<dependency>
 <groupId>org.mockito</groupId>
 <artifactId>mockito-core</artifactId>
 <version>${mockito.version}</version>
 <scope>test</scope>
</dependency>

Para probar la representación, también necesitaremos un archivo JSON de ejemplo para probar contra éste. Así que vamos a crear fixtures/part.json bajo src/test/resources:

{
 "id": 1,
 "name": "testPartName",
 "code": "testPartCode"
}

Y aquí está la clase de prueba JUnit:

import static io.dropwizard.testing.FixtureHelpers.fixture;
import static org.assertj.core.api.Assertions.assertThat;

import org.junit.Test;

import com.fasterxml.jackson.databind.ObjectMapper;
import com.toptal.blog.model.Part;

import io.dropwizard.jackson.Jackson;

public class RepresentationTest {
 private static final ObjectMapper MAPPER = Jackson.newObjectMapper();
 private static final String PART_JSON = "fixtures/part.json";
 private static final String TEST_PART_NAME = "testPartName";
 private static final String TEST_PART_CODE = "testPartCode";

 @Test
 public void serializesToJSON() throws Exception {
   final Part part = new Part(1, TEST_PART_NAME, TEST_PART_CODE);

   final String expected =
       MAPPER.writeValueAsString(MAPPER.readValue(fixture(PART_JSON), Part.class));

   assertThat(MAPPER.writeValueAsString(part)).isEqualTo(expected);
 }

 @Test
 public void deserializesFromJSON() throws Exception {
   final Part part = new Part(1, TEST_PART_NAME, TEST_PART_CODE);

   assertThat(MAPPER.readValue(fixture(PART_JSON), Part.class).getId()).isEqualTo(part.getId());
   assertThat(MAPPER.readValue(fixture(PART_JSON), Part.class).getName())
       .isEqualTo(part.getName());
   assertThat(MAPPER.readValue(fixture(PART_JSON), Part.class).getCode())
       .isEqualTo(part.getCode());
 }
}

Cuando se trata de probar los recursos, el punto principal de la prueba de Dropwizard es que realmente se está comportando como un cliente HTTP, enviando solicitudes HTTP contra los recursos. Por lo tanto, no estás probando métodos como lo harías normalmente en un caso común. Aquí está el ejemplo de nuestra clase PartsResource:

public class PartsResourceTest {
 private static final String SUCCESS = "Success...";
 private static final String TEST_PART_NAME = "testPartName";
 private static final String TEST_PART_CODE = "testPartCode";
 private static final String PARTS_ENDPOINT = "/parts";

 private static final PartsService partsService = mock(PartsService.class);

 @ClassRule
 public static final ResourceTestRule resources =
     ResourceTestRule.builder().addResource(new PartsResource(partsService)).build();

 private final Part part = new Part(1, TEST_PART_NAME, TEST_PART_CODE);

 @Before
 public void setup() {
   when(partsService.getPart(eq(1))).thenReturn(part);
   List<Part> parts = new ArrayList<>();
   parts.add(part);
   when(partsService.getParts()).thenReturn(parts);
   when(partsService.createPart(any(Part.class))).thenReturn(part);
   when(partsService.editPart(any(Part.class))).thenReturn(part);
   when(partsService.deletePart(eq(1))).thenReturn(SUCCESS);
 }

 @After
 public void tearDown() {
   reset(partsService);
 }

 @Test
 public void testGetPart() {
   Part partResponse = resources.target(PARTS_ENDPOINT + "/1").request()
       .get(TestPartRepresentation.class).getData();
   assertThat(partResponse.getId()).isEqualTo(part.getId());
   assertThat(partResponse.getName()).isEqualTo(part.getName());
   assertThat(partResponse.getCode()).isEqualTo(part.getCode());
   verify(partsService).getPart(1);
 }

 @Test
 public void testGetParts() {
   List<Part> parts =
       resources.target(PARTS_ENDPOINT).request().get(TestPartsRepresentation.class).getData();
   assertThat(parts.size()).isEqualTo(1);
   assertThat(parts.get(0).getId()).isEqualTo(part.getId());
   assertThat(parts.get(0).getName()).isEqualTo(part.getName());
   assertThat(parts.get(0).getCode()).isEqualTo(part.getCode());
   verify(partsService).getParts();
 }

 @Test
 public void testCreatePart() {
   Part newPart = resources.target(PARTS_ENDPOINT).request()
       .post(Entity.entity(part, MediaType.APPLICATION_JSON_TYPE), TestPartRepresentation.class)
       .getData();
   assertNotNull(newPart);
   assertThat(newPart.getId()).isEqualTo(part.getId());
   assertThat(newPart.getName()).isEqualTo(part.getName());
   assertThat(newPart.getCode()).isEqualTo(part.getCode());
   verify(partsService).createPart(any(Part.class));
 }

 @Test
 public void testEditPart() {
   Part editedPart = resources.target(PARTS_ENDPOINT + "/1").request()
       .put(Entity.entity(part, MediaType.APPLICATION_JSON_TYPE), TestPartRepresentation.class)
       .getData();
   assertNotNull(editedPart);
   assertThat(editedPart.getId()).isEqualTo(part.getId());
   assertThat(editedPart.getName()).isEqualTo(part.getName());
   assertThat(editedPart.getCode()).isEqualTo(part.getCode());
   verify(partsService).editPart(any(Part.class));
 }

 @Test
 public void testDeletePart() {
   assertThat(resources.target(PARTS_ENDPOINT + "/1").request()
       .delete(TestDeleteRepresentation.class).getData()).isEqualTo(SUCCESS);
   verify(partsService).deletePart(1);
 }

 private static class TestPartRepresentation extends Representation<Part> {

 }

 private static class TestPartsRepresentation extends Representation<List<Part>> {

 }

 private static class TestDeleteRepresentation extends Representation<String> {

 }
}

Construye tu Aplicación Dropwizard

La mejor práctica es crear el archivo único FAR JAR que contenga todos los archivos .class necesarios para ejecutar la aplicación. El mismo archivo JAR puede implementarse en un entorno diferente desde la prueba a la producción, sin ningún cambio en las bibliotecas de dependencias. Para comenzar a construir nuestra aplicación de ejemplo como un fat JAR, necesitamos configurar un complemento de Maven llamado maven-shade. Debes agregar las siguientes entradas en la sección de complementos de tu archivo pom.xml.

Aquí está la configuración Maven de ejemplo para construir el archivo JAR.

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
 <modelVersion>4.0.0</modelVersion>
 <groupId>com.endava</groupId>
 <artifactId>dropwizard-blog</artifactId>
 <version>0.0.1-SNAPSHOT</version>
 <name>Dropwizard Blog example</name>

 <properties>
   <dropwizard.version>1.1.0</dropwizard.version>
   <mockito.version>2.7.12</mockito.version>
   <mysql.connector.version>6.0.6</mysql.connector.version>
   <maven.compiler.source>1.8</maven.compiler.source>
   <maven.compiler.target>1.8</maven.compiler.target>
 </properties>

 <dependencies>
   <dependency>
     <groupId>io.dropwizard</groupId>
     <artifactId>dropwizard-core</artifactId>
     <version>${dropwizard.version}</version>
   </dependency>
   <dependency>
     <groupId>io.dropwizard</groupId>
     <artifactId>dropwizard-jdbi</artifactId>
     <version>${dropwizard.version}</version>
   </dependency>
   <dependency>
     <groupId>io.dropwizard</groupId>
     <artifactId>dropwizard-auth</artifactId>
     <version>${dropwizard.version}</version>
   </dependency>
   <dependency>
     <groupId>io.dropwizard</groupId>
     <artifactId>dropwizard-testing</artifactId>
     <version>${dropwizard.version}</version>
   </dependency>
   <dependency>
     <groupId>org.mockito</groupId>
     <artifactId>mockito-core</artifactId>
     <version>${mockito.version}</version>
     <scope>test</scope>
   </dependency>
   <dependency>
     <groupId>mysql</groupId>
     <artifactId>mysql-connector-java</artifactId>
     <version>${mysql.connector.version}</version>
   </dependency>
 </dependencies>

 <build>
   <plugins>
     <plugin>
       <groupId>org.apache.maven.plugins</groupId>
       <artifactId>maven-shade-plugin</artifactId>
       <version>2.3</version>
       <configuration>
         <createDependencyReducedPom>true</createDependencyReducedPom>
         <filters>
           <filter>
             <artifact>*:*</artifact>
             <excludes>
               <exclude>META-INF/*.SF</exclude>
               <exclude>META-INF/*.DSA</exclude>
               <exclude>META-INF/*.RSA</exclude>
             </excludes>
           </filter>
         </filters>
       </configuration>
       <executions>
         <execution>
           <phase>package</phase>
           <goals>
             <goal>shade</goal>
           </goals>
           <configuration>
             <transformers>
               <transformer
                 implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer" />
               <transformer
                 implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                 <mainClass>com.endava.blog.DropwizardBlogApplication</mainClass>
               </transformer>
             </transformers>
           </configuration>
         </execution>
       </executions>
     </plugin>
   </plugins>
 </build>
</project>

Ejecución de la Aplicación

Ahora deberíamos poder ejecutar el servicio. Si construiste correctamente tu archivo JAR, lo que necesitas hacer es abrir el símbolo del sistema y ejecutar el siguiente comando para ejecutar tu archivo JAR:

java -jar target/dropwizard-blog-1.0.0.jar server configuration.yml

Si todo salió bien, deberías ver algo como esto:

INFO  [2017-04-23 22:51:14,471] org.eclipse.jetty.util.log: Logging initialized @962ms to org.eclipse.jetty.util.log.Slf4jLog
INFO  [2017-04-23 22:51:14,537] io.dropwizard.server.DefaultServerFactory: Registering jersey handler with root path prefix: /
INFO  [2017-04-23 22:51:14,538] io.dropwizard.server.DefaultServerFactory: Registering admin handler with root path prefix: /
INFO  [2017-04-23 22:51:14,681] io.dropwizard.server.DefaultServerFactory: Registering jersey handler with root path prefix: /
INFO  [2017-04-23 22:51:14,681] io.dropwizard.server.DefaultServerFactory: Registering admin handler with root path prefix: /
INFO  [2017-04-23 22:51:14,682] io.dropwizard.server.ServerFactory: Starting DropwizardBlogApplication
INFO  [2017-04-23 22:51:14,752] org.eclipse.jetty.setuid.SetUIDListener: Opened application@7d57dbb5{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}
INFO  [2017-04-23 22:51:14,752] org.eclipse.jetty.setuid.SetUIDListener: Opened admin@630b6190{HTTP/1.1,[http/1.1]}{0.0.0.0:8081}
INFO  [2017-04-23 22:51:14,753] org.eclipse.jetty.server.Server: jetty-9.4.2.v20170220
INFO  [2017-04-23 22:51:15,153] io.dropwizard.jersey.DropwizardResourceConfig: The following paths were found for the configured resources:

   GET     /parts (com.toptal.blog.resource.PartsResource)
   POST    /parts (com.toptal.blog.resource.PartsResource)
   DELETE  /parts/{id} (com.toptal.blog.resource.PartsResource)
   GET     /parts/{id} (com.toptal.blog.resource.PartsResource)
   PUT     /parts/{id} (com.toptal.blog.resource.PartsResource)

INFO  [2017-04-23 22:51:15,154] org.eclipse.jetty.server.handler.ContextHandler: Started i.d.j.MutableServletContextHandler@58fa5769{/,null,AVAILABLE}
INFO  [2017-04-23 22:51:15,158] io.dropwizard.setup.AdminEnvironment: tasks = 

   POST    /tasks/log-level (io.dropwizard.servlets.tasks.LogConfigurationTask)
   POST    /tasks/gc (io.dropwizard.servlets.tasks.GarbageCollectionTask)

INFO  [2017-04-23 22:51:15,162] org.eclipse.jetty.server.handler.ContextHandler: Started i.d.j.MutableServletContextHandler@3fdcde7a{/,null,AVAILABLE}
INFO  [2017-04-23 22:51:15,176] org.eclipse.jetty.server.AbstractConnector: Started application@7d57dbb5{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}
INFO  [2017-04-23 22:51:15,177] org.eclipse.jetty.server.AbstractConnector: Started admin@630b6190{HTTP/1.1,[http/1.1]}{0.0.0.0:8081}
INFO  [2017-04-23 22:51:15,177] org.eclipse.jetty.server.Server: Started @1670ms

Ahora tienes tu propia aplicación Dropwizard escuchando en puertos 8080 para solicitudes de aplicación y 8081 para solicitudes de administración.

Ten en cuenta que server configuration.yml se utiliza para iniciar el servidor HTTP y pasar la ubicación del archivo de configuración YAML al servidor.

¡Excelente! Finalmente hemos implementado un microservicio usando el framework Dropwizard. Ahora vamos a tomar un descanso y tomar una taza de té. Hiciste un buen trabajo.

Acceso a los Recursos

Puedes utilizar cualquier cliente HTTP como POSTMAN o cualquier otro. Deberías poder acceder a tu servidor presionando http://localhost:8080/parts. Debes recibir un mensaje indicando que las credenciales son necesarias para acceder al servicio. Para autenticar, agrega el encabezado Authorization con el valor support_test_token. Si se realiza correctamente, deberías ver algo como:

{
 "code": 200,
 "data": []
}

Lo que significa que tu base de datos está vacía. Crea tu primera parte cambiando el método HTTP de GET a POST y suministra esta carga útil:

{
 "name":"My first part",
 "code":"code_of_my_first_part"
}

Todos los demás endpoints funcionan de la misma manera, así que sigue jugando y disfruta.

Cómo Cambiar la Ruta del Contexto

La aplicación Dropwizard, de forma predeterminada, se iniciará y se ejecutará en /. Por ejemplo, si no menciona nada sobre la ruta de contexto de la aplicación de forma predeterminada, se puede acceder a la aplicación desde la URL http://localhost: 8080/. Si deseas configurar tu propia ruta de contexto para tu aplicación, añade las siguientes entradas a tu archivo YAML. ~~~ server: applicationContextPath: /application ~~~

Finiquitando Nuestro Tutorial Dropwizard

Ahora, cuando tengas instalado el servicio REST de Dropwizard, es momento de resumir algunas de las ventajas o desventajas clave de utilizar Dropwizard como framework REST. Es absolutamente obvio, por este post, que Dropwizard ofrece un bootstrap extremadamente rápido de tu proyecto. Y eso es probablemente la mayor ventaja de usar Dropwizard.

Además incluirá todas las bibliotecas/herramientas de vanguardia que necesitarás para desarrollar tu servicio. Así que definitivamente no necesitas preocuparte por eso. También te da una gestión de configuración muy agradable. Por supuesto, Dropwizard tiene algunas desventajas también. Usando Dropwizard estás restringido a usar lo que Dropwizard ofrece o apoya. Pierdes parte de la libertad a la que puedes estar acostumbrado cuando desarrollas. Pero aun así ni siquiera lo llamaría una desventaja ya que esto es exactamente lo que hace que Dropwizard sea lo que es—fácil de configurar, fácil de desarrollar, pero aún un marco REST muy robusto y de alto rendimiento.

En mi opinión, la adición de complejidad al framework mediante el apoyo de más y más bibliotecas de terceras partes también introduciría una complejidad innecesaria en el desarrollo.

UNDERSTANDING THE BASICS

What is the meaning of representational state transfer (REST)?

Representational State Transfer (REST) is a style of architecture (not to be mixed with the set of standards) based on a set of principles that describe how networked resources are defined and addressed.

What is a REST end point?

What is a REST web service?

What is a microservice architecture?

Por: Dusan Simonovic

Articulo vía: Toptal

Mapeo Wireframe: Cómo Evitar El Atraso de los Scope

2017-09-05T18:38:00.000-03:00

Imagina esta situación: Estás trabajando en un nuevo sitio web y en el proceso de creación de los wireframes. En tus reuniones de revisión, recibes comentarios de su cliente y equipo, prefaciando la generación inevitable de solicitudes de cambios, sugerencias de mejoras y actualizaciones. Después de varias reuniones de revisión, te sientes como si estuvieras atrapado en un bucle sin fin, los cambios se están haciendo y revirtiendo, la demanda de tu cliente para más características parece seguir para siempre, y llegar a un acuerdo parece imposible.

O, tal vez, ocurre lo contrario: presentas tus wireframes, todo el mundo asiente con la cabeza de acuerdo, y los wireframes están bien para pasar a la siguiente etapa. Pero, a medida que el trabajo avanza, te das cuenta de que no refleja tu intención-más características están siendo abarrotadas y el flujo se siente.

¿Que pasó? La respuesta es simple: falta de comunicación.

Comunícate más Eficazmente con tus Wireframes

Una de nuestras principales herramientas de comunicación como diseñadores de UX son los wireframes, los “blueprints” en blanco y negro que nos convierten en los arquitectos del diseño web. Aunque los wireframes carecen de los detalles coloridos del diseño visual, son la base para el diseño del producto, del mismo modo que los planos arquitectónicos son la base para la construcción final de un edificio.

Los wireframes son más que un mapa estático. Usando la analogía de una casa, no sólo muestran una habitación, sino más bien toda la casa y todas las diferentes maneras que un usuario puede mover a su alrededor. También incluyen el interior, definiendo el propósito principal de cada habitación.

Además, los wireframes muestran más que sólo habitaciones. Ayudan a planificar los viajes y definir la experiencia que un visitante tendrá en un paseo por la casa. Puedes usar wireframes para muchas cosas, y son muchas cosas que tu equipo y cliente necesitarán entender a medida que un proyecto evoluciona. Parte del trabajo de diseñador de UX es ser traductor, asegurando que todos los involucrados comprendan la visión prevista.

Llevando tus Wireframes al Siguiente Nivel con un Mapa de Wireframes

Entonces, ¿cómo comunicamos el viaje del usuario? ¿Cómo se puede mapear la experiencia del usuario de una manera que sea fácil de leer para que tu equipo y tu cliente pueda visualizarlo? ¿Cómo puedes asegurarte de que el viaje siga siendo sencillo y ofrezca todos los elementos necesarios para cada habitación sin crear barreras frustrantes?

Aquí hay una herramienta útil para comunicar y organizar tus wireframes con mayor eficacia: un mapa wireframe.

Un mapa wireframe es una forma de hacer coincidir tus wireframes con el sitemap de tu sitio web (o con los flujos de usuario de tu producto). Para este proceso de asignación, necesitas plantillas de estructura de wireframes que representen un tipo de página específico (por ejemplo, página de formulario vs. página de destino vs. página de lista de productos vs. página de detalles del producto). Es como decidir el propósito de cada habitación en una casa primero, que luego determina los elementos dentro de cada habitación. Una plantilla sería un cuarto de baño con un inodoro y un fregadero como elementos de contenido común.

La creación de un mapa wireframe le beneficiará de varias maneras:

Ayuda a estimar el alcance del proyecto (¿Cuántas plantillas de wireframe necesito?)
Proporcionar una visión general de todas las plantillas diferentes que deben crearse (que también puede ser valioso como un índice para un estilo, o una simple lista de verificación para identificar plantillas que pueden ser reutilizadas para otras páginas)
Mejorar la comunicación con respecto al objetivo de sus wireframes y ayudar a sus clientes a entender mejor el viaje del usuario

¿Cómo Crear un Mapa de Wireframe?

Hay tres pasos involucrados en la creación de un mapa wireframe.

Paso 1: Identificar Elementos de Contenido

Antes de empezar a bucear en wireframes, es útil pensar en todas las diferentes piezas que necesitan vivir en un wireframe, como los elementos que desea tener en cada habitación para decidir cuán grande debe ser su habitación. Para un sitio de comercio electrónico, los ejemplos pueden ser: barra de búsqueda, filtrado de productos, descripción del producto, imagen del producto, precio, selector de cantidad, botón ‘añadir al carrito’, productos recomendados, icono del carrito de compras … Considerando los componentes de IU necesarios.

Comienza a enumerar todos los elementos de contenido (componentes) en los que puedas pensar: piensa en la funcionalidad que desea ofrecer para ayudar al usuario a avanzar y cumplir con los requisitos del negocio.
Agrega otra columna para el tipo de página (por ejemplo, la página de detalles del producto, el carrito de la compra, la página de destino, etc.) para agrupar los elementos de contenido.
En una tercera columna, clasifica sus artículos de contenido por importancia (es decir, bajo, medio, alto).
Si tienes historias de usuarios, puedes agregar otra columna para referirte a los números de historia relacionados.

Un ejemplo de una lista de elementos de contenido

¿Por qué es útil la clasificación de los elementos de contenido? Tiene dos propósitos principales:

Creación de una jerarquía: El ranking define la jerarquía de contenido de cada página y le da una guía para sus wireframes (qué contenido debe estar en la parte superior).
Evitar el desorden: Priorizar los elementos de contenido ayudará a mantener el enfoque minimalista, así como ayudarte a tomar decisiones con ty equipo sobre qué contenido realmente necesita.

Los elementos de contenido definen el ámbito del trabajo. Tener una lista de elementos de contenido te ayudará a pasar a la fase de planificación más fácilmente y se puede utilizar para definir el proceso y estimar el trabajo de los wireframes. (Por ejemplo, ¿cómo estructuramos nuestros sprints?, ¿qué contenido abordamos primero?)

La lista de contenido también es muy útil durante cualquier discusión con respecto a los requisitos. Puede identificar fácilmente los elementos de contenido que acordó y qué elementos adicionales se solicitan y se consideran una solicitud de cambio.

Paso 2: Definir el Mapa del Sitio y los Flujos de Usuario

Tienes los elementos de contenido que necesitas proporcionar y los agrupas en páginas. Echemos un vistazo a una visión general por ponerlos fuera. ¿Cómo están interconectados? ¿Cómo navega un usuario a través de ellos para lograr sus objetivos?

Llega a este nivel creando un sitemap (para sitios web) o un flujo de usuario (para aplicaciones):

Mapa del sitio: Muestra una visión general de todas las páginas y su jerarquía.
Flujos de usuario: Visualiza cómo se interconectan las páginas para los escenarios clave de casos de uso.

Versión simplificada de un mapa del sitio y del flujo de usuario

Paso 3: Mapea tus Wireframes

Ahora que ya sabes qué contenido debe proporcionar, en qué páginas debe proporcionarlos y cómo están conectados, puedes empezar a trabajar en tus wireframes.

Define las plantillas de página que necesitan wireframes basadas en el mapa del sitio y los flujos de usuario. (Cada página que requiera funcionalidad única va a ser una plantilla diferente).

Plantillas de alambre que representan páginas únicas

Si encuentras variaciones menores para determinadas plantillas (por ejemplo, una página de contenido con un control deslizante en el encabezado o no), trabaja en páginas maestras y omite estas variaciones menores. Tus wireframes deben incluir todos los componentes principales que vivirían en esta plantilla de página maestra.
Ahora traza sus wireframes al mapa del sitio y los flujos de usuario. Puedes actualizar tu sitemap con miniaturas de wireframes para cada tipo de página. La codificación de colores o la numeración mantendrán las cosas en sincronía, ayudarán a dar una mejor visión general y ayudarán a los clientes a entender qué wireframes necesitan.

Un ejemplo de mapa de sitio con código de color

Un ejemplo de un mapa de plantilla wireframe. El mapa del sitio está a la izquierda y los wireframes están a la derecha con los códigos de color correspondientes.

Para sitios muy complejos, un sistema de numeración puede tener sentido frente a la codificación de color

¿Por qué es útil este proceso de mapeo? Es una gran herramienta para usar al crear la visión general de alto nivel de un proyecto. En lugar de simplemente mirar los wireframes autónomos página por página, el mapa wireframe le permitirá a ti y a tu equipo ver los wireframes en su contexto. ¿De dónde vienen los usuarios? ¿A dónde van ahora?

Para volver a la analogía de la casa, es el plano que se crea para visualizar la estructura de la casa, en consecuencia pasar a mirar las primeras representaciones de cada habitación (que son los wireframes para cada plantilla de página), y luego para compartir el resultado final y la visión general.

Llevando el Flujo de Trabajo de Wireframe al Siguiente Nivel

En resumen, aquí es por qué los mapas de wireframe son una comunicación útil y una herramienta de organización:

Ayudarán con la planificación. (¿Qué contenido tenemos y qué wireframes necesitamos?).
Serán útiles como una lista de verificación durante el proceso de creación del proyecto. (¿Qué componentes puedo reutilizar para mantenerme constante?).
Ayudarán con la estimación de costo y tiempo del proyecto, así como para reducir las ineficiencias.
Te ayudarán a rastrear tus tareas (trabajo completado vs. trabajo todavía en el backlog).
Te ayudarán a comunicar mejor el propósito y el objetivo de sus wireframes durante las revisiones (como los wireframes se están utilizando para el proyecto en general).

Un mapa de wireframes es una herramienta útil para estimar el alcance del trabajo al principio de un proyecto, y como una lista de verificación a través de su proceso de trabajo. Ayudará a mejorar el proceso de toma de decisiones de tu equipo, mantendrá a todos en la misma página y periódicamente los reenfocará en la visión general de alto nivel del proyecto. ¡Feliz mapeo!

Por: Frauke Seewald

Articulo Vía: Toptal

Gráficos 3D: Un Tutorial de WebGL

2017-08-28T07:38:00.000-03:00

El mundo de los gráficos 3D puede ser muy intimidante al principio. Ya sea que sólo desee crear un logotipo 3D interactivo o diseñar un juego completo, si no conoces los principios de la representación en 3D, te puedes quedar atrapado en una biblioteca que abstrae un montón de cosas.

Usar una biblioteca puede ser la herramienta adecuada y JavaScript tiene una increíble fuente abierta en forma de three.js. Hay algunas desventajas en el uso de soluciones pre-hechas, aunque:

Pueden tener muchas características que no planeas utilizar. El tamaño de las características base minificadas tres.js es alrededor de 500kB, y cualquier característica adicional (cargar archivos de modelo real es una de ellas) hacen que la carga útil sea aún más grande. Transferir esa cantidad de datos sólo para mostrar un logotipo giratorio en su sitio web sería un desperdicio.
Una capa extra de abstracción puede hacer modificaciones que normalmente son fáciles, difíciles de hacer. Su forma creativa de sombrear un objeto en la pantalla puede ser sencilla de implementar o requerir decenas de horas de trabajo para incorporar en las abstracciones de la biblioteca.
Mientras que la biblioteca se optimiza muy bien en la mayoría de los escenarios, se pueden eliminar adornos extras para tu caso de uso particular. El renderizador puede hacer que ciertos procedimientos se ejecuten millones de veces en la tarjeta gráfica. Cada instrucción eliminada de tal procedimiento significa que una tarjeta gráfica más débil puede manejar tu contenido sin problemas.

Incluso si decides utilizar una biblioteca de gráficos de alto nivel, tener conocimientos básicos de las cosas más escondidas te permite utilizarla con mayor eficacia. Las bibliotecas también pueden tener funciones avanzadas, como ShaderMaterial enthree.js. El conocer los principios de representación gráfica te permite utilizar tales características.

Nuestro objetivo es dar una breve introducción a todos los conceptos clave detrás de la prestación de gráficos 3D y el uso de WebGL para su aplicación. Verás que lo más común que se hace es mostrar y mover objetos 3D en un espacio vacío.

El código final está disponible para que experimentes y juegues con él.

Representando Modelos 3D

Lo primero que tendrías que entender es cómo se representan los modelos 3D. Un modelo está hecho de una malla de triángulos. Cada triángulo está representado por tres vértices para cada una de las esquinas del triángulo. Hay tres propiedades unidas a los vértices que son las más comunes.

Posición del Vértice

La posición es la propiedad más intuitiva de un vértice. Es la posición en el espacio 3D, representada por un vector 3D de coordenadas. Si conoces las coordenadas exactas de tres puntos en el espacio, tendrías toda la información que necesita para dibujar un triángulo simple entre ellos. Para que los modelos parezcan realmente buenos cuando se procesan, hay un par de cosas más que deben proporcionarse al renderizador.

Vértice Normal

Considera los dos modelos anteriores. Consisten en las mismas posiciones del vértice aunque se ven totalmente diferente cuando son representadas. ¿Cómo es eso posible?

Además de decirle al renderer donde queremos que se encuentre un vértice, también podemos darle una pista sobre cómo la superficie está inclinada en esa posición exacta. La pista está en la forma del vector normal de la superficie en ese punto específico del modelo, representado con un vector 3D. La siguiente imagen debe darte un aspecto más descriptivo de cómo se maneja.

Las superficies de la izquierda y derecha corresponden a la bola izquierda y derecha de la imagen anterior, respectivamente. Las flechas rojas representan los vectores normales que se especifican para un vértice, mientras que las flechas azules representan los cálculos del procesador de cómo un vector normal debe buscar todos los puntos entre los vértices. La imagen muestra una demostración para el espacio 2D, pero el mismo principio se aplica en 3D.

El vector normal es un indicio de cómo las luces iluminarán la superficie. Cuanto más cerca está la dirección de un rayo de luz al vector normal, más brillante es el punto. Tener cambios graduales en dirección al vector normal causa gradientes ligeros, mientras que tener cambios abruptos sin cambios entre estos, da como resultado superficies con iluminación constante a través de ellos, al igual que cambios repentinos en la iluminación.

Coordenadas de Textura

La última propiedad significativa son las coordenadas de textura, comúnmente referidas como mapeo UV. Tienes un modelo y una textura que deseas aplicarle. La textura tiene varias áreas y éstas representan las imágenes que queremos aplicar a diferentes partes del modelo. Debe haber una manera de marcar qué triángulo debe representarse con qué parte de la textura. Ahí es donde entra el mapeo de textura.

Para cada vértice, marcamos dos coordenadas, U y V. Estas coordenadas representan una posición en la textura, con U representando el eje horizontal y V el eje vertical. Los valores no están en píxeles sino en una posición porcentual dentro de la imagen. La esquina inferior izquierda de la imagen se representa con dos ceros, mientras que la parte superior derecha se representa con dos unos.

Un triángulo se pinta tomando las coordenadas UV de cada vértice en el triángulo y aplicando la imagen que se captura entre esas coordenadas en la textura.

Puedes ver una demostración de mapeo UV en la imagen de arriba. El modelo esférico fue tomado y cortado en partes que son lo suficientemente pequeñas para ser aplanadas en una superficie 2D. Las costuras donde se realizaron los cortes están marcadas con líneas más gruesas. Uno de los parches ha sido resaltado, así que puedes ver bien cómo las cosas coinciden. También puedes ver cómo una costura a través de la mitad de la sonrisa coloca partes de la boca en dos parches diferentes.

Los wireframes no forman parte de la textura, pero se superponen sobre la imagen para que puedas ver cómo se correlacionan las cosas.

Cargando un modelo OBJ

Lo creas o no, esto es todo lo que necesitas saber para crear tu propio cargador de modelos simple. El formato de archivo OBJ es lo suficientemente simple para implementar un analizador en unas pocas líneas de código.

El archivo enlista las posiciones de los vértices en un formato v <float> <float> <float>, con un cuarto floatopcional, que ignoraremos, para mantener las cosas simples. Los vértices se representan de forma similar con vn <float> <float> <float>. Finalmente, las coordenadas de textura se representan con vt <float> <float>, con un tercer float opcional que seguiremos ignorando. En los tres casos, los float representan las respectivas coordenadas. Estas tres propiedades se acumulan en tres matrices.

Los rostros se representan con grupos de vértices. Cada vértice se representa con el índice de cada una de las propiedades, por lo que los índices comienzan en 1. Hay varias maneras de cómo esto está representado, pero nos adheriremos a la ‘v1/vt1/vn1 v2/vt2/vn2 v3/vt3/vn3`, requiriendo que las tres propiedades sean proporcionadas y limitando a tres el número de vértices por cada cara. Todas estas limitaciones se están haciendo para mantener el cargador tan simple como sea posible, ya que todas las demás opciones requieren algún procesamiento extra trivial antes de que puedan estar en un formato que a WebGL le guste.

Hemos puesto muchos requisitos para nuestro cargador de archivos. Eso puede sonar limitante, pero las aplicaciones de modelado 3D tienden a darle la capacidad de establecer esas limitaciones al exportar un modelo como un archivo OBJ.

El siguiente código analiza una cadena que representa un archivo OBJ y crea un modelo en forma de una matriz de rostros.

function Geometry (faces) {
 this.faces = faces || []
}

// Parses an OBJ file, passed as a string
Geometry.parseOBJ = function (src) {
 var POSITION = /^v\s+([\d\.\+\-eE]+)\s+([\d\.\+\-eE]+)\s+([\d\.\+\-eE]+)/
 var NORMAL = /^vn\s+([\d\.\+\-eE]+)\s+([\d\.\+\-eE]+)\s+([\d\.\+\-eE]+)/
 var UV = /^vt\s+([\d\.\+\-eE]+)\s+([\d\.\+\-eE]+)/
 var FACE = /^f\s+(-?\d+)\/(-?\d+)\/(-?\d+)\s+(-?\d+)\/(-?\d+)\/(-?\d+)\s+(-?\d+)\/(-?\d+)\/(-?\d+)(?:\s+(-?\d+)\/(-?\d+)\/(-?\d+))?/

 lines = src.split('\n')
 var positions = []
 var uvs = []
 var normals = []
 var faces = []
 lines.forEach(function (line) {
   // Match each line of the file against various RegEx-es
   var result
   if ((result = POSITION.exec(line)) != null) {
     // Add new vertex position
     positions.push(new Vector3(parseFloat(result[1]), parseFloat(result[2]), parseFloat(result[3])))
   } else if ((result = NORMAL.exec(line)) != null) {
     // Add new vertex normal
     normals.push(new Vector3(parseFloat(result[1]), parseFloat(result[2]), parseFloat(result[3])))
   } else if ((result = UV.exec(line)) != null) {
     // Add new texture mapping point
     uvs.push(new Vector2(parseFloat(result[1]), 1 - parseFloat(result[2])))
   } else if ((result = FACE.exec(line)) != null) {
     // Add new face
     var vertices = []
     // Create three vertices from the passed one-indexed indices
     for (var i = 1; i < 10; i += 3) {
       var part = result.slice(i, i + 3)
       var position = positions[parseInt(part[0]) - 1]
       var uv = uvs[parseInt(part[1]) - 1]
       var normal = normals[parseInt(part[2]) - 1]
       vertices.push(new Vertex(position, normal, uv))
     }
     faces.push(new Face(vertices))
   }
 })

 return new Geometry(faces)
}

// Loads an OBJ file from the given URL, and returns it as a promise
Geometry.loadOBJ = function (url) {
 return new Promise(function (resolve) {
   var xhr = new XMLHttpRequest()
   xhr.onreadystatechange = function () {
     if (xhr.readyState == XMLHttpRequest.DONE) {
       resolve(Geometry.parseOBJ(xhr.responseText))
     }
   }
   xhr.open('GET', url, true)
   xhr.send(null)
 })
}

function Face (vertices) {
 this.vertices = vertices || []
}

function Vertex (position, normal, uv) {
 this.position = position || new Vector3()
 this.normal = normal || new Vector3()
 this.uv = uv || new Vector2()
}

function Vector3 (x, y, z) {
 this.x = Number(x) || 0
 this.y = Number(y) || 0
 this.z = Number(z) || 0
}

function Vector2 (x, y) {
 this.x = Number(x) || 0
 this.y = Number(y) || 0
}

La estructura Geometry contiene los datos exactos necesarios para enviar un modelo a la tarjeta gráfica para ser procesados. Antes de hacer eso, es probable que quieras tener la capacidad de mover el modelo en la pantalla.

Realización de Transformaciones Espaciales

Todos los puntos en el modelo que cargamos son relativos a su sistema de coordenadas. Si queremos traducir, rotar y escalar el modelo, lo que debemos hacer es realizar esa operación en su sistema de coordenadas. El sistema de coordenadas A, relativo al sistema de coordenadas B, está definido por la posición de su centro como vector p_ab y el vector para cada uno de sus ejes x_ab, y_ab y z_ab, representando la dirección de ese eje. Así que si un punto se mueve por 10 en el eje x del sistema de coordenadas A, entonces — en el sistema de coordenadas B — se moverá en la dirección de x_ab, multiplicado por 10.

Toda esta información se almacena en el siguiente formulario matriz:

x_ab.x  y_ab.x  z_ab.x  p_ab.x
x_ab.y  y_ab.y  z_ab.y  p_ab.y
x_ab.z  y_ab.z  z_ab.z  p_ab.z
    0       0       0       1

Si queremos transformar el vector 3D q, sólo tenemos que multiplicar la matriz de transformación con el vector:

q.x
q.y
q.z
1

Esto hace que el punto se mueva por q.x a lo largo del nuevo eje x, por q.y a lo largo del nuevo eje y, y por q.z a lo largo del nuevo eje z. Finalmente hace que el punto se mueva adicionalmente por el vector p, que es la razón por la que usamos un uno como el elemento final de la multiplicación.

La gran ventaja de utilizar estas matrices es el hecho de que si tenemos múltiples transformaciones a realizar en el vértice, podemos fusionarlas en una transformación, multiplicando sus matrices antes de transformar el vértice mismo.

Hay varias transformaciones que se pueden realizar, y echaremos un vistazo a las principales.

Sin Transformación

Si no ocurre ninguna transformación, entonces el vector p es un vector cero, el vector x es [1, 0, 0], y es [0, 1, 0] y z es [0, 0, 1]. A partir de ahora nos referiremos a estos valores como valores por defecto para estos vectores. La aplicación de estos valores nos da una matriz de identidad:

Éste es un buen punto de partida para encadenar transformaciones.

Traducción

Al momento de realizar la traducción todos los vectores, excepto el vector p, tienen sus valores por defecto. Esto da lugar a la siguiente matriz:

1 0 0 p.x
0 1 0 p.y
0 0 1 p.z
0 0 0   1

Ajuste

Ajustar un modelo significa reducir la cantidad que cada coordenada contribuye a la posición de un punto. No existe un desplazamiento uniforme causado por el ajuste, por lo que el vector p mantiene su valor predeterminado. Los vectores de eje predeterminados deben multiplicarse por sus respectivos factores de escala, lo que da como resultado la siguiente matriz:

s_x   0   0 0
 0 s_y   0 0
 0   0 s_z 0
 0   0   0 1

Aquí s_x, s_y, y s_z representan el ajuste aplicado a cada eje.

Rotación

La imagen anterior muestra lo que sucede cuando giramos el marco de coordenadas alrededor del eje Z.

La rotación no da lugar a un desplazamiento uniforme, por lo que el vector p mantiene su valor por defecto. Ahora las cosas se ponen un poco más complicadas. Las rotaciones causan que el movimiento a lo largo de cierto eje en el sistema de coordenadas original se mueva en una dirección diferente. Por lo tanto, si giramos un sistema de coordenadas 45 grados alrededor del eje Z, moviéndonos a lo largo del eje x del sistema de coordenadas original, se produce un movimiento en una dirección diagonal entre el eje x y el eje y en el nuevo sistema de coordenadas.

Para simplificar las cosas, le mostraremos cómo las matrices de transformación buscan rotaciones alrededor de los ejes principales.

Around X:
       1         0         0 0
       0  cos(phi)  sin(phi) 0
       0 -sin(phi)  cos(phi) 0
       0         0         0 1

Around Y:
cos(phi)         0  sin(phi) 0
       0         1         0 0
-sin(phi)         0  cos(phi) 0
       0         0         0 1

Around Z:
cos(phi) -sin(phi)         0 0
sin(phi)  cos(phi)         0 0
       0         0         1 0
       0         0         0 1

Implementación

Todo esto se puede implementar como una clase que almacena 16 números, almacenando matrices en un orden de columna mayor.

function Transformation () {
 // Create an identity transformation
 this.fields = [1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1]
}

// Multiply matrices, to chain transformations
Transformation.prototype.mult = function (t) {
 var output = new Transformation()
 for (var row = 0; row < 4; ++row) {
   for (var col = 0; col < 4; ++col) {
     var sum = 0
     for (var k = 0; k < 4; ++k) {
       sum += this.fields[k * 4 + row] * t.fields[col * 4 + k]
     }
     output.fields[col * 4 + row] = sum
   }
 }
 return output
}

// Multiply by translation matrix
Transformation.prototype.translate = function (x, y, z) {
 var mat = new Transformation()
 mat.fields[12] = Number(x) || 0
 mat.fields[13] = Number(y) || 0
 mat.fields[14] = Number(z) || 0
 return this.mult(mat)
}

// Multiply by scaling matrix
Transformation.prototype.scale = function (x, y, z) {
 var mat = new Transformation()
 mat.fields[0] = Number(x) || 0
 mat.fields[5] = Number(y) || 0
 mat.fields[10] = Number(z) || 0
 return this.mult(mat)
}

// Multiply by rotation matrix around X axis
Transformation.prototype.rotateX = function (angle) {
 angle = Number(angle) || 0
 var c = Math.cos(angle)
 var s = Math.sin(angle)
 var mat = new Transformation()
 mat.fields[5] = c
 mat.fields[10] = c
 mat.fields[9] = -s
 mat.fields[6] = s
 return this.mult(mat)
}

// Multiply by rotation matrix around Y axis
Transformation.prototype.rotateY = function (angle) {
 angle = Number(angle) || 0
 var c = Math.cos(angle)
 var s = Math.sin(angle)
 var mat = new Transformation()
 mat.fields[0] = c
 mat.fields[10] = c
 mat.fields[2] = -s
 mat.fields[8] = s
 return this.mult(mat)
}

// Multiply by rotation matrix around Z axis
Transformation.prototype.rotateZ = function (angle) {
 angle = Number(angle) || 0
 var c = Math.cos(angle)
 var s = Math.sin(angle)
 var mat = new Transformation()
 mat.fields[0] = c
 mat.fields[5] = c
 mat.fields[4] = -s
 mat.fields[1] = s
 return this.mult(mat)
}

Mira a Través de una Cámara

Aquí viene la parte clave de la presentación de objetos en la pantalla: la cámara. Hay dos componentes clave para una cámara; Su posición, y cómo proyecta objetos observados en la pantalla.

La posición de la cámara se maneja con un simple truco. No hay diferencia visual entre mover la cámara un metro adelante y mover el mundo entero un metro hacia atrás. Así que naturalmente, hacemos esto último aplicando la inversa de la matriz como una transformación.

El segundo componente clave es la forma en que los objetos observados se proyectan sobre el lente. En WebGL, todo lo visible en la pantalla se encuentra en una caja. La caja se extiende entre -1 y 1 en cada eje. Todo lo visible está dentro de esa caja. Podemos utilizar el mismo enfoque de matrices de transformación para crear una matriz de proyección.

Proyección Ortográfica

La proyección más simple es la [proyección ortográfica] (https://www.scratchapixel.com/lessons/3d-basic-rendering/perspective-and-orthographical-projection-matrix/orthographic-projection-matrix). Se toma una caja en el espacio que indica el ancho, la altura y la profundidad con la suposición de que su centro está en la posición cero. A continuación, la proyección redimensiona la caja para que se ajuste a la caja previamente descrita dentro de la cual WebGL observa objetos. Dado que queremos cambiar el tamaño de cada dimensión a dos, ajustamos cada eje a 2/size, donde size es la dimensión del eje respectivo. Una pequeña advertencia es el hecho de que estamos multiplicando el eje Z con un negativo. Esto se hace porque queremos voltear la dirección de esa dimensión. La matriz final tiene esta forma:

2/width        0        0 0
     0 2/height        0 0
     0        0 -2/depth 0
     0        0        0 1

Proyección Perspectiva

No vamos a pasar por los detalles de cómo se diseña esta proyección, pero sólo usa la fórmula final, que es bastante estándar por ahora. Podemos simplificarlo colocando la proyección en la posición cero en los ejes x e y, haciendo los límites derecho/izquierdo y superior/inferior iguales a width/2 y height/2, respectivamente. Los parámetros n y f representan los planos de recorte near y far, que son la distancia más pequeña y más grande que un punto puede ser para poder ser capturado por la cámara. Están representados por los lados paralelos del frustum en la imagen anterior.

Una proyección de perspectiva suele estar representada con un campo de visión (we’ll use the vertical one), relación de aspecto, y las distancias de plano cercano y lejano. Esa información se puede utilizar para calcular width y height, y entonces la matriz se puede crear a partir de la siguiente plantilla:

2*n/width          0           0           0
       0 2*n/height           0           0
       0          0 (f+n)/(n-f) 2*f*n/(n-f)
       0          0          -1           0

Para calcular el ancho y la altura, se pueden usar las siguientes fórmulas:

height = 2 * near * Math.tan(fov * Math.PI / 360)
width = aspectRatio * height

El FOV (campo de visión) representa el ángulo vertical que la cámara captura con su lente. La relación de aspecto representa la relación entre el ancho y la altura de la imagen y se basa en las dimensiones de la pantalla que estamos mostrando.

Implementación

Ahora podemos representar una cámara como una clase, la cual almacena la posición de la cámara y la matriz de proyección. También necesitamos saber cómo calcular las transformaciones inversas. Resolver las inversiones de matriz generales puede ser problemático, pero existe un enfoque simplificado para nuestro caso en especial.

function Camera () {
 this.position = new Transformation()
 this.projection = new Transformation()
}

Camera.prototype.setOrthographic = function (width, height, depth) {
 this.projection = new Transformation()
 this.projection.fields[0] = 2 / width
 this.projection.fields[5] = 2 / height
 this.projection.fields[10] = -2 / depth
}

Camera.prototype.setPerspective = function (verticalFov, aspectRatio, near, far) {
 var height_div_2n = Math.tan(verticalFov * Math.PI / 360)
 var width_div_2n = aspectRatio * height_div_2n
 this.projection = new Transformation()
 this.projection.fields[0] = 1 / height_div_2n
 this.projection.fields[5] = 1 / width_div_2n
 this.projection.fields[10] = (far + near) / (near - far)
 this.projection.fields[10] = -1
 this.projection.fields[14] = 2 * far * near / (near - far)
 this.projection.fields[15] = 0
}

Camera.prototype.getInversePosition = function () {
 var orig = this.position.fields
 var dest = new Transformation()
 var x = orig[12]
 var y = orig[13]
 var z = orig[14]
 // Transpose the rotation matrix
 for (var i = 0; i < 3; ++i) {
   for (var j = 0; j < 3; ++j) {
     dest.fields[i * 4 + j] = orig[i + j * 4]
   }
 }

 // Translation by -p will apply R^T, which is equal to R^-1
 return dest.translate(-x, -y, -z)
}

Esta es la pieza final que necesitamos antes de que podamos empezar a dibujar en la pantalla.

Dibujar un objeto con el canal de Gráficos WebGL

La superficie más simple que puedes dibujar es un triángulo. De hecho, la mayoría de las cosas que dibujas en el espacio 3D consisten en un gran número de triángulos.

Lo primero que debes entender es cómo se representa la pantalla en WebGL. Es un espacio 3D, que abarca entre -1 y 1 en el eje x, y y z. De forma predeterminada, este eje z no se utiliza, pero estás interesado en gráficos 3D, por lo que deberás habilitarlo de inmediato.

Teniendo esto en cuenta, lo que sigue son tres pasos necesarios para dibujar un triángulo sobre esta superficie.

Puedes definir tres vértices que representarían el triángulo que deseas dibujar. Los datos se serializan y se envían a la GPU (unidad de procesamiento gráfico). Con un modelo entero disponible, puedes hacer eso para todos los triángulos en el modelo. Las posiciones de vértice que das están en el espacio de coordenadas local del modelo que cargaste. Puesto de manera más simple, las posiciones que proporcionas son las exactas del archivo y no las que consigues después de realizar transformaciones de la matriz.

Ahora que le has dado los vértices a la GPU, le dices a la GPU qué lógica usar cuando colocas los vértices en la pantalla. Este paso se utilizará para aplicar nuestras transformaciones de matriz. La GPU es muy buena para multiplicar muchas matrices 4x4, por lo que pondremos esa característica a buen uso.

En el último paso, la GPU rasterizará ese triángulo. La rasterización es el proceso de tomar gráficos vectoriales y determinar qué píxeles de la pantalla necesitan ser pintados, para que el objeto gráfico vectorial se muestre. En nuestro caso, la GPU está tratando de determinar qué píxeles se encuentran dentro de cada triángulo. Para cada píxel, la GPU te preguntará de qué color deseas que esté pintado.

Estos son los cuatro elementos necesarios para dibujar lo que quieras y son el ejemplo más simple de un canal de gráficos. Lo que sigue es una mirada a cada uno de ellos y una implementación simple.

El Framebuffer Predeterminado

El elemento más importante para una aplicación WebGL es el contexto WebGL. Puedes acceder a éste con gl = canvas.getContext ('webgl'), o usar ’experimental-webgl' como alternativa, en caso de que el navegador utilizado actualmente no soporte todas las funciones de WebGL. El ‘lienzo’ al que nos referimos es el elemento DOM del lienzo en el que queremos dibujar. El contexto contiene muchas cosas, entre las cuales está el framebuffer predeterminado.

Podría describir un framebuffer como cualquier buffer (objeto) en el que puedas dibujar. De forma predeterminada, el framebuffer predeterminado almacena el color de cada píxel del lienzo al que está vinculado el contexto de WebGL. Como se describe en la sección anterior, cuando dibujamos sobre el framebuffer, cada píxel está situado entre -1 y 1 en el eje x y y. Algo que también mencionamos es el hecho de que, por defecto, WebGL no utiliza el eje z. Esa funcionalidad se puede habilitar al ejecutar gl.enable (gl.DEPTH_TEST). Genial, pero ¿qué es una prueba de profundidad?

Habilitar la prueba de profundidad permite que un píxel almacene tanto el color como la profundidad. La profundidad es la coordenada z de ese píxel. Después de dibujar un píxel a una cierta profundidad z, para actualizar el color de ese píxel debes dibujar en una posición z que esté más cerca de la cámara. De lo contrario, el intento de dibujo será ignorado. Esto permite la ilusión de 3D ya que dibujar objetos que están detrás de otros objetos hará que los objetos sean ocluidos por otros objetos delante de ellos.

Cualquier dibujo que realices permanecerá en la pantalla hasta que les digas que se despejen. Para ello, tienes que llamar a gl.clear (gl.COLOR_BUFFER_BIT | gl.DEPTH_BUFFER_BIT). Esto borra tanto el color como el buffer de profundidad. Para elegir el color al cual se ajustan los píxeles borrados, usa gl.clearColor (rojo, verde, azul, alfa).

Vamos a crear un procesador que utiliza un lienzo y lo borra a petición:

function Renderer (canvas) {
 var gl = canvas.getContext('webgl') || canvas.getContext('experimental-webgl')
 gl.enable(gl.DEPTH_TEST)
 this.gl = gl
}

Renderer.prototype.setClearColor = function (red, green, blue) {
 gl.clearColor(red / 255, green / 255, blue / 255, 1)
}

Renderer.prototype.getContext = function () {
 return this.gl
}

Renderer.prototype.render = function () {
 this.gl.clear(gl.COLOR_BUFFER_BIT | gl.DEPTH_BUFFER_BIT)
}

var renderer = new Renderer(document.getElementById('webgl-canvas'))
renderer.setClearColor(100, 149, 237)

loop()

function loop () {
 renderer.render()
 requestAnimationFrame(loop)
}

Adjuntar esta secuencia de comandos al siguiente HTML dará un rectángulo azul brillante en la pantalla

<!DOCTYPE html>
<html>
<head>
</head>
<body>
   <canvas id="webgl-canvas" width="800" height="500"></canvas>
   <script src="script.js"></script>
</body>
</html>

El llamado requestAnimationFrame hace que el nudo sea llamado nuevamente tan pronto como se haya hecho el renderizado anterior y se haya terminado todo el manejo del evento.

Objetos de Vértices Buffer

Lo primero que debes hacer es definir los vértices que deseas dibujar. Puedes hacer esto describiéndolos a través de vectores en el espacio 3D. Después de eso, debes mover esos datos a la memoria RAM de la GPU, creando un nuevo Buffer Vertex Buffer (VBO).

Un Objeto Buffer en general es un objeto que almacena una matriz de fragmentos de memoria en la GPU. Al ser un VBO, éste sólo denota para lo que la GPU puede utilizar la memoria. La mayoría de las veces, los objetos de buffer que crees serán VBOs.

Puedes llenar el VBO tomando todos los vértices N que tenemos y creando una matriz de floats con elementos 3N para la posición de vértice y VBOs normales de vértice, y 2N para las coordenadas de textura VBO. Cada grupo de tres floats, o dos floats para coordenadas UV, representa coordenadas individuales de un vértice. Luego pasamos estas matrices a la GPU, y nuestros vértices están listos para el resto del canal.

Dado que la data está ahora en la RAM de la GPU, puedes eliminarla de la memoria RAM de uso general. Es decir, a menos que desees modificarla más tarde y volver a cargarla. Cada modificación debe ser seguida por una subida ya que las modificaciones en nuestras matrices JS no se aplican a VBOs en la memoria RAM real de la GPU.

A continuación se muestra un ejemplo de código, el cual proporciona toda la funcionalidad descrita. Una nota importante es el hecho de que las variables almacenadas en la GPU no son recolectadas de la basura. Eso significa que tenemos que eliminarlas manualmente, una vez que no queremos usarlas más. Sólo te daremos un ejemplo de cómo se hace aquí y no nos centrará más en ese concepto. La supresión de variables de la GPU sólo es necesaria si piensa dejar de usar cierta geometría en todo el programa.

También añadimos serialización a nuestra clase Geometry y elementos dentro de ella.

Geometry.prototype.vertexCount = function () {
 return this.faces.length * 3
}

Geometry.prototype.positions = function () {
 var answer = []
 this.faces.forEach(function (face) {
   face.vertices.forEach(function (vertex) {
     var v = vertex.position
     answer.push(v.x, v.y, v.z)
   })
 })
 return answer
}

Geometry.prototype.normals = function () {
 var answer = []
 this.faces.forEach(function (face) {
   face.vertices.forEach(function (vertex) {
     var v = vertex.normal
     answer.push(v.x, v.y, v.z)
   })
 })
 return answer
}

Geometry.prototype.uvs = function () {
 var answer = []
 this.faces.forEach(function (face) {
   face.vertices.forEach(function (vertex) {
     var v = vertex.uv
     answer.push(v.x, v.y)
   })
 })
 return answer
}

////////////////////////////////

function VBO (gl, data, count) {
 // Creates buffer object in GPU RAM where we can store anything
 var bufferObject = gl.createBuffer()
 // Tell which buffer object we want to operate on as a VBO
 gl.bindBuffer(gl.ARRAY_BUFFER, bufferObject)
 // Write the data, and set the flag to optimize
 // for rare changes to the data we're writing
 gl.bufferData(gl.ARRAY_BUFFER, new Float32Array(data), gl.STATIC_DRAW)
 this.gl = gl
 this.size = data.length / count
 this.count = count
 this.data = bufferObject
}

VBO.prototype.destroy = function () {
 // Free memory that is occupied by our buffer object
 this.gl.deleteBuffer(this.data)
}

El tipo de datos VBO genera el VBO en el contexto WebGL pasado, basado en la matriz pasada como segundo parámetro.

Puedes ver tres llamadas al contexto gl. La llamada createBuffer () crea el buffer. La llamada bindBuffer () indica a la máquina de estado WebGL que utilice esta memoria específica como la actual VBO (ARRAY_BUFFER) para todas las operaciones futuras, hasta que se indique lo contrario. Después de eso, establecemos el valor de la VBO actual a los datos proporcionados, con bufferData ().

También proporcionamos un método de destrucción que elimina nuestro objeto de memoria intermedia de la GPU RAM, usando deleteBuffer().

Puedes utilizar tres VBOs y una transformación para describir todas las propiedades de una malla, junto a su posición.

function Mesh (gl, geometry) {
 var vertexCount = geometry.vertexCount()
 this.positions = new VBO(gl, geometry.positions(), vertexCount)
 this.normals = new VBO(gl, geometry.normals(), vertexCount)
 this.uvs = new VBO(gl, geometry.uvs(), vertexCount)
 this.vertexCount = vertexCount
 this.position = new Transformation()
 this.gl = gl
}

Mesh.prototype.destroy = function () {
 this.positions.destroy()
 this.normals.destroy()
 this.uvs.destroy()
}

Como ejemplo, aquí se ve cómo podemos cargar un modelo, almacenar sus propiedades en la malla (mesh) y luego destruirlo:

Geometry.loadOBJ('/assets/model.obj').then(function (geometry) {
 var mesh = new Mesh(gl, geometry)
 console.log(mesh)
 mesh.destroy()
})

Shaders

Lo que sigue es el proceso de dos pasos previamente descrito, que se trata de mover puntos en las posiciones deseadas y pintar todos los píxeles individuales. Para ello, escribimos un programa que se ejecuta en la tarjeta gráfica muchas veces. Este programa normalmente consta de al menos dos partes. La primera parte es un Shader de Vértices, que se ejecuta para cada vértice, y las salidas donde debemos colocar el vértice en la pantalla, entre otras cosas. La segunda parte es el Fragmento de Shader, que se ejecuta para cada píxel que cubre un triángulo en la pantalla, y produce el color en el cual el píxel debe ser pintado.

Shaders de Vértices

Digamos que quieres tener un modelo que se mueve de izquierda y derecha en la pantalla. En un enfoque ingenuo, puedes actualizar la posición de cada vértice y volver a enviarlo a la GPU. Ese proceso es costoso y lento. Alternativamente, darías un programa para que la GPU se ejecute para cada vértice y hacer todas esas operaciones en paralelo con un procesador que está construido para hacer exactamente ese trabajo. Ése es el papel de un shader de vértices.

Un shader de vértices es la parte de la canalización de procesamiento que procesa vértices individuales. Una llamada al shader de vértices recibe un único vértice y genera un único vértice después de aplicar todas las transformaciones posibles al vértice.

Shaders están escritos en GLSL. Hay muchos elementos únicos en este lenguaje, pero la mayoría de la sintaxis es muy similar a C, por lo que debe ser comprensible para la mayoría de las personas.

Hay tres tipos de variables que entran y salen de un shader de vértices, y todas ellas sirven a un uso específico:

atributo — Estas son entradas que contienen propiedades específicas de un vértice. Anteriormente describimos la posición de un vértice como un atributo en forma de un vector de tres elementos. Puedes ver a los atributos como valores que describen un vértice.
uniforme — Estas son entradas que son las mismas para cada vértice dentro de la misma llamada de renderizado. Digamos que queremos mover nuestro modelo, definiendo una matriz de transformación. Puedes usar una variable uniforme para describir eso. También puedes usar recursos de la GPU, como texturas. Puedes ver estos uniformes como valores que describen un modelo o una parte de un modelo.
variaciones — Estas son las salidas que pasamos al fragmento de shader. Puesto que hay potencialmente miles de píxeles para un triángulo de vértices, cada píxel recibirá un valor interpolado para esta variable, dependiendo de la posición. Así que si un vértice envía 500 como una salida, y en otro 100, un píxel que está en el medio de estos recibirá 300 como entrada para esa variable. Puedes ver las variaciones como valores que describen superficies entre vértices.

Por lo tanto, digamos que deseas crear un shader de vértices que reciba una posición normal y coordenadas uv para cada vértice, y una posición vista (posición de cámara inversa) y una matriz de proyección para cada objeto representado. Digamos que también quieres pintar píxeles individuales basados en sus coordenadas uv y sus normales. Te preguntarás “¿Cómo se vería ese código?”.

attribute vec3 position;
attribute vec3 normal;
attribute vec2 uv;
uniform mat4 model;
uniform mat4 view;
uniform mat4 projection;
varying vec3 vNormal;
varying vec2 vUv;

void main() {
   vUv = uv;
   vNormal = (model * vec4(normal, 0.)).xyz;
   gl_Position = projection * view * model * vec4(position, 1.);
}

La mayoría de estos elementos deben ser auto-explicativos. Lo más importante es notar que no hay valores de retorno en la función main. Todos los valores que quisiéramos retornar se asignan, ya sea a variables variantes o a variables especiales. Aquí asignamos a gl_Position, que es un vector de cuatro dimensiones, por lo que la última dimensión siempre debe estar en uno. Otra cosa extraña que podrías notar es la forma en que construimos un vec4 fuera del vector de posición. Puedes construir un vec4 usando cuatro floats, dos vec2s, o cualquier otra combinación que resulte en cuatro elementos. Hay un muchos tipos de castings, aparentemente, extraños que tienen sentido una vez que estés familiarizado con las matrices de transformación.

También puedes ver que aquí podemos realizar transformaciones de matriz fácilmente. GLSL está específicamente diseñado para este tipo de trabajo. La posición de salida se calcula multiplicando la proyección, la vista y la matriz del modelo y aplicándola a la posición. La salida normal se acaba de transformar en el espacio mundial. Más adelante explicaremos por qué nos hemos detenido allí con las transformaciones normales.

Por ahora, lo mantendremos sencillo y pasaremos a pintar píxeles individuales.

Fragmento de Shaders

Un fragmento shader es el paso después de la rasterización en el canal de gráficos. Genera color, profundidad y otros datos para cada píxel del objeto que se está pintando

Los principios detrás de la implementación de shaders de fragmentos son muy similares a los shaders de vértices. Sin embargo, hay tres grandes diferencias:

No hay más salidas variables, y las entradas atributos han sido reemplazadas con entradas `variadas’. Acabamos de pasar a nuestro canal, y las cosas que son la salida en el shader vértice son ahora entradas en el fragmento de shader.
Nuestra única salida ahora es gl_FragColor, que es un vec4. Los elementos representan rojo, verde, azul y alfa (RGBA), respectivamente, con variables en el rango de 0 a 1. Debes mantener alfa en 1, a menos que estés haciendo la transparencia. Sin embargo, la transparencia es un concepto bastante avanzado, por lo que nos atenemos a los objetos opacos.
Al principio del fragmento de shader, es necesario establecer la precisión del flotador, que es importante para las interpolaciones. En casi todos los casos, sólo se adhieren a las líneas del siguiente shader.

Con esto en mente, puedes escribir fácilmente un shader que pinta el canal rojo basado en la posición U, canal verde basado en la posición V, y fija el canal azul al máximo.

#ifdef GL_ES
precision highp float;
#endif

varying vec3 vNormal;
varying vec2 vUv;

void main() {
   vec2 clampedUv = clamp(vUv, 0., 1.);
   gl_FragColor = vec4(clampedUv, 1., 1.);
}

La función clamp sólo limita todos los floats en un objeto para estar dentro de los límites dados. El resto del código debe ser bastante sencillo.

Con todo esto en mente, lo que queda por hacer es implementar esto en WebGL.

Combinación de Shaders en un Programa

El siguiente paso es combinar los shaders en un programa:

function ShaderProgram (gl, vertSrc, fragSrc) {
 var vert = gl.createShader(gl.VERTEX_SHADER)
 gl.shaderSource(vert, vertSrc)
 gl.compileShader(vert)
 if (!gl.getShaderParameter(vert, gl.COMPILE_STATUS)) {
   console.error(gl.getShaderInfoLog(vert))
   throw new Error('Failed to compile shader')
 }

 var frag = gl.createShader(gl.FRAGMENT_SHADER)
 gl.shaderSource(frag, fragSrc)
 gl.compileShader(frag)
 if (!gl.getShaderParameter(frag, gl.COMPILE_STATUS)) {
   console.error(gl.getShaderInfoLog(frag))
   throw new Error('Failed to compile shader')
 }

 var program = gl.createProgram()
 gl.attachShader(program, vert)
 gl.attachShader(program, frag)
 gl.linkProgram(program)
 if (!gl.getProgramParameter(program, gl.LINK_STATUS)) {
   console.error(gl.getProgramInfoLog(program))
   throw new Error('Failed to link program')
 }

 this.gl = gl
 this.position = gl.getAttribLocation(program, 'position')
 this.normal = gl.getAttribLocation(program, 'normal')
 this.uv = gl.getAttribLocation(program, 'uv')
 this.model = gl.getUniformLocation(program, 'model')
 this.view = gl.getUniformLocation(program, 'view')
 this.projection = gl.getUniformLocation(program, 'projection')
 this.vert = vert
 this.frag = frag
 this.program = program
}

// Loads shader files from the given URLs, and returns a program as a promise
ShaderProgram.load = function (gl, vertUrl, fragUrl) {
 return Promise.all([loadFile(vertUrl), loadFile(fragUrl)]).then(function (files) {
   return new ShaderProgram(gl, files[0], files[1])
 })

 function loadFile (url) {
   return new Promise(function (resolve) {
     var xhr = new XMLHttpRequest()
     xhr.onreadystatechange = function () {
       if (xhr.readyState == XMLHttpRequest.DONE) {
         resolve(xhr.responseText)
       }
     }
     xhr.open('GET', url, true)
     xhr.send(null)
   })
 }
}

No hay mucho que decir sobre lo que está sucediendo aquí. A cada shader se le asigna una cadena como fuente y se compila, después de lo cual verificamos si hay errores de compilación. Entonces, creamos un programa enlazando estos dos shaders. Finalmente, almacenamos punteros para todos los atributos y uniformes relevantes para la posteridad.

Realmente dibujando el modelo

Por último, pero no menos importante, dibuja el modelo.

Primero escoge el programa de shader que deseas usar

ShaderProgram.prototype.use = function () {
 this.gl.useProgram(this.program)
}

A continuación, envía todos los uniformes relacionados con la cámara a la GPU. Estos uniformes cambian sólo una vez por cada cambio de cámara o movimiento.

Transformation.prototype.sendToGpu = function (gl, uniform, transpose) {
 gl.uniformMatrix4fv(uniform, transpose || false, new Float32Array(this.fields))
}

Camera.prototype.use = function (shaderProgram) {
 this.projection.sendToGpu(shaderProgram.gl, shaderProgram.projection)
 this.getInversePosition().sendToGpu(shaderProgram.gl, shaderProgram.view)
}

Por último, se toman las transformaciones y VBOs y se asignan a uniformes y atributos, respectivamente. Dado que esto tiene que hacerse a cada VBO, puede crear su vinculación de datos como un método.

VBO.prototype.bindToAttribute = function (attribute) {
 var gl = this.gl
 // Tell which buffer object we want to operate on as a VBO
 gl.bindBuffer(gl.ARRAY_BUFFER, this.data)
 // Enable this attribute in the shader
 gl.enableVertexAttribArray(attribute)
 // Define format of the attribute array. Must match parameters in shader
 gl.vertexAttribPointer(attribute, this.size, gl.FLOAT, false, 0, 0)
}

A continuación, se asigna una matriz de tres floats para el uniforme. Cada tipo de uniforme tiene una firma diferente, por lo que la documentación y más documentación son tus amigos aquí. Finalmente, dibuja la matriz triangular en la pantalla. Le dice a la llamada de dibujo [drawArrays ()] (https://developer.mozilla.org/en-US/docs/Web/API/WebGLRenderingContext/drawArrays) desde que vértice puede iniciar, y cuántos vértices dibujar. El primer parámetro pasado le dice a WebGL cómo interpretará la matriz de vértices. El uso de TRIÁNGULOS toma tres por tres vértices y dibuja un triángulo para cada triplete. Usar PUNTOS sólo dibujaría un punto para cada vértice pasado. Hay muchas más opciones, pero no hay necesidad de descubrir todo al mismo tiempo. A continuación se muestra el código para dibujar un objeto:

Mesh.prototype.draw = function (shaderProgram) {
 this.positions.bindToAttribute(shaderProgram.position)
 this.normals.bindToAttribute(shaderProgram.normal)
 this.uvs.bindToAttribute(shaderProgram.uv)
 this.position.sendToGpu(this.gl, shaderProgram.model)
 this.gl.drawArrays(this.gl.TRIANGLES, 0, this.vertexCount)
}

El renderizador necesita ser extendido un poco, para acomodar todos los elementos adicionales que necesitan ser manejados. Debe ser posible adjuntar un programa de shader y renderizar una matriz de objetos basada en la posición actual de la cámara.

Renderer.prototype.setShader = function (shader) {
 this.shader = shader
}

Renderer.prototype.render = function (camera, objects) {
 this.gl.clear(gl.COLOR_BUFFER_BIT | gl.DEPTH_BUFFER_BIT)
 var shader = this.shader
 if (!shader) {
   return
 }
 shader.use()
 camera.use(shader)
 objects.forEach(function (mesh) {
   mesh.draw(shader)
 })
}

Podemos combinar todos los elementos que tenemos para finalmente dibujar algo en la pantalla:

var renderer = new Renderer(document.getElementById('webgl-canvas'))
renderer.setClearColor(100, 149, 237)
var gl = renderer.getContext()

var objects = []

Geometry.loadOBJ('/assets/sphere.obj').then(function (data) {
 objects.push(new Mesh(gl, data))
})
ShaderProgram.load(gl, '/shaders/basic.vert', '/shaders/basic.frag')
            .then(function (shader) {
              renderer.setShader(shader)
            })

var camera = new Camera()
camera.setOrthographic(16, 10, 10)

loop()

function loop () {
 renderer.render(camera, objects)
 requestAnimationFrame(loop)
}

Esto parece un poco aleatorio, pero se puede ver los diferentes parches de la esfera, en función de dónde están en el mapa UV. Puedes cambiar el shader para pintar el objeto marrón. Simplemente establece el color para cada píxel para que sea el RGBA para marrón:

#ifdef GL_ES
precision highp float;
#endif

varying vec3 vNormal;
varying vec2 vUv;

void main() {
   vec3 brown = vec3(.54, .27, .07);
   gl_FragColor = vec4(brown, 1.);
}

No parece muy convincente. Parece que la escena necesita algunos efectos de sombreado.

Añadiendo luz

Las luces y las sombras son las herramientas que nos permiten percibir la forma de los objetos. Las luces vienen en muchas formas y tamaños: focos que brillan en un cono, bombillas que difunden luz en todas direcciones, y lo más interesante, el sol, que está tan lejos que toda la luz que brilla sobre nosotros irradia, para todos los intentos y en la misma dirección.

La luz solar suena como si fuera la más sencilla de implementar ya que todo lo que necesita proporcionar es la dirección en la que se propagan todos los rayos. Para cada píxel que dibujes en la pantalla, comprueba el ángulo bajo el cual la luz golpea el objeto. Aquí es donde entran las normales de superficie.

Puedes ver todos los rayos de luz que fluyen en la misma dirección y golpear la superficie bajo diferentes ángulos, los cuales se basan en el ángulo entre el rayo de luz y la normal de superficie. Cuanto más coinciden, más fuerte es la luz.

Si realizas un producto de punto entre los vectores normalizados para el rayo de luz y la normal de superficie, obtendrás -1 si el rayo golpea la superficie perfectamente perpendicular, 0 si el rayo es paralelo a la superficie y 1 si lo ilumina desde el lado opuesto. Así que cualquier cosa entre 0 y 1 no debe agregar luz, mientras que los números entre 0 y -1 deben aumentar gradualmente la cantidad de luz que golpea el objeto. Puedes probar esto agregando una luz fija en el código shader.

#ifdef GL_ES
precision highp float;
#endif

varying vec3 vNormal;
varying vec2 vUv;

void main() {
   vec3 brown = vec3(.54, .27, .07);
   vec3 sunlightDirection = vec3(-1., -1., -1.);
   float lightness = -clamp(dot(normalize(vNormal), normalize(sunlightDirection)), -1., 0.);
   gl_FragColor = vec4(brown * lightness, 1.);
}

Pusimos el sol para que brille en la dirección hacia delante-izquierda-abajo. Puedes ver que tan suave es el shader, aunque el modelo es muy irregular. También se puede notar la oscuridad de la parte inferior izquierda. Podemos añadir un nivel de luz ambiente, lo que hará más brillante el área en la sombra.

#ifdef GL_ES
precision highp float;
#endif

varying vec3 vNormal;
varying vec2 vUv;

void main() {
   vec3 brown = vec3(.54, .27, .07);
   vec3 sunlightDirection = vec3(-1., -1., -1.);
   float lightness = -clamp(dot(normalize(vNormal), normalize(sunlightDirection)), -1., 0.);
   float ambientLight = 0.3;
   lightness = ambientLight + (1. - ambientLight) * lightness;
   gl_FragColor = vec4(brown * lightness, 1.);
}

Puedes lograr este mismo efecto introduciendo una clase de luz que almacena la dirección de la luz y la intensidad de la luz ambiental. A continuación, puedes cambiar el fragmento de shader para acomodar esa adición.

Ahora el shader se convierte en:

#ifdef GL_ES
precision highp float;
#endif

uniform vec3 lightDirection;
uniform float ambientLight;
varying vec3 vNormal;
varying vec2 vUv;

void main() {
   vec3 brown = vec3(.54, .27, .07);
   float lightness = -clamp(dot(normalize(vNormal), normalize(lightDirection)), -1., 0.);
   lightness = ambientLight + (1. - ambientLight) * lightness;
   gl_FragColor = vec4(brown * lightness, 1.);
}

Ahora puedes definir la luz:

function Light () {
 this.lightDirection = new Vector3(-1, -1, -1)
 this.ambientLight = 0.3
}

Light.prototype.use = function (shaderProgram) {
 var dir = this.lightDirection
 var gl = shaderProgram.gl
 gl.uniform3f(shaderProgram.lightDirection, dir.x, dir.y, dir.z)
 gl.uniform1f(shaderProgram.ambientLight, this.ambientLight)
}

En la clase del programa shader, agrega los uniformes necesarios:

this.ambientLight = gl.getUniformLocation(program, 'ambientLight')
this.lightDirection = gl.getUniformLocation(program, 'lightDirection')

En el programa, agrega una llamada a la nueva luz en el renderizador:

Renderer.prototype.render = function (camera, light, objects) {
 this.gl.clear(gl.COLOR_BUFFER_BIT | gl.DEPTH_BUFFER_BIT)
 var shader = this.shader
 if (!shader) {
   return
 }
 shader.use()
 light.use(shader)
 camera.use(shader)
 objects.forEach(function (mesh) {
   mesh.draw(shader)
 })
}

El nudo cambiará un poco:

var light = new Light()

loop()

function loop () {
 renderer.render(camera, light, objects)
 requestAnimationFrame(loop)
}

Si has hecho todo bien, entonces la imagen renderizada debe ser la misma que en la última imagen.

Un último paso a considerar sería añadir una textura real a nuestro modelo. Vamos a hacer eso ahora.

Añadiendo texturas

HTML5 tiene un gran soporte para cargar imágenes, por lo que no hay necesidad de hacer el análisis de imagen muy intenso. Las imágenes se pasan a GLSL como sampler2D diciéndole al shader cuál de las texturas enlazadas debe muestrear. Hay un número limitado de texturas que uno podría vincular y el límite se basa en el hardware utilizado. Un sampler2D puede ser consultado para los colores en ciertas posiciones. Aquí es donde entran las coordenadas UV. Aquí hay un ejemplo en el que reemplazamos el marrón con colores muestreados.

#ifdef GL_ES
precision highp float;
#endif

uniform vec3 lightDirection;
uniform float ambientLight;
uniform sampler2D diffuse;
varying vec3 vNormal;
varying vec2 vUv;

void main() {
   float lightness = -clamp(dot(normalize(vNormal), normalize(lightDirection)), -1., 0.);
   lightness = ambientLight + (1. - ambientLight) * lightness;
   gl_FragColor = vec4(texture2D(diffuse, vUv).rgb * lightness, 1.);
}

El nuevo uniforme tiene que ser agregado al listado en el programa del shader:

this.diffuse = gl.getUniformLocation(program, 'diffuse')

Finalmente, implementaremos la carga de la textura. Como se dijo anteriormente, HTML5 proporciona facilidades para cargar imágenes. Todo lo que necesitamos hacer es enviar la imagen a la GPU:

function Texture (gl, image) {
 var texture = gl.createTexture()
 // Set the newly created texture context as active texture
 gl.bindTexture(gl.TEXTURE_2D, texture)
 // Set texture parameters, and pass the image that the texture is based on
 gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, gl.RGBA, gl.UNSIGNED_BYTE, image)
 // Set filtering methods
 // Very often shaders will query the texture value between pixels,
 // and this is instructing how that value shall be calculated
 gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_MAG_FILTER, gl.LINEAR)
 gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_MIN_FILTER, gl.LINEAR)
 this.data = texture
 this.gl = gl
}

Texture.prototype.use = function (uniform, binding) {
 binding = Number(binding) || 0
 var gl = this.gl
 // We can bind multiple textures, and here we pick which of the bindings
 // we're setting right now
 gl.activeTexture(gl['TEXTURE' + binding])
 // After picking the binding, we set the texture
 gl.bindTexture(gl.TEXTURE_2D, this.data)
 // Finally, we pass to the uniform the binding ID we've used
 gl.uniform1i(uniform, binding)
 // The previous 3 lines are equivalent to:
 // texture[i] = this.data
 // uniform = i
}

Texture.load = function (gl, url) {
 return new Promise(function (resolve) {
   var image = new Image()
   image.onload = function () {
     resolve(new Texture(gl, image))
   }
   image.src = url
 })
}

El proceso no es muy diferente al proceso usado para cargar y enlazar VBOs. La principal diferencia es que ya no estamos vinculados a un atributo, sino que unimos el índice de la textura a un uniforme entero. El tipo sampler2D no es más que un puntero desplazado a una textura.

Ahora todo lo que hay que hacer es ampliar la clase Mesh para manejar texturas también:

function Mesh (gl, geometry, texture) { // added texture
 var vertexCount = geometry.vertexCount()
 this.positions = new VBO(gl, geometry.positions(), vertexCount)
 this.normals = new VBO(gl, geometry.normals(), vertexCount)
 this.uvs = new VBO(gl, geometry.uvs(), vertexCount)
 this.texture = texture // new
 this.vertexCount = vertexCount
 this.position = new Transformation()
 this.gl = gl
}

Mesh.prototype.destroy = function () {
 this.positions.destroy()
 this.normals.destroy()
 this.uvs.destroy()
}

Mesh.prototype.draw = function (shaderProgram) {
 this.positions.bindToAttribute(shaderProgram.position)
 this.normals.bindToAttribute(shaderProgram.normal)
 this.uvs.bindToAttribute(shaderProgram.uv)
 this.position.sendToGpu(this.gl, shaderProgram.model)
 this.texture.use(shaderProgram.diffuse, 0) // new
 this.gl.drawArrays(this.gl.TRIANGLES, 0, this.vertexCount)
}

Mesh.load = function (gl, modelUrl, textureUrl) { // new
 var geometry = Geometry.loadOBJ(modelUrl)
 var texture = Texture.load(gl, textureUrl)
 return Promise.all([geometry, texture]).then(function (params) {
   return new Mesh(gl, params[0], params[1])
 })
}

Y el guión final principal se vería de la siguiente manera:

var renderer = new Renderer(document.getElementById('webgl-canvas'))
renderer.setClearColor(100, 149, 237)
var gl = renderer.getContext()

var objects = []

Mesh.load(gl, '/assets/sphere.obj', '/assets/diffuse.png')
   .then(function (mesh) {
     objects.push(mesh)
   })

ShaderProgram.load(gl, '/shaders/basic.vert', '/shaders/basic.frag')
            .then(function (shader) {
              renderer.setShader(shader)
            })

var camera = new Camera()
camera.setOrthographic(16, 10, 10)
var light = new Light()

loop()

function loop () {
 renderer.render(camera, light, objects)
 requestAnimationFrame(loop)
}

Incluso animar puede ser fácil en este punto. Si quisieras que la cámara girara alrededor de nuestro objeto, puedes hacerlo con sólo agregando una línea de código:

function loop () {
 renderer.render(camera, light, objects)
 camera.position = camera.position.rotateY(Math.PI / 120)
 requestAnimationFrame(loop)
}

Tienes libertad de jugar con shaders. Agregar una línea de código convertirá esta iluminación realista en algo caricaturesco.

void main() {
   float lightness = -clamp(dot(normalize(vNormal), normalize(lightDirection)), -1., 0.);
   lightness = lightness > 0.1 ? 1. : 0.; // new
   lightness = ambientLight + (1. - ambientLight) * lightness;
   gl_FragColor = vec4(texture2D(diffuse, vUv).rgb * lightness, 1.);
}

Es tan simple como decirle a la iluminación que vaya a sus extremos, basándose en si cruzó un umbral establecido.

A Dónde ir Después

Hay muchas fuentes de información para aprender todos los trucos y complejidades de WebGL. Y la mejor parte es que si no puedes encontrar una respuesta relacionada con WebGL, puedes buscarla en OpenGL, ya que WebGL se basa en un subconjunto de OpenGL con algunos nombres cambiados.

En ningún orden en particular, aquí hay algunas fuentes excelentes para obtener información más detallada, tanto para WebGL como para OpenGL.

Fundamentos de WebGL
WebGL de aprendizaje
Un tutorial muy detallado OpenGL tutorial, te guiará a través de todos los principios fundamentales descritos aquí, de una manera muy lenta y detallada.
Y hay muchos, muchos otros sitios dedicados a enseñarte los principios de la computación gráfica.
Documentación de MDN para WebGL
Especificación de Khronos WebGL 1.0 si estás interesado en comprender los detalles más técnicos de cómo debería funcionar la API WebGL en todos los casos.

UNDERSTANDING THE BASICS

What is WebGL?

WebGL is a JavaScript API that adds native support for rendering 3D graphics within compatible web browsers, through an API similar to OpenGL.

How are 3D models represented in memory?

What is a vertex shader?

What is a fragment shader?

How do objects move in a 3D scene?

Por: Adnan Ademovic

Artículo vía: Toptal

Diseñando Para La Conducta Humana: Definiendo Lo Intangible

2017-08-23T06:30:00.000-03:00

Utilizando analítica de comportamiento y ciencia de datos para dar forma a la experiencia del usuario:

Diseñar una experiencia empática requiere inmersión total en las vidas de tu público objetivo. Como implica el precepto del profesional de UX “caminar una milla en los zapatos de tu cliente” supone entrevistas, personajes, casos de uso, flujos de usuarios, mapas de viaje, grupos de enfoque, etc. que están involucrados en un intento educado de involucrar con precisión a las personas que más desean influir .

Pero, ¿qué pasa con los tipos de personalidad individuales? ¿Qué es lo que realmente motiva a una persona? ¿Qué valoran realmente? ¿Qué factores están jugando en su vida que pueden afectar o influir en su capacidad de participar en una experiencia? Estos son todos intangibles que a menudo no tenemos una forma sustantiva de cuantificar.

La ciencia de datos y análisis de datos nos pueden decir mucho sobre los hábitos en línea de una persona. Interpretar que los datos nos pueden dar una idea de sus vidas. Pero, ¿qué pasa con lo que sucede fuera del mundo en línea y dentro de sus cabezas? Aquí es donde la ciencia del comportamiento puede ayudar.

La ciencia del comportamiento es el estudio del comportamiento humano y la toma de decisiones. Implica la observación directa e indirecta de las personas mediante un enfoque cualitativo y cuantitativo. Mediante este método, puedes observar tipos de comportamiento específicos durante el proceso de diseño de producto.

Distinguir los arquetipos ayuda a clasificar a las personas en grupos más grandes. El valor de esta ciencia, sin embargo, se puede encontrar mejor en situaciones en las que una persona se desvía de su norma arquetípica. Cuando las personas se apartan de los típicos patrones de toma de decisiones, podemos implementar codazos y otros motivadores para impactar positivamente en su comportamiento y devolverlos a la experiencia. Esta práctica tiene un gran valor, especialmente en la asistencia sanitaria, donde el comportamiento del paciente es importante para mantener la salud y el bienestar.

Veamos un modelo básico para determinar el tipo de personalidad de una persona.

Arquetipos

Los arquetipos se basan en gran medida en los patrones de comportamiento del usuario o del grupo de usuarios. Se definen mediante el estudio de patrones de acción durante una experiencia: cómo y por qué la gente compra algo — y por qué, y por lo que están motivados a tomar medidas. Sumergiéndose en su comportamiento, ves y experimentas cosas desde su punto de vista. Esto resulta en una estrategia de diseño más precisa en el futuro. También ayuda a marcar con mayor precisión y medir los análisis que se utilizarán más tarde para iterar en la solución de diseño.

Arquetipos (por Mateusz Grzesiak)

¿Por qué deberías preocuparte por los arquetipos? Al entender el arquetipo de una persona, puedes “estar en su lugar” más fácilmente. Inmersiéndote en el proceso de aprender para quién estás diseñando provee la invaluable información y autentifica tu comprensión de sus preocupaciones y desafíos. La claridad obtenida al hacer esto te ayudará a diseñar con sus necesidades plenamente en mente.

“Los arquetipos son tendencias innatas que configuran el comportamiento humano, un patrón de comportamiento sobre el cual otros son copiados y emulados” - Carl Jung

Definiendo Arquetipos

El primer paso para determinar el arquetipo de una persona es hacer preguntas durante una serie de entrevistas con los usuarios. A continuación, puedes realizar un seguimiento con preguntas adicionales durante la configuración de su perfil y luego, se dispersarán más preguntas a lo largo de la experiencia del producto a medida que lo utilicen con el tiempo. El objetivo es aclarar la información que le dice lo que les importa, lo que los motiva y lo que valoran.

Determinar aspectos de su vida fuera de línea — los factores de la vida que influyen en su toma de decisiones — ayuda a identificar su mentalidad. ¿Tienen deuda? ¿Están pasando por un cambio de relación? Y así sucesivamente. Los problemas de la vida como estos impactan a la gente de muchas maneras. Esta información de la vida real se utiliza a menudo en soluciones de atención médica — su uso también tiene valor en los bienes de consumo y otras situaciones en línea basadas en el hábito.

Entrevistando potenciales usuarios ayuda a definir arquetipos de usuarios de producto.

En el lado de análisis de datos, observando donde la gente visita en línea — sus hábitos de compra y patrones sociales — también puede darnos una visión de su mundo. Estos datos se vuelven más valiosos a medida que se recopilan e interpretan durante períodos de tiempo más largos. Los patrones cambian lentamente a medida que pasa el tiempo, y al cuantificar su actividad y progresión desde esta perspectiva, empezamos a recoger una historia y un cuadro más profundo de su vida.

Del lado de los datos analíticos, hay muchas maneras diferentes de definir arquetipos. Algunos usuarios pueden estar en el lado competitivo, mientras que otros pueden ser de una mentalidad más del tipo del rebaño. Algunos podrían ser el solista y otros son el tipo de nutrición, más desinteresado y siempre dispuesto a ayudar a las personas necesitadas.

Para más ejemplos de arquetipos de diseño, mira esto.

¿Son Los Arquetipos Mejores Que Las Personas?

Las personas son geniales para definir una audiencia general y sus miembros, pero tratan fuertemente con los hechos y las características de una persona y menos sobre cómo piensan. Ellos definen con quién estamos hablando. Los arquetipos se sumergen más profundamente en los patrones de comportamiento con los que opera una persona. Y, como veremos más adelante en este artículo, aún más importante, las cosas que pueden causar una reacción adversa.

Un simple modelo para cambio de conducta

Sesgos Cognitivos Que Afectan A Los Arquetipos

Cuando con el tiempo las personas se desvían de lo que usualmente se percibe como su norma conductual, generalmente es causada por alguna forma de sesgo cognitivo. Hay cientos de sesgos cognitivos diferentes que han sido estudiados a fondo en el campo de la psicología humana.

En lo que se refiere a diseñar para el comportamiento del usuario, tendemos a pensar que las cosas seguirán siendo las mismas. Es una suposición peligrosa — no hacer un alojamiento para el cambio y el impacto de sesgos puede causar rápidamente a un usuario a perder cualquier motivación para continuar con la experiencia.

El acoplamiento de los arquetipos con los sesgos cognitivos de los usuarios le da claridad al crear una matriz de contenido estratégico. La matriz indicaría maneras de responder a las desviaciones de la norma en el comportamiento de los usuarios. Echemos un vistazo a algunos de los sesgos más grandes abordados en el diseño de comportamiento.

Parcialidad Del Status Quo

Tener un sesgo de status quo por lo general significa que tú eres muy resistente al cambio. Las personas de statu quo deben estar fuertemente motivadas para intentar algo nuevo. Estos no son los nuevos adoptadores de productos nuevos. Diseñar para esta tendencia significa lentos objetivos incrementales durante un período de tiempo más largo.

Aversión A La Pérdida

La aversión a la pérdida es como suena: la tendencia a temer perder algo o no conseguir lo suficiente con el tiempo. Este sesgo se utiliza a menudo por la comercialización para que pueda comprar un producto ahora. Diseñar para este sesgo significa resaltar lo que se perderá al no actuar inmediatamente.

Por ejemplo: un servicio en línea ofrece una prueba gratuita de 30 días. Hacia el final de los días de prueba, recibirás mensajes diciendo: “Sus días de pruebas están a punto de expirar. No pierdas esta oferta especial, ¡compra ahora!” Otro ejemplo común: es mejor que compres los billetes de avión ahora porque sólo quedan “dos asientos”.

La Mentalidad del Rebaño o el Efecto de la Banda

Esta es la tendencia a hacer (o creer) las cosas porque muchas otras personas hacen (o creen) las mismas cosas. Es la tendencia a querer pertenecer a un grupo.

Por ejemplo: ¿Alguna vez has ido a un sitio de viajes o productos y visto una frase como “45 otras personas están viendo esto ahora”, o “35 personas buscan reservar una habitación en este hotel?” Esa es una técnica de marketing para intentar hacerte sentir como si te dejaran fuera del grupo si no compras ahora. En muchos casos también se combina con la aversión a la pérdida. Diseñar para este sesgo significa destacar lo que otras personas están haciendo en el sitio en este momento.

Disponibilidad Heurística

La Disponibilidad Heurística es la evaluación o decisión rápida sobre un asunto, persona, etc. basada en la opinión actual. Es la tendencia a hacer suposiciones. Diseñar para esto significa asegurarse de que la conciencia de la información no se asume como los usuarios se mueven a través del viaje. Esto también se refiere a la idea de que si escuchas algo repetido largo y con frecuencia debe ser cierto.

Descuento Hiperbólico

Piensa en compra de impulso — obtener una recompensa más inmediata con un descuento. Un descuento hiperbólico que lleva a opciones que son inconsistentes en el tiempo: las personas toman decisiones hoy en día que sus futuro yos preferirían no haber hecho a pesar de utilizar el mismo razonamiento.

Por ejemplo, digamos que deseas comprar flores en línea. Vas a través de los pasos para conseguir esas rosas hermosas para ser entregadas y, al final, se te ofrece una serie de productos adicionales como chocolates, un osito de peluche, etc., todo a una tasa de descuento, pero sólo si se compran ahora. Puedes decidir obtener los ítems adicionales o no. Es difícil de predecir. Cosas como lo que sientes ese día, cuál es tu razón (positiva o negativa) para obtener las flores, cómo está en tu cuenta bancaria y si hoy era día de pago o no, todos juegan un papel en si agregas o no ese elemento adicional . Diseñar para este sesgo significa trabajar en el diseño una característica conocida como “FOMO” o “temor de perderse” si no actúas ahora.

Hay cientos de sesgos diferentes por ahí. Estos son algunos de los más comunes que se utilizan en el diseño. Identifique un grupo de ellos para usarlo para sus necesidades específicas del proyecto.

Por Jm3 (Own work) [CC BY-SA 4.0], via Wikimedia Commons

Poniéndolo Todo Junto

Al crear una base para su diseño utilizando la ciencia del comportamiento — definiendo el arquetipo de una persona y comprendiendo estratégicamente cómo diseñar usando sesgos cognitivos, puede dar forma más precisa a las experiencias interactivas que dinámicamente personalice contenido. Al aprender acerca de la persona, su comportamiento, y los episodios de sesgo en el tiempo, puedes adaptar progresivamente la experiencia del producto con el fin de mantenerlos motivados. Cuando se combinan, estos esfuerzos junto con la analítica de datos y la ciencia de datos son herramientas poderosas que pueden ayudar a influir positivamente en el comportamiento humano.

Otras Lecturas

Dos recursos útiles para explorar aún más la ciencia del comportamiento y el concepto de arquetipo:

La Nueva Ciencia Del Diseño Para Humanos
Stanford Social Innovation Review

Usando Diseño Conductual Para Crear Productos Más Atractivos
Mind the Product

Por: Mike Slone

Articulo vía: Toptal

13 Podcasts Que Todo Diseñador Debería Escuchar

2017-08-17T06:30:00.000-03:00

Cada diseñador tiene una manera diferente de “conectar” cuando empieza a trabajar en un nuevo diseño. Escuchar música es probablemente una de las mejores opciones cuando trabajas en un sprint de diseño. Es posible que prefieras poner un programa de televisión de fondo, de esos que te dan un placer culpable. Pero de vez en cuando, puede ser que desees cambiarlo y aprender algo nuevo mientras que diseñas tu próxima obra maestra.

Por eso compilé una lista de cada gran podcast de diseño para ayudar a enfocarte, obtener inspiración y mantenerte entretenido mientras diseñas. Tenemos todo, desde divertidos programas relacionados con la industria hasta los mejores podcasts tecnológicos sobre diseño y podcasts que te ayudarán a ver tus diseños de una nueva forma.

Comencemos…

ShopTalk

ShopTalk podcast de diseño y UX en vivo organizado por Chris Coyier y Dave Rupert. Cada semana, el dúo está acompañado por un invitado especial para discutir el diseño y desarrollo de páginas web front-end y para responder a las preguntas enviadas por los oyentes. Hay más de 260 episodios de este podcast, por lo que seguramente te mantendrá ocupado durante un tiempo.

Adventures in Design

Si estás buscando algo para comenzar tu mañana todos los días, Adventures in Design tiene un nuevo episodio de lunes a viernes. Con casi 600 episodios hasta la fecha, este podcast cubre “la realidad de tratar de vivir sus sueños creativos”. Los temas son de la rama del diseño, y encontrarás un montón de bromas de diversión con esta dosis diaria de diseño.

Design Details

Presentado por Bryn Jackson y Brian Lovin, este podcast de diseño te permite aprender de los mejores de la industria. Como ellos dicen, los anfitriones hablan con las personas que diseñan sus productos favoritos. Los últimos episodios incluyen entrevistas con un diseñador de producto en Slack, un director creativo de Google, y el líder de diseño en Shopify.

Design Matters con Debbie Millman

Este podcast afirma ser el primer podcast del mundo sobre diseño. Los episodios están compuestos de conversaciones con diseñadores, escritores, artistas, músicos y otros tipos creativos que tienen perspectivas únicas sobre el diseño moderno.

NTMY the Show

Presentado por Tobias van Schneider, NTMY significa “Nice to Meet You”. El programa es un podcast basado en una conversación personal en la que Tobias conoce un nuevo tipo de creatividad cada semana. Los huéspedes anteriores han incluido diseñadores de prendas de vestir, un diseñador convertido en comediante y un artista. Este es un podcast más reciente, con sólo dieciséis episodios hasta ahora.

Obsessed with Design

Este podcast tiene una visión amplia del diseño, no sólo se centra en el desarrollo web, sino en todo tipo de diseño. El anfitrión Josh Miles entrevista a un diseñador diferente en cada episodio con enfoques que van desde la ilustración, hasta marca y arquitectura.

The Hacking UI podcast

En un fragmento de su popular boletín informativo, el podcast de Hacking UI presenta a los creadores Sagi Shrieber y David Tintner discutiendo sus pasiones: diseño, desarrollo, emprendimiento, tiempo de hacking y tecnología. Los episodios regularmente presentan entrevistas con algunos de los mejores diseñadores que trabajan hoy en día.

UI Breakfast: UI/UX Design and Product Strategy

Uno de los mejores podcasts de UX/UI, UI Breakfast es conducido por la consultora independiente Jane Portman. Originalmente de Rusia, Jane trae a expertos de la industria para compartir sus conocimientos e información sobre las tendencias UI / UX, productos, marketing y mucho más.

User Defenders

Otro gran podcast UX. User Defenders es conducido por Jason Ogle. Jason ofrece “entrevistas inspiradoras con superhéroes UX”. La idea detrás del podcast es ayudar a los diseñadores más nuevos a aprender de lo mejor al llegar a qué inspira a estos superhéroes UX, qué los motiva, y cómo obtuvieron éxito.

The Deeply Graphic Design Cast

Este podcast de diseño mantiene su enfoque en el diseño gráfico. Una buena salida de los podcasts anteriores basados en entrevistas, Deeply Graphic se centra en un tema de diseño diferente cada episodio, tomando una profunda inmersión en temas como el diseño con SEO en mente, el trabajo con subcontratistas, y el uso de moodboards.

Design Review

Design Review se emite dos veces por semana y se centra en diferentes aspectos del diseño de producto. Chris Liu y Jonathan Shariat hablan sobre el pensamiento del diseño, las herramientas, la experiencia del usuario y más. Ya hay 53 episodios, y todavía están haciendo nuevos.

Code podcast

Code Podcast— ¿Suena como algo para los desarrolladores? Lo es, pero también cubren algunos temas de diseño. Este podcast es una gran oportunidad para aprender sobre el diseño desde la perspectiva de un desarrollador con conocimiento de diseño.

Creative Honey

Si estás interesado en los enfoques de otros diseñadores, Creative Honey es definitivamente para ti. Grandes entrevistas, charlas sobre comunidad de diseño, y un poco de psicología. Desafortunadamente no han añadido nuevos episodios últimamente, pero todavía hay mucho contenido valioso en sus archivos.

Por: Michael Abehsera

Articulo vía: Toptal

Tutorial de Power Pivot para Excel: Los Casos y Ejemplos más Usados

2017-08-02T00:30:00.000-03:00

Todo analista financiero es un genio en Excel. Sin embargo, al hacerse más económico el almacenamiento, nuestras organizaciones van acumulando más data. Y al tener más de esta data se hace más complicado trabajar con Excel—o llegamos al límite de fila 1,048,576, o el documento disminuye la velocidad tratando de procesar todo.

A menudo, la decisión se encuentra entre perder detalles organizados cuidadosamente, o trabajar en un libro de trabajo tediosamente lento. A veces, tenemos que ser creativos para poder combinar dos grandes sets de data. Recurrimos a usar fórmulas complejas y esperamos una eternidad para que los cálculos sean resueltos.

Afortunadamente, ya no tienes que tomar estas decisiones. La funcionalidad de Power Pivot de Excel provee una manera de extraer, combinar y analizar grandes sets de data. A pesar del hecho de que fue lanzado con Excel en el año 2010, la mayoría de los analistas financieros que conozco todavía no saben cómo usar Power Pívot, y muchos ni siquiera saben que existe.

En este artículo, te voy a enseñar cómo usar Power Pívot para sobrellevar algunos problemas comunes de Excel y echaremos un vistazo a las ventajas adicionales clave del software usando algunos ejemplos. Este tutorial de Power Pívot para Excel tiene como finalidad servir de guía para lo que puedes conseguir con esta herramienta y, al final, voy a explorar algunos ejemplos de casos de uso dónde Power Pívot puede ser invaluable.

¿Qué es Power Pivot y Por qué es Útil?

Power Pivot es una característica de Microsoft Excel que fue introducida como un agregado de Excel 2010 y 2013 y es, ahora, una característica nativa para Excel 2016. Como lo explica Microsoft, Power Pivot para Excel “te permite importar millones de filas de data desde múltiples fuentes de data a un solo libro de trabajo de Excel, crear relaciones entre data heterogénea, crear columnas calculadas y medir usando fórmulas, construir PivotTables y PivotCharts, y luego analizar a profundidad la data para que así puedas tomar decisiones de negocios oportunas sin la asistencia del equipo IT.”

La expresión de lenguaje principal usada por Microsoft en Power Pivot es DAX (Data Analysis Expressions), aunque otros también pueden usarse en situaciones específicas. De nuevo, como lo explica Microsoft, “DAX es una colección de funciones, operadores y constantes que se pueden usar en una fórmula, o expresión, para calcular y regresar uno o más valores. Puesto de manera más sencilla, DAX te ayuda a crear nueva información desde la data que ya se encuentra en tu modelo.” Afortunadamente, para aquellos ya familiarizados con Excel, las fórmulas DAX les parecerán conocidas, ya que muchas de las fórmulas tienen sintaxis similar (ej., SUM, AVERAGE, TRUNC).

Para aclarar, los beneficios clave de usar Power Pivot vs. Excel básico se puede resumir así:

Te permite importar y manipular cientos de millones de filas de data donde Excel tiene una fuerte constricción de más de un millón de filas.
Te permite importar data desde múltiples fuentes a un libro de trabajo de fuente único, sin tener que crear múltiples hojas de fuente que sufren de control de versión y problemas de transferibilidad.
Te permite manipular la data importada, analizarla y sacar conclusiones sin bajar la velocidad de tu computadora a la velocidad de un caracol.
Te permite visualizar la data con PivotCharts y Power BI.

En las siguientes secciones, pasaré por cada uno de los beneficios nombrados y te mostraré cómo Power Pivot para Excel te puede ayudar.

1) Importar Grandes Sets De Data

Como ya lo discutimos, una de las limitaciones más grandes de Excel tiene que ver con el trabajo con sets de data extremadamente grandes. Afortunadamente para nosotros, Excel puede subir más del límite de la fila de un millón, directamente a Power Pivot.

Para demostrar esto generé una muestra de un set de data de un valor de ventas de dos años, esto para un vendedor de productos de deporte, con nueve categorías de productos diferentes y cuatro regiones. El set de data resultante es de dos millones de filas.

Usando la tabulación Data en la banda, cree una Nueva Pregunta del archivo CSV (Muestra 1). Esta funcionalidad usada antes se llamaba PowerQuery, pero desde Excel 2016, se ha integrado mucho más en la tabulación de Data de Excel.

Muestra 1: Creando una Nueva Prueba

¡Pasar de un libro de trabajo en blanco de Excel a subir las dos millones de filas a Power Pivot tomó más o menos un minuto! Nota que pude formatear un poco de data ligera al ascender la primera fila para que se convirtieran en los nombres de las columnas. En los últimos años, la funcionalidad de Power Query ha mejorado enormemente, pasó de un agregado de Excel a parte integrada de la tabulación de Data en la barra de herramientas. Power Query puede girar, aplastar, limpiar y dar forma a tu data a través de una variedad de opciones y su propio idioma, M.

2) Importar Data desde Múltiples Fuentes

Uno de los beneficios clave de Power Pivot para Excel, es la habilidad de importar data fácilmente de múltiples fuentes. Previamente, muchos de nosotros creábamos múltiples hojas de trabajo para nuestras distintas fuentes de data. A menudo, este proceso involucraba escribir código VBA y copiar y pegar de estas fuentes dispares. Afortunadamente para nosotros, Power Pívot te permite importar data desde distintas fuentes de data directamente a Excel sin tener que encontrarse con los problemas mencionados anteriormente.

Al usar la función Query en la Muestra 1, podemos extraer desde cualquiera de las siguientes fuentes:

Microsoft Azure
SQL Server
Teradata
Facebook
Salesforce
Archivos JSON
Libros de trabajo de Excel
…y muchos más

Más aún, múltiples fuentes de data pueden ser combinadas en la función Query o en la ventana Power Pivot, para integrar data. Por ejemplo, puedes extraer data de costo de producción de un libro de trabajo de Excel y resultados de ventas verdaderos del servidor SQL a través de Query hacia Power Pivot. A partir de ahí, puedes combinar los dos sets de data al combinar números de un lote de producción con márgenes brutos por unidad.

3) Trabajar con Grandes Sets de Data

Otra ventaja clave de Power Pivot para Excel es la habilidad de manipular y trabajar con grandes sets de data para alcanzar conclusiones y análisis relevantes. Pasaré por algunos ejemplos comunes, para darte una apreciación del poder de la herramienta.

Medidas

Los adictos a Excel estarán completamente de acuerdo con que PivotTables son unas de las tareas más útiles pero al mismo tiempo frustrantes de realizar. Particularmente frustrantes cuando se trata de trabajar con grandes sets de data. Afortunadamente, Power Pivot para Excel nos permite crear, rápida y fácilmente, PivotTables cuando se trabaja sets de data más grandes.

En la imagen de abajo (Muestra 2), nota como la ventana de Power Pivot está separada en dos cristales. El cristal de arriba tiene la data y el de abajo contiene las medidas. Una medida es un cálculo que se realiza en todo el set de data. He ingresado una medida al ingresar la celda resaltada.

Total Sales:=SUM('Accounting Data'[Amount])

Esto crea una nueva medida que suma a través de la columna de Cantidad. Similarmente, puedo ingresar otra medida en la celda de abajo.

Average Sales:=AVERAGE('Accounting Data'[Amount])

Muestra 2: Creando Medidas

Desde ahí, observa lo rápido que es crear una PivotTable familiar en un gran set de data.

Muestra 3: Creando una PivotTable

Tablas de Dimensión

Como analistas financieros que usan Excel, nos convertimos adeptos al usar fórmulas complicadas para doblegar la tecnología a nuestra voluntad. Dominamos VLOOKUP, SUMIF, y hasta el temido INDEX(MATCH()). Sin embargo, al usar Power Pivot, podemos deshacernos de mucho de esto.

Muestra 4: Agregar una Tabla Creada por el Usuario a un Modelo Power Pivot

Para demostrar esta funcionalidad, creé una pequeña tabla de referencia en la que asigné cada Categoría a un Tipo. Al escoger “Agregar a Modelo de Data”, esta tabla es cargada a Power Pivot (Muestra 4 arriba).

También creé una tabla de fecha para ser usada con nuestro set de data (Muestra 5). Power Pivot para Excel hace más fácil crear una tabla de fecha rápidamente, para así consolidar por meses, trimestres y días de la semana. El usuario puede también crear una tabla de fecha más a la medida para analizar por semanas, años fiscales, o cualquier agrupamiento específico de la organización.

Muestra 5: Crear una Tabla de Fecha

Columnas de Cálculo

Aparte de las medidas, hay otro tipo de cálculo: las columnas de cálculo. Los usuarios de Excel se sentirán cómodos escribiendo estas fórmulas, ya que son muy similares a escribir fórmulas en tablas de fecha. Creé una nueva columna de cálculo abajo (Muestra 6) la cual organiza la tabla de Data de Contabilidad por Cantidad. Las ventas por debajo de 50 dólares se marcan como “Pequeñas” y el resto se marcan como “Grandes”. ¿No se siente intuitiva la fórmula?

Muestra 6: Creando una Columna de Cálculo

Relaciones

Luego, podemos crear una relación entre el campo de la Categoría de la tabla de Data de Contabilidad y el campo de Categoría de la tabla de Categoría, usando la Vista de Diagrama. Adicionalmente, podemos definir una relación entre el campo Fecha de Ventas de la tabla de Data de Contabilidad y el campo de Fecha de la tabla de Calendario.

Muestra 7: Definiendo Relaciones

Ahora, sin necesidad de ninguna función SUMIF o VLOOKUP, podemos crear una PivotTable que calculó Ventas Totales por año y tipo, con un cortador para el Tamaño de la Transacción.

Muestra 8: PivotTable Usando Relaciones

O, podemos crear una gráfica de Ventas Regulares para cada día de la semana usando la nueva tabla de Calendario.

Muestra 9: PivotChart Usando Relaciones

Mientras esta gráfica parece simple, es impresionante que haya tomado menos de 10 segundos crear una consolidación de más de dos millones de filas de data, sin agregar una nueva columna a la data de ventas.

Mientras podemos llevar a cabo estos escenarios de reportaje consolidados, también podemos adentrarnos en los ítems de línea individuales. Retenemos nuestra data altamente granular.

Funciones Avanzadas

Hasta ahora, la mayoría de los análisis que he mostrado son, relativamente, cálculos directos. Ahora, quiero demostrar algunas de las capacidades más avanzadas de esta plataforma.

Inteligencia de Tiempo

A menudo, cuando examinamos los resultados financieros, queremos compararlos a un periodo de tiempo comparable del año anterior. Power Pivot tiene unas funciones de inteligencia de tiempo integradas.

Same Period Last Year Sales:=CALCULATE([Total Sales],SAMEPERIODLASTYEAR('Calendar'[Date]))
 
YOY Sales Growth:=if(not(ISBLANK([Same Period Last Year Sales])),([Total Sales]/[Same Period Last Year Sales])-1,BLANK())

Por ejemplo, agregar solo dos medidas sobre la tabla de Data de Contabilidad en Power Pivot me permite producir la siguiente PivotTable en solo un par de clics.

Muestra 10: Inteligencia de Tiempo PivotTable

Granularidades Disparejas

Como analista financiero, un problema que tengo que resolver a menudo es las granularidades disparejas. En nuestro ejemplo, la data exacta de ventas se muestra en el nivel de categoría, pero preparemos un presupuesto que está solo en un nivel de temporada. Para extender esta disparidad, vamos a preparar un presupuesto trimestral, aunque la data de ventas sea diaria.

Muestra 11: Granularidades - Tabla de Presupuesto

Con Power Pivot para Excel, esta inconsistencia se resuelve fácilmente. Al crear dos tablas de referencia adicionales, o tablas de dimensión en nomenclatura de base de datos, podemos crear las relaciones apropiadas para analizar nuestras ventas verdaderas en comparación con las cantidades presupuestadas.

Muestra 12: Granularidades - Relaciones Disparejas

En Excel, la siguiente PivotTable está lista rápidamente.

Muestra 13: Granularidades - Presupuesto Disparejos vs. Resultados Verdaderos

Además, podemos definir nuevas medidas que calculan la divergencia entre ventas verdaderas y ventas presupuestadas, como se muestra abajo:

Actual-to-Budget Variance:=if(ISBLANK([Total Budgeted Sales]),BLANK(),[Total Sales]/[Total Budgeted Sales]-1)

Al usar esta medida, podemos mostrar la divergencia en una PivotTable.

Muestra 14: Granularidad es Disparejas - Resultados Divergentes

Porcentaje Total

Finalmente, examinemos las ventas en una categoría en particular como porcentaje de todas las ventas (ej., contribución de categoría a ventas generales), y ventas en una categoría en particular como porcentaje de todas las ventas de un mismo tipo (ej., contribución de categoría a ventas por temporadas). Creé las dos medidas que se muestran abajo:

Total Sales as Percent of All Sales:=[Total Sales]/CALCULATE([Total Sales],ALL('Accounting Data'))
Total Sales as Percent of Type:=[Total Sales]/CALCULATE([Total Sales],ALL('Accounting Data'[Category]))

Esas medidas ahora se pueden implementar en una nueva PivotTable:

Muestra 15: Porcentaje Total

Nota como se realizan los cálculos en ambos tipos de niveles, el de categoría y el de tipo temporal. Me encanta como se realizan estos cálculos, tan rápido y sin esfuerzo, sobre todo en un set de data tan grande. Estos son solo unos pocos ejemplos de la elegancia y el claro poder computacional de Power Pivot.

Compresión

Otro beneficio es que los tamaños de los archivos se minimizan. El tamaño original del archivo era de 91MB y ahora es menos de 4MB. Eso es una compresión de 96% del archivo original.

Muestra 16: Tamaños de Archivo

¿Cómo sucede esto? Power Pivot usa el motor xVelocity para comprimir la data. En términos más sencillos, la data está almacenada en columnas en vez de filas. Este método de almacenamiento permite a la computadora comprimir valores duplicados. En nuestro ejemplo de set de data, hay solo cuatro regiones que se repiten en los dos millones de filas. Power Pivot para Excel puede almacenar eficientemente esta data. El resultado es que para la data que tiene muchos valores repetitivos, cuesta mucho menos almacenar esta data.

Algo importante a resaltar es que yo usé cantidades de dólares completas en este set de data de muestra. Si hubiese incluido dos puntos decimales para reflejar céntimos, el efecto de compresión disminuiría a un impresionante 80% del tamaño del archivo original.

Tabular SSAS

Los modelos Power Pivot también pueden ser expansibles a toda la empresa. Digamos que construyes un modelo Power Pivot que comienza a ganar usuarios en la organización, o la data crece a 10 millones de filas, o ambas. En ese momento, puede que no quieras treinta usuarios distintos actualizando el modelo o haciendo cambios. El modelo puede ser convertido en una Tabular SSAS, sin mayores inconvenientes. Todas las tablas y relaciones son retenidas, pero ahora puedes controlar la frecuencia de actualización, asignar roles (ej., solo lectura, lectura y procesar) a varios usuarios, e implementar un pequeño front-end de Excel, el cual se conecta al modelo Tabular. El resultado es que tus usuarios podrían acceder al modelo tabular implementado, con un pequeño libro de trabajo, pero no accederían a las fórmulas y medidas.

4) Análisis y Visualización de Data

Fórmulas CUBE

Una de las peticiones más comunes de mis clientes es que cree reportes que conformen diseños estrictamente definidos. Tengo clientes que piden anchos de columna específicos, códigos de color RGB y nombres y tamaños de letras predeterminados. Considera el siguiente panel de instrumentos:

Muestra 17: Fórmulas CUBE empotradas

¿Cómo poblamos los números de ventas sin generar PivotTables, si todas nuestras ventas son almacenadas con Power Pivot para Excel? Usando fórmulas CUBE! Podemos escribir fórmulas CUBE dentro de cualquier celda Excel y realizará el cálculo con el modelo Power Pivot que ya hemos construido.

Por ejemplo, la siguiente fórmula está escrita en la celda bajo el nombre “Ventas Totales 2016:”

=CUBEVALUE("ThisWorkbookDataModel","[Measures].[Total Sales]","[Calendar].[Year].[2016]")

La primera parte de la fórmula, resaltada en amarillo, se refiere al nombre del modelo Power Pivot. En general, se usa ThisWorkbookDataModel para versiones más nuevas de Power Pivot para Excel. La porción en verde define que queremos usar la medida Ventas Totales. La parte en azul instruye a Excel a filtrar solo para filas que tengan una Fecha de Ventas con un año igual a 2016.

Detrás de escena, Power Pivot ha construido un cube Online Analytical Processing (OLAP) con la data, columnas calculadas y medidas. Este diseño permite al usuario Excel poder acceder a la data con solo traerla directamente con las funciones de CUBE. Al usar las fórmulas CUBE, he podido construir declaraciones financieras que conforman diseños predeterminados. Esta habilidad es uno de los beneficios de usar Power Pivot para Excel para análisis financieros.

Power BI

Otra ventaja de Power Pivot para Excel es que puedes tomar rápidamente cualquier libro de trabajo de Power Pivot que construyas y convertirlo en un modelo Power BI. Al importar el libro de trabajo de Excel directamente a una aplicación de escritorio Power BI o Power BI online, puedes analizar, visualizar y compartir tu data con cualquier persona en tu organización. Esencialmente, Power BI es Power Pivot, PowerQuery, y SharePoint, todos en uno. Debajo, creé un tablero al importar el libro de trabajo de Power Pivot para Excel a la aplicación de escritorio Power BI. Nota lo interactiva que es la interfaz:

Muestra 18: Power BI

Algo genial sobre Power BI son las Preguntas y Respuestas en Idioma Natural. Para demostrarlo, cargué el modelo Power BI a mi cuenta en línea de Power BI. Desde la página web puedo hacer preguntas y Power BI construye el análisis apropiado mientras escribo:

Muestra 19: Preguntas y Respuestas en Idioma Natural

Este tipo de habilidad de preguntar le permite al usuario hacer preguntas del modelo de data e interactuar con la data en una manera más sencilla que en Excel.

Otro beneficio de Power BI es que los desarrolladores de Microsoft están lanzando actualizaciones constantemente. Nuevas características, que han sido pedidas por los usuarios, se lanzan mensualmente. Lo mejor de todo, es una transición sin inconvenientes de Power Pivot para Excel. Así que, ¡el tiempo que invertiste aprendiendo las fórmulas DAX se puede implementar en Power BI! Para el analista que necesita compartir sus análisis con muchos usuarios en varios dispositivos, valdría la pena explorar Power BI.

Las Mejores Prácticas

Una vez que comienzas, hay un par de mejores prácticas que deberías seguir.

La primera es decidir conscientemente que importa en primer lugar. ¿En algún momento usarás la dirección de la casa del vendedor? ¿Necesito saber la dirección de correo electrónico de mi cliente en el contexto de este libro de trabajo? Si la meta es agregar la data al tablero, entonces parte de la data disponible no será necesaria para esos cálculos. Dedicarle tiempo a limpiar la data entrante permitirá aligerar la carga de problemas y uso de memoria más tarde cuando se expanda tu set de data.

Otra de las mejores prácticas es recordar que Power Pivot no es Excel. En Excel, estamos acostumbrados a crear cálculos al expandir, constantemente, nuestras hojas de cálculo a la derecha. Power Pivot para Excel procesa efectivamente la data si limitamos esto a lo deseado. En vez de crear constantemente columnas de cálculo a la derecha de tu data, aprende a escribir medidas en el cristal inferior. Este hábito asegurará archivos más pequeños y computaciones más rápidas.

Finalmente, sugeriría usar nombres comunes en inglés para las medidas. Me tomó algo de tiempo adaptarme a esto. Pasé los primeros años inventando nombres como SumExpPctTotal, pero una vez que otras personas comenzaron a usar los mismos libros de trabajo, tuve mucho que explicar. Ahora, cuando comienzo un nuevo libro de trabajo, uso nombres como Ítem de Línea de Gastos como Porcentaje de Gastos Totales. A pesar de que el nombre es más largo, es mucho más fácil de usar por otra persona.

Casos de Uso en el Mundo Real

En este artículo, presenté solo parte de las maneras en que Power Pivot para Excel te permite tomar un paso importante, más allá de lo común de Excel. Pensé que sería útil resaltar algunos casos de la vida real en los que Power Pivot para Excel me ha sido extremadamente útil.

Aquí hay algunos:

Analiza el rendimiento de un gran portafolio de valores en distintos rangos de tiempo: Ya que Power Pivot para Excel nos permite definir medidas que comparan un período de tiempo con uno previo, rápidamente podemos tener rendimiento trimestre tras trimestre, año tras año y mes tras mes, todos de manera continua, al escribir un par de medidas.
Resalta la data de contabilidad usando niveles de agregación a la medida: Al identificar por nombre, categoría y estado financiero cada ítem de línea de un libro mayor de contabilidad, los reportes se pueden crear rápidamente, incluyendo los ítems de línea apropiados.
Las cadenas pueden identificar ventas de la misma tienda: Al usar una tabla que mapea cuando las tiendas están en línea, los resultados financieros pueden compararse en una base de la misma tienda.
Señala los que han estado por encima y por debajo de las ventas: PivotTables se puede crear para resaltar el top 5 de los SKU al igual que los 5 más bajos por ventas, márgenes generales, período de producción, etc.
Los minoristas pueden definir tablas de calendario que usan una configuración 4-4-5: Usando una tabla de fecha hecha a la medida, un minorista puede asignar cada día a un mes específico 4-4-5 fácilmente, luego los resultados de las ventas diarias se pueden pasar al mes correspondiente.

De Hojas de Trabajo Torpes a Libros de Trabajo Modernos

Como analistas financieros, se nos pide realizar cálculos complejos en sets de data que siguen creciendo. Ya que Excel es la herramienta analítica por defecto, la curva de aprendizaje de Power Pivot es fácil y muchas de las funciones imitan las funciones nativas de Excel.

Con el uso de las funciones CUBE, Power Pivot para Excel se integra fácilmente a tus libros de trabajo ya existentes en Excel. La ganancia de eficiencia computacional no se puede negar. Asumiendo una rapidez de procesamiento de 20% más velocidad, lo cual es conservador, el analista financiero que pase seis horas al día en Excel se puede ahorrar 300 horas al año.

Adicionalmente, ahora podemos analizar sets de data que son más largos comparados con los que analizábamos anteriormente con nuestro Excel tradicional. Con modelos diseñados eficientemente, podemos tener más de 10 veces la data que se nos permitía anteriormente con Excel tradicional, mientras mantenemos una agilidad analítica. Con la habilidad de convertir los modelos desde Power Pivot al Tabular SSAS, la cantidad de data que se puede procesar es de 100–1,000 veces lo que podemos alcanzar en Excel.

La habilidad de Power Pivot para Excel de realizar cálculos con extrema rapidez, en grandes cantidades de data y todavía retener la habilidad de sumergirse en los detalles, puede transformar los análisis financieros de torpes hojas de cálculo a libros de trabajo modernos.

Si te interesa probar Power Pivot para Excel, debajo hay algunos materiales que te pueden ser útil para comenzar.

Referencias y Guías Útiles

Collie, R., & Singh, A. (2016). Power Pivot and Power BI: The Excel user’s guide to DAX, Power Query, Power BI & Power Pivot in Excel 2010-2016. United States: Holy Macro! Books.
Ferrari, A., & Russo, M. (2015). The definitive guide to DAX: Business intelligence with Microsoft Excel, SQL Server Analysis Services, and Power BI. United States: Microsoft Press, USA.

Por: Ellen Su

Articulo vía: Toptal

Diseño Persuasivo: Usando Psicología Avanzada Efectivamente

2017-07-16T22:31:00.002-03:00

“Las emociones forman toda actividad en formas adaptativas. En la ausencia de componentes emocionales, la toma de decisiones es virtualmente imposible.” —Saver & Damasio (1991)

Los sitios web han avanzado mucho en poco tiempo–es realmente increíble cómo muchos de estos sitios que pertenecen a las marcas más establecidas de la última década, han cambiado desde su primera iteración.

Cuando los sitios web fueron usados por primera vez por propósitos comerciales, no le prestaron mucha atención a la experiencia de usuario; el punto era poner la mayor cantidad de contenido posible en una página. Ahora ponen un peso mayor en investigación, con una mina de datos, y optimizados para tomar tu atención y ofrecerte el contenido exacto, junto a funcionalidades y opciones al mismo tiempo.

Más y más compañías están usando investigación psicológica avanzada y para empujar a más compras y fidelidad de parte de los usuarios, han transformado lo que era arte en ciencia.

El sitio web de Apple de 1997

Diseño Persuasivo

En adición a muchos elementos esenciales, el buen diseño siempre tendrá en mente las necesidades psicológicas y emocionales. Miremos al diseño persuasivo y exploremos cómo los procesos mentales que influenciaron cómo los humanos se comportan puede ser aplicado al diseño.

La palabra ”persuación” es muchas veces asociada con la manipulación, engaños, y—especialmente para un diseñador–el uso de patrones oscuros. Se ha ganado una reputación particular; sin embargo, seamos claros en que no es eso lo que estamos debatiendo. El diseño persuasivo puede mejorar la experiencia de usuario al hacer un sitio web fácil de usar—entiende de disparadores psicológicos, la conducta de los usuarios y las entabla.

Por ejemplo, Amazon persuade a los usuarios para que sigan comprando más al recomendar productos alternativos y accesorios, y emplea patrones miméticos y persuasivos al mostrar opciones como “clientes que vieron este objeto también compraron…”. Para cerrar una venta rápidamente, también le ofrecen a los compradores la habilidad de comprar con un sólo click.

Todos estamos gastando mucho más tiempo en un mundo online, y los diseñadores pueden usar lo que han aprendido de conductas offline para crear mejores experiencias de usuario. Así quieras modificar un sitio web existente o construir una app, el diseño persuasivo guiará y apoyará la experiencia online del usuario.

¿Cómo puede un diseñador usar lo último en investigación de psicología para mejorar el impacto de sus diseños?

Entender los principios de la psicología te provee con la habilidad de explicar la racionalidad subyacente de tu trabajo. Puede:

Servir como fuente de investigación y justificación en déficit de investigación de usuario.
Ayudar a validar tu diseño y razonar con un cliente.

Debatamos algunas teorías.

La Percepción Del Control

Como humanos, tenemos una necesidad innata de control. Esto nos lleva hacia nuestros humildes comienzos. En ponerle un precio a la jerarquía de las necesidades, el psicólogo Abraham Maslow nombró las más básicas: salud, comida, y sueño. Todas estas requieren un nivel de control sobre nuestro ambiente.

La Jerarquía De Las Necesidades De Maslow (cortesía de psychologytoday.com)

Como diseñadores UI, necesitamos asegurarnos que nuestros usuarios tendrán una experiencia positiva dentro del ambiente que creamos para ellos. Esto significa hacerlos sentir poderosos al ofrecerles herramientas que los harán sentir como si estuvieran en control de su travesía.

Consultor UX Nadine Kintscher dice, “Hoy, puedes ajustar el brillo de tus pantallas, desactivar notificaciones, y decidir si quieres que tu teléfono se conecte a datos y una red de teléfono o no…Incluso si estos ajustes sólo amplian la batería de tu dispositivo por sólo unos minutos, te da un sentimiento cálido de logro. TÚ estás a cargo.”

Necesitamos crear interfaces que son un balance entre ser funcional y visualmente cautivantes, y darle a los usuarios un poco de control para que tengan una experiencia satisfactoria.

Realestate, un sitio web Australiano de búsqueda de inmuebles, tiene éxito en hacer lo mencionado con anterioridad al dejar que sus usuarios filtren las propiedades de acuerdo a sus preferencias, y al darles la opción de ordenar por una norma limitada.

Motivación, Habilidad Y Disparador

¿Cómo diseñas una experiencia digital que le permita a los usuarios entablar conductas deseadas que ocurrirán en el momento exacto? Motivación, habilidad, y disparadores—una simple teoría basada en el Modelo Conductual de Fogg—es ideal para cualquiera intentando entender la psicología persuasiva. De acuerdo con el principio de la motivación, habilidad, y disparadores, la conducta ocurre cuando una persona es motivada, tiene la habilidad de tomar parte en la conducta, y es presentado con un disparador. Cuando estos tres elementos se unen en el mismo momento es cuando una conducta deseada puede ocurrir.

Un buen ejemplo es TurboTax, debatido en el libro Diseño Para La Mente: Siete Principios Psicológicos Del Diseño Persuasivo.

Aunque no lo disfrutemos, estamos altamente motivados para archivar nuestros impuestos. Sin embargo, el sistema impositivo de Estados Unidos es, como el de cualquier otro país, muy complejo para comprender fácilmente. TurboTax ha aumentado la habilidad al permitirle a sus usuarios completar más fácilmente sus impuestos al hacer preguntas básicas. Lejos se han ido los largos documentos—y en cambio, TurboTax ha creado un proceso de trabajo donde los usuarios son guiados a través de un proceso paso a paso. El valor final propuesto es la habilidad de fácilmente archivar impuestos de forma electrónica y enviar un pago–el disparador.

Encontrar situaciones exactamente con la combinación perfecta y la habilidad para un disparador perfecta podría sentirse artificial o no natural. Está bien si uno sobrepasa el otro; un buen ejemplo es twittear—la motivación podría ser baja, pero el disparador podría estar ahí y su habilidad ser muy alta.

Como diseñadores, podemos usar esta teoría para examinar cómo estamos construyendo las motivaciones de nuestros usuarios y la habilidad antes de que les pidamos que se comprometan con una conducta determinada.

Motivación provee una razón para que alguien se involucre en la tarea.
Habilidad provee a las personas con la oportunidad de completar la tarea.
Disparadores ocurren en nuestro ambiente o cerebro y dan pie a que una persona haga algo.

Ambas teorías requieren un poco de investigación pero son altamente útiles cuando se diseñan interfaces.

Alternativamente, hay algunas teorías psicológicas más simples que requieren menos investigación y pueden ser implementadas en tus diseños de forma inmediata, como los conceptos de escasez y el miedo de perderse algo (FOMO).

Amazon usa el FOMO efectivamente al añadir una nota de urgencia a un producto (resaltado)

Captura La Atención De Tu Audiencia

Por décadas, los psicólogos han estado obsesionados con nuestra decreciente habilidad de prestar atención.

Rastrear eso mide cuándo y por cuánto tiempo un usuario puede encontrarse en un punto y ha estado cerca por un tiempo determinado. Muestra que el período de concentración promedio en internet es menos que un par de segundos—tomamos decisiones inmediatas sobre un sitio y, si no es para nosotros, nos vamos.

EyeQuant ha tomado esta idea un paso más allá al construir un algoritmo predictivo usando datos de rastreo del movimiento de nuestros ojos. En vez de usar un programa para eso en tu propio sitio, puedes subir un diseño a su sitio web y te dirán cómo las personas perciben y se concentran en tu sitio.

Usando participantes Alemanes, construyeron una base de datos masiva sobre qué atrae la atención del usuario y lo que no—los contrastes de color, por ejemplo, atraen la vista, y así también lo hacen las tipografías y texto en negrita.

Software de seguimiento de ojos puede ser costoso, y en vez de eso, software de análisis como Sumo Heat Maps son útiles para mostrar qué y cómo tus visitantes están haciendo click, y qué les llama más la atención. Sin embargo, es esencial recordar que mientras estemos capturando la atención del cerebro, podríamos empujar a los usuarios lejos de algo más importante.

Usando software de seguimiento de ojos o mapas de calor les permite a los diseñadores tener una devolución inmediata y objetiva de sus diseños. Como diseñador, puede servir como validación para tus ideas de UX y proveer datos para tus decisiones de diseño, además de permitirte optimizar dichos diseños al realizar tests inteligentes A/B.

Sumo Heat Map

Deseo Mimético

¿Te has dado cuenta que los seres humanos naturalmente imitan los deseos de otros seres humanos? El deseo humano es, de lejos, deseo arbitrario. Esta teoría, originada por Rene Girard, sugiere que si alguien muestra deseo por un objeto, también desearás ese objeto. Los publicistas amarán esto–ya que ha demostrado ser exitosos.

Tú y yo somos criaturas miméticas. Diseño Neuronal por Darren Bridger exploró esta teoría y encontró que tenemos un sistema de neuronas espejo. En otras palabras, el sólo ver a alguien hacer algo como recoger un objeto puede causar que tu cerebro copie esa acción.

La teoría del deseo mimético significa que queremos algo más si vemos que alguien más lo posee—un diseñador puede emplear esto al usar prueba social.

Un ejemplo de la técnica de “prueba de usuario” son los testimoniales. Los testimonios funcionan porque vienen de personas que comparten sus deseos de usuarios y valores. Por ejemplo, Foundrmag no sólo usa la voz del usuario sino que también les muestra rostros, disparando el sistema de neuronas espejo.

Foundrmag

Otra implementación es “prueba social experta”, donde tu producto recibe una “estampa de aprobación” de un experto con credibilidad, como un blogger de industria. Esto puede aparecer como una mención de Twitter, una cita textual de prensa, o inclusive un artículo de blog. Google usa esta técnica en su última campaña para el smartphone Pixel.

Psicología En El Diseño De Hoy Y Más Allá

Es un momento emocionante para los diseñadores—tenemos los recursos e investigación para apoyar todo nuestro trabajo.

Tendencias de diseño suelen moverse al tacto, voz, realidad virtual (VR), realidad aumentada (AR), realidad mixta (MR), y el Internet De Las Cosas (IoT); mientras nos movemos hacia estas tecnologías de interacción, las personas requerirán formas más intuitivas de usar sus interfaces.

Veremos muchas nuevas oportunidades de diseño, y de psicología en general tendrá un rol directo y esencial en estos desarrollos.

El siguiente gran cambio será cómo interactuemos con nuestros dispositivos día a día—moviéndonos de lo táctil a auriculares que leerán nuestras ondas cerebrales. Esta tecnología está ya disponible y le da a las personas la habilidad de controlar sus dispositivos directamente con su pensamiento.

A medida que nos acercamos a los pensamientos reales de las personas, la psicología en el diseño–y la responsabilidad moral del diseñador–tendrán un rol muy importante e que incluso será aún mayor.

Además de usar analíticas, investigación de usuario, mapas de empatía y otros acercamientos para ayudar a tomar decisiones de diseño e iterar en un producto, los diseñadores deberían considerar juntar sus “bolsas de trucos” con los métodos de diseño persuasivo anteriormente mencionados.

El diseño persuasivo no es malo. Es una herramienta, y como cualquier herramienta esta puede ser mal usada. Sin embargo, con la investigación correcta y su aplicación bien pensada, puede ser una valiosa incorporación al juego de herramientas de cualquier diseñador.

Por: Bronwen Rees
Articulo vía: Toptal

Guarda la Calma y Transiciona a un Nuevo Equipo de Desarrollo

2017-07-02T15:34:00.001-03:00

Es común que un producto de software haga una transición de un equipo de desarrollo a otro en el curso de su vida. Las diferentes etapas del producto pueden requerir un equipo de desarrollo diferente: una consultaría para construir la versión inicial, un desarrollador independiente para mantenerla, un equipo interno para llevarlo a escala, o un diseñador profesional para hacerlo visualmente llamativo.

A pesar de que esto ocurre con frecuencia, muchos fundadores no técnicos y los propietarios de los productos no se encuentran preparados y luchan cuando llega el momento de traer al próximo equipo. Esto a menudo da como resultado una incapacidad para que el nuevo equipo pueda avanzar rápidamente, una pérdida de tiempo, y una frustración que incluye a todos los miembros.

Si esto suena como que podrías ser tú, ya sea ahora o en el futuro, entonces deberías estar algo preocupado. Por suerte, voy a guiarte a través de los pasos a seguir para prepararte para esta eventualidad y hacer la transición lo más sencilla posible.

Pasar la Antorcha: Abordando un Nuevo Equipo de Desarrollo

En este artículo, voy a ofrecerte una lista de verificación que te ayudarán a prepararte para un cambio de este tipo. Comenzarás a conocer tu producto en un nivel más íntimo y obtendrás un mayor control sobre los diversos servicios y tecnologías que conlleva el hacerlo, lo cual te ayudará a abordar un nuevo equipo con tranquilidad relativa y confianza.

Al pasar la antorcha a los nuevos desarrolladores, asegúrese de que el nuevo equipo no se queme.

¿Pero si no estás reemplazando todo el equipo? ¿Deberías tomarte el tiempo de leer esto?

Incluso si algunos miembros del equipo anterior permanecen a bordo, puede ser que no tengan todas las respuestas e información necesaria para una transición sin problemas. A pesar de que pueden proporcionar continuidad y ayuda en el proceso de transferencia de conocimiento del antiguo equipo al nuevo, depender de los miembros del equipo titular no reemplaza el hecho que el dueño del producto se haga cargo y facilite la transferencia. Además, no poder hacerse cargo podría causar fricción entre los nuevos y antiguos miembros del equipo, o responsabilizar a antiguos miembros del equipo con tareas innecesarias, obligándolos a perder demasiado tiempo comunicándose con los nuevos miembros del equipo y resolviendo distintos problemas.

Sin embargo, si algunos miembros del equipo se quedan a bordo, pueden ser de gran valor en tus esfuerzos de transición. Consulta con ellos, mantenlos informados y trata de aprovechar su experiencia sin inundarlos con demasiadas tareas relacionadas con la transición. ¡No esperes que ellos hagan todo el trabajo pesado! Ese es tu trabajo.

Así que sin más preámbulos, ¡metámonos de lleno en esto!

Reunir Documentación

A los desarrolladores independientes a menudo se les pide saltar en una base de código existente que nunca han visto antes. Esto es especialmente cierto con respecto a los ingenieros de software de Toptal. Nuestro objetivo es siempre ponernos en marcha tan pronto como sea posible para que podamos empezar a tener un impacto positivo para nuestros clientes.

Tener acceso a una documentación clara e íntegra sobre el proyecto puede acelerar dramáticamente el proceso de incorporación, y ayudar a los desarrolladores a evitar errores que pueden impedir el progreso.

Una buena documentación debe cubrir al menos los siguientes temas:

Creación de un entorno de desarrollo - La primera tarea para cualquier nuevo empleado es instalar la aplicación y ponerla en funcionamiento en sus propias computadoras. El proceso para hacer esto varía entre las tecnologías. En general, requiere tareas tales como obtener el código fuente, la creación de la base de datos, la instalación de dependencias, configurar el entorno con claves de la API y las credenciales, la importación de datos de muestra, y así sucesivamente. Los desarrolladores tienen una buena idea de todo lo relacionado con este proceso dentro de sus respectivos campos, y deben tener la capacidad de ajustar los detalles conformemente.
Ejecutar el conjunto de pruebas automatizadas - Al ver pasar las pruebas de una aplicación nos aseguramos que todo se ha configurado correctamente y que los próximos cambios no rompen ninguna de las características actuales.
Implementar en los servidores de ensayo y producción - Actualizar la aplicación en vivo con los nuevos cambios es un proceso altamente estructurado, y el orden de esas operaciones se debe esbozar paso a paso lo más detallado posible.
Cualquier otra información que sea relevante para un nuevo desarrollador a bordo - Cada aplicación tiene su propio conjunto de peculiaridades. Al escribir estas peculiaridades, se le ahorra a futuros equipos, esfuerzos innecesarios en depurar problemas que el equipo anterior ya ha descubierto cómo solucionar.

Una buena documentación es la piedra angular de cualquier transición exitosa. Asegúrate de que tu nuevo equipo tiene todo lo que necesita.

La documentación debe ser escrita por un desarrollador que tenga experiencia de primera mano en la configuración de la aplicación y contribuyendo a la base de códigos.

¡Antes de que ocurra cualquier transición, solicita que el equipo de desarrollo anterior facilite la transferencia de conocimientos mediante la creación de un recurso que toque los temas anteriores!

Si la escritura no es el punto fuerte del equipo, pídeles que registren una o más capturas de pantalla que demuestren la configuración del entorno de desarrollo, despliegue, etc. Hoy en día incluso hay herramientas como Vagrant y Docker que permiten a entornos de desarrollo completos ser empaquetados y distribuidos a los demás. En esencia, en lugar de dar instrucciones a alguien sobre cómo construir un martillo, entregales el martillo.

La prueba de fuego para saber qué tan comprensible y efectiva es la documentación de un proyecto, es la rapidez en que un nuevo desarrollador puede entender la configuración de su entorno de desarrollo y ejecución de su aplicación.

Entiende tu Producto

Tener gran documentación no te exime de la necesidad de conocer los fundamentos de la tecnología de tu propio producto. Como propietario de un producto de software, es tu responsabilidad entender tu aplicación lo mejor posible, incluso si no posees muchos conocimientos técnicos.

¿Sin antecedentes técnicos? No hay excusa para no comprender adecuadamente los componentes básicos de tu proyecto. Te puede costar muy caro.

¿Qué elementos tecnológicos utiliza tu aplicación? - Hay muchos marcos de aplicación común para el back-end y el front-end, y cualquier equipo nuevo de desarrollo debe estar familiarizado con los que utiliza tu aplicación. Algunos ejemplos de tecnologías web de back-end son Ruby on Rails, Node.js, y [Django](https://en.wikipedia.org/wiki/Django_(web_framework). Algunos ejemplos de tecnologías web front-end son React.js, Angular.js, y Ember.js.
¿Dónde se encuentra alojado? - Diferentes servidores web tienen diferentes procesos de implementación, que requieren diversos niveles de experiencia. En los últimos años, las tecnologías de nube han creado una serie de nuevas opciones de alojamiento web, y tendrás que identificar cuál de estos, en concreto, estás utilizando y describir por qué lo elegiste sobre los demás.
¿Cuál es el proceso de desarrollo? - ¿Tu equipo utiliza una herramienta de gestión de control de fuente específica como [Git](https://en.wikipedia.org/wiki/Git_(software)? Si es así, ¿cuál es el proceso por el cual una nueva característica se ha desarrollado, probado, aprobado, e implementado? El proceso debe ser normalizado, debidamente documentado y fácil de reproducir por los nuevos integrantes.
¿Qué servicios de terceros utiliza tu aplicación? - Algunas aplicaciones se basan en servicios de terceros como Shopify. Por favor, ten en cuenta que la dependencia de los servicios de terceros está aumentando gradualmente, e incluso si actualmente no utilizas ningún servicio adicional, tu proyecto puede decidir emplear un servicio de terceros más adelante.
¿En qué plataformas se puede ejecutar tu aplicación? - ¿Tu aplicación es una aplicación de escritorio, aplicación web, sitios web responsive para teléfonos móviles, una aplicación nativa de iOS, aplicación nativa de Android, o alguna otra? ¿Se ejecuta en varias plataformas diferentes? ¿Cuál plataforma es tu prioridad en un momento dado? ¿En cuál plataforma es tu producto más fuerte o más débil? Asegúrate de conocer todos los detalles de las plataformas actuales de tu aplicación, e incluso a cuáles se puede ampliar.

Toma Posesión

El proceso de desarrollo de software de hoy en día utiliza una gran cantidad de servicios de terceros y herramientas. Ya sea que lo sepa o no, tu aplicación no es una excepción.

Durante el trascurso de desarrollo, tu equipo anterior puede haberse registrado o suscrito a tu nombre, o incluso utilizado sus propias cuentas para obtener acceso a los servicios que se necesitaban. La transición a un nuevo equipo significa que debes tomar posesión y estar en control de cada uno de los servicios y herramientas en las cuales tu aplicación está basada, para que así puedas permitir el acceso a tu nuevo equipo, sin necesidad de pasar por un intermediario o perseguir a los desarrolladores originales.

La siguiente lista muestra las diferentes herramientas o servicios externos de los que tu aplicación podría sacar provecho:

Gestión de Fuente de Control - GitHub, Bitbucket, Gitlab
Alojamiento Web - Heroku, EngineYard, Digital Ocean, Bluehost, Amazon Web Services
Alojamiento de archivos - Amazon Web Services (S3)
Proveedor de DNS - GoDaddy, DNSimple, Hover
Servicios de Desarrollo - NewRelic, FileStack, Segment, Bugsnag (y muchos otros)
Servicios de Pago - Stripe, Braintree, PayPal
Servicios de blog - WordPress, Tumblr, Ghost
Soluciones de comercio electrónico - Shopify, Squarespace
Analítica / Seguimiento - Google Analytics, Mixpanel, Kissmetrics
Email Marketing: MailChimp, Constant Contact

Pregúntale a tu equipo de desarrollo saliente cuáles son aplicables. Para cualquiera de los servicios que son de propiedad del equipo de desarrollo, pídeles que te transfieran la propiedad. Si eso no es posible, entonces pídeles ayuda para crear una nueva cuenta y asegúrate de que la aplicación utiliza tu cuenta en lugar de la de ellos. Esto no debería requerir nada más que cambiar algunos ajustes de configuración para tu aplicación. No hace falta decir que debes asegurarte de que cada contrato de desarrollo protege tus intereses desde el primer día y garantiza una transición sin problemas, sin importar la situación.

Autoriza el Acceso

Con una sólida comprensión del ecosistema de tu aplicación y la propiedad de las diversas herramientas y servicios que utiliza, ahora puedes dar acceso completo al equipo entrante o miembro.

La mayoría de los servicios te permitirá añadir un colaborador a tu cuenta y otorgarle un determinado nivel de acceso. Está bien ser conservador en este caso, muchos fundadores, especialmente los empresarios individuales, prefieren dar a sus desarrolladores acceso de administrador a sus servicios y hacer que manejen todo. Esto tiene el efecto secundario de mantenerte fuera del circuito, que como hemos aprendido, puede hacer más difícil la transición en el futuro.

¿Deberías darle a tus desarrolladores privilegios completos de administrador? Es tu decisión, a la mayoría de las personas no parece importarles el uso de este enfoque. Sin embargo, siempre se debe planificar a futuro y asegurarse de que tu decisión no afecte negativamente a un nuevo equipo de desarrollo. De no hacerlo en las primeras etapas del proyecto puede tener consecuencias molestas en el futuro.

Gestionando el traspaso

Ahora que has cubierto todas las bases, necesitas gestionar el traspaso de un equipo a otro. Estos son algunos consejos básicos para enfrentar tanto al equipo entrante como al de salida.

Asegúrate de administrar adecuadamente los aspectos técnicos y personales de tu traspaso de proyecto. Permite que tu nuevo equipo se sienta como en casa.

Equipo Entrante

Establece expectativas - El nuevo equipo debe saber cuáles son tus objetivos más importantes para que puedan centrarse en la dirección correcta. La gestión de tus propias expectativas sobre lo que el nuevo equipo puede lograr de inmediato es igualmente importante.
Realiza visitas de control a menudo - No dejes al nuevo equipo a su suerte. Debes hacer visitas de control con frecuencia para asegurarte de que tienen todo lo que necesitan, y que no se sientan como que tienen que valerse por sí mismos. Trata de hacer esto sin llegar a hacer micro gestión. Asegúrate de que sepan que estás para apoyar y ayudar si lo necesitan, pero no pongas presión innecesaria sobre ellos.
Sé paciente - Se necesita tiempo para que los desarrolladores puedan adaptarse a una nueva base de códigos. Entiende que habrá un poco de tiempo de aprendizaje antes de que el nuevo equipo pueda igualar el ritmo del anterior.

Equipo Saliente

Recolecta todo el código en circulación - Asegúrate de que todo el código fuente se haya registrado en el repositorio principal, y que sabes el estado de lo que se ha desplegado y lo que no. El nuevo equipo tendrá que saber exactamente dónde retomar y empezar a trabajar. Yo mismo he experimentado una situación en la que seguí el trabajo de un equipo que había desplegado código sin ponerlo en el repositorio principal. Esto llevó a que se crearan bugs, la duplicación de trabajo y dolores de cabeza que podrían haberse evitado fácilmente si el equipo saliente hubiera dejado el código fuente en un estado coherente.
Actualiza el nivel de acceso - Si se separaron en buenos términos, es posible que desees mantenerlos con acceso a tu código y/o despliegue. Muchos equipos están dispuestos a ayudar durante la fase de transición, hasta que el nuevo equipo pueda asumir plenamente. Si no, considera cambiar o revocar el acceso para evitar cualquier problema accidental o conflictos con el nuevo equipo.
Dales las gracias por su trabajo - Las transiciones pueden ser agitadas. Mientras estás ocupado con el nuevo equipo, no te olvides de agradecer a tu equipo saliente por su contribución al proyecto.

Conclusión

Cualquier transición en la vida puede dar miedo, lo cual trae la incertidumbre de si funcionará o no, el miedo a lo desconocido, y así sucesivamente. La transición a un nuevo equipo de desarrollo no es diferente, pero puedes y debes tomar medidas para que sea más fácil. En la mayoría de los casos, sólo se requiere un poco de planificación a largo plazo.

Tener un mayor conocimiento técnico y no técnico de tu producto de software, el proceso de desarrollo, y todas las cosas que entraron en el proceso ayudará a que cualquier transición de un equipo a otro, sea tan tranquila y sin dolor como sea posible.

Lo mejor de todo: ¡Tu nuevo equipo te respetará y dará las gracias por estar preparado! Es probable que les ahorre tiempo y esfuerzo, lo que también significa que vas a ahorrar dinero. Además, cuanto más pronto el nuevo equipo se dé cuenta de la insistencia en un alto nivel profesional, mejor. Lo más probable es que continúen la implementación de estas prácticas una vez tomen el control del proyecto, por lo que la próxima transición será también sin problemas.

Así que vamos a revisar los puntos clave que deben preceder a cualquier transferencia de propiedad de tu producto de software:

Recoger o crear la mayor documentación posible acerca de tu aplicación, el entorno de desarrollo y el proceso de despliegue.
Conocer tu producto dentro y por fuera.
Mantener el control de todos los servicios y dependencias de terceros de tu aplicación, y tener los nombres de usuario y contraseñas para todo.
Esté preparado para darle a tu nuevo equipo acceso a todo lo que necesitan para empezar a funcionar.
Sé proactivo y no dejes nada al azar, o para el equipo de desarrollo de salida.

Por: Carlos Ramirez III
Articulo vía: Toptal

SaaS - Tácticas de Fijación de Precios Que Pueden Catapultar Tu Negocio

2017-06-24T21:59:00.001-03:00

La fijación de precios es una de las palancas financieras más importantes que tienen las compañías a su disposición para influenciar el éxito financiero de su negocio. Sin embargo, no es una tarea fácil.

Primero, la fijación de precios afecta a múltiples inversionistas, dentro y fuera de la compañía. Experimentar con la fijación de precios no es una tarea que se deba tomar con ligereza. Segundo, encontrar el precio correcto es notoriamente difícil. Las preferencias de los clientes son difíciles de estimar con anticipación, e internamente, puede ser difícil anticipar los efectos de los cambios de precio en el desempeño financiero de una compañía. Y finalmente, por supuesto, la fijación de precios no sucede en un espacio vacío. En cualquier mercado competitivo, el cambio de precios puede llevar, a menudo, a acciones que podrían cancelar el efecto deseado del ajuste de precios.

Con esto en mente, las técnicas y los métodos necesarios para estos retos son extremadamente útiles.

En mi experiencia, habiendo co-fundado una empresa de herramientas de desarrolladores que usa el modelo SaaS, he aprendido a apreciar el modelo de negocios SaaS como algo, entre otras cosas, que muestra buena relación con los precios. Las características intrínsecas de SaaS y su mecanismo de entrega tiene ramificaciones importantes relacionadas a la fijación de precios, lo cual, como resultado, puede ser muy útil en el manejo financiero de tu compañía.

En este artículo, exploro en más detalle lo que son y cómo pueden beneficiar tu negocio desde un análisis financiero y un punto de vista administrativo.

¿Qué es SaaS?

Software como Servicio (SaaS) es un modelo de entrega y licencia software en el cual el software tiene licencia de mano de una tercera parte y es entregado a los clientes a través de la internet. Comparado con modelos software alojados localmente, los clientes SaaS no tienen que instalar el software, actualizarlo, mantenerlo e integrarlo. La gran mayoría de los aspectos técnicos están “bajo control” gracias al proveedor SaaS, para que el cliente pueda empezar a usar el producto SaaS con poco esfuerzo.

Las ramificaciones y beneficios de SaaS versus otros tipos de servicios son expuestos gráficamente en la gráfica #1 abajo. Como puedes ver, con software tradicionales on-premises, el cliente tiene que manejar la mayoría de las actividades relacionadas a la instalación y ejecución del software. Del otro lado del espectro, SaaS se encarga de todo esto del lado del proveedor del software. Hay sombras dentro; por ejemplo, la Infraestructura como servicio y la Plataforma como Servicio.

Los pros y contras de SaaS son muy directos. Por una parte, SaaS es mucho más fácil de instalar y ejecutar. No requiere servidores locales, almacenamiento, administración, etc. Por otra parte, no permite el mismo nivel de personalización que un software on-premises puede proporcionar.

El cambio de un software alojado localmente a SaaS se ha estado dando por un tiempo y es parte de un cambio más general en la industria IT a aplicaciones basadas en la nube. Según FTI Consulting, 69% de los negocioshoy en día usan al menos una aplicación basada en la nube.

El cambio para SaaS desde servicios on-premises pueden ser vistos muy bien cuando observamos Adobe, uno de los jugadores mejor conocidos de la industria. Como se puede ver en la gráfica #2, cortesía de Tom Tunguz, las ganancias del producto de Adobe que no es parte de SaaS, alcanzó 3.4 billones de dólares en 2011 y se redujo a 1.6 billones de dólares en solo tres años. Una reducción tan grande en ganancias, normalmente, traería ramificaciones pero Adobe también ha estado ofreciendo una variedad de productos SaaS, lo cual ha incrementado cinco veces más las ganancias, de 0.45 billones de dólares en 2011 a 2.1 billones en 2014. La mezcla en los cambios de productos de Adobe es indicativo del cambio general de la industria al alejarse de los software alojados localmente y dirigirse a las provisiones de software basados en la nube, como SaaS.

Todo indica que esta tendencia tiene muchas probabilidades de continuar. Gartner estima que el software de aplicación fue un mercado de 144 billones de dólares en 2016 y que, para 2020, los negocios se estarán cambiando a software basados en la nube, al ritmo de 216 billones de dólares al año.

SaaS es un Modelo de Negocios que se Relaciona Bien con la Fijación de Precios

Como ya lo mencioné, las razones para este cambio a aplicaciones basadas en la nube son variadas. Los costos más bajos de instalación y mantenimiento son, por supuesto, un factor importante. Sin embargo, un beneficio importante que he descubierto en las aplicaciones basadas en SaaS es que dan mucha importancia a la fijación de precios. Así, gana tanto el cliente como los negocios que proporcionan el servicio y creo que juega un papel importante al momento de explicar el cambio de industria de manera general.

En particular, hay muchas características operacionales intrínsecas de SaaS como modelo de negocio, que por su parte tiene implicaciones sobre la fijación de precios y específicamente, crea y magnifica el número de impulsos de fijación de precios que los negocios tienen a su disposición. En particular, resalto cuatro beneficios relacionados con fijación de precios de los productos SaaS:

Flexibilidad: Por la naturaleza basada en la web y naturaleza de tiempo real del mecanismo de entrega, los productos SaaS son muy flexibles y permiten una iteración constante. Esto afecta la fijación de precios también, ya que los cambios en la fijación de precios puede ser relativamente fácil de implementar y el impacto de estos cambios se puede medir inmediatamente. Se puede seguir iterando hasta que se alcance el precio deseado.
Seguimiento de Uso en Tiempo Real: Ya que los productos SaaS están en la nube, el uso del software por un cliente es seguido en tiempo real del lado del proveedor del servicio. Esto significa que las compañías SaaS tienen más capacidad de cobrar en base a cada usuario que las compañías tradicionales on-premises. Esto tiene varios beneficios detallados abajo.
Efectos de Red: El mecanismo de entrega e implementación tranquila de los productos SaaS actúa como un activador de los efectos de red. Esto tiene ramificaciones importantes en la fijación de precios, lo cual hace más fácil crear y cambiar por estos efectos de red, y así, en teoría, maximizar la monetización.
Freemium: Debido al costo de casi cero de los costos de margen de entrega y alojamiento de productos, las compañías SaaS son más capaces de permitirle a los clientes usar ciertos productos de manera gratuita por meses o hasta años, hasta que actualicen o cancelen el servicio. Freemium previene que la fijación de precios del producto llegue a ser una barrera para los usuarios que prueban o adoptan el producto, y así se aumenta el número de posibles clientes.

Beneficio No. 1: Flexibilidad de Fijación de Precios

El primer y sin duda más importante beneficio financiero de adoptar un modelo SaaS es la flexibilidad inherente que ofrece el modelo. En particular, la flexibilidad se refiere a los siguientes atributos:

Iteración Rápida: Gracias al mecanismo de entrega, SaaS te permite iterar rápidamente en los cambios de fijación de precios para que puedas hacer pruebas de puntos de precio y paquetes hasta que llegues a la mezcla óptima.
Fijación de Precios por Parte: SaaS se presta muy bien para una fijación de precios por parte, lo cual significa que tiene la habilidad de poner precios a diferentes ofertas de productos, a diferencia de dirigirse a sub-segmentos de múltiples clientes.
Sin Intermediarios: SaaS es entregado directamente al cliente, sin pasar por intermediarios. Esto remueve un inversionista clave de la ecuación y le regresa a la compañía una gran flexibilidad para probar diferentes puntos de fijación de precios y paquetes.

Un ejemplo práctico de esto se puede observar al analizar la evaluación de Zendesk en fijación de precios. Zendesk es una exitosa compañía software de servicio al consumidor, la cual genera más de 300 millones de dólares en ganancias anuales. Ofrece diferentes características del mismo producto a diferentes segmentos del cliente.

Como se ve en el ejemplo de abajo, en enero de 2015, Zendesk ofrecía cinco planes diferentes para cinco segmentos diferentes. Su plan más económico estuvo disponible a 1 dólar por agente por mes, mientras que el más caro era 195 dólares por agente por mes. También dirigió a los usuarios hacia el plan “Plus” al resaltarlo en verde.

Muestra 2: Opciones de Fijación de Precios de Zendesk en Enero de 2015

Source: Archive.org

En enero, 2016, Zendesk debe haber sentido que había todavía algo que mejorar en la fijación de precios; ellos disminuyeron el número total de planes de cinco a cuatro. También hicieron cambios en la fijación de precios de planes, donde el plan menos costoso aumentó de 1 a 5 dólares por agente por mes, mientras el más costoso disminuyó de 199 a 99 dólares por agente por mes. Los nombres de los planes también fueron cambiados (ej., “Starter” a “Essential”) y los usuarios fueron dirigidos al plan “Professional” con una técnica de resaltado más ligera.

Muestra 3: Opciones de Fijación de Precios de Zendesk en Enero de 2016

Source: Archive.org

En 2017, la fijación de precios cambió nuevamente y el número de planes aumentó de nuevo a cinco. Mientras que el plan menos costoso se mantuvo en 5 dólares por agente por mes, su plan más costoso aumentó de 99 a 199 dólares por agente por mes. Al remover lo resaltado, Zendesk dejó de dirigir a las personas a cualquier plan.

Muestra 4: Opciones de Fijación de Precios de Zendesk en Enero de 2017

Source: Zendesk Pricing Page

Zendesk, desafortunadamente, no revela los efectos específicos que los cambios de fijación de precios han tenido. Sin embargo, el punto más general que muestra lo útil de la flexibilidad se resume muy bien en este post: “Encontrar el balance correcto entre valor y ganancia - tu habilidad para ayudar a los clientes y ser compensados de manera justa por esa ayuda - te llevará al éxito o al fracaso […] empresa.” Sin duda, los cambios de Zendesk son una reflexión de este punto.

Para resumir, SaaS, como mecanismo de entrega, permite una capacidad más grande de flexibilidad e iteración en cuanto a fijación de precios. Como lo dice Lincoln Murphy de Sixteen Ventures, “La fijación de precios (como casi todo) nunca es una situación donde se instala y se olvida,” así que la habilidad de iterar, probar, aprender y mejorar es una característica muy útil del modelo de negocios SaaS.

Análisis de Cohorte

Si los resultados de los cambios de fijación de precios no pueden ser medidos de una manera definitiva, no tiene sentido iterar. Así que es importante instalar una colección de data apropiada, al igual que procesos de medidas y herramientas desde el comienzo.

Una de las maneras de medir los resultados es a través de un análisis de cohorte. En este análisis, se coloca a los clientes en diferentes cohortes (grupos) basados en una característica, normalmente un periodo de tiempo seleccionado. Todos los nuevos clientes se pueden dividir en cohortes basadas en la fecha en que se hicieron clientes. Por ejemplo, puede haber diferentes cohortes como clientes que se unen en enero, febrero, marzo y etc.

Las herramientas analíticas como Mixpanel ofrece análisis de cohorte basados en la data que recolectan. Como se ve en el ejemplo de abajo (Tabla 1), la retención está siendo analizada para medir cuántas personas siguen usando un producto ficticio a lo largo del tiempo. Para entrar en detalles, la cohorte del 27 de abril de 2014 tiene una tasa de retención de 23% en la semana 6, lo cual quiere decir que el 23% de las personas que se inscribieron en la semana del 27 de abril de 2014 siguen usando el producto en la 6ta semana. La cohorte del 13 de julio de 2014 tiene una tasa de retención de 9.6% en la semana 6, esto indica una baja significativa en las tasas de retención, lo cual a su vez significa un gran problema con esta cohorte o una acción tomada dentro de ese periodo de tiempo.

El aspecto crítico del análisis de cohorte es la disponibilidad de data, así que es crucial que la data que será la base del análisis de cohorte sea recolectada correctamente y disponible cuando sea necesario.

Menos es Más

En un estudio bien conocido realizado por los psicólogos Sheena Lyengar y Maek Lepper, se mostró que las opciones múltiples pueden producir “parálisis de elección.” Como se explica en este artículo HBR:

“[…] consumidores en un supermercado importante vieron una mesa de muestra con 24 variedades de mermelada gourmet. Aquellos que probaron las muestras recibieron un cupón de 1 dólar en cualquiera de las mermeladas. En un día diferente, los consumidores vieron una mesa similar, excepto que solo se mostraban seis variedades de la mermelada. La muestra más grande atraía más interés que la pequeña. Pero al momento de comprar, las personas que vieron la muestra grande tenían posibilidad 1 de 10 de comprar, a diferencia de las personas que vieron la muestra más pequeña.”

Debido a la fijación de precios tan distante, la ausencia de intermediarios y las capacidades de iteración de SaaS, un producto puede ser ofrecido en muchas formas diferentes. Sin embargo, se debe tener cuidado de no crear una instancia de parálisis de opciones; por esto, es indispensable, de igual manera, acercarse a la fijación de precios desde una perspectiva de diseño.

Un ejemplo práctico de esto se puede ver con Hubspot. Hubspot es una plataforma de administración de mercadeo y ventas que automatiza y hace que el mercadeo por correo electrónico, la analítica y el SEO sean más efectivos. PriceIntellingently hace un buen trabajo explicando cómo, a pesar de que la fijación de precios de Hubspot se puede mostrar en una variedad de formas (ej., una barra en movimiento que muestra el aumento en la fijación de precios mientras aumenta el número de contactos), solo tres planes diferentes fueron creados basados en tres diferentes valores métricos. Esto hace que estos planes sean más fáciles de seguir y entender.

Beneficio No. 2: Fijación de Precios “Por-uso”

El segundo beneficio clave de los productos SaaS es que por el mecanismo de entrega, SaaS se presta muy bien para una fijación de precios por-uso. Estos se dan porque el uso del cliente se puede seguir y medir apropiadamente, ya que el software se ejecuta desde el lado del proveedor del servicio.

Fijación de precios por-uso es una herramienta de fijación de precios muy útil, por los siguientes motivos:

Crea una barrera más baja para la adopción del cliente.

Los usuarios enfrentan una barrera financiera directa más baja al inscribirse en el servicio, ya que saben que sus gastos estarán nivelados con su uso. En contraste, los software tradicionales on-premises normalmente cobra una tarifa estándar basada en una suposición de uso estimado. Este estimado no necesariamente se relaciona con las necesidades del cliente en cuestión.

Como lo señaló Reason Street en este artículo, “Por el bajo o ningún costo de las tarifas de las nuevas empresas, los clientes de empresas que normalmente se toman de seis meses a un año para tomar una decisión sobre el software de la empresa, a menudo se saltan esta decisión y simplemente empiezan a probar el servicio. Los clientes después aumentan su uso basándose en la necesidad real de la empresa (Pagando por adelantado las licencias de tarifas por puesto).”

Los Costos se Pueden Alinear Mejor con Las Ganancias.

La fijación de precios por uso también le permite al proveedor del servicio alinear mejor sus propios costos con sus ganancias, ya que la ganancia que recibe está atada a los costos, ésta se contrae para cobrar el servicio. Como señala, Reason Street “Para las nuevas empresas software, particularmente en el sector SaaS, una vez que es construido el producto viable mínimo inicial, las empresas pueden escalar ganancias más cerca a la escala en costos requeridos para hacer entrega del servicio. Algunas empresas SaaS prefieren pago-por-usuario, porque la relación de valor se hace muy clara para el cliente, y pueden priorizar el desarrollo de características y servicio basado en las necesidades expresadas por el cliente.”

La fijación de precios por-uso lleva a una mayor adhesión.

La fijación de precios por-uso normalmente lleva a una adhesión mayor por parte de los clientes y esto tiene dos razones importantes.

Primero, ya que los gastos del cliente se extienden por un gran periodo de tiempo, sus costos en cualquier momento serán pequeños comparados con otros costos por los que pasan sus negocios. Como resultado, pueden no estar tentados a disminuir estos. Por supuesto, si el cliente viera estos costos por completo (o hasta un periodo de tiempo más largo) podría notar que el costo total es mucho mayor, pero la psicología humana no siempre sigue la lógica.

Segundo, dado que la fijación de precios por-uso lleva a barreras de adopción más bajas (como se explica abajo), los clientes tienden a darle una oportunidad de prueba al servicio. Mientras continúan usando el servicio, el software puede ser puesto a un lado en los procesos diarios de la compañía, haciendo más difícil y costoso cambiar proveedores. Andreessen Horowitz resume este punto y los beneficios relacionados muy bien:

“Una vez una empresa SaaS ha generado suficiente dinero por su base de clientes instalada para cubrir el costo de adquirir nuevos clientes, esos clientes se quedan por mucho tiempo. Estos negocios son inherentemente adheridos porque el cliente ha, esencialmente, subcontratado al ejecutar su software al vendedor […]

Es muy difícil cambiar vendedores SaaS una vez que están dentro del ritmo de trabajo del negocio. Los clientes SaaS, por definición, tomaron la decisión de tener un vendedor externo para manejar la aplicación. En el modelo de licencia perpetua, el equipo interno IT manejó todas las instancias software y así podría tomar el costo interno para poder cambiar de vendedores si así lo quieren.”

La fijación de precios por-uso permite la fijación de precios por suscripción, la cual ayuda con el plan financiero.

Para estar claros, la fijación de precios por-uso no siempre es buena. Hay un intercambio de flujo de efectivo muy claro, que viene de un cambio de licencia directa a la fijación de precios por-uso. Este efecto se ilustra muy bien nuevamente, por Andreessen Horowitz:

“En el mundo software tradicional, las empresas como Oracle y Sap hacen la mayor parte de su negocio al vender una licencia perpetua para su software y luego venden actualizaciones para éste. En este modelo, los clientes pagan por la licencia software por adelantado y luego, normalmente, pagan una tarifa de mantenimiento anual (alrededor de 15-20% de la tarifa de licencia original). Aquellos de nosotros que venimos de este mundo llamaríamos a esta transacción una “dineroctomía”: El cliente pregunta cuánto cuesta el software y luego el vendedor pregunta al cliente cuál es su presupuesto; milagrosamente, el costo iguala el presupuesto y, voila, la operación de dineroctomía se completa.

Esto es perfecto para compañías de software antiguo y es excelente para la contaduría de estados de cuenta de ganancia tradicional. ¿Por qué? Porque el tiempo de ganancias y gastos están perfectamente alineados. Todos los costos de tarifa de licencia van directamente a la línea de ganancias y todos los gastos asociados se reflejan igualmente, así que 1 millón de dólares en tarifas de licencias vendidas en el trimestre, se muestra como 1 millón de dólares en ganancias en el trimestre. Así es como las compañías software pueden obtener la rentabilidad de la declaración de ingresos en los inicios de ciclo de vida.

Ahora, compara eso con lo que pasa con SaaS. En vez de comprar una licencia perpetua para el software, el cliente está accediendo a usar el software de manera continua, a través de un modelo basado en servicio — por ello el término “software como servicio”. Aunque un cliente, normalmente, firma un contrato por 12-24 meses, la empresa no puede reconocer esos 12-24 meses de tarifas como ganancias por adelantado. Por el contrario, las reglas de contaduría requieren que la empresa reconozca ganancias en el momento en que se entrega el servicio software (así que para un contrato de 12 meses, la ganancia cada mes a 1/12 del valor total del contrato).

Todavía la empresa causó que casi todos sus gastos pudieran adquirir a ese cliente desde el comienzo — ventas y mercadeo, desarrollo y mantenimiento del software, alojar infraestructura — por adelantado. Muchos de estos gastos por adelantado no tienen un reconocimiento a lo largo del tiempo en la declaración de ingresos y ahí está el problema: El tiempo de ganancia y gastos están mal alineados.”

Este efecto se muestra gráficamente en las gráficas 3 y 4 debajo:

Sin embargo, como se puede ver claramente en la gráfica de arriba, el mayor beneficio de la suscripción de fijación de precios es que provee un ciclo de flujo de dinero más estable y predecible, el cual puede ser de gran ayuda cuando se trata de planes financieros. Esto ayuda a explicar por qué a la gran mayoría de los productos SaaS se les fija precios en base mensual o de suscripción.

Beneficio No. 3: Crea y Cobra para Efectos de Red

Otro beneficio importante de la fijación de precios en los productos SaaS, ya que estos se prestan bien para los efectos de red y esto tiene implicaciones útiles para la fijación de precios. Para ser más preciso, cuando decimos que SaaS “se prestan bien para los efectos de red”, queremos decir que a) SaaS puede ser un habilitador para crear efectos de red, y b) SaaS como mecanismo de entrega es, a menudo, más práctico para actividades que ya se benefician de efectos de red naturales. Antes de pasar a ver las implicaciones de fijación de precios en este punto, entendamos un poco más como SaaS se presta muy bien para efectos de red.

SaaS como un Habilitador Poderoso de Efectos de Red

Como mencionamos, los atributos específicos de los productos SaaS, a menudo, significa que estos pueden ser habilitadores poderosos para efectos de red. Existen tres razones específicas:

1) SaaS es un buen software de colaboración, dado que es entregado por internet.

Al usar el internet, en vez de una entrega alojada localmente, el software SaaS les permite a las personas colaborar en tiempo real (ej. Google Docs) y ver cosas simultáneamente. También evita los problemas de interoperabilidad entre diferentes usuarios (tal vez por sus sistemas operativos), de nuevo esto hace la colaboración más fácil.

Como se señala aquí, la facilidad de la colaboración para los productos SaaS es “porque la colaboración es una de las categorías SaaS más pobladas y cambiantes.” Algunos ejemplos de compañías en este espacio incluyen servicios como Campfire para la colaboración en equipo, Basecamp para gestión de proyecto, AnyMeeting para conferencia web, Vidyo para conferencia por vídeo, Box para almacenamiento y Google Apps para productividad.

2) SaaS hace más fácil trabajar con fuentes externas, dado que hay menos problemas interoperacionales.

La mayoría de los negocios tienen que interactuar con múltiples terceras partes, ya sean vendedores, proveedores, freelancers, etc. Cuando se usa el software para trabajar juntos, la interoperabilidad de este software pasa a ser un problema. SaaS resuelve esto al remover la interoperabilidad (aparte de la interoperabilidad en el nivel de buscador, que es muy mínima en la mayoría de los casos). Como se ve aquí, “está la más obvia que está conectando unos negocios con otros. Por ejemplo, si estás en manejo de compras y conectas compañías a posibles proveedores, como lo hace Kinnek. Esto crea un lugar en el mercado como efectos de red donde más proveedores crean más compradores de valor y viceversa.”

Una repercusión de esto es que, dado que SaaS es relativamente fácil de instalar y ejecutar, agrega menos fricción al momento de convencer a otras partes de ejecutar el mismo software que tú, lo cual hace más fácil crear efectos de red.

3) SaaS permite efectos de red habilitados por data.

Ya que SaaS permite rastreo de data en tiempo real, también puede llevar los llamados efectos de red habilitados por data. En este fascinante blog post por Tomas Tunguz, Capitalista Emprendedor en Redpoint Ventures, el resalta este punto (específicamente refiriéndose a los lugares de mercado habilitados por SaaS) de la siguiente forma:

“Ya que SEM implementa SaaS para el lado del proveedor y el de la demanda, estas compañías pueden desarrollar un entendimiento excepcional de su mercado. Acceso a la data del proveedor y la demanda del consumidor proporciona 4 ventajas clave para SEM.

Primero, SEM entiende la curva provisión/demanda en todo segundo […] Consecuentemente, si hay un desbalance provisión/demanda, el SEM puede [entrar] a hacer un balance del mercado.

Segundo, SEM entiende la excelencia operacional de sus proveedores […] El SEM puede calificar mejor y unir provisión y demanda.

Tercero, la data acumulada en la demanda del consumidor y desempeño del proveedor, se compone en un valor único de data que crea una fosa alrededor del negocio.

Cuarto, por la visibilidad de provisión/demanda, un gran conocimiento sobre la excelencia del proveedor y la habilidad de identificar los tipos correctos de compradores y vendedores, SEM se beneficia de un mercado más eficiente.”

Beneficios de Fijación de Precios de los Efectos de Red

El beneficio de fijación de precios de lo mostrado arriba es que SaaS hace más fácil fijar precios de productos, para que así los efectos de red sean alentados primero y luego aprovechados. Específicamente por el mecanismo de entrega, SaaS hace más fácil implementar pago por cuenta o pago por sistema de fijación de precios de usuario.

Los beneficios de la fijación de precios por usuario con relación a efectos de red se pueden resumir de la siguiente manera: dado que en una base por usuario el costo es relativamente menor, esto introduce poca fricción para compañías al probar un servicio. Si así lo hacen, y asumiendo que les guste, esto da inicio a la creación de efectos de red. Una vez que los efectos de red se establecen, las compañías sacan el producto SaaS a la organización más amplia, la cual a su vez permite al modelo de fijación de precios por usuario, “manejar” la salida y capturar el máximo de ganancias. En muchos casos, no se ofrece descuento para grandes volúmenes por la “adicción” al servicio que ha creado el efecto de red.

Un buen ejemplo de lo anterior es JIRA. JIRA es un producto software encargado de gestión de proyecto y rastreo de problemas, proporcionado por Atlassian, una compañía Australiana de productos SaaS de 6 billones de dólares. JIRA permite a los desarrolladores documentar y revisar bugs y otros problemas, al igual que realizar funciones de gestión de proyectos. Mientras más personas usen JIRA, más valioso es para cada usuario.

Como resultado de esto, la fijación de precios de JIRA refleja los efectos de red. Mientras aumenta el número de usuarios usando el producto, la fijación de precios por usuario también aumenta. Para un equipo pequeño, de 10 personas, se fija un precio de 10 dólares por usuario mientras que para 50 personas la fijación es de 50 dólares, lo cual es un aumento de cinco veces (Tabla 2).

Mientras que el efecto exacto de esta fijación de precios es imposible de conocer, un vistazo rápido al reporte anual (página 44 y 49) de Atlassian, muestra que la ganancia en cuanto a subscriptores aumentó un 1200% (12.24 millones de dólares en 2014 a 146.66 millones de dólares en 2016) mientras que el número de clientes aumentó un 80% (37,250 en 2014 a 60,950 en 2016). La matemática simple muestra que si la fijación de precios hubiese quedado igual, las ganancias de Atlassian serían solo de 22 millones de dólares, debido a un aumento de 80% en el número de clientes. En otras palabras, gracias a los cambios en su fijación de precios, Atlassian genera unos 124 millones de dólares adicionales (146 millones de dólares - 22 millones de dólares) por año!

El punto general de cobrar por efectos de red se resume muy bien en este ensayo academico: “La presencia de efecto de red también favorece el pago por uso sobre la licencia perpetua; si el efecto de red es fuerte, el pago por uso siempre dominará la licencia perpetua sin importar el costo inconveniente o una potencial piratería. Con más clientes heterogéneos, una potencial piratería más alta, costos inconvenientes más bajos y efectos de red más fuertes, la licencia de pago por uso da paso a más ganancias de vendedores pero también un excedente social más alto que la licencia perpetua”.

Beneficio No. 4: Freemium - La Fijación de Precios como Estrategia de Mercadeo

Freemium es una estrategia de mercadeo donde una parte o todo el producto se ofrece con cero fijación de precios por tiempo ilimitado. La parte “-mium” de la palabra “freemium” se refiere a “premium”, donde el usuario del producto gratis podría actualizar a un producto premium, ej., pagar por el producto. Freemium se ofrece con la esperanza de que algunos de los usuarios del producto gratis actualicen a premium, pero esta oferta es por tiempo ilimitado, para que así los usuarios puedan actualizar cuando lo deseen.

Los beneficios de freemium se resumen muy bien en este Artículo de Reseña de Harvard Business:

“Muchos factores contribuyen al atractivo de la estrategia freemium. Ya que las características gratis son una herramienta de mercadeo potente, el modelo permite a una nueva empresa avanzar y atraer una base de usuario sin gastar recursos en campañas de publicidad o una fuerza de ventas tradicional. Las tarifas de suscripción mensual que normalmente se cobran, están demostrando ser una fuente más sustentable de ganancias que el modelo de publicidad que prevalece entre las empresas en línea en los inicios del 2000. Las redes sociales son conductores poderosos: Muchos servicios ofrecen incentivos por referir amigos (lo cual es más atractivo cuando el producto es gratis). Y freemium es más exitoso que las pruebas gratis de 30 días u otras ofertas de tiempo limitado, porque los clientes se han vuelto cautelosos con los procesos de cancelación engorrosos y les parece que el acceso gratis ilimitado es más convincente”.

La pertinencia de esto para el modelo SaaS es que freemium solo funciona si el precio de entrega del servicio gratis es marginal. Si no, es poco probable que freemium funcione desde un punto de vista financiero. Afortunadamente para SaaS, este es uno de los beneficios inherentes del mecanismo de entrega. (Gráfica #5).

Así, SaaS se presta muy bien para ofrecer la fijación de precios freemium. Este punto se resume muy bien en este post,

“Para que el modelo freemium funcione, un atributo específico del producto ya debe estar en funcionamiento - baja distribución marginal y costo de producción. Solo si puedes mantener el costo lo más bajo posible, un usuario gratis extra te costará nada más que una entrada de base de datos […] ésta es una característica inherente de los productos SaaS”

Una compañía que tiene una excelente oferta freemium SaaS es Slack, la cual tiene más de 4 millones de usuarios activos diariamente hasta ahora. De estos usuarios, 1.25 millones son pagos pero los otros 2.75 millones están usando el producto gratis. La fijación de precios no previene que usen el producto y los hace usuarios pagos potencialmente en meses y años venideros. En otras palabras, muchas ventajas se adquieren gracias a la fijación de precios de cero-dólares.

Slack parece estar beneficiándose de su estructura freemium, con una tasa de conversión anunciada de 30%. En otras palabras, de los 2.75 millones de usuarios que usan Slack gratis, se espera que 800,000 pasen a ser usuarios pagos en el futuro. Eso es muchas ganancias recurrentes; para ser un poco más preciso, a 6.67 dólares/mes/usuario con su plan más económico, eso es 5.3 millones de dólares adicionales en ganancias al mes.

No todos los productos se crean igual; por esto, cada producto podría tener una oferta freemium diferente, al igual que una tasa de conversión. Por ejemplo, mientras que Spotify tiene una tasa de conversión de 27% de freemium a premium, Dropbox tiene una tasa de 4%. Por este motivo, cada compañía debería descubrir si freemium es asequible. Sin embargo, como dice, Ben Chestnut, co-fundador de MailChimp, el día del helado gratis de Ben & Jerry’s mostró que freemium podría ser muy poderoso y lo ha sido para MailChimp desde que empezaron a ofrecerlo, ocho largos años después de fundar la compañía.

N.B. En este artículo, *Freemium* se define como una oferta de un producto a un cliente por tiempo ilimitado. Una prueba gratis se define como una oferta de un producto pago a un cliente por un tiempo limitado. Una prueba gratis no se considera *freemium*, ya que no se puede ofrecer indefinidamente. Para leer más sobre la implementación de *freemium* y pruebas gratis, por favor revisa este artículo de Lincoln Murphy.

En Una Nube

Mientras más y más compañías cambian una provisión de servicios basada en la nube, el cambio de SaaS a software on-premises seguramente continúe de manera estable. Y creemos que es algo bueno. Las nuevas empresas tendrán más facilidad de ofrecer el mismo servicio que compañías más grandes y establecidas solo han podido hacer gracias a grandes inversiones en habilidades internas. Los clientes tendrán más flexibilidad de encontrar productos que hagan un balance de sus necesidades con su bolsillo. En otras palabras, SaaS crea situaciones de éxito a través del espectro.

Mientras la tecnología SaaS y nuestro entendimiento de sus beneficios se desarrolla, esperamos ver más modelos de fijación de precios emerger para aprovecharse de este modelo tan único. Los ejemplos dados no son exhaustivos, y son solo un reflejo de los tipos de implementación de fijación de precios usada en el mundo SaaS, espero que este artículo pueda servir de guía para retos y oportunidades continuas en fijación de precios.

Por: Tayfun Uslu
Articulo vía: Toptal

Introducción A PHP 7: Qué Hay De Nuevo Y Qué Se Ha Ido

2017-06-18T22:00:00.000-03:00

Uno de los eventos más emocionantes en el 2015 en el mundo de PHP fue el lanzamiento de PHP 7;10 años después del lanzamiento de la última versión principal, PHP 5. Con un gran paso adelante, PHP 7 introduce un montón de nuevas características y actualizaciones de rendimiento.

Sin embargo, también elimina la funcionalidad antigua, obsoleta, que introduce algunos pausas de compatibilidad, lo que hace más difícil para las aplicaciones más antiguas migrar a la nueva versión. Esta guía debe servir como un recorrido rápido sobre qué esperar si planeas mover sus aplicaciones existentes, o construir otras nuevas, encima de PHP 7.

Pero Espera, ¿ A Dónde Fue PHP 6?

Si no has estado trabajando con PHP últimamente, puedes preguntarte qué pasó con PHP 6, ¿por qué el salto de PHP 5 a PHP 7? Bueno, larga historia corta, PHP 6 fue un fracaso. La característica principal de la versión 6 era el soporte nativo de caracteres Unicode, ya que PHP se utiliza principalmente en el desarrollo web y la web necesita Unicode, por lo que el movimiento para traer Unicode a PHP tenía sentido.

La idea era traer un soporte completo para Unicode al núcleo mismo. Habría traído capacidades extendidas al lenguaje: desde la habilidad de usar emojis tontos, como nombres de variables y de funciones, hasta poderosas funciones internacionales de cuerdas. Por ejemplo, cuando otro idioma utiliza letras mayúsculas y minúsculas de manera diferente al inglés, o cuando un nombre en caracteres chinos necesita ser convertido al inglés.

PHP 6 era ambicioso, pero basura. Así es como terminamos con PHP 7, saltando la versión 6 en el proceso.

Desafortunadamente, este ambicioso plan resultó ser un mayor problema de lo previsto. La mayor parte de la base de código tenía que ser portada para soportar Unicode tanto para las extensiones principales como para las importantes, lo que resultó tedioso y complicado. Esto frenó el desarrollo de otras características en el lenguaje, frustrando a muchos desarrolladores de PHP en el proceso. Se presentaron obstáculos adicionales, lo que resultó en menos interés en el desarrollo de un soporte nativo de Unicode, lo que finalmente llevó al abandono del proyecto.

Dado que los recursos, tales como libros y artículos, se habían escrito para PHP 6 y su soporte Unicode, la nueva versión sería renombrada PHP 7 para evitar la confusión.

De todos modos, suficiente sufrimiento del pasado triste, vamos a ver lo que PHP 7 trae a la fiesta.

Batalla De Rendimiento, PHP 7 vs. PHP 5

Con prácticamente todas las actualizaciones, se esperan mejoras de rendimiento menores. Sin embargo, esta vez PHP trae una mejora significativa sobre versiones anteriores que hacen el funcionamiento escarpado una de las características más atractivas de PHP 7. Esto viene como parte del proyecto “PHPNG”, que aborda los componentes internos del propio motor Zend.

Mediante la refactorización de estructuras de datos internas y la adición de un paso intermedio para codificar la compilación en forma de un árbol de sintaxis abstracto (AST), el resultado es un rendimiento superior y una asignación de memoria más eficiente. Los números mismos parecen muy prometedores; Los Benchmarksrealizados en aplicaciones del mundo real muestran que PHP 7 es dos veces más rápido que PHP 5.6 en promedio y que resulta en un 50% menos de consumo de memoria durante las solicitudes, convirtiendo a PHP 7 en un fuerte rival para el compilador HHVM JIT de Facebook. Echa un vistazo a este infográfico de Zend representando el rendimiento de algunos comunes CMS y Frameworks.

PHP 7 se ve y se siente familiar, pero está ajustado para el rendimiento. El refinado Motor Zend y las ganancias de rendimiento resultantes hacen una gran diferencia.

La disminución en el consumo de memoria también permite a las máquinas más pequeñas manejar mejor las solicitudes junto con la oportunidad de construir micro servicios alrededor de PHP. Los cambios internos, en particular la implementación de AST, también abren posibilidades de optimizaciones futuras que podrían empujar aún más el rendimiento. Se está considerando una nueva implementación interna de un compilador JIT para futuras versiones.

PHP 7 Azúcar Sintáctica

PHP 7 viene con nuevas características de sintaxis. Aunque no amplían las capacidades del propio lenguaje, proporcionan una forma mejor o más fácil de hacer que tu código sea más agradable para escribir y más cómodo para a los ojos.

Declaraciones De Importación De Grupo

Ahora, podemos agrupar las declaraciones de importación para las clases que se originan desde el mismo espacio de nombres en la línea de ‘uso.’ Esto debería ayudar a alinear las declaraciones de una manera significativa o simplemente guardar algunos bytes en tus archivos.

use Framework\Module\Foo;
use Framework\Module\Bar;
use Framework\Module\Baz;

Con PHP 7 podemos usar:

use Framework\Module\{Foo, Bar, Baz};

O si preferimos un estilo multi-linear:

use Framework\Module{
   Foo,
   Bar,
   Baz
};

Operador Coalescente Nulo

Esto resuelve un problema común en la programación PHP, donde queremos asignar un valor a una variable de otra variable, si esta última está realmente configurada; de lo contrario proporcionarle un valor diferente a esta. Se utiliza comúnmente cuando trabajamos con la entrada proporcionada por el usuario.

Pre-PHP 7:

if (isset($foo)) {
   $bar = $foo;
} else {
   $bar = 'default'; // we would give $bar the value 'default' if $foo is NULL
}

Después de PHP 7:

 
$bar = $foo ?? 'default';

Esto también puede estar encadenado con un número de variables:

$bar = $foo ?? $baz ?? 'default';

Operador De Nave Espacial

El operador de la nave espacial <=> permite una comparación de tres vías entre dos valores, no solo indicando si son iguales, sino también cuál es mayor, sobre la desigualdad devolviendo 1,0 o -1.

Aquí podemos tomar diferentes acciones dependiendo de cómo los valores difieren:

switch ($bar <=> $foo) {
   case 0:
       echo '$bar and $foo are equal';
   case -1:
       echo '$foo is bigger';
   case 1:
       echo '$bar is bigger';
}

Los valores comparados pueden ser enteros, flotantes, cadenas o incluso matrices. Consulta la documentación para tener una idea de cómo se comparan los diferentes valores entre sí.

Nuevas Funciones En PHP 7

Pero, por supuesto, PHP 7 también aporta nuevas y emocionantes funcionalidades.

Tipos De Parámetros Escalares Y Sugerencias De Tipo De Retorno

PHP 7 extiende las declaraciones de tipos anteriores de parámetros en métodos (clases, interfaces y matrices) añadiendo los cuatro tipos escalares; Integers (int), Floats (float), Booleans (bool) y Strings (string) como posibles tipos de parámetro.

Además, podemos especificar opcionalmente qué tipo de métodos y funciones devuelven. Los tipos soportados son * bool *, * int *, * float *, * string *, * array *, * callable *, nombre de * Clase * o * Interface *, * self * y * parent * (para métodos de clase)

Clase Calculadora
{
  // Declaramos que los parámetros proporcionados son del tipo entero
  Función Pública addTwoInts (int $ x, int $ y): int {
         Retorno $ x + $ y; // También decimos explícitamente que este método devolverá un entero
  }
}

Las declaraciones de tipo permiten la construcción de aplicaciones más robustas y evitan pasar y devolver valores erróneos de las funciones. Otros beneficios incluyen analizadores de código estático e IDEs, que proporcionan una mejor visión de la base de código si faltan los DocBlocks.

Dado que PHP es un lenguaje de tipificación débil, ciertos valores para los tipos de parámetro y de retorno se emitirán en función del contexto. Si pasamos el valor “3” en una función que tiene un parámetro declarado de tipo int, el intérprete lo aceptará como un entero y no lanzará ningún error. Si no deseas esto, puede habilitar modo estricto añadiendo una directiva dedeclarar.

Declarar (tipos_estrictos = 1);

Esto se establece en una base por archivo, ya que una opción global dividiría los repositorios de código en aquellos que están construidos con rigor global en y aquellos que no lo son, resultando en un comportamiento inesperado cuando combinamos código de ambos.

Excepciones Del Motor

Con la adición de excepciones del motor, los errores fatales que podrían haber resultado en la terminación del Script se pueden capturar y manejar fácilmente.

Errores como llamar a un método inexistente no terminará el Script, sino que lanzarán una excepción que puede ser manejada por un bloque de prueba de captura, lo que mejora el manejo de errores para sus aplicaciones. Esto es importante para ciertos tipos de aplicaciones, servidores y Daemons, ya que los errores fatales requerirían que se reiniciaran. Las pruebas en PHPUnit también deberían ser más útiles, ya que los errores fatales eliminan toda la serie de pruebas. Las excepciones, en lugar de errores, se manejarían por caso de prueba.

PHP 7 se ve y se siente familiar, pero está ajustado para el rendimiento. El refinado Motor Zend y las ganancias de rendimiento resultantes hacen una gran diferencia.

PHP 7 añade una serie de nuevas clases de excepción basadas en el tipo de errores que se pueden encontrar. Con el fin de mantener la compatibilidad entre versiones, se ha añadido una nueva interfaz Throwable que se puede implementar a partir de excepciones de motor y de usuario. Esto era necesario para evitar excepciones del motor para extender la clase de excepción de base, lo que resulta en antiguas excepciones de captura de código que no existían antes.

Antes de PHP 7 esto habría terminado el script con un error fatal:

try
{
   thisFunctionDoesNotEvenExist();
}
catch (\EngineException $e) {
   //
Clean things up and log error
   echo
$e->getMessage();
}

Clases Anónimas

Las clases anónimas son primos de funciones anónimas que podrías usar en una instancia simple a corto plazo. Las clases anónimas se pueden crear y utilizar fácilmente como un objeto normal. Aquí hay un ejemplo de los documentos.

Pre-PHP 7

php
class
MyLogger {
 public function log($msg) {
 
   print_r($msg . "\n");
 }
}
 
$pusher->setLogger(
new MyLogger() );

Con clase anónima:

php
$pusher->setLogger(new class {
 public
function log($msg) {
   print_r($msg
. "\n");
 }
});

Las clases anónimas son útiles en las pruebas unitarias, particularmente en pruebas de objetos y servicios. Esto nos ayuda a evitar las pesadas bibliotecas y los marcos replica la creación de un objeto simple que proporciona la interfaz que queremos imitar.

Funciones CSPRNG

Se agregaron dos nuevas funciones para generar cadenas y números enteros criptográficamente seguros.

random_bytes(int
$len);

Devuelve una cadena aleatoria con longitud $len.

php
random_int(int
$min, int $max);

Devuelve un número entre $miny $max.

Sintaxis de Escape de Codepoint Unicode

A diferencia de muchos otros lenguajes, antes de PHP 7, PHP no tenía una manera de escapar de un código Unicode en literales de cadena,. Esta funcionalidad agrega la secuencia de escape `\ u ‘para producir dichos caracteres usando su código de código UTF-8. Esto es mejor que insertar los caracteres directamente, permitiendo un mejor manejo de los caracteres invisibles, así como los caracteres que tienen la misma representación gráfica, pero difieren en el significado.

echo "\u{1F602}"; // outputs 😂‚

Ten en cuenta que esto rompe el código existente con la secuencia `\ u ‘porque cambia el comportamiento.

Los Generadores Se Actualizan

Generadores en PHP obtienen también algunas características adicionales agradables. Ahora, los generadores tienen una instrucción de retorno que puede usarse para permitir que produzca un valor final después de la iteración. Esto se puede utilizar para comprobar que el generador se ha ejecutado sin errores y permite que el código que llamó al generador maneje varios escenarios de manera adecuada.

Además, los generadores pueden devolver y rendir expresiones de otros generadores. Esto les permite dividir las operaciones complejas en unidades más simples y modulares.

function genA() {
   yield 2;
   yield 3;
   yield 4;
}
 
function genB() {
   yield 1;
   yield from genA(); // 'genA' Se llama aquí e itera
sobre
   yield 5;
   return 'success'; // Este es un resultado final que
podemos comprobar más tarde
}
 
foreach (genB() as $val) {
   echo "\n $val"; // Esto emitirá los
valores 1 a 5 para}
 
$genB()->getReturn(); // Esto debería devolver el "éxito"
cuando no hay errores.

Expectativas

Las expectativas son una mejora de la función de afirmar () mientras se mantiene la compatibilidad hacia atrás. Permiten aserciones de costo cero en el código de producción y proporcionan la posibilidad de lanzar excepciones personalizadas cuando la afirmación falla, lo cual puede ser útil durante el desarrollo.

Afirmar () se convierte en una construcción de lenguaje en PHP 7. Las aserciones deben usarse para propósitos de depuración sólo en entornos de desarrollo y pruebas. Para configurar su comportamiento, se nos proporcionan dos nuevas directivas.

zend.afirmación - 1: generar y ejecutar código (modo de desarrollo) (valor por defecto) - 0: genera el código pero salta a su alrededor en tiempo de ejecución - -1: no genera código que lo convierte en coste cero (modo de producción)
afirmación.excepción - 1: lanzar cuando la aserción falla, lanzando el objeto proporcionado como excepción o lanzando un nuevo objeto * ErrorAfirmación * si no se proporcionó la excepción - 0: usa o genera un * Throwable * como se describió anteriormente, pero solo genera una advertencia basada en ese objeto en lugar de lanzarla (compatible con el comportamiento de PHP 5)

Preparación Para Pasar de PHP 5 a PHP 7

La introducción de un lanzamiento importante brinda la oportunidad de cambiar/actualizar las funcionalidades más antiguas o incluso eliminarlas si se consideran demasiado viejas o han quedado obsoletas durante algún tiempo. Tales cambios pueden introducir interrupciones en compatibilidad en aplicaciones más antiguas.

Otro problema que surge de esta versión, es que las bibliotecas y los marcos importantes de los que dependes pueden no haber sido actualizados para soportar la última versión. El equipo de PHP ha intentado hacer los nuevos cambios lo más atrasados posible y permitir que la migración a la nueva versión sea lo más sencilla posible. Las aplicaciones más nuevas y más actualizadas deberían encontrar más fácil pasar a la nueva versión, mientras que las aplicaciones más antiguas pueden tener que decidir si los beneficios superan el costo, posiblemente eligiendo no actualizar.

La mayoría de los descansos son menores y se pueden mitigar fácilmente, mientras que otros pueden requerir más esfuerzo y tiempo. Básicamente, si tenías advertencias de obsoletos en tu aplicación antes de instalar PHP 7 probablemente obtendrás errores que romperán la aplicación hasta que se resuelva. Fuiste advertido, ¿verdad?

Antiguos SAPIs y extensiones

Lo más importante, las SAPIs viejas y desaprobadas fueron eliminadas como la extensión mysql (pero no deberías estar usando esto en primer lugar, ¿verdad?). Para obtener una lista completa de extensiones y destacados eliminado puedes comprobar este RFCs aquí y aquí.

Además, otros SAPIs están siendo portados a PHP 7.

Cargas de SAPIs y extensiones viejas fueron eliminadas de PHP 7.Estamos prediciendo que no se perderán.

Sintaxis de variable uniforme

Esta actualización hizo algunos cambios a favor de la coherencia para las construcciones de variable- variable. Esto permite expresiones más avanzadas con variables, pero introduce cambios en el comportamiento en algunos otros casos, como se muestra a continuación.

                       //
old meaning
           // new meaning
$$foo['bar']['baz']
    ${$foo['bar']['baz']}
    ($$foo)['bar']['baz']
$foo->$bar['baz']
      $foo->{$bar['baz']}
      ($foo->$bar)['baz']
$foo->$bar['baz']()
    $foo->{$bar['baz']}()
    ($foo->$bar)['baz']()
Foo::$bar['baz']()
     Foo::{$bar['baz']}()
     (Foo::$bar)['baz']()

Esto rompería el comportamiento de las aplicaciones que accedían a valores como éste. Por otro lado, puede hacer algunas cosas limpias como esto :.

//
Nested ()
foo()();
// Calls the return of foo()
$foo->bar()();
 
//
IIFE syntax like JavaScript
(function()
{
   //
Function body
})();
 
//
Nested ::
$foo::$bar::$baz

Etiquetas De Estilo Antiguo Eliminadas

Las etiquetas de apertura / cierre `` <% …%> , <% = …%> , ... </ script> `se eliminan y ya no son válidas. Sustituirlas por los válidos debería ser fácil, pero ¿qué estás haciendo con ellos de todos modos, raro?

Nombres No Válidos Para Clases, Interfaces Y Rasgos

Como resultado de las adiciones, como las clases de tipo de parámetro y retorno, las interfaces y los rasgos ya no pueden tener los siguientes nombres:

- bool - int - float - string - nulo - verdadero - falso

Estos causan roturas a las aplicaciones existentes y las bibliotecas que las utilizan, pero deben ser fáciles de arreglar. Además, aunque no causan ningún error y son válidos, no deben utilizarse los siguientes, ya que están reservados para uso futuro:

-recurso

objecto - mixto - numérico

Abstenerse de usarlos debería ahorrarte el trabajo de cambiarlos en el futuro. Para una lista completa de cambios que romperían la compatibilidad, comprueba este documento.

También puedes utilizar php7cc, que verifica tu código y puede detectar posibles problemas que puedan surgir si te mudas a PHP 7. Pero, por supuesto, no hay mejor manera que instalar PHP 7 y comprobarlo por ti mismo. ## Potenciales Problemas de Compatibilidad con PHP ### PHP 7 Compatibilidad de Infraestructura

Una gran cantidad de servicios de hosting han comenzado a añadir soporte para PHP 7. Esta es una buena noticia para los proveedores de alojamiento compartido, ya que las ganancias de rendimiento les permitirá aumentar el número de sitios web de los clientes en su hardware, reduciendo sus gastos operativos y aumentando sus márgenes. En cuanto a los propios clientes, no deben esperar demasiado de un impulso en estas condiciones, pero para ser justos, el alojamiento compartido no es una opción orientada al rendimiento de todos modos.

Por otro lado, los servicios que ofrecen los servidores privados virtuales o servidores dedicados obtendrán los beneficios completos de este golpe de rendimiento. Algunos servicios de PaaS como Heroku soportaban PHP 7 desde el principio, pero otros servicios, como AWS Beanstalk y OpenShift de Oracle, están rezagados. Consulta el sitio web de tu proveedor PaaS para ver si PHP 7 ya está soportado, o si el soporte viene en un futuro próximo. Por supuesto, los proveedores IaaS te permiten tomar el control del hardware e instalar PHP 7 (o compilar si es más a tu gusto). Los paquetes de PHP 7 ya están disponibles para los principales entornos IaaS.

PHP 7 Compatibilidad de Software

Además de la compatibilidad de infraestructura, también debes tener en cuenta posibles problemas de compatibilidad de software. Los sistemas de gestión de contenidos populares como WordPress, Joomla y Drupal han añadido soporte para PHP 7 con sus últimas versiones. Los marcos importantes como Symfony y Laravel también disfrutan de un apoyo total. Sin embargo, es hora de una palabra de precaución. Este soporte no se extiende a código de terceros en forma de complementos, plugins, paquetes o lo que sea que ru CMS o framework los llame. Pueden sufrir problemas de compatibilidad y es tu responsabilidad asegurarte de que todo esté listo para PHP 7.

Para los repositorios activos y mantenidos, esto no debería ser un problema. Sin embargo, los repositorios antiguos y sin mantenimiento que carecen de soporte de PHP 7 podrían hacer que tu aplicación entera no fuese utilizable.

El futuro de PHP

La versión de PHP 7 eliminó el código antiguo y obsoleto y allanó el camino para nuevas características y actualizaciones de rendimiento en el futuro. Además, se espera que PHP obtenga optimizaciones de rendimiento adicionales pronto. A pesar de tener algunas pausas de compatibilidad con versiones anteriores, la mayoría de los problemas son fáciles de resolver. Las bibliotecas y los frameworks ahora están migrando su código a PHP 7 haciendo disponible así las últimas versiones. Quiero incentivarte a probar y ver los resultados por ti mismo. Tal vez tu aplicación ya es compatible y espera para usar y beneficiarte de, PHP 7.

por: Vilson Duka
Articulo vía: Toptal

Hogar Inteligente Hogar: Domesticando El Internet De Las Cosas

2017-06-11T23:59:00.000-03:00

La tecnología del hogar inteligente está en auge. A pesar de las proyecciones lucrativas para el mercado, y la cantidad en incremento de siempre de dispositivos conectados, tenemos aún que ser testigos de un gran impacto social desde la adopción del consumidor dentro del hogar. Como momento crítico potencial al acecho, hay bastantes debates alrededor de la privacidad, integración y otros temas técnicos. Y aún así, parece haber menos especulación en cuanto a por qué los consumidores aún no se han subido al vagón de la emoción, o cómo la vida doméstica ha mejorado. Considerando cuán personal es un hogar, ¿debería ser preocupante que aquellos haciendo publicidad de estos productos hablan menos sobre la calidad de vida que de datos, energía y ‘seguridad’? ¿Es acaso la adopción de la Internet de las Cosas dentro de nuestros hogares algo inevitable? ¿O acaso ya está aquí?

Algún Lugar Cerca Del Futuro

La persona inteligente regresa a su certificada casa inteligente de ‘Internet - de - las - Cosas’ después de un largo día de trabajo. El sistema de seguridad inteligente siente que la persona inteligente está sola e inicia la secuencia de ‘Noche de Viernes En Casa’. Por dentro, un intercomunicador con una voz de madre estandarizada sugerirá que la persona inteligente ordene comida esta noche. La persona inteligente descarga sus cosas en la cocina donde la hornalla inteligente muestra una selección de comida a domicilio, en vez de la usual guía de recetas. Luego del arribo de la comida, la persona inteligente irá a la sala de estar para relajarse y mirar un poco de televisión vistiendo sólo su ropa interior. La televisión inteligente prepara una selección de maratones de Netflix categorizadas por estados de ánimo. La persona inteligente elige: ‘¿Quieres que te suban el ánimo? Lista de Comedia’, y antes de que el show comience, la persona inteligente revisará una serie de gráficos que mostrará datos propios de actividad y dieta durante el día. Una lista de tips para vivir inteligentemente se generará al fondo, una de las cuales dice que basado en la cantidad de noches consecutivas en la cual la Persona Inteligente ha estado sola, deberían considerar una selección de sitios de citas populares en vez de mirar televisión esta noche. Al toque de un dedo, la persona inteligente acepta una solicitud e instantáneamente una cantidad de perfiles son exhibidos, cada uno elegido de una lista de preferencias generada por la Persona Inteligente. De repente, una cantidad de pings y mensajes de esperanzadores que también están en su casa llenan la pantalla. El intercomunicador de la casa inteligente repite en voz alta ‘¡Tienes un email!’. La persona inteligente juega con el control remoto y - ooops - el televisor toma una selfie en respuesta a la cantidad de pings. Su imagen, sentado y vistiendo sólo su ropa interior y comiendo fideos aparece brevemente en la pantalla antes de ser enviada al éter. La cadena de mensajes se duplica sólo para congelar el sistema, causando que la casa inteligente tenga que ser reiniciada. La casa se oscurece, y en la pantalla apagada de la televisión inteligente se refleja la imagen de la persona inteligente de nuevo, finalmente sola.

Hogar Inteligente Hogar

Con el debate y los titulares acerca del Internet de las Cosas, y la cantidad de dispositivos conectados y tasaciones de mercado - ¿queda alguien para preguntar sobre qué pasará a la casa cuando el Hogar Inteligente tome control? El tener una casa es una de las más viejas tradiciones que tenemos como humanos. ¿Acaso la existencia del Hogar Inteligente significa el fin del hogar como lo conocemos?

El hogar es el lugar original donde construimos nuestra identidad y marcamos nuestro lugar en el mundo - el perfil original. Cada generación ha formado su morada radical como su perspectivas marcas en el mundo. Podemos ahora mirar hacia atrás a esos hogares del pasado como ventanas a las vidas pasadas de esas generaciones, sus valores y ambiciones. ¿Qué dirá nuestro Hogar Inteligente de nosotros? O quizás, en lugar de eso, ¿qué le está diciendo al resto de las personas?

Una Breve Historia Sobre El Hogar Automatizado

El proceso hacia el hogar automatizado comenzó hace casi dos siglos. Cuando conectamos nuestros hogares por primera vez, la bombilla de luz nos dio la noche. Ya no más el hombre estaría encerrado a los límites del sol. La tecnología ofrecía liberación de las horas naturales del día. Un tiempo después, los electrodomésticos reemplazaron las herramientas y todo lo que se movía, o podía moverse, obtuvo energía a través de baterías. La primera generación del hogar automatizado prometía un mejor desempeño a cambio de tiempo de ocio. Más tiempo para la familia, u ofrecerle a la ama de casa una chance para que pueda perseguir su carrera. El hogar automatizado nos liberó de la necesidad de mantenerlo.

Ahora bien, la tendencia tecnológica continúa llevándonos a través de la siguiente generación a una nueva domesticidad, y aunque siempre habrá lamentos por lo que ha pasado, quizá el cambio no sea tan malo. Si hay una nueva liberación, tal vez es la liberación de estar en casa. La liberación de sentarnos y permitirle al mundo visitarnos por dentro. La libertad del exterior. La libertad de los unos con los otros. Sin embargo, esta vez, ¿puede esta libertad venir con un costo?

El hogar es el dispositivo de seguridad original - la pared de fuego original. Pero ahora, mientras le permitimos al mundo entero flotar a través de nuestras paredes y dentro de nuestras casas, ¿hemos desinflado el concepto entero de nuestra casa, el cual ha existido por milenios? Hablamos de seguridad y privacidad ahora en el contexto de sistemas técnicos y hardware pero, ¿hemos olvidado lo que originalmente la privacidad significa? En los espacios donde una vez tuvimos la mayor intimidad, nos exponemos completamente al invitar al mundo entero a nuestras casas. ¿Debemos perder el hogar para adoptar el Hogar Inteligente? Considerando la aceptación a nivel mundial de que la privacidad ha muerto, estos pensamientos pueden ser obsoletos de ser escuchados por desarrolladores y diseñadores web. El punto en realidad es fundamentalmente cuestionar qué es lo que nos ofrece el Hogar Inteligente a cambio de lo que debemos darle. Entonces, ¿vale la pena ese trato? ¿LA vida doméstica mejorará como lo hizo durante las primeras generaciones de automatización? O, ¿cómo nos aseguramos, especialmente como la comunidad que se tomará parte de este cambio, de que al menos alguna cantidad de domesticidad sea salvada?

El Estado Del Internet De Las Cosas

El Internet de las Cosas es uno de esos monstruosos términos del momento que cuando los escuchamos, sabemos de su significancia, y aún así es probable que sepamos mucho menos sobre sus efectos tangibles. Podremos escuchar que hay estimaciones de 200 mil millones de dispositivos siendo conectados en un futuro cercano, o que el valor del mercado se proyecta a 80 mil millones de dólares. Los números tienen significancia similar de la misma forma en la que sabemos que la Tierra está a 92.2 millones de millas del sol. Son números muy importantes, y aún así mucho de nosotros no entendemos las especificaciones, o le damos importancia a esos números de forma diaria. Todo lo que la mayoría de las personas quiere saber en muchos casos es: ¿cómo va a esto a cambiar, o mejorar nuestra vida?

¿Qué es lo que resiste a que adoptemos a la tecnología inteligente para el hogar con la misma ubicuidad que los teléfonos inteligentes de hoy? Considera las fases tempranas de la tecnología de los smartphones, ¿qué causó que dieran el gran salto de un dispositivo de nicho, a ser ajustados en la cadera de casi cada persona y sus abuelos?

Los smartphones existieron desde hace casi una década antes de que el mercado viera un auge significativo. El lanzamiento del iPhone en 2007 generó un giro mayor porque Apple quería ser el primero en diseñar y comerciar el dispositivo para uso diario. Los elementos que el iPhone introdujeron o mejoraron parecían ser ajustes sutiles de interfaces, y aún así fueron capaces de catalizar un giro mayor. Entonces, ¿qué podría ser ese punto crítico, o producto para los hogares inteligentes?

El Problema Con Los Productos De Nicho

Parece que todos los días sale un producto nuevo para hogares inteligentes con los cuales decorar tu propio hogar, y aún así con cada nueva aplicación aparece un nuevo dispositivo, con un nuevo control remoto que podría conectarse con otra nueva app en tu smartphone. No importa cuán potencialmente útiles sean estos dispositivos, parecen ser novedad y excesivos sin ser asociados con un propósito más grande.

Recientemente, Yves Behar publicó los diseños para un sistema de rastreo de un jardín conectado llamado Edyn. El sistema contiene dos productos, uno para monitorear la tierra, y otra para responder a los datos rastreados y regar el jardín cuántas veces sea necesario. Con esos datos, la app puede recomendar qué plantas son las más fáciles de cultivar, y qué puede necesitar el producto para florecer.

Parece muy útil - ¿Pero es lo suficientemente necesario para ser ampliamente adoptado, o para realmente cambiar la forma en la que cuidamos nuestros jardines? Especialmente considerando que para muchos, la jardinería es una actividad placentera. Las personas por lo general utilizan esta actividad como una herramienta de meditación. De hecho, hay un estudio reciente sugiriendo que mientras más feliz la persona es, más ejercen la jardinería, y mientras más una persona hace justamente eso, más felices son. Entonces, ¿qué es exactamente lo que sugiere Edyn que puede mejorar sobre este proceso de jardinería que no tuviese antes? Si la jardinería se convierte en algo más fácil, ¿qué más hay para ganar en cuanto a tiempo en el día? Tal vez ahora la jardinería inteligente puede hacer que miremos otro episodio más en Netflix, en vez de regar el jardín por nuestra cuenta. ¡Con suerte, algún día no tendrán que levantar un dedo verde nunca más! Imagina todos los episodios que podrían ser vistos en Netflix.

Ahora, no quiero tomar como punto a Edyn, pero a lo que voy es que esta herramienta representa la mayor cantidad de tecnología de hogar inteligente hoy en día. Mucho de ello sería genial de tener, creo, pero no parece valer la pena todo el costo y esfuerzo.

Entonces, ¿Qué Sigue?

El problema con la tosca interacción entre múltiples apps ahora es clara para el mercado porque hay un empujón definitivo hacia quienes pueden desarrollar el ‘núcleo’ para todos los dispositivos de hogares inteligentes. Algunos de los jugadores más importantes por ahora son SmartThings, Wink, incluso Apple está generando un momento a través de Apple TV, y Amazon tiene el dispositivo llamado Echo.

Sin embargo, no hay por ahora alguien a la cabecera, ni tampoco demasiadas casas han comenzado a adoptar la tecnología. Lo que parece faltar es, al igual que con el caso del iPhone, es la interfaz apropiada que pueda aliviar el dolor de cabeza de la tecnología del hogar inteligente que se interponga en el camino de la conveniencia.

La mayor parte del proceso que estas tecnologías están intentando mejorar no son exactamente molestias mayores - apagar luces, poner algo de música, etc. Entonces, si la experiencia es difícilmente más disfrutable, la nueva tecnología no será adoptada.

Un producto, Josh.ai, ha reconocido esta necesidad de cohesión entre dispositivos, y su manifiesto se enfoca en la interfaz. Josh.ai anticipa la necesidad para que los programas desarrollasen y construyesen a través del tiempo junto con el usuario. Eventualmente, ciertos comandos se memorizaron a tal punto que Josh.ai sabrá que cada mañana debería lentamente prender las luces, prender el noticiero de la mañana, y preparar una taza de café. La interfaz toma cualquier peso de elegir entre apps, y en en cambio responde a comandos por voz para manejar todos los dispositivos conectados. Josh.ai es promocionado como tu mejor amigo en casa. Incluso le hablas como si fuera tu mejor amigo.

Josh.ai basa su producto alrededor del uso de la voz en vez de cualquier otra interfaz. Esto podría ser un movimiento crítico para la tecnología del hogar inteligente. La plataforma de Josh.ai esencialmente pregunta cómo puede el usuario programar su casa de la forma más fácil. La esperanza es que incluso procesos complejos como rutinas matutinas puedan ser programadas por voz, y luego memorizadas para futuras instancias. “Hey Josh, cuando llegue a casa ¿podrías prender las luces, poner el horno a 300 grados, y quizá poner algo de música de Frank Sinatra? ¡Llevaré a un amigo!”.

Si Josh.ai es uno de los centros más potenciales y optimistas que la tendencia del Hogar Inteligente para moverse a la siguiente fase, ¿qué nos dice su manifiesto sobre la ambición de de qué podemos esperar de la tecnología en el futuro?

Muchas veces la frase “haz de tu vida algo más fácil y productivo” aparece en mucho de estos manifiestos. Pero, si mucho de estos núcleos ofrecen es el control autónomo de pequeñas cosas como luces y música, entonces ¿qué tan fáciles se vuelven nuestras vidas? ¿Puede todo esto comprarse con la transición de escobas a aspiradoras?

Los tres puntos esenciales de Josh.ai son: ahorro de energía desconsiderado, conciencia continua de los dispositivos, y un sistema más en cadena. ¿Cómo estos valores se comparan a tecnologías pasadas que significativamente liberaban a la persona común? En los manifiestos de muchos de estos dispositivos centrales, hay difícilmente algún lenguaje que parezca remótamente humano.

Aunque los beneficios de algunos de esos productos son decepcionantes, el problema es que incluso la más pequeña de las cosas propone un riesgos significante. Tomemos a Nest como ejemplo, ¿qué podría ser más inofensivo que un termostato? Y sin embargo en su corto tiempo de vida, Nest ha sido denunciado por la venta de información sobre incendios caseros alrededor de la industria de las compañías de seguros.

Incluso si el Centro del Hogar Inteligente fuese tu ‘mejor amigo’, ¿quieres que tu mejor amigo sepa todo sobre tus preferencias? ¿Cuánto le permitimos realmente a nuestros mejores amigos que sepan sobre nosotros? ¿Les decimos que nos sentimos solos? ¿Qué perfiles miramos en internet? Incluso si nuestro mejor amigo es bueno guardando secretos, ¿les diríamos todo? ¿Sobre aquella vez?

En cualquier momento que alguien se queje sobre lo que es inevitable, se los percibe como un orador quejoso. Pero esta es una transición extraña donde parece que muchos de estos productos no han ganado demasiado, y aún así hay un riesgos significante en qué puede ser perdido si las tecnologías son adoptadas. ¿No se siente extraño que en el último siglo nuestros padres y abuelos marchaban por privacidad, y que ahora nosotros la estemos entregando tan ansiosamente?

por: Ken Mundle
Articulo vía: Toptal

Deja De Crear Basura: Una Guía Para Diseñar Interfaces Que Duren Mucho Tiempo

2017-06-04T20:05:00.000-03:00

Somos una sociedad que constantemente arroja cosas a la basura, de moda rápida a obsolescencias manufacturadas en nuestros dispositivos, mucho de lo que compramos se tira a la basura en menos de un año. Los productos comienzan a deteriorarse demasiado rápido o son reemplazados por más nuevo, brillante o moderno.

No solo esto es terrible desde una perspectiva de sustentabilidad, pero cuando algo está diseñado para ser reemplazado de forma casi inmediata, significa que estamos creando literalmente basura.

Lo mismo pasa en el diseño de producto digital. ¿Cuál es el punto de perseguir ciegamente las últimas tendencias si el resultado tendrá que ser reemplazado con un completo rediseño unos meses después? ¿El complicado efecto que buscas lograr con tu infraestructura lo hará defectuoso e inutilizable sólo poco tiempo después de su lanzamiento?

Diseñadores profesionales siempre deben estar atentos de las últimas tendencias en diseño y tecnología, pero los mejores diseñadores encuentran un punto de apoyo firme para desafiar y durar más que cualquier tendencia. Al concentrarse en el problema central que los diseñadores intentaban resolver, también lograron un diseño que ha conseguido durar por muchos años. Los mejores diseños son eternos.

“El buen diseño dura muchísimo tiempo. Evade estar de moda y por eso nunca parece anticuado. A diferencia de un diseño que está de moda, este otro dura muchos años–incluso en la sociedad descartable de hoy.” Dieter Rams

Diseñar para la longevidad

Aunque no hay una forma increíblemente segura de capturar un rayo dentro de la botella del diseño inmortal, las siguientes pautas te ayudarán a asegurar tu diseño para el futuro.

Evade estar a la moda

Siempre pregúntate esto: ¿Esta nueva tendencia que estoy poniendo en mi diseño algo que soportar las que vengan en el futuro? Las tendencias van y vienen, y depender de la modernidad puede condenar a tu diseño a sentirse antiguo ni bien aparezca la próxima ola de tendencias. Hace mucho tiempo, esto era innovador:

Image credit: Buzzfeed

¿Recuerdas aquellos días del diseño del eskeumorfismo, cuando toda interfaz parecía ser cubierta en gradientes excesivos, sombras y texturas como madera y cuero? Lo que comenzó como una forma de hacer uso de las propiedades de objetos análogos del mundo real para ser incluídos en interfaces digitales e incorporar metáforas visuales, se convirtieron en una novedad de pasarela.

Las tendencias no son problemáticas por sí solas, pero un buen diseñador puede ver a través de qué es útil. El eskeumorfismo en el diseño por sí mismo resalta la necesidad de que las interfaces digitales reflejen patrones en la realidad. Un control que se vea como un interruptor le da una pista al usuario en cuanto a su significado. La mayoría de los calendarios digitales tendrán fechas ordenadas para verse de la misma forma que el que tienes colgando en tu pared. Los diseñadores han aprendido desde ese entonces que los patrones parecidos al cuero y papel roto son visualmente innecesario y se ven pasados de moda.

La tendencia de hoy es el montón de pila de basura de mañana. Mira críticamente a lo que es popular y pregúntate por qué lo es, ¿cuál es la necesidad específica la que parece estar refiriéndose? Una vez que excaves pasando la basura, puede que llegues a encontrar un poco de algún tesoro que valga la pena incorporar a tu pensamiento de diseño.

El último diseño de iCal de apple mantiene una conexión visual con la idea de un calendario, pero se deshace de los elementos innecesarios que distraen al usuario propios del eskeumorfismo, los cuales alguna vez fueron “tendencia”. En vez de seguir una tendencia estética específica, la nueva iteración se enfoca sólo en elementos de interfaz que añadan al entendimiento del usuario en la información de qué es lo que hay que hacer con él.

Mantenlo simple

Como el escritor Antoine de Saint-Exupery dijo, “Un diseñador sabe que ha llegado a la perfección no cuando no hay nada más que añadir, sino cuando no hay nada más para quitar”. A menudo, la evolución del diseño es un proceso progresivo de simplificación. Si comienzas con simplicidad y evades características superfluas o complejidades innecesarias, tu diseño tendrá más espacio para adaptarse cuando sea necesario y evadir modificaciones mayores.

Piensa como el logo de Apple es hoy: sencillo, limpio e icónico. Podrás reconocer el original por Ronald Wayne. Mientras que es una hermosa pieza de ilustración, tiene más en común visualmente con una etiqueta de una patente médica del página del siglo 19 que la elegante encarnación que quita el aliento de muchos hoy en día.

Image credit: Manzana Comestible

Cuando se edita un diseño desde su concepto crudo e inicial, piensa sobre el problema que estás intentando resolver. ¿Qué es lo más esencial en el diseño? ¿Qué es lo menos esencial? ¿Puede cualquier cosa ser alejada de la complejidad de tu solución para resolver un problema más simple y elegante? Mientras más enfocado tu diseño esté en la solución, es probable que dure por más tiempo.

No rompas la caja

¿Cuándo es necesario reinventar la rueda? Pocas veces. Quizá puedas diseñar una interfaz increíble que requiera código complejo y personalizado, y pueda empujar los bordes de tu infraestructura al mismísimo límite para poder conseguir el efecto correcto, ¿pero deberías? ¿Tu solución podrá crear una situación que sea tan rígida que una sola actualización software cause que toda tu casa de naipes se caiga? ¿Tu diseño necesitará ir directamente a la basura porque en realidad rompe la internet?

Haz uso de patrones familiares en tus diseños y codear dentro de infraestructuras comunes y lenguajes de markup. No le pidas a tus usuarios tener que bajar cosas extra sólo para que puedan usar tu sitio o app. Tu UI no sólo será más fácil de entender, sino que también más fácil de entender. Piensa sobre todas las veces en las que deberíamos haber elegido no usar Flash.

Ten una buena justificación y pensamiento para lo que haces. La audacia es el alma del diseño de alto impacto, pero elige tus batallas. Concéntrate en un sola meta para la “magia”, pero juega teniendo las reglas en mente en todo el resto. No sólo eso le ayudará a ese detalle estrella a brillar, sino que te ahorrará a ti y a tu equipo de desarrollo muchos dolores de cabeza.

Predice tu futuro

No, no tienes que invertir en una bola de cristal, pero debes pensar en el futuro. Si quieres que tu diseño dure, tendrás que intentar e imaginar la trayectoria de la solución de diseño. Esta es una de las cosas difíciles de hacer para los diseñadores, pero para ser parte del futuro un diseño debe anticipar, o crear, futuras tendencias.

La cámara instantánea Polaroid, por ejemplo, vio la tendencia de la fotografía casual décadas antes de la selfie. Al concentrarse en hacer una cámara que capture y desarrolle fotos en el momento, Polaroid satisfació a la cultura moderna concentrada en imágenes y su necesidad siempre creciente de gratificación instantánea—¡Sólo mira la marca de Instagram!

Image credit: Polaroid

No sólo es Polariod el ancestro de la selfie, sino que el diseño es tan exitoso que incluso las supercomputadoras en nuestros bolsillos pueden tomar fotos digitales en alta resolución de forma ilimitada en el momento, y por eso la foto Polaroid en su formato físico es aún inmensamente popular.

Observa el problema que estás resolviendo e intenta imaginar las siguientes etapas en la evolución de su uso–¡quizá puedas predecir el futuro! Como dijo el analista en sistemas Alan Kay, “la mejor forma de predecir el futuro es inventándolo”.

Observar diseños atemporales para inspirarte

Algunos de los mejores diseños han logrado superar su contexto original para volverse atemporales. A continuación, unos ejemplos de diseños que han persistido relativamente sin cambiar.

El sistema de estantería de Dieter Rams

En uno de los 10 Mandamientos del Buen Diseño, el diseñador industrial y arquitecto Dieter Rams dice que un buen diseño debería durar mucho tiempo. El sistema de estantería de Dieter Rams hace uso de la simplicidad y modularidad permitiendo a decenas de configuraciones que se adapten a cualquier contexto o necesidad. Quizá sea por eso que el sistema de Ram ha sobrevivido relativamente sin cambiar desde los años 60 y puede ser encontrado en uso alrededor del mundo.

La página del home de Google

Google comenzó su vida como un motor de búsqueda competitivos como muchos otros a fines de los años del siglo 20. Google se familiarizó con el concepto de búsqueda de manera muy diferente a comparación de su competencia. Un logo, una barra de búsqueda y un botón, y la opción de “me siento con suerte”. La simplicidad fue audaz y persuasivo.

Avancemos rápidamente unos veinte años aproximadamente, y la página del home es casi igual. Hay sólo una barra de búsqueda y un botón. Ah, y la opción de “me siento con suerte” también está ahí, también.

La silla Eames

Crédito de la imagen: Herman Miller

La silla de salón icónica Eames y otomana debutaron casi hace medio siglo atrás en 1956. El diseño simple, con madera contrachapada moldeada sobre tapizado de cuero resolvía un problema simple de proveer a una silla simple de oficina algo más cómodo para una siesta. Cincuenta años después, el mismo diseño simple es aún distinguido como es funcional. Aquí hay un vistazo a las 10 más icónicas sillas Eames.

Jim Henson in Eames Lounge. Image credit: Eames Office

Twitter

Mucho de lo que hace Twitter especial es su fidelidad con el concepto de ser breve. Twitter es el haiku de las redes sociales—un límite de 140 caracteres impuesto en cada publicación hace que los usuarios sean inteligentes, claros y minimalistas. La idea original para la plataforma comunicacional parecida a los SMS para que amigos compartan breves statuses de actualización fue creado en 2006. Más de diez años después, se ha convertido en una de las plataformas más populares en las redes sociales, valuadas en casi 10 billones de dólares. En vez de limitarse creativamente por el límite de caracteres, unos 300 millones de usuarios de Twitter han innovado desde adentro las coacción sin alterar de difundir los ahora ubicuos conceptos como el hashtag y el retweet.

Twitter circa 2012. Crédito de imagen:Seldo

Las zapatillas de Converse All-Star

Crédito de imagen: Smithsonian

Desde James Dean a Kristen Stewart y desde los Harlem Globetrotters al Doctor, todos parecen al menos tener un par de las icónicas zapatillas. Simple lona enmarcada en suela de goma ligera y con ese tope en la punta de los pies. Aunque está disponible en decenas de colores y patrones visuales, el diseño original del zapato de basket de 1920 no ha cambiado demasiado en casi 100 años, y a sus muchos seguidores les gusta así.

Crédito de imagen: Dazed Digital

Craigslist

El mercado digital donde puedes encontrar un compañero de habitación, un trabajo de medio tiempo, un futón usado una colección de paquetes de ketchup de alrededor del mundo, y todo en el medio. Lanzado como una web de simple esqueleto con una lista categórica de eventos y trabajos en San Francisco, incluso veinte años y decenas de ciudades después, la interfaz del sitio es aún libre de distracciones–ni banners o vistosos elementos de UI pueden encontrarse–lo cual es una gran parte de su magia. Algunos podrán pensar que es muy feo, pero el éxito multimillonario de Craiglist puede ser atribuído a su diseño brutalista de su sitio. Concentrándose en por qué los usuarios están ahí, en vez del placer visual, Craiglist es el lugar al cual recurrir para encontrar un buen departamento o la venta de tu colección de 300 peluches de pingüinos.

El logo de BMW

Crédito de la imagen: Logo Design Love

Aunque la idea de que el logo deba evocar las hélices giratorias de un avión ha desacreditado el mito, el clásico emblema existe aún hoy sin haber sido tocado idénticamente a su concepto original de 1917. La simplicidad limpia de los patrones blancos y azules en los cuadrados (inspirados en la bandera de Bavaria) aún está encerrado con un anillo negro y con las letras de la compañía arriba: BMW.

La caja para delivery de Oyster Pail

Crédito de la imagen: HelloGiggles

Con un objeto tan simplemente sutil que es realmente familiar para ti, probablemente no lo pienses dos veces: el oyster pail, más comúnmente conocido como la caja de delivery que se despliega en su propio plato. Patentes para este ingenioso diseño datan a fines del siglo 19, cuando se servía como transporte para la pesca de ostras. A mitad del siglo 20, sin embargo, a la caja de papel que se dobla se le dio una nueva vida como el contenedor favorito de todo, desde arroz frito a General Tso.

Crédito de imagen: CBS News

Deja de crear basura. Concéntrate en detalles y un diseño que dure bastante

En un mundo de ritmo rápido, es fácil para incluso brillantes diseñadores a entrar y salir de sus momentos de inspiración y existencia sólo para ser reemplazados o finalmente ser olvidado. La evolución es un proceso necesario no sólo en el mundo natural, sino también en el mundo de diseño.

Nuestros productos creativos deben, a menudo, adaptarse rápidamente para estar a la par con los cambios en la tecnología y cultura. Sin embargo, al mirar a través de las tendencias, concentrarse en la solución, y anticipando el futuro, tus diseños podrán ser algún día atemporales como el sitio de Space Jam.

Crédito de imagen: Space Jam