martes, 27 de mayo de 2014

¿Cómo podemos optimizar código JavaScript?


Cuando desarrollamos aplicaciones empleando JavaScript, estamos utilizando una tecnología que corre desde el lado de las máquinas cliente, es decir, la página se dibuja en el momento que se invoca y todo ese procesamiento se da en tu computadora (la máquina cliente).

Estos tipos de lenguajes tienen la particularidad de que, a diferencia de los pre-compilados o compilados, son lenguajes interpretados. Estos no se compilan o no requieren compilación en tiempo de ejecución. JavaScript es un lenguaje interpretado.


Ahora sabiendo esto nos podemos preguntar, ¿Qué ventajas tienen este tipo de lenguajes? 

La ventaja principal es que no hay llamadas al servidor. Esto es una gran ventaja a la hora de desarrollar aplicaciones ya que reducimos el nivel de procesamiento de los servidores.
Cuando desarrolles aplicaciones que hacen llamadas a los servidores pensá que eso es tiempo de procesamiento y a la hora de construir un nuevo sistema siempre lo que se busca es lograr una buena performance.

Bajo este concepto podemos pensar que si tenemos una aplicación con código JavaScript, una buena idea sería intentar reducir al máximo las llamadas al servidor.

Pero… ¿Cómo puedo hacer que mi página sea aún más eficiente?

Existe una forma de darle formato a los archivos JavaScript transformándolos en archivos con extensión “.min”. 
Es probable que esto te resulte familiar si alguna vez usaste las librerías jQuery. Muchas veces cuando nos descargamos estas librerías tenemos los archivos con extensión “.js.min”. 
Sí, es medio raro, pero también son archivos JavaScript. ¿Probaste abrir esos archivos? Cuando los abras vas a ver código sin saltos de línea y todo codeado en una línea. 

En esta imagen te muestro como se ve un archivo “minificado”:


Como se puede ver, tenemos todo en una sola línea.

Ahora la siguiente pregunta es, ¿Por qué “Minificar” un archivo?

Cuando minificamos un archivo, reescribimos las estructuras del código de una forma eficiente.
Está demostrado que haciendo esto optimizamos la ejecución del código JavaScript y con esto llegamos a lo que te mencioné en un principio, lo que quieren todos tus clientes, lograr una buena performance. Como resultado de la minificación de tus archivos JavaScript vamos a tener una funcionalidad idéntica pero más eficiente.

Existen herramientas para minificar archivos, pero eso te lo voy a contar en el próximo artículo.

A modo de conclusión, te sugiero que cuando construyas aplicaciones con código JavaScript consideres minificar tus archivos. Vas a hacer que el rendimiento de la ejecución de tu aplicación sea mucho mejor.

¡Gracias por tu contribución Santiago Molina!

miércoles, 21 de mayo de 2014

Nueva versión de Nintex workflow para Office 365

por Fernando Hunth


20 de mayo 2014

Paulatinamente Nintex va agregando nuevas funcionalidades a la version para Office 365. Estas funcionalidades ya existian en las version para Sharepoint on Premise, pero faltaban agregarlas para Sharepoint OnLine.
La última versión de Nintex Workflow para Office 365 añade nuevas capacidades como máquinas de estado , RunIf y etiquetas de acciones . Ahora se puede diseñar flujos de trabajo con acciones de máquinas de estado y acciones RunIf para construir procesos ágiles , dinámicos y poderosos con lógica avanzada . Con la nueva función de etiquetado de una acción , los usuarios pueden etiquetar fácilmente cada acción en su diseño de flujo de trabajo para describir el proceso en términos fáciles de entender.

Máquinas de Estado

Ahora los usuarios , con las máquinas de estado pueden modelar los procesos de flujo de trabajo para saltar entre los diferentes niveles de la lógica de negocio de una manera que es fácil de entender y mantener. Por ejemplo , si hay varios niveles de aprobaciones sincrónicos ( en procesos como el on boarding de empleado , aprobación de documentos, proceso de creación de anuncios, generación de órdenes de venta , etc ) y un cierto nivel rechaza la solicitud , entonces la máquina de estado le permite volver a la nivel previo de aprobación.

nintex-workflow-office365-state-machines

 

Acción RunIf

La acción RunIf permite encapsular las acciones de flujo de trabajo para funcionar sólo si se cumple una determinada condición .

nintex-workflow-office365-runif-action

Etiqueta tus flujos de trabajo


Ahora se pueden agregar etiquetas significativas para sus acciones de flujo de trabajo que ayuda a los usuarios a entender el proceso y su estado actual mejor. Se proporciona un contexto para el propietario de procesos de negocio para las revisiones y documentación , especialmente si no están familiarizados con el icono de la acción.

 

 

 

 

Si queres conocer mas acerca de Nintex Workflows por favor, contáctanos . Estaremos encantados de discutir este tema con mayor detalle.

 

twitter-icon[6]
Seguinos en Twitter
Seguir a @baufest_ar
Seguir a @baufestusa

martes, 13 de mayo de 2014

Código Visual Fox con calidad asegurada, parte 2: Configurando FoxUnit en nuestro entorno de trabajo

por Julian Haeberli

Continuando con el artículo en el cual introdujimos FoxUnit, en esta segunda parte nos enfocaremos en un nivel más técnico, concretamente en cómo configurar y hacer funcionar FoxUnit en nuestro entorno de trabajo.




En ese sentido, debemos aclarar que FoxUnit se ejecuta dentro de nuestro entorno de desarrollo actual: Puede ser colocado en su propia carpeta (y añadirlo al path) o descomprimirlo dentro de la carpeta misma del proyecto. 

Dentro de la carpeta del proyecto actual, debemos crear una carpeta llamada “Tests” que servirá de almacenamiento para nuestros futuros tests. 

Debemos ejecutar FXU.PRG, y aparecerá la lista de las pruebas actuales. Si esta es la primera vez que ejecutamos FoxUnit, se nos pedirá que especifiquemos o creemos una nueva carpeta para nuestras pruebas.


Se puede filtrar la lista de test ingresando los datos buscados en los campos “Class” (Por clase) y “Name” (por nombre de Test).

Creación de un Test


Hacemos clic en el botón ‘New Class’ para crear una nueva clase de prueba. Podemos basar la clase de prueba en las plantillas incluidas con FoxUnit o en una plantilla personalizada. 
Después de utilizar una plantilla personalizada, FoxUnit la agrega a la lista de plantillas disponibles. 

La clase de prueba estándar incluye comentarios y ejemplos de cómo podemos usar los métodos default (el mínimo sólo incluye las definiciones de métodos). 

Hay dos métodos incorporados a la plantilla: Setup y TearDown. En Setup pondremos el código necesario para instanciar elementos comunes a varios test, para inicializar variables, establecer conexiones a la base de datos, todo lo que pueda ser reutilizado por varios test. En TearDown, cerraremos las conexiones abiertas, limpiaremos la memoria, etc. FoxUnit llama a estos dos métodos cada vez que se ejecuta un test.

Por ejemplo, voy a probar una clase personalizada denominada Cliente. Esta clase es responsable de la creación y la gestión de clientes. Dado que toda la clase de prueba utiliza este objeto para sus propósitos de prueba, he agregado una propiedad llamada oObject antecediendo cualquier método que apunta a este objeto:

DEFINE CLASS Cliente as FxuTestCase OF FxuTestCase.prg
oObjeto = . NULL.

Ahora puse la propiedad oObjeto a la clase Cliente en el método ‘Setup’:

Function Setup
oObjeto = CREATEOBJECT ( "Cliente")

Ahora, cada vez que el test se ejecuta, se dispara este método, creando el objeto.

Verificando el resultado

Hay otros tres métodos ocultos en la clase de prueba: assertEquals, assertTrue y AssertNotNull. Utilizaremos estos métodos para validar los resultados.

Vamos a empezar con AssertNotNull:

Hacemos clic en el botón Agregar Test. FoxUnit añade un método llamado NewTestMethod a la clase de prueba.

Cambiamos el nombre para describir lo que está probando, como ElObjetoFueCreado.

Agregamos código al método para verificar su funcionalidad. Utilizaremos AssertNotNull para obtener una notificación cuando se produce un error:

Function ElObjetoFueCreado 
THIS.AssertNotNull ("El objeto no ha sido creado.", THIS.oObjeto)

Cerramos la clase donde ubicamos nuestro código. Nuestro test se muestra ahora como una de las pruebas disponibles. 
Seleccionamos el test en FoxUnit y hacemos clic en el botón seleccionado para ejecutar la prueba. 
Si la prueba no se ejecuta correctamente, aparecerá en rojo:


En la pestaña “Failures and Errors” (Fallas y errores) tenemos un detalle completo donde el código no se ha ejecutado correctamente.

En este caso falló porque yo no le dije dónde encontrar el objeto cClaseCliente, que tiene la definición de la clase Cliente. Esta es la solución:

Function Setup
SET CLASSLIB TO cClaseCliente
oObject = CREATEOBJECT ("Cliente")

Cuando un test se ejecuta correctamente, aparecerá en verde. 

Ejecución masiva de test

FoxUnit nos permite seleccionar todos los test que queramos ejecutar, podemos hacer una batería de pruebas y ejecutarlos masivamente mientras nos dedicamos a otras tareas. 
Al final, aparecerá cada test con su correspondiente resultado y/o detalle de errores.

Es bueno recalcar que si cerramos Visual Fox y entramos más tarde, se mantendrá todo nuestro último trabajo en FoxUnit.

Links Útiles:

  • Sitio oficial:
  • Review:

En Baufest nos preocupamos por la calidad del código entregado a nuestros clientes. Por eso siempre estamos buscando las mejores soluciones.