Semana de los NI 2017 (3 de 3)
Erdos Miller tuvo un gran tiempo esta semana pasada en NI Week 2017, llegamos a sentarnos en una variedad de sesiones y hemos resumido nuestras notas de varias sesiones divididas en tres blogs.
Este blog contiene notas relativas a:
- Sesión AD0194 que cubrió un nuevo tipo de VI en LabVIEW 2017.
- Sesión 0826 que cubrió ideas e historia en lo que respecta al diseño de interfaz de usuario
- Sesión 0205 que cubrió cómo utilizar procedimientos almacenados para simplificar el código de base de datos
Uso de VIs maleables para una mayor reutilización de código
AD0194
Stephen Loftus-Mercer; Jeff Kodosky
Esta sesión presentó una nueva característica SUPER técnica que se ha introducido en LabVIEW 2017, proporcionando un método alternativo para la funcionalidad enfocada anteriormente sólo accesible usando xnodes. Los VIs maleables permiten a un desarrollador crear un solo VI que puede crear automáticamente un nuevo VI dependiendo de los tipos de datos cableados en el VI maleable cuando se utiliza como un subVI. Los VIs maleables aumentan la capacidad de los desarrolladores para la reutilización de código y, en última instancia, reduce el tiempo de comercialización y el coste.
Los VIs maleables le permiten crear un VI polimórfico como las funciones aritméticas primitivas que NI proporciona. Esto puede facilitar significativamente la reutilización de código para múltiples tipos de datos (por ejemplo, escalar datos de unidades brutas a unidades de ingeniería ya sea un doble, punto fijo o booleano).
Otra de las adiciones técnicas muy interesantes para hacer esto posible es una estructura de caso especial llamada 'Estructura de Especialización de Tipo' que puede ser utilizada para ciertos tipos de datos que allanan el camino para la conversión de tipo seguro.
Creación de Interfaces de Usuario Avanzadas con LabVIEW
0826
Collin Draughon
Esta sesión fue una visión general de las interfaces de usuario seguido de una historia reciente de los diseños de interfaz de usuario y, finalmente, información sobre LVNXG (LabVIEW NXG) en términos de qué nuevos elementos trajo a la mesa en términos de herramientas para el desarrollo de interfaces de usuario, con la adición de soporte WPF y prácticamente ser capaz de hacer una interfaz de usuario de un sitio web, las opciones para la creación de interfaces en LVNXG son menos limitadas y en última instancia, será estéticamente más agradable.
En la sesión se resumió que las interfaces de usuario deben girar en torno a la eficiencia, la adaptabilidad y la modularidad; cuando se siguen estos tres principios aumentan las posibilidades de que la experiencia del usuario sea buena. Las interfaces pasaron por un par de fases (especialmente en el mundo LabVIEW): skeuomorphism donde el diseño imitaba mandos y botones de la vida real para ayudar a la transición de los controles físicos a los controles de software, diseño plano en el que los diseños eran minimalistas y destinados a aumentar la eficiencia, reducir la complejidad y transmitir información fácilmente y, finalmente, el diseño material que utiliza la iluminación y las sombras para transmitir inmediatez y énfasis.
Las mejores prácticas de interfaz de usuario son las siguientes:
- La coherencia es lo más importante, las diferencias pueden distraer.
- La paleta de colores debe ser limitada (nosotros usamos Palleton)
- Simplicidad = éxito
LabVIEW NXG desde la perspectiva de UIs:
- SoporteWPF, lo que significa que prácticamente se pueden importar diseños que reflejen sitios web
- Lienzo fijo (los diagramas de bloques son infinitos)
- Las directrices reemplazan a los divisores, los controles se pueden anclar a las directrices para dictar lo que sucede al cambiar el tamaño, se pueden configurar para cambiar el tamaño como un porcentaje o píxeles
- LabVIEW está 100% basado en vectores (yay for zoom)
- Las interfaces de usuario pueden estar totalmente basadas en web, es decir, su interfaz de usuario puede ser un sitio web y soportar tecnologías basadas en web.
Conectividad avanzada a bases de datos
0205
William Welch
Aunque fiel a su palabra, la sesión implicó una solución indicativa de un desarrollador de LabVIEW. A menudo una de las preguntas que siempre nos hacemos (como desarrolladores) es cómo podemos hacer un proceso más eficiente, o hacer nuestro trabajo más fácil. Esta sesión mostró cómo el uso de procedimientos almacenados en una base de datos puede reducir la complejidad del código fuente y hacer más eficientes los procesos que implican una gran cantidad de datos.
Yo, que he tenido el mismo problema en proyectos recientes, encontré la idea fascinante. La solución era utilizar una tecnología ya incorporada en SQL: La idea general era que se podía utilizar lo que se reduce a una subrutina situada en el lado del servidor a la que se podían proporcionar parámetros e incluso devolver valores específicos.
Al colocar la "lógica de negocio" en un procedimiento almacenado en un servidor, se permite lo siguiente:
- Una única ubicación para actualizar el código en lugar de actualizarlo en varios lugares
- Reducir el número de llamadas a la base de datos para lograr un determinado
Por lo general, en una base de datos relacional, cuando se desea insertar datos en una tabla que tiene una clave primaria, no puede haber duplicados, por lo que, sin un procedimiento almacenado, se necesitarán al menos dos llamadas para introducir datos en la tabla: (1) se debe consultar la tabla para ver si existe la clave primaria y (2) si existe la clave primaria, se actualizan los datos; de lo contrario, se insertan los datos. Aunque se podría suponer, que se podría hacer esto en la aplicación una sola vez y simplemente 'recordar' que para ello sólo hay que hacer una operación, también hay que tener en cuenta que se trata de una base de datos cuyo propósito es permitir que múltiples clientes accedan a los datos simultáneamente y que la existencia de esa clave primaria nunca es un hecho.
Espero poner esto en práctica pronto, quizás incluso crear algunos blogs con pruebas de concepto sobre el uso de procedimientos almacenados en LabVIEW.
