Autor:

05 Ene 2017
Android, Desarrollo, Diseño 0 comment

Los 10 errores más comunes en diseño de aplicaciones móviles

BY KENT MUNDLE – TECHNICAL EDITOR @ TOPTAL (TRANSLATED BY MARISELA ORDAZ)

 

El mercado de las aplicaciones móviles está saturado de competencia. Las tendencias cambian rápidamente, pero ningún nicho de mercado puede durar mucho tiempo sin que varios competidores entren en juego. Estas condiciones dan lugar a una alta tasa de fracaso en todos los ámbitos para el mercado de las aplicaciones móviles. Sólo el 20% de las aplicaciones descargadas ven regresar a los usuarios después del primer uso, mientras que sólo el 3% de las aplicaciones permanecen en uso después del primer mes.

Si cualquier parte de una aplicación no es deseable, o el proceso de entenderla es lento, los usuarios son más propensos a instalar una nueva, en lugar de esperar hasta el final con el producto imperfecto. El consumidor no pierde nada cuando se deshace de una aplicación – excepto los esfuerzos de los diseñadores y desarrolladores. Así que, ¿por qué fallan tantas aplicaciones? ¿Es un fenómeno predecible que los diseñadores de aplicaciones y desarrolladores deben aceptar? Para los clientes, ¿es aceptable ésta tasa de éxito? ¿Qué se necesita para llevar tus diseños al 3% de las aplicaciones prósperas?

Los errores más comunes van desde no mantener la constancia a lo largo de la vida útil de una aplicación, hasta atraer a los usuarios en primer lugar. ¿Cómo pueden ser diseñadas las aplicaciones con una simplicidad intuitiva, sin llegar a ser repetitivas y aburridas? ¿Cómo puede una aplicación ofrecer todos los detalles agradables, sin perder de vista un propósito mayor? La mayoría de las aplicaciones viven y mueren en los primeros días, así que aquí están los diez errores más comunes que los diseñadores pueden evitar.

Sólo el 3% de las aplicaciones móviles se mantienen en uso después de ser descargadas.

Error Común # 1: Una Primer Mala Impresión

A menudo, el primer uso, o el primer día con una aplicación, es el período más crítico para atraer a un potencial usuario. La primera impresión es tan crítica que podría ser un punto de partida para el resto de éste top 10. Si algo no está bien, o parece confuso o aburrido, los usuarios potenciales pierden interés rápidamente; aunque, el equilibrio apropiado para la primera impresión es difícil de lograr. En algunos casos, un largo proceso de integración (onboarding), o un proceso para descubrir características necesarias pueden aburrir a los usuarios.

Sin embargo, una aplicación que sea tentadora instantáneamente puede pasar por alto la necesidad de un tutorial adecuado, y promover la confusión. Se debe encontrar el equilibrio entre una aplicación que es inmediatamente intuitiva, y que también introduzca a los usuarios a las características más divertidas y atractivas con rapidez. Ten en cuenta que cuando los usuarios llegan a tu aplicación, la están viendo por primera vez. Es importante tener un proceso de prueba adecuado para determinar cómo los demás perciben tu aplicación desde el principio. Lo que parece obvio para el equipo de diseño, puede que no lo sea para los recién llegados.

Integración Inadecuada

La integración o incorporación es el proceso paso a paso de la introducción de un usuario a tu aplicación. Aunque puede ser una buena manera de orientar a alguien de forma rápida, la integración también puede ser un proceso prolongado que se interpone en el camino de tus usuarios y su contenido. A menudo, estos tutoriales son demasiado largos, y es probable que los lean por encima.

A veces, los usuarios han visto que tu aplicación es utilizada en público o en algún otro lugar, de tal manera que llegan a entenderla de una vez y quieren usarla a la primera. Por lo tanto, permite una especie de estrategia de salida rápida para evitar por completo el bloqueo de la aplicación a partir de su primer uso. Para asegurarte que el proceso de incorporación es de hecho efectivo, debes tener en cuenta qué valores esto puede comunicar y cómo hacerlo. El proceso de integración debe demostrar el valor de la aplicación con el fin de enganchar un usuario, en lugar de sólo una explicación.

No Sobrecargues la Animación en el Inicio

Algunos diseñadores deciden dar una buena primera impresión con animaciones de entrada, que sean fascinantes y deslumbren a los nuevos usuarios. Sin embargo, ten en cuenta que cada vez que alguien quiere ejecutar la aplicación, va a tener que ver la misma cosa una y otra vez. Si la aplicación tiene una función diaria, entonces esto va a cansar a tus usuarios de forma rápida. Diez segundos del día de alguien para deslizar un logo por la pantalla y tal vez hacerlo girar un par de veces en realidad no vale la pena después de un tiempo.

Error Común # 2: Diseñar una Aplicación sin Propósito

Evita entrar en el proceso de diseño sin intenciones concisas. Las aplicaciones son a menudo diseñadas y desarrolladas con el fin de seguir las tendencias, en lugar de resolver un problema, llenar un nicho, u ofrecer un servicio distintivo. ¿Cuál es la ambición de la aplicación? Para el diseñador y su equipo, el sentido de propósito afectará cada paso de un proyecto. Esta sensibilidad guiará cada decisión de la marca o la comercialización de una aplicación, con el formato de wireframe, y un botón estético. Si el propósito es claro, cada pieza de la aplicación comunicará y funcionará como un todo coherente. Por lo tanto, asegúrate de que el equipo de diseño y desarrollo considere continuamente sus decisiones dentro de un objetivo mayor. A medida que avanza el proyecto, la ambición inicial puede cambiar. Esto está bien, siempre y cuando la visión siga siendo coherente.

Transmitir esta visión a tus usuarios potenciales significa que van a entender qué valor traerá la aplicación a sus vidas. Por lo tanto, esta visión es algo importante que se debe transmitir en la primera impresión. La pregunta es, ¿qué tan rápido puedes convencer a los usuarios de tu visión para la aplicación? Cómo se va a mejorar la vida de una persona, o proporcionar algún tipo de goce o comodidad. Si esta ambición es difundida eficazmente, entonces, siempre y cuando tu aplicación sea en realidad útil, llegará al 3%.

A menudo, unirse a un mercado pre-existente, o una aplicación del nicho de mercado, significa que hay aplicaciones que estudiar, mientras diseñas tu propia aplicación. Por lo tanto, ten cuidado de cómo eliges ‘dar nuevo propósito’ a lo que ya está en el mercado. Estudia el mercado de las aplicaciones existentes en lugar de solo revisar. Entonces, mejora a partir de productos existentes, en lugar de imitar sin pensar.

Error Común # 3: Desaprovechar el Diseño de Mapeo en UX

Ten cuidado de no pasar por alto una planificación cuidadosa de la arquitectura UX de una aplicación antes de comenzar un trabajo de diseño. Incluso antes de llegar a una etapa de wireframing, el flujo y la estructura de una aplicación deben ser mapeados.

Los diseñadores están, a menudo, demasiado emocionados como para producir la estética y detalles. Esto da lugar a una cultura de diseñadores que generalmente no aprecian el UX ni la lógica o la navegación necesaria dentro de una aplicación. Ve más despacio. Esboza el flujo de la aplicación primero antes de preocuparte demasiado por las pinceladas más finas. A menudo, las aplicaciones fallan por una falta general de flujo y organización, en lugar de datos imperfectos. Sin embargo, una vez que el proceso de diseño comienza siempre se debe mantener el objetivo principal en mente. Los detalles y estética deberían entonces evocar claramente el concepto primordial.

Error Común # 4: No Tomar en Cuenta el Presupuesto de Desarrollo de la Aplicación

Tan pronto como se dibuja la base de la aplicación, es un buen momento para obtener un presupuesto del equipo de desarrollo. De esta manera no se llega al final del proyecto y de repente se necesita empezar a eliminar características críticas. A medida que desarrollas tu carrera de diseño, siempre toma nota de los costos regulares de construcción de tus conceptos para que tu pensamiento de diseño corresponda con restricciones económicas. Los presupuestos deben ser las restricciones de diseño útiles dentro de las cuales se puede trabajar.

Muchas aplicaciones fallidas tratan de cargar demasiadas funciones desde su lanzamiento.

Error Común # 5: Sobrecarga de Características de Diseño

Con suerte, un riguroso wireframing marcará claramente la diferencia entre las funciones necesarias y las excesivas. La plataforma ya es la “navaja suiza” definitiva, por lo que tu aplicación no tiene que serlo. No sólo el sobrecargar una aplicación con características puede conducir a una probable experiencia de desorientación para el usuario, pero una aplicación sobresaturada también será difícil de comercializar. Si el uso de la aplicación es difícil de explicar de una manera concisa, lo más probable es que esta esté tratando de hacer demasiado. Disminuir características siempre es difícil, pero necesario. A menudo, la mejor estrategia podría ser la de ganar confianza desde el principio con una o algunas funciones, y más adelante en la vida de la aplicación se pueden “probar” las nuevas. De esta manera, las características adicionales son menos propensas a interferir con los cruciales primeros días de vida de una aplicación.

Error Común # 6: Descartar el Contexto de la Aplicación

Aunque las condiciones de la mayoría de las oficinas de diseño prácticamente operan en un vacío, los diseñadores de aplicaciones deben estar al tanto de contextos más amplios. Aunque el propósito y la ambición son importantes, se vuelven irrelevantes si no se dirigen en el contexto adecuado. Recuerda que aunque tú y tu equipo de diseño conocen la aplicación muy bien, y les parezca evidente la interfaz del usuario, esto puede no ser el caso para los nuevos usuarios, o diferentes grupos demográficos.

Ten en cuenta el contexto inmediato o situación en la que se pretende utilizar la aplicación. Teniendo en cuenta la situación social, ¿cuánto tiempo puede la persona considerar utilizar la aplicación? ¿Qué otra cosa podría ser útil para ellos encontrar dada la circunstancia? Por ejemplo, la interfaz UBER sobresale ya que se utiliza con mucha rapidez. Esto significa que en su mayor parte, no hay mucho espacio para otro tipo de contenido. Esto es perfecto porque cuando un usuario está fuera con sus amigos y necesita reservar un viaje, su conversación es poco interrumpida en el proceso. UBER esconde una gran cantidad de contenido de soporte dentro de la aplicación, pero sólo aparece una vez que el escenario lo requiere.

¿Quién es el público objetivo de la aplicación? ¿Cómo podría el tipo de usuario influir cómo es el diseño de la aplicación? Tal vez, debes considerar que una aplicación específica para un usuario más joven puede ser capaz de tomar más libertades asumiendo un cierto nivel de intuición por parte del usuario. Considerando que muchas funciones pueden necesitar ser señaladas específicamente para un usuario menos conocedor de la tecnología. ¿Tu aplicación está destinada a ser visitada de forma rápida y por un corto período de tiempo? O, ¿es una aplicación con una gran cantidad de contenido que permite a los usuarios quedarse en ella un tiempo? ¿Cómo será el diseño para transmitir este tipo de uso?

Un buen diseño de aplicación debe considerar el contexto en el que se utiliza.

Error Común # 7: La Subestimación del Cross-Platform

A menudo, las aplicaciones se desarrollan rápidamente como respuesta a los cambios del mercado o competidores que avanzan. Esto suele resultar en contenido web siendo arrastrado a la plataforma móvil. Un tema constante, lo que se podría pensar sería ampliamente entendido ahora, sucede tan a menudo que las aplicaciones y otros contenidos para móviles hacen transiciones pobres entre el escritorio, o plataformas móviles. Ya no es posible que el diseño móvil haga reducción gradual de contenido web sin consecuencias con la esperanza de conseguir rápido un negocio en el mercado móvil. La transición de web a móvil no sólo significa reducir todo, sino también ser capaz de trabajar con menos. Las funciones, navegación y el contenido deben ser transportados con mínima estrategia.

Otro problema común aparece cuando un equipo de desarrollo de aplicación aspira a lanzar un producto al mismo tiempo en todas las plataformas, y través de diferentes tiendas de aplicaciones. Esto a menudo resulta en una compatibilidad pobre, o en general, una aplicación con errores y sin pulir. La gimnasia que implica un equilibrio de múltiples plataformas puede ser demasiado para sumarse al lanzamiento de una aplicación. Sin embargo, a veces no hace daño llevarlo lentamente con un sistema operativo a la vez y corregir los problemas principales, antes de preocuparse por la compatibilidad entre plataformas.

Error Común # 8: El Diseño de la Aplicación es Demasiado Complicado

El famoso arquitecto Mies Van der Rohe dijo una vez: “Es mejor ser bueno que ser único”. Asegúrate de que tu diseño esté cumpliendo con lo acordado antes de empezar a romper la caja o agregar adornos. Cuando un diseñador se encuentra a sí mismo añadiendo detalles a fin de hacer una composición más atractiva o emocionante, estas opciones, es probable, que carezcan de mucho valor. Seguir preguntando a lo largo del proceso de diseño, ¿cuánto puedo quitar? En lugar de diseñar de forma aditiva, diseña de forma reductora. ¿Qué no se necesita? Este método está dirigido tanto hacia el contenido, el concepto y la función, como a la estética.

La complejidad excesiva es a menudo el resultado de un diseño que innecesariamente rompe convenciones. Varios símbolos e interfaces son estándar dentro de nuestro lenguaje visual y táctil. ¿Tu producto realmente podrá beneficiarse de la reelaboración de estos estándares? Iconos Estándar han demostrado ser universalmente intuitivos. Por lo tanto, a menudo son la forma más rápida de proporcionar indicaciones visuales sin llenar innecesariamente una pantalla. No dejes que tus detalles de diseño interrumpan el contenido real ni el funcionamiento de la aplicación. A menudo, a las aplicaciones no se les da suficiente espacio en blanco. La necesidad de espacio en blanco es un concepto gráfico que ha trascendido tanto lo digital como lo impreso, por lo que no debe subestimarse. Mantén un espacio entre los elementos en la pantalla, de modo que todo el trabajo que pusiste en la navegación y UX se pueda sentir.

El proceso de diseño de aplicaciones puede ser reductor, en lugar de aditivo

Error Común # 9: Inconsistencias de Diseño

En cuanto a la simplicidad, si un diseño va a introducir nuevos estándares, deben ser por lo menos equilibrados en toda la aplicación. Cada nueva función o parte del contenido no necesariamente tiene que ser una oportunidad para introducir un nuevo concepto de diseño. ¿Los textos están formateados de manera uniforme? ¿Los elementos de la interfaz se comportan de manera predecible, pero agradable a lo largo de la aplicación?

La coherencia del diseño debe encontrar el equilibrio entre la existente dentro del lenguaje visual común, así como evitar estar estéticamente estancada. El equilibrio entre la consistencia intuitiva y el aburrimiento es una línea muy fina.

Error Común # 10: Desaprovechar App Beta Testings

Todos los diseñadores deben analizar el uso de sus aplicaciones con algún tipo de ciclo de retroalimentación con el fin de aprender lo que está y no está funcionando. Un error común en las pruebas es que un equipo haga sus pruebas beta con sus propios miembros. Es necesario traer ojos frescos con el fin de excavar realmente en los borradores de la aplicación.

Envía un anuncio buscando probadores beta y trabaja con un grupo selecto antes de anunciarlo al público. Esto puede ser una gran manera de limar detalles, editar características, y encontrar lo que falta. A pesar de que las pruebas beta pueden llevar mucho tiempo, puede ser una mejor alternativa que desarrollar una aplicación que fracase. Anticipa que las pruebas a menudo toman 8 semanas para algunos desarrolladores para poder hacerlo correctamente. Evita el uso de amigos o compañeros de trabajo como probadores, ya que no pueden criticar la aplicación con la honestidad que necesitas. El uso de los blogs de aplicación o páginas web para revisar tu aplicación es otra manera de probar la aplicación en un lugar público sin un lanzamiento completo. Si estás teniendo dificultades al disminuir características para tu aplicación, esta es una buena oportunidad para ver qué elementos importan o no.

El mercado de diseño de aplicaciones es un campo de batalla, por lo que el diseño de productos que son sólo adecuados simplemente no es suficiente. Encuentra una manera de conectar a los usuarios desde el principio – comunicar y demostrar los valores críticos y características tan pronto como sea posible. Para poder hacer esto, el equipo de diseño debe tener una visión coherente de lo que la aplicación desea lograr. Para establecer esta ambición, un proceso de story-boarding riguroso puede limar lo que es y no es imprescindible. Considera qué tipos de usuarios encajarían mejor con la aplicación. Y luego, refina y perfecciona hasta que absolutamente nada más puede ser eliminado del proyecto sin que éste se caiga a pedazos.

 El artículo original lo pueden encontrar en Totpal.
27 Dic 2016
Desarrollo, Programación, Ruby 0 comment

Construye Elegantes Componentes Rails Con Plain Old Ruby Objects

BY EQBAL QURAN – FREELANCE SOFTWARE ENGINEER @ TOPTAL(TRANSLATED BY MARISELA ORDAZ)

#Decoupling #RoR #Ruby #RubyOnRails

Tu sitio web está avanzando y estás creciendo rápidamente. Ruby/Rails es tu mejor opción de programación. Tu equipo es más grande y ya dejaste el concepto “modelos gordos, controladores delgados” (fat models, skinny controllers) como estilo de diseño para tus aplicaciones Rails. Sin embargo, todavía no quieres dejar de usar Rails.

No hay problema. Hoy vamos a discutir cómo usar las mejores prácticas POO para hacer tu código más limpio, aislado y separado.

¿Vale La Pena Refactorizar Tu Aplicación?

Comencemos por mirar como deberías decidir si tu aplicación es una buena candidata para refactorización.

Aquí hay una lista de métricas y preguntas que usualmente me hago para determinar si mis códigos necesitan o no refactorización.

  • Unidades de prueba lentas. las unidades de prueba PORO normalmente corren rápido, con códigos bien aislados, así que las pruebas que corren lento pueden, a menudo, ser un indicador de un mal diseño o responsabilidades sobre-acopladas.
  • FAT models or controllers. Un modelo o controlador con más de 200 líneas de código (LOC) es generalmente un buen candidato para refactorizar.
  • Base de código excesivamente larga. Si tienes ERB/HTML/HAML con más de 30,000 LOC o código fuente Ruby (sin GEMs ) con más de 50,000 LOC, hay una gran posibilidad de que debas refactorizar.

Intenta usar algo así para saber cuántas líneas de código fuente Ruby tienes:

find app -iname "*.rb" -type f -exec cat {} \;| wc -l

Este comando buscará en todos los archivos con extensión .rb (archivos ruby) en la carpeta /app, luego imprime el número de líneas. Por favor, ten en cuenta que este número es solo un aproximado, ya que las líneas de comentario se incluirán en este total.

Otra opción más precisa e informativa es usar la tarea rakestats de Rails, la cual expone un resumen rápido de líneas de código, número de clases, número de métodos, el ratio de métodos a clases y el ratio de líneas de código por método:

*bundle exec rake stats*                                                                       
+----------------------+-------+-----+-------+---------+-----+-------+
| Nombre                 | Líneas | LOC | Clase | Método | M/C | LOC/M |
+----------------------+-------+-----+-------+---------+-----+-------+
| Controladores          |   195 | 153 |     6 |      18 |   3 |     6 |
| Helpers              |    14 |  13 |     0 |       2 |   0 |     4 |
| Modelos               |   120 |  84 |     5 |      12 |   2 |     5 |
| Mailers              |     0 |   0 |     0 |       0 |   0 |     0 |
| Javascripts          |    45 |  12 |     0 |       3 |   0 |     2 |
| Bibliotecas            |     0 |   0 |     0 |       0 |   0 |     0 |
| Controlador specs     |   106 |  75 |     0 |       0 |   0 |     0 |
| Helper specs         |    15 |   4 |     0 |       0 |   0 |     0 |
| Modelo specs          |   238 | 182 |     0 |       0 |   0 |     0 |
| Petición specs        |   699 | 489 |     0 |      14 |   0 |    32 |
| Routing specs        |    35 |  26 |     0 |       0 |   0 |     0 |
| Vista specs           |     5 |   4 |     0 |       0 |   0 |     0 |
+----------------------+-------+-----+-------+---------+-----+-------+
| Total                |  1472 |1042 |    11 |      49 |   4 |    19 |
+----------------------+-------+-----+-------+---------+-----+-------+
 Código LOC: 262     Prueba LOC: 780     Ratio Código a Prueba: 1:3.0
  • ¿Puedo extraer patrones recurrentes en mi base de código?

Separando en Acción

Comencemos con un ejemplo de la vida real.

Imagina que queremos escribir una aplicación que siga el tiempo para las personas que trotan; en la página principal, el usuario puede ver los tiempos que se introduzcan.

Cada una de las entradas de tiempo tienen fecha, distancia, duración, e información adicional relevante del “status” (ej.: clima, tipo de terreno, etc.), y una velocidad promedio que puede ser calculada cuando sea necesario.

Necesitamos un reporte que muestre la velocidad promedio y distancia por semana. Si la velocidad promedio en la entrada es mayor a la velocidad promedio en total, notificaremos al usuario a través un SMS (para este ejemplo, usaremos NexmoRESTful API para enviar el SMS).

La página principal te permitirá seleccionar la distancia, fecha y tiempo en que se está trotando, para así crear una entrada similar a ésta:

También tenemos una página de estadísticas, la cual es básicamente un reporte semanal que incluye la velocidad promedio y distancia cubierta por semana.

  • Puedes ver la muestra online aquí.

El Código

La estructura del directorio de la aplicación se ve similar a esto:

     ⇒  tree
   .
   ├── assets
   │   └── ...
   ├── controllers
   │   ├── application_controller.rb
   │   ├── entries_controller.rb
   │   └── statistics_controller.rb
   ├── helpers
   │   ├── application_helper.rb
   │   ├── entries_helper.rb
   │   └── statistics_helper.rb
   ├── mailers
   ├── models
   │   ├── entry.rb
   │   └── user.rb
   └── views
       ├── devise
       │   └── ...
       ├── entries
       │   ├── _entry.html.erb
       │   ├── _form.html.erb
       │   └── index.html.erb
       ├── layouts
       │   └── application.html.erb
       └── statistics
           └── index.html.erb

No voy a discutir el modelo Usuario ya que no es nada fuera de lo común, dado que lo estamos usando con Devise para implementar autenticación.

En lo referente al modelo Entrada, contiene la lógica de negocios para nuestra aplicación.

Cada Entrada pertenece a un Usuario.

Validamos la presencia de los siguientes atributos para cada entrada distancia, períodode_tiempo, fecha_hora y estatus.

Cada vez que creamos una entrada, comparamos la velocidad promedio del usuario con el promedio de todos los usuarios en el sistema, y le notificamos al usuario vía SMS, usando Nexmo(no discutiremos como se usa la biblioteca de Nexmo, aunque quería demostrar un caso en el que usamos una biblioteca externa).

Nota que la Entrada modelo contiene más que la lógica de negocio sola. También maneja algunas validaciones y llamados.

La entries_controller.rb tiene las acciones CRUD principales (aunque sin actualización). EntriesController#index obtiene las entradas para el usuario actual y ordena los records por fecha de creación, mientras que EntriesController#create crea una nueva entrada. No hay necesidad de discutir lo obvio ni las responsabilidades de EntriesController#destroy :

Mientras que statistics_controller.rb es responsable de calcular el informe semanal, StatisticsController#index obtiene las entradas para el usuario conectado y los agrupa por semana, empleando el método #group_by el cual se encuentra en la clase Enumerable en Rails. Luego, intenta decorar los resultados al usar algunos métodos privados.

No discutimos mucho las vistas aquí ya que el código fuente se explica así mismo.

Debajo se encuentra la vista para enlistar las entradas para el usuario conectado (index.html.erb). Este es el patrón que se usará para mostrar los resultados de la acción índice (método) en el controlador de entradas:

Nota que estamos usando render @entries parciales, para llevar el código compartido a un patrón parcial _entry.html.erb para que así podamos mantener nuestro código DRY y reusable:

Lo mismo se aplica a una _forma parcial. En vez de usar el mismo código con (nuevas y editadas) acciones, creamos una forma parcial reusable:

En lo que concierne a la vista de la página de informe semanal, statistics/index.html.erb muestra algunas estadísticas, e informa sobre las actividades semanales del usuario al agrupar algunas entradas:

Y finalmente, el helper para las entradas, entries_helper.rb, incluye dos helpersreadable_time_period y readable_speed los cuales deberían hacer los atributos más fáciles de leer:

Nada muy complicado hasta ahora.

La mayoría de ustedes pueden argumentar que refactorizar esto va en contra del principio KISS y hará el sistema más complicado.

¿Entonces, esta aplicación, de verdad, necesita ser refactorizada?

Absolutamente no, pero lo consideraremos solo con el propósito de muestra.

Después de todo, si observas la siguiente sección y las características que indican que una aplicación necesita refactorización, se vuelve obvio que la aplicación en nuestro ejemplo, no es una candidata válida para refactorización.

El Ciclo De La Vida

Empecemos por explicar el patrón de estructura MVC en Rails.

Usualmente comienza por el buscador al hacer una petición como https://www.toptal.com/jogging/show/1.

El servidor web recibe la petición y usa rutas para definir qué controlador usar.

Los controladores hacen el trabajo de analizar las peticiones de usuarios, entregas de data, cookies, sesiones, etc., y luego pide al modelo que obtenga la data.

Los modelos son clases Ruby que le hablan a la base de datos, guardan y validan la data, ejecutan la lógica de negocio y hacen el trabajo pesado. Las vistas son lo que el usuario puede ver: HTML, CSS, XML, Javascript, JSON.

Si queremos mostrar la secuencia de una petición de ciclo de vida Rails, se vería como esto:

Rails decoupling MVC life cycle

Lo que quiero conseguir es agregar más abstracción, usando POROs y hacer el patrón algo similar a lo siguiente, para las acciones create/update:

Rails diagram create form

Y algo similar a esto para las acciones list/show :

Rails diagram list query

Al agregar abstracciones POROs estamos asegurando una separación completa, entre responsabilidades SRP, algo que Rails no domina totalmente.

Directrices

Para alcanzar el nuevo diseño, usaré las directrices que se ven abajo, pero ten en cuenta que éstas no son reglas que debes seguir al pie de la letra. Piensa que son directrices flexibles que hacen refactorizar más fácil.

  • Los modelos ActiveRecord pueden contener asociaciones y constantes, pero nada más. Eso significa que no habrá llamados (usa objetos de servicio y agrega los llamados ahí) y sin validaciones (usa Form objects para incluir nombres y validaciones para el modelo).
  • Mantén a los Controladores como capas delgadas y siempre llama a objetos de Servicio. Algunos de ustedes se preguntarán ¿por qué usar controladores, si queremos seguir llamando objetos de servicio para contener la lógica? Bueno, los controladores son un buen lugar para tener el routing HTTP, análisis de parámetros, autenticación, negociación de contenidos, llamar al servicio correcto u objeto editor, atrapar excepciones, formato de respuestas y regresar el estado de código HTTP correcto.
  • Los servicios deberían llamar objetos Query, y no almacenar estado. Usa métodos de instancia no de clase. Deben haber muy pocos métodos públicos guardados con SRP.
  • Queries deberían hacerse con objetos query. Los métodos de objeto Query deben regresar un objeto, un hash o array, pero no una asociación ActiveRecord.
  • Evita usar Helpers, mejor usa decoradores. ¿Por qué? Una dificultad común con helpers en Rails, es que se pueden convertir en un montón de funciones no-OO, las cuales comparten un nombre de espacio y se sobreponen entre ellas. Pero es mucho peor, el hecho no de que no se puede usar ningún polimorfismo con los helpers de Rails — al proveer diferentes implementaciones para diferentes contextos o tipos, y superación o sub-clasificación de helpers. Pienso que las clases de helper en Rails deberían usarse, generalmente, para métodos de utilidad, no para casos de uso específico; como formatear atributos modelo para cualquier lógica de presentación. Mantenlos ligeros y fáciles de seguir. Decoradores/Delegantes mejor.** ¿Por qué? Después de todo, las preocupaciones parecen ser parte de Rails, y pueden secar (DRY up) un código cuando se comparte entre múltiples modelos. Sin embargo, el problema mayor es que las preocupaciones no hacen al objeto modelo más cohesivo. Solo que el código está mejor organizado. En otras palabras, no hay un cambio real al API del modelo.
  • Intenta extraer Objetos de Valor de los modelos para mantener tu código más limpio y agrupar atributos relacionados.
  • Siempre pasa una variable de instancia por cada vista.

Refactorizar

Antes de empezar quiero discutir algo más. Cuando se comienza la refactorización, usualmente terminas preguntándote: “¿Es una buena refactorización?”

Si sientes que estás haciendo más separación o aislamientos entre responsabilidades (aunque eso signifique agregar más código y nuevos archivos) entonces, esto es algo bueno. Después de todo, separar una aplicación es una muy buena práctica y hace más fácil, para nosotros, hacer una prueba de unidad apropiada.

No voy a discutir cosas, como mover lógica desde los controladores a los modelos, ya que supongo que a estás haciendo eso y te sientes cómodo usando Rails (usualmente Controlador Flaca y modelo FAT).

Con el propósito de mantener este artículo conciso, no voy a discutir cómo hacer pruebas pero esto no significa que tú no deberías hacer pruebas.

Por el contrario, deberías empezar siempre con una prueba para asegurarte de que las cosas van bien, antes de avanzar. Esto es algo obligatorio, en especial cuando se hace refactorización.

Luego podemos implementar cambios y asegurarnos de que las pruebas pasen por las partes relevantes del código.

Extraer Objetos De Valor

Primero, ¿qué es un objeto de valor?

Martin Fowler explica:

Objeto de Valor es un objeto pequeño, como un objeto de dinero o rango de fechas. Su característica clave es que siguen semánticas de valor, en vez de semánticas referenciales.

En ocasiones, te puedes encontrar con una situación donde un concepto merece su propia abstracción y donde la igualdad de ésta no se basa en valores, sino en la identidad. Ejemplos de esto pueden ser: Ruby’s Date, URI y Pathname. La extracción de un objeto de valor (o modelo de dominio) es una gran conveniencia.

¿Para qué molestarse?

Una de las grandes ventajas de un objeto de valor, es que ayudan a obtener una expresividad en tu código. Tu código tendrá una tendencia a ser más claro, o al menos puede serlo si tienes buenas prácticas en cuanto a nombres. Ya que el Objeto de Valor es una abstracción, lleva a códigos más claros y menos errores.

Otra ganancia es la inmutabilidad. La inmutabilidad de objetos es muy importante. Cuando estamos almacenando ciertos sets de data, lo cual puede ser usado en un objeto de valor, usualmente no me gusta que la data sea manipulada.

¿Cuándo es esto útil?

No existe la respuesta perfecta a esta pregunta. Haz lo que sea más conveniente para ti y lo que tenga más sentido en una situación dada.

Más allá de esto, hay algunas directrices que uso para ayudarme a tomar esa decisión.

Si crees que un grupo de métodos está relacionado, bueno, con objetos de valor es más caro. Esta expresividad significa que un objeto de valor, debería representar un set de data distintivo, lo cual puede ser deducido por tu desarrollador promedio solo con ver el nombre del objeto.

¿Cómo se hace esto?

Los Objetos de Valor deberían seguir ciertas reglas:

  • Los Objetos de Valor deberían tener múltiples atributos.
  • Los atributos deberían ser inmutables, a través del ciclo de vida del objeto.
  • La igualdad es determinada por los atributos del objeto.

En nuestro ejemplo, crearé un objeto de valor EntryStatus, para abstraer los atributos Entry#status_weather y Entry#status_landform a su propia clase, lo cual se ve de esta manera:

Nota: Esto es solo un PORO (Plain Old Ruby Object), no se hereda de ActiveRecord::Base. Hemos definido métodos de lector para nuestros atributos y estamos asignándolos al inicio. También, usamos una mezcla comparable, para equiparar objetos usando el método (<=>).

Podemos modificar el modelo Entry para usar el objeto de valor que hemos creado:

También podemos modificar el método EntryController#create para usar el nuevo objeto de valor en concordancia:

Extrae Objetos de Servicio

¿Qué es un objeto de Servicio?

El trabajo de un objeto de Servicio es mantener el código durante un espacio particular de la lógica de negocio. A diferencia del estilo “modelo fat”, donde un número pequeño de objetos contienen muchos, muchos métodos, para toda la lógica necesaria, usando objetos de servicio da como resultado muchas clases, cada una de éstas sirviendo un propósito único.

¿Por qué? ¿Cuáles son los beneficios?

  • Separar. Los Objetos de Servicio te ayudan a conseguir más aislaciones entre los objetos.
  • Visibilidad. Los Objetos de Servicio (Si están bien nombrados) muestran lo que hace una aplicación. Puedo pasar la mirada por el directorio de servicios, para ver que capacidades provee una aplicación.
  • Limpia modelos y controladores. Los controladores encienden la petición (params, sesión, cookies) en los argumentos, los pasa al servicio y los redirige o deja dependiendo de la respuesta del servicio. Mientras los modelos solo tratan con asociaciones y persistencia. Extraer código de los controladores/modelos hacia objetos de servicio apoyaría a SRP y separaría más el código. La responsabilidad del modelo sería solo tener que lidiar con asociaciones y guardar/eliminar registros, mientras el objeto de Servicio tendría una sola responsabilidad (SRP). Esto lleva a un mejor diseño y mejores unidades de prueba.
  • DRY y Acepta el cambio. Yo mantengo objetos de servicio lo más simple y pequeños posible. Yo compongo objetos de servicio con otros objetos de servicio, y los reúso.
  • Limpia y acelera tu suite de pruebas. Los servicios son fáciles y rápidos de probar, ya que son objetos Ruby pequeños con un punto de entrada (el método llamada). Los servicios complejos se componen con otros servicios, así que puedes separar tus pruebas fácilmente. También, usar objetos de servicio hace más fácil recuperar objetos relacionados sin necesidad de cargar el ambiente completo de rails.
  • Rescatable desde cualquier parte. Los objetos de servicio serán llamados, seguramente, desde los controladores al igual que desde objetos de servicio, DelayedJob / Rescue / Sidekiq Jobs, Rake tasks, consola, etc.

Por otro lado, nada es perfecto. Una desventaja de los objetos de Servicio es que pueden ser un exceso para cada pequeña acción. En estos casos, puedes terminar complicando y no simplificando tu código.

¿Cuándo deberías extraer Objetos de Servicio?

Aquí tampoco hay una regla fija.

Normalmente, los objetos de Servicio son mejores para sistemas de medianos a grandes: aquellos con una cantidad decente de lógica, más allá de las operaciones CRUD estándares.

Así que cuando pienses que un trozo del código no pertenece en el directorio, en el lugar donde lo ibas a agregar, es buena idea reconsiderarlo y ver si sería mejor que fuese a un objeto de servicio.

Aquí están algunos indicadores de cuándo usar objetos de Servicio:

  • La acción es compleja.
  • La acción alcanza múltiples modelos.
  • La acción interactúa con un servicio externo.
  • La acción no es una preocupación primordial del modelo subrayado.
  • Hay múltiples maneras de realizar la acción.

¿Cómo debes diseñar Objetos de Servicio?

Diseñar la clase para un objeto de servicio es relativamente directo, ya que no necesitas gems especiales, tampoco debes aprender un DLS nuevo, pero si puedes, más o menos, confiar en las habilidades de diseño software que ya posees.

Usualmente, utilizo las siguientes directrices y convenciones para diseñar el objeto de servicio:

  • No almacenes el estado del objeto.
  • Usa métodos de instancia, no métodos de clase.
  • Debe haber muy pocos métodos públicos (preferiblemente uno que apoye *SRP.
  • Los métodos deben regresar resultados de objeto ricos, no booleanos.
  • Los servicios van debajo del directorio app/services . Te aconsejo que uses subdirectorios, para dominios lógicas de negocio fuertes. Por ejemplo, el archivo app/services/report/generate_weekly.rb definirá Report::GenerateWeekly mientras que app/services/report/publish_monthly.rb definirá Report::PublishMonthly.
  • Los servicios comienzan con un verbo (y no terminan en servicio): ApproveTransaction, SendTestNewsletter, ImportUsersFromCsv.
  • Los servicios responden al método llamada. Me di cuenta que usar otro verbo lo hace un poco redundante: ApproveTransaction.approve() no se lee bien. También, el método llamada, es el método de facto de lambda, procs, y objetos de método.

Si observas StatisticsController#index, notarás un grupo de métodos (weeks_to_date_from, weeks_to_date_to, avg_distance, etc.) agrupados al controlador. Eso no es bueno. Considera las ramificaciones, si quieres generar el informe semanal fuera de statistics_controller.

En nuestro caso, vamos a crear Report::GenerateWeekly y extraigamos el informe de lógica de StatisticsController:

Así que StatisticsController#index ahora se ve más limpio:

Al aplicar el patrón del objeto de Servicio, agrupamos código alrededor de una acción compleja y específica y promovemos la creación de métodos pequeños y más claros.

Tarea:considera usar Objeto de Valor para el WeeklyReport en vez de Struct.

Extrae Objetos Query De Los Controladores

¿Qué es un Objeto Query?

Un objeto Query es un PORO, el cual representa una base de datos de consulta. Puede ser reusada en diferentes lugares de la aplicación, mientras que, al mismo tiempo, esconde la lógica de consulta. También provee una buena unidad aislada para pruebas.

Deberías extraer consultas SQL/NoSQL complejas hacia sus propias clases.

Cada objeto Query es responsable de regresar un set de resultados basado en las reglas de criterio/negocio.

En este ejemplo, no tenemos ninguna consulta (query) compleja, así que usar objeto Query no sería eficiente. Sin embargo, con el fin de demostrar, extraeremos la consulta en Report::GenerateWeekly#call y crearemos generate_entries_query.rb:

Y en Report::GenerateWeekly#call, reemplacemos:

 def call
   @user.entries.group_by(&:week).map do |week, entries|
     WeeklyReport.new(
      ...
     )
   end
 end

con:

 def call
   weekly_grouped_entries = GroupEntriesQuery.new(@user).call

   weekly_grouped_entries.map do |week, entries|
     WeeklyReport.new(
      ...
     )
   end
 end

El patrón de objeto query (consulta) ayuda a mantener la lógica de tu modelo estrictamente relacionada a un comportamiento de clase, mientras que mantiene tus controladores flacas. Debido a que no son más que plain old Ruby classes, los objetos query no necesitan heredar de ActiveRecord::Base, y deberían ser responsables por nada más que la ejecución de consultas.

Extrae Crear Entrada A Un Objeto de Servicio

Ahora, vamos a extraer la lógica de crear una nueva entrada a un nuevo objeto de servicio. Vamos a usar la convención y creemos CreateEntry:

Y ahora nuestro EntriesController#create es de la siguiente manera:

 def create
   begin
     CreateEntry.new(current_user, entry_params).call
     flash[:notice] = 'Entry was successfully created.'
   rescue Exception => e
     flash[:error] = e.message
   end

   redirect_to root_path
 end

Más Validaciones A Un Objeto De Forma

Ahora las cosas comienzan a ponerse más interesantes.

Recuerda que en nuestras directrices acordamos que queríamos que los modelos tuvieran asociaciones y constantes, pero nada más (ni validaciones ni llamados). Así que empecemos por remover los llamados y usa un objeto de Forma en su lugar.

Un objeto de Forma es un PORO (Plain Old Ruby Object). Toma el mando del controlador/objeto de servicio cuando necesite hablar con la base de datos.

¿Por qué usar objetos de Forma?

Cuando necesites refactorizar tu aplicación, siempre es buena idea tener en mente, la responsabilidad única principal (SRP).

SRP te ayuda a tomar mejores decisiones de diseño, en cuanto a la responsabilidad que debe tener una clase.

Tu modelo de mesa de base de datos (un modelo ActiveRecord en el contexto de Rails), por ejemplo, representa un record de la base de datos único en código, así que no hay razón para que esté preocupado con nada que haga tu usuario.

Aquí es donde entra el objeto de Forma.

Un objeto de Forma es responsable de representar una forma en tu aplicación. Así que cada campo de entrada puede ser tratado como un atributo en la clase. Puede validar que esos atributos cumplen algunas reglas de validación, y puede pasar la data “limpia” a donde debe ir (ej., tu modelo de base de datos o tal vez tu constructor de búsqueda de consultas).

¿Cuándo deberías usar un objeto de Forma?

  • Cuando quieras extraer las validaciones de los modelos Rails.
  • Cuando múltiples modelos pueden ser actualizados por una sola forma de entrega, deberías crear un objeto de Forma.

Esto te permite poner toda la lógica de forma (nombrar convenciones, validaciones, y otros) en un solo lugar.

¿Cómo crear un objeto de Forma?

  • Crea una clase simple Ruby.
  • Incluye ActiveModel::Model (en Rails 3, tienes que incluir Nombre, Conversión y Validación, en su lugar).
  • Empieza a usar tu nueva clase de forma, como si fuera un modelo regular de ActiveRecord, donde la mayor diferencia es que no puedes continuar con la data almacenada en este objeto.

Por favor, ten en cuenta que puedes usar la gem reform, pero siguiendo con PORO, crearemos entry_form.rb lo cual se ve así:

Y modificaremos CreateEntry para comenzar a usar el objeto de Formato EntryForm:

     class CreateEntry
      
      ......
      ......

       def call
         @entry_form = ::EntryForm.new(@params)

         if @entry_form.valid?
            ....
         else
            ....
         end
       end
     end

Nota: Algunos de ustedes dirán que no hay necesidad de acceder al objeto de Forma desde el objeto de Servicio y que podemos llamar al objeto de Forma directamente desde el controlador, lo cual es un argumento válido. Sin embargo, preferiría tener un flujo claro, por eso siempre llamo al objeto de Forma desde objeto de Servicio.

Mueve los Llamados al Objeto de Servicio.

Como acordamos anteriormente, no queremos que nuestros modelos contengan validaciones y llamados. Extrajimos las validaciones usando objetos de Forma. Pero todavía estamos usando algunos llamados (after_create en modelo Entry compare_speed_and_notify_user).

¿Por qué queremos remover los llamados de los modelos?

Desarrolladores Rails usualmente comienzan a notar un dolor con los llamados, durante las pruebas. Si no estás haciendo pruebas con tus modelos ActiveRecord, comenzarás a notar el dolor después, mientras crece tu aplicación y mientras se necesite más lógica para llamar o evitar los llamados.

después_* los llamados son usados primordialmente en relación a guardar o continuar con el objeto.

Una vez que el objeto es guardado, el propósito (ej. responsabilidad) del objeto ha sido cumplido. Así que, si todavía vemos llamados siendo invocados, después de que el objeto ha sido guardado, estos probablemente son llamados que buscan salir del área de responsabilidad de objetos, y ahí es cuando encontramos problemas.

En nuestro caso, estamos enviando un SMS al usuario, lo que no está relacionado con el dominio de Entrada.

Una manera simple de resolver el problema es, mover el llamado al objeto de servicio relacionado. Después de todo, enviar un SMS para el usuario correspondiente está relacionado al Objeto de Servicio CreateEntry y no al modelo Entrada, como tal.

Al hacer esto, ya no tenemos que apagar, el método compare_speed_and_notify_user en nuestras pruebas. Hemos hecho que esto sea un asunto sencillo, el crear una entrada sin que sea necesario enviar un SMS y estamos siguiendo un buen diseño de Objeto Orientado, al asegurarnos de que nuestras clases tengan una responsabilidad única (SRP).

Así que ahora CreateEntry es algo similar a esto:

Usa Decoradores En Vez De Helpers

Aunque podemos fácilmente usar la colección Draper de modelos de vista y decoradores, me quedo con PORO, por este artículo, como lo he estado haciendo hasta ahora.

Lo que necesito es una clase que llame métodos al objeto decorado.

Puedo usar method_missing para implementar eso, pero usaré la biblioteca estándar de Ruby, SimpleDelegator. El siguiente código muestra cómo usar SimpleDelegator para implementar nuestro decorador base:

   % app/decorators/base_decorator.rb
   require 'delegate'

   class BaseDecorator < SimpleDelegator
     def initialize(base, view_context)
       super(base)
       @object = base
       @view_context = view_context
     end

     private

     def self.decorates(name)
       define_method(name) do
         @object
       end
     end

     def _h
       @view_context
     end
   end

¿Por qué el método _h?

Este método actúa como un proxy para contexto de vista. Por defecto, el contexto de vista es una instancia de una clase vista, siendo ésta ActionView::Base. Puedes acceder a los helpers de vistas de la siguiente manera:

   _h.content_tag :div, 'my-div', class: 'my-class'

Para hacerlo más conveniente agregamos un método decorado a ApplicationHelper:

   module ApplicationHelper

     # .....

     def decorate(object, klass = nil)
       klass ||= "#{object.class}Decorator".constantize
       decorator = klass.new(object, self)
       yield decorator if block_given?
       decorator
     end

     # .....

   end

Ahora, podemos mover los helpers EntriesHelper a los decoradores:

   # app/decorators/entry_decorator.rb
   class EntryDecorator < BaseDecorator
     decorates :entry

     def readable_time_period
       mins = entry.time_period
       return Time.at(60 * mins).utc.strftime('%M <small>Mins</small>').html_safe if mins < 60
       Time.at(60 * mins).utc.strftime('%H <small>Hour</small> %M <small>Mins</small>').html_safe
     end

     def readable_speed
       "#{sprintf('%0.2f', entry.speed)} <small>Km/H</small>".html_safe
     end
   end

Y podemos usar readable_time_period y readable_speed de la siguiente forma:

   # app/views/entries/_entry.html.erb
   -  <td><%= readable_speed(entry) %> </td>
   +  <td><%= decorate(entry).readable_speed %> </td>

   -  <td><%= readable_time_period(entry) %></td>
   +  <td><%= decorate(entry).readable_time_period %></td>

Estructura Después De Refactorizar

Terminamos con más archivos, pero eso no es necesariamente algo malo (y recuerda esto, desde el comienzo, estábamos conscientes de que este ejemplo era con fines demostrativos y no era necesariamente un buen caso de uso para refactorización):

   app
   ├── assets
   │   └── ...
   ├── controllers
   │   ├── application_controller.rb
   │   ├── entries_controller.rb
   │   └── statistics_controller.rb
   ├── decorators
   │   ├── base_decorator.rb
   │   └── entry_decorator.rb
   ├── forms
   │   └── entry_form.rb
   ├── helpers
   │   └── application_helper.rb
   ├── mailers
   ├── models
   │   ├── entry.rb
   │   ├── entry_status.rb
   │   └── user.rb
   ├── queries
   │   └── group_entries_query.rb
   ├── services
   │   ├── create_entry.rb
   │   └── report
   │       └── generate_weekly.rb
   └── views
       ├── devise
       │   └── ..
       ├── entries
       │   ├── _entry.html.erb
       │   ├── _form.html.erb
       │   └── index.html.erb
       ├── layouts
       │   └── application.html.erb
       └── statistics
           └── index.html.erb

Conclusión

Aunque nos enfocamos en Rails en este blog post, RoR (Ruby on Rails) no es una dependencia de los objetos de servicio ni de otros POROs. Puedes usar este enfoque con cualquier framework web, móvil o aplicación de consola.

Al usar MVC como arquitectura, todo se mantiene junto y te hace ir más lento porque la mayoría de los cambios tienen un impacto en otras partes de la aplicación. También te obliga a pensar donde poner algunas lógicas de negocio – ¿debería ir en el modelo, el controlador o la vista?

Al usar un simple PORO, hemos movido la lógica de negocio a los modelos o servicios, que no heredan de ActiveRecord, lo cual ya es una ganancia, sin mencionar que tenemos un código más claro, lo cual apoya SRP y pruebas de unidades más rápidas.

Una arquitectura limpia intenta poner las casillas de uso en el centro/parte superior de tu estructura para que veas fácilmente lo que hace tu aplicación. También facilita la adopción de cambios, porque es más modular y aislado. Espero haber demostrado como al Plain Old Ruby Objects y más abstracciones, separa preocupaciones, simplifica pruebas y ayuda a producir código limpio y fácil de mantener.

 

El artículo original lo pueden encontrar en Totpal.

20 Dic 2016
Sin categoría 0 comment

Guía Definitiva Para Construir Aplicaciones Para Niños

BY TANYA UNGER – FREELANCE DESIGNER @ TOPTAL (TRANSLATED BY MARISELA ORDAZ)

 

Recuerdo que Mark Zuckerberg una vez dijo “Definitivamente no hubiese ingresado al mundo de la programación si no hubiese jugado juegos de niño”

Esta correlación no es una sorpresa, aunque sí vislumbró una revelación cuando estaba investigando sobre las aplicaciones más populares para niños para este post: aparecían constantemente las mismas aplicaciones. En ese momento, noté que el crear aplicaciones fenomenales para niños tiene poder increíble pero subestimado en lo que se refiere a moldear el futuro.

A través de sus aplicaciones, estos diseñadores y desarrolladores tienen una gran influencia sobre futuras generaciones. Indirectamente, sus aplicaciones son responsables por la creación de los futuros Mark Zuckerberg.

Se puede argumentar que estas aplicaciones seleccionadas tienen un impacto colectivo en el futuro, mucho más grande que compañías exitosas y establecidas a las que admiramos, por lo que diseñar una aplicación para niños no es fácil. De hecho, es muy difícil.

Si crees que eres apto para este reto, sigue leyendo. En este post, aprenderás:

Diseñar Para Niños vs. Diseñar Para Adultos: 4 Diferencias Clave

La principal diferencia entre diseñar para niños o para adultos se reduce a la meta(s) del usuario.

cuando diseñas para niños, la recta final es solo una pequeña parte de la historia.

Según Debra Gelman, autora del libro diseñando para niños: Productos digitales para jugar y aprender (Designing for Kids: Digital Products for Playing and Learning), cuando diseñas para adultos—hasta cuando diseñas juegos para adultos—el fin es ayudarlos a cruzar la meta. Cuando diseñas para niños, la meta es solo una pequeña parte de la historia.

Aquí están cuatro diferencias clave a examinar.

1. Los Niños Adoran Un Buen Desafío O Conflicto.

Piénsalo. Un adulto que usa una aplicación de algún banco o de email solo quiere terminar su tarea lo más rápido y fácil posible. Mientras que un niño que juega, disfruta los desafíos y conflictos en el camino, porque hace su éxito mucho más significativo al final.

Un ejemplo importante es Toca House, una aplicación popular de IPad, de los creadores de Toca Boca, la cual reta a los niños a aspirar una alfombra sucia. Por supuesto, la alfombra no queda limpia después de solo una pasada, porque eso no sería lo suficientemente difícil.

Gelman dice que los micro-conflictos – como el aspirar una alfombra sucia – ayuda a los niños a resolver sus propios conflictos internos. Ella refuerza su caso con un estudio lego en juego de conflicto, el cual presenta que los micro-conflictos ayudan a los niños a desarrollar habilidades como:

  • Predecir cómo otras personas podrían reaccionar a su comportamiento
  • Controlar sus propias emociones
  • Comunicarse con claridad
  • Ver los puntos de vista de otras personas
  • Resolver desacuerdos de manera creativa

2. Los Niños Quieren Feedback Sobre Todo.

Cuando juegan en un espacio digital, los niños esperan feedback auditivo y visual cada vez que hacen algo.

Por esto, la mayoría de las aplicaciones para niños generan algún tipo de reacción o respuesta por cada interacción. Ellos esperan ser recompensados por cualquier cosa que hagan.

3. Los Niños Confían Más Que Los Adultos.

Porque los niños no pueden predecir ni entender las consecuencias de sus acciones con antelación, son, normalmente, más confiados que los adultos. Esto significa que tú, como diseñador, tienes la responsabilidad de saber esto y construir resguardos en tu aplicación.

4. Los Niños Se Desarrollan Más Rápido Que Los Adultos.

Si visitas una App Store, notarás que la categoría para los niños puede estar dividida por rangos de edad – “Menores a 5 años,” Entre 6 y 8 años,” y “Entre 9 y 11 años”. Esto se debe a que los niños se desarrollan más rápido que los adultos, lo que quiere decir que una aplicación para un niño de cuatro años no será adecuada para un niño de seis.

Una regla general: Enfócate en un rango de dos años máximo. Piensa en las diferencias entre niños de cuatro y ocho años. Mientras uno de estos grupos se puede aventurar y aprender sobre la aplicación en el camino, el otro puede necesitar instrucciones claras para aumentar su confianza al usar la aplicación.

Diseñar para Niños vs. Diseñar para Adultos: 4 Similitudes Clave

La buena noticia es que no tienes que reaprender todo lo que sabes sobre diseño para hacer una aplicación para niños. Todavía hay un par de similitudes entre diseñar para adultos y para niños.

Aquí muestro las cuatro similitudes clave en el diseño para niños y para adultos.

1. Los Usuarios Esperan Constancia.

Los niños y adultos esperan de igual manera que los patrones de diseño sean constantes. Contrario a la creencia popular, a los niños no les gusta cuando todo en su pantalla hace algo “cool.”

Según Gelman, los niños al igual que los adultos, se molestan cuando hay elementos de diseño que parecen ser al azar e innecesarios. A los niños les gusta que los ítems en una pantalla hagan cosas “cool”, siempre cuando haya un método para la locura proverbial.

“Los elementos que se ponen en el camino, tienen animación espontánea o no tienen una contribución fija, pueden frustrar a niños y adultos por igual y causar que abandonen un juego o aplicación por completo”, Gelman dice. “adicionalmente, si todo se mueve, tiene colores brillantes o hace ruido en el mismo nivel, los niños y adultos se confunden sobre lo que es o no interactivo, y esto hace muy difícil para ellos usar la aplicación o sitio web. Un principio común en el diseño para adultos es mantener las interacciones y feedback constantes, para que así los usuarios puedan aprender cómo usar el sitio web o aplicación rápidamente. Lo mismo se aplica para los niños.”

2. Los Usuarios Necesitan Una Razón Para Usar Tu Aplicación.

Tu aplicación debe tener un propósito, y este propósito debe ser obvio desde el comienzo para niños y adultos.

Mientras que es fácil creer que los niños amarán explorar tu aplicación, si no tienen una razón para usarla, se aburrirán con rapidez.

Ya sea diseñar para niños o adultos, siempre debes articular muy bien que hace tu aplicación y como funciona, todo esto antes de que los usuarios tengan la oportunidad de aburrirse de ella.

3. Los Usuarios No Quieren Ser Sorprendidos.

Los usuarios se van a imaginar que tu aplicación funciona de cierta forma y esperan que funcione de esa manera. No quieren sorprenderse cuando funcione de manera distinta a lo que esperaban.

Por ejemplo, cuando compras algo online, después de pagar esperas recibir un correo electrónico que confirma tu compra. Los adultos no quieren ser redirigidos a una landing page, donde tratas de revenderlos en otra oferta.

Lo mismo se aplica a los niños, dice Gelman, y muestra el siguiente ejemplo.

“Así como un niño agrega gemas a una caja en un juego, se espera que se pueda abrir la caja y ver las gemas, no tener que abrir la caja, abrir gavetas, y cazar las cosas que pensabas que ya estaban ahí,” dice ella.

4. Los Usuarios Quieren Algo Más.

Gelman llama a esto lagniappe.

Una lagniappe es algo extra—un huevo de Pascua—lanzado a los usuarios o clientes de deleite, y ambos, adultos o niños, disfrutan estas pequeñas e inesperadas interacciones que aumentan la experiencia en el sitio web o la aplicación.

Lagniappes son distintas a las sorpresas, estas últimas, como a mencione arriba, no son del agrado de los usuarios.

Una sorpresa es cuando alguien viene detrás de ti, cuando estás concentrado en el trabajo y te asusta. Una lagniappe, es la versión mejorada en primera clase de esto y es gratis, cuando antes estabas apretujado en el asiento del medio, entre dos bebés llorones y sus mamás.

Por ejemplo, “desliza para refrescar” de Snapchat, muestra un fantasma bailando que cambia de color, lo cual deja saber a sus usuarios que la transmisión se está actualizando.

También puedes tomar ideas de Toca Boca.

Ten en mente estas similitudes y diferencias, cuando diseñes para niños o adultos.

Un Framework para diseñar para niños

Diseñar una buena aplicación para niños es más que hacer menos complejos conceptos de adultos. Debes entender a tus usuarios y donde son cognitivos, físicos sentimentales, para que tu aplicación pueda resonar.

Diseñar para niños

Simultáneamente, no debes tampoco desviarte de los principios comunes del diseño, por lo que es útil entender las similitudes del diseño para niños y para adultos.

Algunos de estos pasos te parecerán conocidos.

Deja Tu Libro De Bocetos, Y Toma Tu Cuaderno.

Uno de los motivos por los que diseñar para niños puede ser tan difícil es porque los diseñadores no son niños. Es un problema porque, como sabemos, los diseñadores deben tener empatía por el usuario.

Pero antes de que decidas ir a observar niños para entender cómo interactúan unos con otros, que llama su atención y que no, escoge un rango de edad – dos años máximo – en el cual concentrarte.

Una vez que hayas escogido el rango de edad, puedes observar y tomar notas.

Seamos honestos, puede ser difícil entender a los niños, en especial para aquellos que como yo, no estamos alrededor de ellos a menudo. Por eso, debes observarlos para entenderlos.

También, los niños de hoy son nativos digitales. Han crecido con tecnología desde su nacimiento, así que aunque trates de recordar cómo era ser niño, no podrías relacionarte completamente a los jóvenes de hoy.

Trata de observar distintos grupos de niños del mismo rango de edad, que se conozcan entre ellos, todas niñas, todos niños, bajo techo o al aire libre.

Los niños dicen mucho solo por lo que juegan, con que juegan, cuánto tiempo deciden jugar con esto y cuando deciden jugar con otra cosa. Source

¿Cómo juegan, se comunican e interactúan con cosas en su ambiente?

Sorprendentemente, cualquier cosa tonta que hace un niño podría decirte potencialmente como un niño usará tu aplicación.

Aquí hay algunas preguntas que te podrías hacer.

  • ¿Los niños en este rango de edad disfrutan seguir las reglas o prefieren inventar sus propios juegos?
  • ¿Lo están intentando de verdad o están tratando de comportarse unos más tontos que otros?
  • ¿Hay diferencias en cómo los niños y las niñas se acercan a los juegos?

Ahora, es momento de mejorar las cosas y escoger un tipo específico de juego para reducir solo lo que se relaciona a tu aplicación.

Toca Tea Party, la aplicación popular para iPad de Toca Boca, es un ejemplo primordial aquí.

Comenzó como un prototipo en papel, con recortes de teteras, tazas y platos, encima de un iPad. Los creadores presentaron los elementos y dejaron que los niños jugaran con él.

“Originalmente, la idea era hacer la comida, pero los niños querían pasar esa parte,” dice Jeffery. “Ahora tenemos tortas ya hechas, pero puedes poner la mesa. Una de las características más apreciadas fue la de botar o tumbar las cosas. Esa vino de los niños. “oohh lo tumbó”

Considera El Diseño De Participación.

Diseño de participación, también llamado co-diseño, es un método fenomenal para entender a los niños. Se trata de juntar grupos de niños, darles implementos de artesanía y que ellos mismo aporten ideas para tu proyecto.

Esto ayuda – no porque los diseños saldrán bien – pero porque entenderás cómo miran ciertos temas. Por ejemplo, si una niña crea un hada para que la ayude con su tarea, ¿qué tipo de personalidad tiene? ¿Es traviesa como Campanita? O ¿atenta como el hada madrina en Cenicienta?

También podrías darles a los niños cuadernos de trabajo, o que creen collages o storyboards.

Haz La Prueba.

Ahora es hora de probar tu aplicación con una herramienta de prototipo que te permitirá examinar pruebas complejas, como pasar y hacer zoom.

Estos gestos son importantes porque los niños más pequeños no han desarrollado sus habilidades motoras como lo han hecho los adultos, por esto, no pueden usar sus manos del mismo modo que los adultos. De hecho, un diseñador recomienda no involucrarse con estos gestos en lo absoluto, y quedarse estrictamente con los botones de flechas.

Una vez que has creado tu prototipo, dáselo a un niño y pídele que te enseñe a usar tu aplicación, o mira como le enseña a otro niño a usarla.

Tips para Diseñar para niños

Como a has aprendido, diseñar para niños es algo completamente diferente a diseñar para adultos. A ellos les encanta los colores brillantes y quieren tener feedback en todo lo que hacen.

Para tomar un paso más adelante en nuestra investigación, hablamos con una variedad de expertos sobre el tema. Sigue leyendo para obtener sus mejores tips y trucos para diseñar para niños.

Diseñar para Niños

Deja Que Los Niños Cometan Errores

Word Wizard es una aplicación que le enseña a los niños como deletrear con alfabeto en movimiento que acepta errores de bella manera.

En un ambiente tipo caja de arena, los niños pueden poner letras en el orden que quieran, luego la aplicación lee la “palabra” en voz alta, lo que le permite al niño entender cómo suenan las letras juntas.

Por ejemplo, un niño puede unir una “palabra” de 100 caracteres o una amalgama fascinante de aparentes sonidos sin sentido. Los usuarios pueden cambiar la rapidez del sonido de feedback, acento y tono, lo cual enriquece el juego y poder de inmersión de la experiencia.

No hay un timbre desagradable que les indique a los niños que crearon una palabra que no existe en el diccionario. Tampoco encontrarás un icono de una “x” roja y gigante, ubicada al lado de la yuxtaposición imaginaria.

El niño entenderá que cometió un error por su cuenta al escuchar el resultado.

“Los errores están bien. Es normal cometer errores,” dijo Abel. “Los errores son una parte natural del aprendizaje. Integra el error al aprendizaje.”

Cuando se le preguntó, qué consejo daría le daría a diseñadores interesados en construir aplicaciones para niños, Abel dice que es vital que las aplicaciones educativas se construyan sobre hechos, sino son inútiles.

“Hay muchas aplicaciones, en las que las personas no hicieron la tarea. Puedes fácilmente leer un libro sobre un nuevo tema y aprender todo lo que necesitas saber, antes de comenzar a desarrollar la aplicación. Si tengo alguna duda, le pregunto a los expertos, y ellos me explican todo.”

Dale A Los Niños Infinitas Posibilidades.

Josh Sheldon, Director de Programas en MIT App Inventor, dice que las mejores aplicaciones para niños, les da la libertad de explorar sumergirse en una gran experiencia.

“Asegúrate de que no todo sea como un guión,” recomendó. “Dale a los niños la habilidad de tomar su propio camino o viaje a través de una nueva experiencia.”

Diseña Para Niños Primero.

Los diseñadores fallan cuando tratan de imponer una perspectiva adulta.

“Esto puede variar desde tener interacciones que parecen ser ‘normal’ desde el punto de vista de un adulto, como tocar un objeto para seleccionarlo y tocar de nuevo para usarlo, lo cual es algo con lo que los niños no se relacionan. Los niños tienden a escoger un objeto y realizar su acción en seguida, no es un proceso de dos pasos para ellos.” Víctor Guerrero, programador en Toca Boca.

Guerrero cita Vectorpark como un buen ejemplo.

“[Vectorpark] es bueno con la interactividad y fiscalidad de las interacciones, por esto jugar con objetos en sus creaciones se siente muy bien. Otro aspecto de su trabajo es que los conceptos son sorprendentes lo cual mueve la imaginación también (de niños y adultos).”

Es importante mencionar que los niños tienen más imaginación y son más corporales que los adultos.

“Intenta sorprenderlos, hacienda sistemas que les den libertad para que puedan explorar, y sé creativo con dentro de tu aplicación,” dijo Guerrero.

Pero Ten En Cuenta A Los Adultos.

Abel les recuerde a los diseñadores que debes satisfacer a los padres tanto como a los niños porque no son los hijos los que compran la aplicación. Lo cual hace las cosas difíciles.

Para evitar este obstaculo, Hopscotch, una aplicación que te enseña como codificar o programar, recoge toda la información y feedback de una gran cantidad de personas alrededor del mundo.

“Estamos ubicado junto al Grand Central, así que esperamos a que los niños vengan con sus padres a la tienda de Apple para preguntarles si quieren probar nuestra aplicación,” explicó Liza Conrad, Jefa de Comunidad y Alianzas de Hopscotch.

Conrad recomienda obtener todo el feedback posible de los niños, profesores y padres, en lo que respecta a diferentes contenidos. Si buscas diferentes opiniones de grupos diversos de personas, es más probable que tu aplicación no sea tan inclinada a un solo tema.

Piensa Más Allá De La Realidad.

Según Guerrero, limitarte solo por limitarte podría ser una mala opción, por ejemplo, hacer ropa que sea solo para ciertos personajes o no hacer algo solo porque en la vida real no se puede hacer.

“Una aplicación en las aplicaciones de Toca Boca que a los niños les encanta es poder apilar ítems, como sombreros o bolas de helado. Es difícil hacer algo así en la vida real pero a los niños no les importa, solo quieren jugar y divertirse,” explicó Guerrero. “Desafiar las normas suele dar una perspectiva interesante cuando se juega, y usualmente desafiar las normas también es divertido.”

Los Niños Les Aman La Diversión Difícil.

Un niño de primer grado inspiró al fallecido Matemático, Científico de la Informática y Educador Seymour Papert a encontrar el término que se le escapaba – “diversión difícil.”

“La Academia Gardner fue una de las primeras escuelas en tener suficientes computadoras para que los estudiantes pasaran un tiempo significativo en las mismas todos los días. Su introducción, para todos los grados, fue aprender a programar con el lenguaje de computadora Logo, en un nivel apropiado,” Papert escribió. “Un profesor escuchó a uno de los niños describiendo el trabajo en la computadora así: ‘Es divertido. Es difícil. Es Logo.’ No me cabe ninguna duda de que este niño dijo que el trabajo era divertido porque era difícil a pesar de la dificultad.”

La diversión difícil se reduce a la creencia de que todos disfrutan cuando están trabajando en algo desafiante.

Combina la diversión y el aprendizaje y obtendrás una app que los niños no puedan evitar jugar.

“Alguna vez escuchaste sobre un juego promocionado como fácil? Lo peor sobre un currículo escolar es la fragmentación del conocimiento a pequeñas partes. Esto se supone tiene que hacer que el aprendizaje sea más fácil, pero usualmente termina haciendo que el aprendizaje sea menos personal y eventualmente se vuelve aburrido. Pregúntale a algunos niños: la razón por la que a la mayoría no les gusta la escuela es porque es completamente aburrida no porque sea muy difícil.”

Además Papert no recomendaría que le des un vistazo a los currículos de diseñadores para guiarte, en su lugar ve con los diseñadores y desarrolladores de juegos para que te den consejos.

“Los diseñadores de juegos saben más sobre la naturaleza de aprender que los diseñadores de currículo…. Sus medios de supervivencia dependen de que millones de personas sean capaces de poder superar la gran cantidad de aprendizaje necesaria para superar un juego complicado. Si su público no aprendiera nada, se quedarían sin trabajo. En el caso de los diseñadores de currículo, la situación es al revés; su negocio mejora cuando los estudiantes reprueban y las escuelas buscan otro currículo! Creo que esto explica porque he aprendido tan poco sobre aprendizaje de libros sobre diseño curricular, y he aprendido bastante sobre juegos de computadora gracias a los usuarios (niños en su mayoría) y a los diseñadores (a menudo “niños adultos”).”

No Engañes A Los Niños Para Que Compren Cosas.

Abel recomienda no poner promociones o anuncios en las aplicaciones para niños debido a que los mismos no están preparados para esto.

Este papa/diseñador esta de acuerdo y sin vergüenza alguna habló sobre la aplicación para niños, Talking Tom Cat, en Smashing Magazine.

“Muchas aplicaciones hacen esto, pero Talking Tom Cat es la peor de todas. La pantalla es una mina terrestre de iconos colocados cuidadosamente que conllevan a compras accidentales — sin mencionar los anuncios publicitarios animados diseñados para guiar tu mirada lejos de la misma aplicación,” escribió. “Los patrones oscuros de GoDaddy que intentan engañar a los usuarios para que compren más dominios son una cosa, pero si intentas usar un diseño persuasivo con mi hija, entonces todo se vale. Borrare tu aplicación, y no volveremos a hacer negocios.”

Limpia La Parte De Abajo De Tu Pantalla.

Los niños tocan sin querer la parte de abajo de las tablets sin querer; por lo que, si pones un elemento interactivo en esa parte lo más probable es que irrites a los usuarios, porque constantemente le darán a esa parte de la pantalla sin querer.

No Te Olvides De Usar Colores Brillantes.

Esta se explica sola pero de todos modos es importante.

Los Niños Son Nuestro Futuro. Diseña Una Aplicación Que Los Ayude A Liderar El Camino.

Los usuarios más jóvenes de hoy en día, los recién creados Generación Alfa (nacidos después del 2000) tienen una exposición a la tecnología como nunca antes. Estudios recientes han comprobado que en los Estados Unidos, el 75% de los niños menores de 8 años tienen acceso a un teléfono inteligente o una tablet, al igual que el 36% de los niños menores de 1 año.

Aunque esto podría significar que si diseñas una aplicación para niños tendrías mucho más dinero, también – y más importante – significa que los creadores de aplicaciones tienen el potencial para influenciar toda una nueva generación.

Me refiero, ¿puedes imaginarte ser el responsable por crear el juego que hizo que Zuck se interesará en la programación? De seguro debe ser algo muy emocionante.

 

El artículo original lo pueden encontrar en Totpal.

13 Dic 2016
Diseño, TopTal 0 comment

El Arte de Robar: Cómo Convertirse en un Diseñador Experto

BY MICHAEL ABEHSERA – DESIGN BLOG EDITOR @ TOPTAL (TRANSLATED BY ISABELLA ROLZ)

#Designers #Dribbble #Learning

El pintor Pablo Picasso una vez dijo, “Los buenos artistas copian. Los grandes artistas roban.” Esto nunca ha sido más que cierto, especialmente hoy en día.

Muchas personas creen que los diseñadores son una especie de unicornios, dotados de alguna manera especial, que tenemos una capacidad innata para crear increíbles interfaces, un verdadero talento natural para mezclar colores complementarios, y una inexplicable intuición para construir hermosas tipografías. Sin embargo, nada de esto es cierto. Convertirse en un gran diseñador realmente lleva años de arduo trabajo; de experimentación y fracaso.

El problema con el pensamiento de unicornio es que hace que el diseño parezca inalcanzable para las personas interesadas, pero estas no se consideran seres creativos. He conocido a muchos programadores y personas en la tecnología que están convencidos de que no entrar al mundo del diseño, por este mismo problema. Pero podrían convertir estos bloques mentales en bloques de construcción con un simple cambio de actitud. En lugar de ver el trabajo de otros diseñadores con envidia, piensa en ello como la clave para tu éxito.

De hecho, el diseño interactivo tiene mucho en común con la comunidad de software de código abierto: puedes dominar para robar y copiar del mejor de lo mejor. Y no te equivoques: estos realmente son los mejores diseñadores del mundo, de lugares como Dropbox, Facebook y Palantir.

¿Cómo sé que esto funciona? Porque a mí me funcionó.

Los diseñadores se crean, no nacen. Aprende del secreto de Pablo Picasso para llevar tus habilidades de buenas a excelentes”.

Los paralelismos entre GitHub & Dribbble

Cuando comencé a aprender a diseñar, me sorprendió la cantidad de código que hay ahí fuera y que se puede utilizar de forma gratuita; el software de fuente abierta tiene una cuota de mercado del 80% aproximadamente. La mejor parte es que puedes modificarlo y ver qué sucede, ya que acelera tu aprendizaje. GitHub tiene cada Plugin y cada fragmento de código que puedas imaginar, cualquier cosa, desde un menú desplegable de jQuery a un marco CSS y mucho más.

La característica de rebote de Dribbble es lo más cercano que tenemos en la industria del diseño a la “duplicidad” de GitHub, o la descarga de cualquier pieza de software de fuente abierta y haciéndola tuya.

Es la mejor manera de perfeccionar tus habilidades. Ir a Dribbble, verificar tu UI favorito, e intentar copiarlos píxel por píxel. Puedes agregar tu propio shot y luego hacer rebound para darle crédito al diseñador original. Veamos algunos ejemplos de cómo los diseñadores han utilizado la función de rebote.

Paul Flavius Nechita diseño la toma original y otorgó un PSD gratis, para que todos dentro de la comunidad Dribbble pudieran usarla.

Esto motivó a Artem Borodynya en crear esta increíble pantalla para el procesamiento de tarjetas de crédito.

Wayne Spiegel De Palantir siempre quiso mejorar el UI de Apple Pay. Inspirado por el rebound de Borodyna, él creó esta toma, en donde el usuario escoge la carta deseada de un volante.

En este ejemplo, Smenan creó un papel de Shredder gráfico.

Y Hanna Jung de Google le agregó animaciones.

Este es el sistema innovador de menús para un sitio web de una compañía tecnológica diseñado por Brandon Termini. Añade una foto como esta en Dribbble para realmente traspasar a la comunidad de diseño y sal de tu zona de confort, siendo más creativo.

El trabajo de Termini inspiró a Ilya Kostin en adoptar un enfoque distinto para crear esta interfaz

Anggit Yuniar Pradito diseñó una aplicación inteligente de hogares que da a cada habitación su propio perfil.

Después Ibnu Mas’ud simplificaron la interfaz de usuario para hacerla aún más intuitiva. Muchos otros diseñadores en Dribbble la repuntaron también, todos con diferentes interpretaciones. Si alguna vez te contratan para diseñar una aplicación de automatización de hogar inteligente, ya sabes por dónde empezar.

A la comunidad de Dribbble le encantó la sencillez de este gráfico de uso de energía, diseñado por Kingyo.

Alex Pronsky mejoró el original añadiendo un efecto de cristal, sombras suaves y colores vintage, y luego cedió el PSD a la comunidad de uso gratuito.


Cuando Dropbox se unió Dribbble, la compañía hizo el anuncio con este gráfico.

Lo cual hizo que la comunidad haga rebound de esta publicación más de 200 veces. Es increíble cómo algunos shots despiertan la creatividad en la comunidad. Éste otro diseñado por Jory Raphael fue uno de mis favoritos.


Awesomed diseñó este increíble panel web…

…que inspiró a George Vasyagin a diseñarlo con colores nuevos y brillantes.

Kevin Kalde diseñó esta simple pero atractiva receta widget.

Después, Ididi construyó sobre su diseño mediante la adición de elementos ambientales.

Ramakrishna V diseñó estos interruptores.

Y después Tsuriel les dio vida.

Cuando copias el trabajo de diseño de alguien más, tienes que desarmarlo para entenderlo y aplicarlo a tu proyecto en particular. De lo contrario, el diseño simplemente no funcionará, o parecerá muy fuera de lugar. Copiar efectivamente te enseña a hacerlo de la manera correcta. Sobresalir en lo básico, e innovar en donde tenga sentido.

Si deseas ser un gran diseñador, no te retrases y no dudes de ti mismo. Ve a Dribbble y sigue a los diseñadores cuyas obra admires. Escoge tus fotos favoritas y empieza a copiar. Hazlo más y más y podrás desarrollar y perfeccionar tus habilidades con el tiempo. Eventualmente, podrás hacer las mismas cosas que tus diseñadores favoritos pueden hacer.

El artículo original lo pueden encontrar en Totpal.

06 Dic 2016
Sin categoría 0 comment

Programación Visual con Node-Red: Conectando el Internet de las Cosas con Facilidad

BY JESUS DARIO RIVERA – FREELANCE SOFTWARE ENGINEER @ TOPTAL

#JavaScript #Netbeast #Node.js #NodeRED #VisualProgramming

A través de la programación, hacemos que las máquinas imiten un comportamiento complejo siguiendo secuencias de instrucciones simples. Utilizar lenguajes de programación textual como Asambly, C, Python y JavaScript, es una de las formas principales de hacerlo. Los diseñadores de estos lenguajes de programación han pasado horas y horas tratando de hacer que la experiencia de los programas de escritura sean lo más fácil posible a través de una sintaxis expresiva, fuertes construcciones de programación y cadenas de herramientas poderosas. Sin embargo, todos estos lenguajes de programación comparten un rasgo común: el código fuente textual.

Escribir programas en texto funciona y en la mayoría de los casos funciona bien. Sin embargo, la capacidad de expresar programas visualmente es a menudo deseable. Ser capaz de diseñar el flujo de información a través de diversos componentes de un sistema más grande es normalmente todo lo que se necesita. Las herramientas visuales de programación también son indulgentes con cualquier persona que sea nuevo en la programación y que les es difícil manejar diversos conceptos como las variables, indicadores, señales, alcances, y así sucesivamente.

Connect Hardware Devices With APIs Using Node-RED

Node-RED es una herramienta de programación visual. Muestra visualmente las relaciones y funciones, y permite al usuario programar sin tener que escribir una lengua. Node-RED es un editor de flujo basado en el navegador donde se puede añadir o eliminar nodos y conectarlos entre sí con el fin de hacer que se comuniquen entre ellos.

En Node-RED, cada nodo es uno de los siguientes dos tipos: un nodo de inyección o un nodo de función. Los nodos de inyección producen un mensaje sin necesidad de entrada y lanzan el mensaje al siguiente nodo conectado a éste. Los nodos de función, por el contrario, tienen una entrada y realizan algún trabajo en él. Con una gran cantidad de estos nodos para elegir, Node-Red hace que el conectar los dispositivos de hardware, APIs y servicios en línea sea más fácil que nunca.

Primeros Pasos con el Node-Red

Node-Red se basa en Node.js. Para instalar el Node-Red, necesitas tener tanto Node.js instalado como NPM. Con NPM, es muy fácil instalar Node-Red: npm install -g node-red

El editor de flujo de Node-Red es una aplicación basada en navegadores web. Para poder utilizarlo, ejecuta Node-Red:

npm install -g node-red

Node-RED’s flow editor is a web browser based application. To be able to use it, run Node-RED:

node-red

&hellip y vaya a http: // localhost: 1880.

¡Hola Mundo!

¿Qué tutorial de programación para principiantes está completo sin aprender a decir “Hola, mundo”? Vamos a empezar por probar exactamente eso:

  1. Arrastra y suelta un nodo de inyección en el editor de flujo. Después, haz doble clic y fija la carga útil como cadena y escribe “Hola mundo”.
  2. Arrastra y suelta un nodo de depuración, de la misma manera como lo hiciste con la inyección.
  3. Conéctalos.
  4. Haz clic en el botón “Deploy” en la esquina derecha.
  5. Haz clic en el botón azul justo a la izquierda del nodo de inyección.

Inténtalo. Verás algo como esto:

Sólo JavaScript

Con Node-Red, no te limites con simples nodos y funcionalidades. Como Node-Red está construido sobre Node.js, todo está impulsado por JavaScript. Los nodos son, de hecho, Node.js módulos. Se pueden encontrar en http://flows.nodered.org/, entonces para añadirlos a tu panel de la izquierda se pueden simplemente “instalar con NPM “. De hecho, puedes desarrollar tu propio flujo y subirlos al repositorio de flujo. Las aplicaciones pueden ser tan complejas como desees ya que puedes escribir JavaScript en los nodos de función dentro del editor de código que proporciona Node-Red.

Ya que la plataforma se basa en Node.js, ésta se aprovecha del mismo modelo orientado a eventos y sin bloqueos. Así que una aplicación construida en Node-Red puede ejecutarse en hardware de bajo costo como el Raspberry Pi, así como en la nube.

Ahora Nos Vamos a Meter en las Grandes Ligas: Es hora de Automatizar el Hogar

Para demostrar cómo Node-Red se ajusta en el ámbito del Internet de las Cosas, vamos a construir una aplicación para cambiar el color de una bombilla inteligente. No todo el mundo puede tener el mismo sistema de iluminación inteligente a su disposición, pero no hay nada de qué preocuparse, ya que se puede encontrar el módulo Node-Red apropiado desde el repositorio oficial de flujo. Sin embargo, para hacer las cosas aún más fácil vamos por algo más inteligente.

Déjmae presentarte a Netbeast. Es una plataforma de código abierto para el desarrollo de aplicaciones para los aparatos y dispositivos del Internet de las cosas sin tener que preocuparse por los detalles como los protocolos inalámbricos, compatibilidad de marca, o tener que saber cómo tratar con cada API específica que existe. ¡Nos permite utilizar los dispositivos virtuales que actúan como los de verdad! Así que incluso si no tienes una bombilla inteligente, tienes una virtual disponible.

Podemos instalar el paquete de NPM de Netbeast para Node-Red a nivel mundial así:

npm install -g node-red-contrib-netbeast

El netbeast-red node representará el panel de control Netbeast, lo que traducirá sus primitivas API para todos los dispositivos inteligentes que tienes en casa. ¡Afortunadamente, también está disponible como un módulo!

Inicia Netbeast:

npm install -g netbeast-cli
netbeast start

Esto hará que el panel esté disponible en el puerto 8000 y SSL en 8443. A continuación, abre el navegador a http://localhost:8000 y navega a Explore. Ahí podemos encontrar muchas aplicaciones y plugins. Busca las marcas de tus bombillas inteligente (Philips Hue, LIFX, Wemo) o si no tienes una, intenta descargar el plugin de la bombilla. ¡Comprueba que los plugins del panel contienen uno de estos!

La insignia amarilla indica que los plugins se están ejecutando, pero no pueden encontrar ningún dispositivo. Haz clic en el plugin de la bombilla para crear una bombilla virtual. Cualquier otro dispositivo que se descubra debe aparecer en la red.

Con todo en su lugar, volvamos al trabajo. Haremos un flujo simple:

  1. Arrastra y suelta un nodo de inyección.
  2. Arrastra y suelta el nodo Netbeast.
  3. Arrastra y suelta un nodo de depuración.
  4. Conecta todo como se muestra a continuación:

Ahora vamos a enviar una petición HTTP al panel de control. Al usar la API Netbeast se tendrá que enviar a través del nodo de inyección un JSON que contiene los valores que queremos que se activen en nuestra bombilla.

¡Presiona el botón para inyectar el color y la energía a todas tus bombillas inteligentes!

Cada tema representa un tipo diferente de dispositivo. Así que hay temas no solo para las luces, sino también para la música, calefacción, y el vídeo; así como sensores para la humedad, la presencia, la temperatura, y la lista continúa. Puedes encontrar en tu documentación una lista de temas y su estructura recomendada para ser traducido a todo tipo de dispositivos. Este motor de la IO es novato, pero potente. Un código abierto que permite a los desarrolladores reutilizar la información para crear escenarios realmente conectados, siendo de este modo inteligente.

Ahora Adentrémonos Más

A continuación, vamos a crear un segundo flujo usando otro plugin, un detector de ruido ambiental para utilizarlo como un iniciador para cambiar el color de la bombilla como un semáforo de ruido. En este tutorial vamos a utilizar uno virtual, así que no hay necesidad de comprar un nuevo hardware. Vamos a empezar haciendo clic en el botón “más” en el editor de Node-Red.

Ve de nuevo al Panel http://localhost:8000/explore a la sección Explorar y busca Volume-Plugin. Se trata de una aplicación web muy rudimentaria que se aprovecha de getUserMedia() dentro del navegador para capturar la información multimedia desde una simple aplicación HTML. Por lo tanto, es probable que sólo funcione en los navegadores modernos.

Haz clic en él para abrir, al igual que con la bombilla virtual. En él se solicita permiso para grabar desde el micrófono. A continuación, enviará los mensajes al intermediario MQTT de Netbeast, que será compartido a través de todo el panel de control, y así podremos suscribirnos. Para lograr esto sólo necesitaremos arrastrar y soltar un nodo de netbeast-trigger en el editor node red. A continuación, vamos a insertar una función entre el trigger y el nodo Netbeast, para decidir cuando está demasiado alto y cuando no. Además, deberíamos utilizar algunos nodos de depuración para comprobar si todo está bien. El esquema ahora se verá algo como esto:

Ahora, vamos a introducir algún código en el nodo de función tooLoud. Sí, sé que prometí que podrías programar sin necesidad de codificar, ¡pero ya he demostrado que puedes! Y se puede tratar de combinar los diferentes elementos disponibles u otros nodos del registro para llevar a cabo lo siguiente.

var volume = msg.payload.volume

node.log(volume)

if (volume < 50) {
    return { topic: 'lights', payload: { power: 1, color: '#00CC00'}}
} else if (volume < 75) {
    return { topic: 'lights', payload: { power: 1, color: '#CCCC00'}}
} else {
    return { topic: 'lights', payload: { power: 1, color: '#FF0000'}}
}

Este fragmento de código bastante simple está regresando una de las tres cargas útiles para el siguiente nodo con un código de color específico, dependiendo del nivel de volumen reportado por el nodo anterior.

¡Ahora estamos listos para continuar! Vamos a presionar el botón Deploy de nuevo y armemos un griterío. ¡Veamos cómo cambia la bombilla de un color a otro de inmediato!

Ya que el micrófono y el navegador web que estás utilizando podrían ser diferentes, no dudes en ajustar los valores de la función y umbrales, y también juega con los valores de color para ver cómo cambia tus bombillas.

Crea tus Propios Plugins

Esta bombilla en CSS puro se inspiró en éste cssdeck.

Como habrás notado, la bombilla virtual anterior es muy rudimentaria, por lo que es posible que desees modificarla. O mejor aún, puedes crear tus propios controladores para un hogar inteligente. Así que vamos a pasar por el proceso de crear un plugin virtual para Netbeast, lo que te permitirá crear tus propios controles para dispositivos inteligentes.

Puedes utilizar el paquete netbeast-cli para generar como por arte de magia algunos códigos. Mediante la ejecución de netbeast create myplugin --plugin tendríamos un proyecto básico como el siguiente:

myplugin
├── README.md
├── index.js
├── package.json
└── test.js

Frontend

Ahora, vamos a empezar a mimetizar la bombilla con un frontend. Los controladores de dispositivos por lo general no van a tener uno, así que el comando de andamio no incluye una carpeta pública todavía. Vamos a crear un directorio public dentro del proyecto y colocamos allí los siguientes archivos HTML, CSS y JS.

index.html

<head>
  <title>Netbeast Bulb Plugin</title>
  <link rel="stylesheet" href="bulb.css" media="screen" charset="utf-8">
</head>

<body>
  <div class="top-decoration"></div>
  <div id="plugin front-end">
  </div>
  <div class="bulb-container small">
    <div class="bulb light">
      <div id="bulb">
        <div class="bulb top"></div>
        <div class="bulb middle-1"></div>
        <div class="bulb middle-2"></div>
        <div class="bulb middle-3"></div>
        <div class="bulb bottom"></div>
      </div>
      <div id="base">
        <div class="screw-top"></div>
        <div class="screw a"></div>
        <div class="screw b"></div>
        <div class="screw a"></div>
        <div class="screw b"></div>
        <div class="screw a"></div>
        <div class="screw b"></div>
        <div class="screw c"></div>
        <div class="screw d"></div>
      </div>
    </div>
  </div>
    <div class="code-container">
      <pre><i class="txt-red">beast</i>(<i class="txt-green">'lights'</i>).<i class="txt-blue">set</i>({
  <i class="txt-green">color</i>: <i class="txt-green">"<input id="color" type="text" class="color" name="color" value="00fea5">"</i>,
  <i class="txt-green">power</i>: <i class="txt-green">"<input id="power" type="text" class="power" name="power" value="on">"</i>
})</pre>
    <button id="run-btn">
      RUN
    </button>
  </div><!-- wrapper -->

  <!-- declares bulb features and methods -->
  <script type="text/javascript" src="bulb.js"></script>
  <!-- real time comms library -->
  <script type="text/javascript" src="socketio.js"></script>
  <!-- simulates hardware communication -->
  <script type="text/javascript" src="hw-api.js"></script>
</body>

bulb.css

section {
  float: left;
  padding: 20px 50px 20px 50px;
}

.bulb-light {
  border: 0;
  background: transparent;
  margin: 0 auto !important;
  padding: 0 !important;
  display: block;
  z-index: 1;
}

#bulb { opacity: 1; z-index: 3; display: block;}

.bulb.top {
  border: 0;
  width: 300px;
  height: 300px;
  margin: 0 auto;
  padding: 0;
  border-radius: 999px;
  background: #E7E7E7;
}

.bulb.middle-1 {
  margin: -75px auto 0 auto;
  width: 190px;
  border-left: 35px solid transparent;
  border-right: 35px solid transparent;
  border-top: 55px solid #E7E7E7;
}

.bulb.middle-2 {
  margin: -22px auto 0 auto;
  width: 178px;
  border-left: 19px solid transparent;
  border-right: 19px solid transparent;
  border-top: 50px solid #E7E7E7;
}

.bulb.middle-3 {
  margin: -20px auto 0 auto;
  width: 182px;
  border-left: 5px solid transparent;
  border-right: 5px solid transparent;
  border-top: 30px solid #E7E7E7;
}

.bulb.bottom {
  width: 184px;
  height: 65px;
  margin: -8px auto 0 auto;
  padding: 0;
  border-radius: 0 0 999px 999px;
  background: #E7E7E7;
}

#base { position:relative; z-index: 2; }

.screw {
  transform: rotate(-3deg);
  -ms-transform: rotate(-3deg);
  -webkit-transform: rotate(-3deg);
  padding: 0;
}

.screw-top {
  margin: -18px auto -4px auto;
  padding: 0;
  width: 132px;
  height: 0;
  border-left: 15px solid transparent;
  border-right: 15px solid transparent;
  border-top: 21px solid #D3D3D3;
  border-radius: 999px;
}

.screw.a {
  background: #DDD;
  width: 150px;
  height: 15px;
  border-radius: 999px;
  margin: -1px auto 0px;
}

.screw.b {
  background: #D9D9D9;
  width: 135px;
  height: 15px;
  margin: -1px auto 0px;
}

.screw.c {
  margin: -1px auto 0px;
  width: 78px;
  height: 0;
  border-left: 30px solid transparent;
  border-right: 30px solid transparent;
  border-top: 20px solid #DDD;
  border-radius: 8px;
}

.screw.d {
  margin: 0 auto;
  width: 15px;
  height: 0;
  border-left: 30px solid transparent;
  border-right: 30px solid transparent;
  border-top: 15px solid #444;
}

.on #light {
  -moz-opacity: 1;
  -khtml-opacity: 1;
  opacity: 1;
}

.bulb.top, .bulb.bottom {
  transition: all 0.5s ease-in-out;
}

.bulb.middle-1, .bulb.middle-2, .bulb.middle-3 {
  transition: all 0.5s ease-in-out;
}

Con estos archivos HTML y CSS, ya se debería poder ver una forma de bombilla en tu navegador. ¡Abre el archivo HTML para ver en vivo! ¿Está funcionando? Bien, ahora vamos a darle algunas funciones.

bulb.js

Este archivo imitará el comportamiento de una bombilla con un simple clic de encendido. Al hacer click para apagarla, establecerás un par de funciones que serán utilizadas un poco después para cambiar su color a través de Netbeast.

var color = document.getElementById('color')
var power = document.getElementById('power')
var bulb = document.getElementById('bulb')
var button = document.getElementById('run-btn')
var light = document.getElementById('light')

button.onclick = function toggleBulbState () {
  changeBulbParams({ color: color.value, power: power.value })
}

function setBulbParams (params) {
  if (params.power === 'off') {
    params = { color: 'E7E7E7' }
  }
  console.log('set params', params)

  var bulb_parts = ['.bulb.middle-1', '.bulb.middle-2', '.bulb.middle-3']

  document.querySelector('.bulb.top').style.boxShadow = '0px 0px 98px #' + params.color

  document.querySelector('.bulb.top').style.backgroundColor = params.color
  document.querySelector('.bulb.bottom').style.backgroundColor = params.color
  bulb_parts.forEach(function (className) {
    document.querySelector(className).style.borderTopColor = params.color
  })
}

function changeBulbParams (params) {
  console.log('change params', params)
  /* Overwrite html fields if necessary */
  color.value = params.color || color.value
  power.value = params.power || power.value
  setBulbParams({color: color.value, power: power.value})
}

Luego, todo comenzará a tener sentido: los campos y el botón de ejecución, ¡ahora podrás comenzar a probar los diferentes colores de tu nueva bombilla virtual! Sin embargo, la razón por la que vinimos hasta aquí es para hacer otro dispositivo de nuestro ecosistema del Internet de las Cosas.

hw-api.js

El último de front-end JS realizado por nosotros mismos, simula una conexión inalámbrica con el servidor, como lo haría un WiFi o bombilla Bluetooth con su mando a distancia, tales como un teléfono, un servidor o un hub. ¡Es la interfaz que el código plugin utilizará para controlarlo!

var socket = io.connect()

socket.on('connect', function () { console.log('ws:// bulb is online') })
socket.on('disconnect', function () { console.log('ws:// connection with bulb lost') })

socket.on('set', function (params) {
   changeBulbParams(params) // uses functions from bulb.js!
})

socket.on('get', function () {
  const params = { power: power.value, color: color.value }
  socket.emit('params', params)
})

Por último, necesitamos que la biblioteca WebSocket sea incluida en nuestro HTML para que la interfaz esté lista. Puedes copiar el código fuente de https://raw.githubusercontent.com/netbeast/bulb-plugin/master/public/socketio.js y pegarlo en un archivo llamado socketio.js. Desde un terminal con curl o wget, lo puedes hacer así de simple:

curl https://raw.githubusercontent.com/netbeast/bulb-plugin/master/public/socketio.js  > public/socketio.js

Tendríamos ahora una estructura de archivos que se ve así:

myplugin
├── README.md
├── index.js
├── package.json
├── public
│   ├── bulb.css
│   ├── bulb.js
│   ├── hw-api.js
│   ├── index.html
│   └── socketio.js
└── test.js

Backend

Ahora vamos a implementar la interfaz con el dispositivo y registrarlo en el motor Netbeast. Éste escuchará los websockets para detectar si alguna bombilla se ha instalado en la red, y luego hará un POST a la API del panel de control para que los nuevos recursos estén disponibles.

Por eso, vamos a echar un vistazo a los archivos que generamos antes:

package.json

Este archivo contiene todas las dependencias y la información necesaria para ejecutar tu aplicación. Netbeast utiliza el habitual package.json también para recuperar cierta información, como el nombre o el tipo. ¡Es importante especificar que este paquete es un plugin!

{
  "name": "myplugin",
  "version": "0.0.0",
  "description": "Netbeast plugin for... <your description>",
  "main": "index.js",
  "netbeast": {
    "bootOnLoad": true,
    "type": "plugin"
  },
  "dependencies": {
    "bluebird": "^3.3.5",
    "body-parser": "^1.15.0",
    "express": "^4.13.4",
    "minimist": "^1.2.0",
    "mocha": "^2.3.2",
    "morgan": "^1.6.1",
    "netbeast": "^1.0.6",
    "socket.io": "^1.4.5",
    "superagent": "^1.8.3"
  },
  "devDependencies": {},
  "scripts": {
    "test": "node test.js",
    "start": "node index.js"
  },
  "repository": {
    "type": "git",
    "url": "GITHUB_REPOSITORY"
  },
  "keywords": [
    "iot",
    "netbeast",
    "plugin"
  ],
  "author": "YOUR_EMAIL",
  "license": "GPL 3",
  "bugs": {
    "url": "ISSUES_CHANNEL"
  },
  "homepage": "HOMEPAGE"
}

index.js

¡Éste es el código que se trae desde el panel de control de Netbeast para lanzar el plugin! Éste tendrá que aceptar el puerto a través de argumentos de línea de comando para saber dónde aceptar peticiones entrantes. Se lanzará como si escribiéramos node myplugin.js --port <a free port number>. ¡Recuerda tomar en cuenta el hashbang al principio! #!/usr/bin/env node.

#!/usr/bin/env node

var io = require('socket.io')()
var express = require('express')
var bodyParser = require('body-parser')

var app = express()

// Netbeast apps need to accept the port to be launched by parameters
var argv = require('minimist')(process.argv.slice(2))

app.use(express.static('public')) // will serve our app in an HTTP server
app.use(bodyParser.json()) // will parse JSON API calls
app.use('/api', require('./plugin')(io)) 

var server = app.listen(argv.port || 31416, function () {
  console.log('Bulb plugin listening at http://%s:%s', server.address().address,
  server.address().port)
})

// we need websockets to push updates to browser view
io.listen(server)

Como se puede ver nos faltaba un archivo por iniciar, el que realmente implementa los controladores socket.io. ¡Nada sofisticado!

plugin.js

var express = require('express')
var netbeast = require('netbeast')

var router = express.Router()
var bulbParams // auxiliar variable, nasty way to transmit changes, but works

module.exports = function (io) {
  io = io
  
  // Create resource that works on lights topic and listens on /api route
  netbeast('lights').create({ app: 'myplugin', hook: '/api' })

  io.on('connection', function () { 
  	console.log('ws:// bulb has connected to plugin') 
  })

  io.on('disconnection', function () { 
  	console.log('ws:// bulb has disconnected from plugin') 
  })

  io.on('connect_failure', function (err) { console.trace(err) })

  router.post('/', function (req, res) {
    io.emit('set', {
      power: req.body.power,
      color: req.body.color,
    })
    res.status(200).json(req.body)
  })

  router.get('/', function (req, res) {
    io.emit('get')
    var timerReference = setTimeout(function () {
      if (bulbParams) {
        res.json(bulbParams)
      } else {
        res.status(200).json({ error: 'No bulb available' })
      }
    }, 3000)
  })

  return router
}

Inicia tu Aplicación

Ahora es el momento de probar la aplicación. Puedes empaquetarlo todo en un formato tar.gz y luego subir la aplicación a tu panel de control en la sección de arrastrar y soltar http://localhost:8000/install.

beast package # Compresses your app when ran in myplugin dir

¡Voilà! Ahora puedes ir a tus plugins y probarlo. Ve a la sección de red (http://localhost:8000/devices) para ver su funcionamiento y cambiar su color a partir de ahí.

Si algo sale mal o piensas que podrías haber olvidado un detalle, trata de ejecutar localmente con el nodo node index.js, y tal vez será más fácil de depurar que dentro del registro netbeast start.

Publicar su trabajo

Si deseas que la aplicación aparezca en el panel de control de la sección Explore de Netbeast, debes crear un repositorio en GitHub con la aplicación o plug-in de Netbeast, ambos incluidos en la descripción y README.md.

Para encontrar las aplicaciones que hacemos, usa la API de búsqueda de GitHub. Vemos los mismos resultados que aparecen cuando se realiza una solicitud GET a:https://api.github.com/search/repositories?q=netbeast+language:javascript

¡Sabrás que se mostrará tu aplicación, si parece hay!

¿Qué sigue?

Ambos proyectos son de open source y realmente han involucrado a las comunidades. Si deseas comenzar a crear tus propios flujos o nodos al Node-Red, echa un vistazo a su documentación oficial. Sigue los pasos descritos allí y podrás publicar tu propio nodo o flujo en poco tiempo.

Por otro lado, si quieres entrar en el interior Netbeast, puedes seguir su documentación también o echar un vistazo al repositorio del panel. Al usar la API Netbeast, no tienes que centrarte en los dispositivos individuales, marcas o tecnologías, así que dale una oportunidad. Puedes aprender más sobre esto aquí o unirte a su Slack channel y discutir Node-RED, IoT o Node.js.

Si deseas instalar esto en una Raspberry Pi, Beagle Bone o servidor antiguo, lo convertirías en un Smart Hub fácil de hackear, ¡sin código! Hay instaladores ya hechos para ellos en ambos sitios.

Feliz hacking.

El artículo original lo pueden encontrar en Totpal.

 

28 Nov 2016
Android, Desarrollo, Programación, Tecnología 0 comment

Guía de Desarrolladores de Android para el Patrón de Navegación de Fragmentos

BY BECZE SZABOLCS – FREELANCE SOFTWARE ENGINEER @ TOPTAL(TRANSLATED BY MARISELA ORDAZ)

 

Con el pasar de los años he visto diferentes implementaciones del patrón de navegación de Android. Algunas aplicaciones usaban solo Actividades, mientras que otras Actividades se mezclaban con Fragmentos y/o con Vistas Personalizadas (Custom Views).

Una de mis implementaciones de patrón de fragmentos favorita está basada en la filosofía “Una-Actividad-Múltiples-Fragmentos” (“One-Activity-Multiple-Fragments”), o sencillamente el Patrón de Navegación de Fragmentos (Fragment Navigation Pattern), en donde cada pantalla en la aplicación es un Fragmento de pantalla completa y todos o la mayoría de estos fragmentos se encuentran dentro de una Actividad.

Este enfoque no solo simplifica como se implementa la navegación, sino que también tiene un mejor rendimiento y por ende le ofrece una mejor experiencia de usuario.

Android Developer’s Guide to Fragment Navigation Pattern

En este artículo exploraremos algunas implementaciones de patrón de navegación comunes en Android, luego introduciremos el patrón de navegación basado en Fragmentos. Una aplicación de muestra que implementa este patrón puede ser encontrada en GitHub.

Un Mundo de Actividades

Una aplicación de Android típica que utiliza solamente actividades está organizada en una estructura de tipo Árbol (precisamente en una grafo dirigido) donde la actividad principal en iniciada por el launcher. Mientras navegas por la aplicación hay un “back stack” de la actividad que se mantiene gracias el Sistema Operativo.

Un ejemplo sencillo se muestra en el siguiente diagrama:

Actividad A1 es el punto de entrada de nuestra aplicación (por ejemplo, representa una pantalla inicial o un menú principal) y desde ese punto el usuario puede navegar hacia A2 o A3. Cuando necesites comunicarte entre actividades puedes utilizar startActivityForResult() o podrías compartir un objeto lógico de negocios globalmente accesible entre ambas actividades.

Cuando necesites agregar una nueva Actividad deberás seguir los siguientes pasos:

  • Define la nueva actividad
  • Regístrala en AndroidManifest.xml
  • Ábrela con un startActivity() de otra actividad

Aunque este diagrama de navegación es un enfoque bastante simplificado; pero puede volverse muy complicado cuando necesitas manipular de back stack o cuando tienes que re-utilizar la misma actividad varias veces, por ejemplo cuando te gustaría que el usuario navegará a través de diferentes pantallas de tutoriales pero cada pantalla utiliza la misma actividad como base.

Por suerte tenemos herramientas para estos casos llamadas tareas y algunas guías para una navegación de back stack apropiada.

Luego, con API nivel 11 llegaron los fragmentos…

Un Mundo de Fragmentos

“Android introduce los fragmentos en Android 3.0 (nivel de API 11), principalmente para admitir diseños de IU más dinámicos y flexibles en pantallas grandes, como las de las tablets. Como la pantalla de una tablet es mucho más grande que la de un teléfono, hay más espacio para combinar e intercambiar componentes de la IU. Los fragmentos admiten esos diseños sin la necesidad de que administres cambios complejos en la jerarquía de vistas. Al dividir el diseño de una actividad en fragmentos, puedes modificar el aspecto de la actividad durante el tiempo de ejecución y conservar esos cambios en una pila de actividades administrada por la actividad.” – cita de la Guía de Google API para Fragmentos.

Este Nuevo juguete permitió a los desarrolladores crear una Interfaz de Usuario multi-paneles y poder re-usar los componentes en otras actividades. Algunos desarrolladores adoran esto mientras que otros no tanto. Es un debate popular el hecho de usar o no Fragmentos, pero yo creo que todos estarán de acuerdo en que los fragmentos trajeron una complejidad adicional y los desarrolladores tienen que entenderlos apropiadamente para poder usarlos.

La Pesadilla del Fragmento de Pantalla Completa en Android

Comencé a ver más y más ejemplos donde los fragmentos no solo representaban una parte de la pantalla, sino que toda la pantalla era un fragmento dentro de una actividad. Hubo una vez que vi un diseño en el que cada actividad tenía exactamente un fragmento de pantalla completa y nada más, y la única razón por la que esas actividades existían era para almacenar los fragmentos. Aparte del fallo en el diseño, hay otro problema con este enfoque. Mira un momento el diagram a continuación:

¿Cómo puede A1 comunicarse con F1? Lo que sucede es que A1 tiene total control sobre F1, debido a que creó F1. A1 podría pasar un paquete, por ejemplo, en la creación de F1 o puede invocar sus métodos públicos. ¿Cómo puede F1 comunicarse con A1? Bueno eso es más complicado, puede resolverse con un patrón de callback/observer donde A1 se suscribe a F1 y F1 notifica a A1.

¿Pero cómo se pueden comunicar A1 y A2? Como se explicó anteriormente, se podrían comunicar vía startActivityForResult().

Y ahora la verdadera pregunta: ¿Cómo se pueden comunicar F1 y F2? Aún en este caso podemos tener un componente lógico de negocios el cual es accesible globalmente, y puede ser utilizado para pasar datos. Pero ese componente no siempre equivale a un diseño elegante. ¿Qué pasaría si F2 necesita pasarle información a F1 de forma más directa? En tal caso, con un patrón callback F2 puede notificar a A2, luego A2 termina con un resultado y ese resultado puede ser almacenado por A1 quien puede notificar a F1.

Este enfoque requiere de mucho código boilerplate y se convierte rápidamente en una fuente de bugs, dolor y rabia.

¿Y si pudiéramos deshacernos de todas las actividades y quedarnos sólo con una de ellas la cual mantendrá el resto de los fragmentos?

Patrón de Navegación de Fragmentos

Con el pasar del tiempo comencé a utilizar el patrón de “Una-Actividad-Múltiples-Fragmentos” en la mayoría de mis aplicaciones y aún lo sigo usando. Existen muchas discusiones por ahí sobre este enfoque o filosofía, por ejemplo aquí y aquí. Lo que me perdí fue un ejemplo en concreto que puedo ver y probar por mí mismo.

Miremos el siguiente diagrama un momento:

Ahora tenemos solo una actividad contenedora y tenemos fragmentos múltiples que de nuevo se encuentran en una estructura de tipo Árbol. La navegación entre ellos se maneja por el FragmentManager, este tiene su back stack.

Te podrás cuenta que ahora no tenemos el startActivityForResult() pero podemos implementar el patrón callback/observer. Ahora veamos algunos pros y contras de este enfoque:

Pros:

1. Más limpio y mantenible AndroidManifest.xml

Ahora que tenemos sólo una Actividad, ya no tenemos que actualizar el manifiesto cada vez que agregamos una nueva pantalla. A diferencia de las actividades, no tenemos que declarar los fragmentos.

Esto podría parecer una cosa pequeña, pero para aplicaciones más grandes con más de 50 actividades esto podría mejorar significativamente la legibilidad del AndroidManifest.xml file.

Observa el archivo del manifiesto de la aplicación ejemplo, el cual tiene varias pantallas. El archivo de manifiesto se mantiene súper sencillo.

<?xml version="1.0" encoding="utf-8"?>
  package="com.exarlabs.android.fragmentnavigationdemo.ui" >
  <application android:name= ".FragmentNavigationDemoApplication"
android:allowBackup="true"
  	android:icon="@mipmap/ic_launcher"
android:label="@string/app_name"
android:supportsRtl="true"
android:theme="@style/AppTheme">
<activity
android:name="com.exarlabs.android.fragmentnavigationdemo.ui.MainActivity"
android:label="@string/app_name"
android:screenOrientation="portrait"
android:theme="@style/AppTheme.NoActionBar" >
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
</application>
</manifest>

2. Gestión centralizada de la navegación

En mi código ejemplo, notarás que use NavigationManager el cual en mi caso, es inyectado a cada uno de los fragmentos. Éste gestor puede ser usado como un lugar central para el logging, gestión back stack entre otras, así que los comportamientos de navegación se desacoplan del resto de la lógica del negocio y no se esparcen en implementaciones de diferentes pantallas.

Imaginemos una situación en la que queremos iniciar una pantalla, donde el usuario puede seleccionar algunos ítems de una lista de personas. También te gustaría pasar algunos argumentos de filtrado, como edad, ocupación y género.

En caso de Actividades, escribirías:

Intent intent = new Intent();
intent.putExtra("age", 40);
intent.putExtra("occupation", "developer");
intent.putExtra("gender", "female");
startActivityForResult(intent, 100);

Luego, debes definir onActivityResult en algún lugar abajo y manejar el resultado.

@Override
protected void onActivityResult(int requestCode, int resultCode, Intent data) {
super.onActivityResult(requestCode, resultCode, data);
}

Mi problema personal con éste acercamiento es que estos argumentos son “extras” y no son obligatorios, así que tengo que asegurarme que la actividad receptora maneje los diferentes casos, cuando falte un extra. Después cuando se realice una refactorización y cuando el extra, por ejemplo, de “edad” ya no sea necesario, entonces tengo que buscar por todo el código donde se inició esta actividad y asegurarme de que todos los extras sean correctos.

Además, ¿No sería mejor si el resultado (lista de personas) llegará como _List_ y no en una forma serial que luego debe ser deserializada?

En el caso de la navegación basada en fragmentos, todo es más directo. Todo lo que tienes que hacer es escribir un método en el NavigationManager llamado startPersonSelectorFragment() con los argumentos necesarios y con una implementación callback.

mNavigationManager.startPersonSelectorFragment(40, "developer", "female",
new PersonSelectorFragment.OnPersonSelectedListener() {
@Override
public boolean onPersonsSelected(List<Person> selection) {
[do something]
return false;
}
});

O con RetroLambda

mNavigationManager.startPersonSelectorFragment(40, "developer", "female", selection -> [do something]);

3. Mejores formas de comunicación entre pantallas

Entre actividades, solo podemos compartir un Paquete que contenga datos primitivos o serializados. Ahora con fragmentos podemos implementar un patrón callback donde, por ejemplo, F1 puede escuchar a F2 pasando objetos arbitrarios. Por favor, dale un vistazo a los ejemplos anteriores de implementación de callback, which returns back a _List_.

4. Crear Fragmentos es menos costoso que crear Actividades

Esto se vuelve obvio cuando usas un cajón que tiene por ejemplo 5 ítems de menú y en cada página el cajón debería ser mostrado nuevamente.

En caso de navegación de actividad pura, cada página debería inflarse e iniciar el cajón, pero por supuesto esto es caro.

En el diagrama que se muestra puedes ver varios fragmentos de raíz o root fragments (FR*) los cuales son los fragmentos de pantalla que pueden ser accedidos directamente desde el cajón, y también el cajón es solo accesible cuando se muestran estos fragmentos. Todo lo que se encuentra a la derecha de la línea marcada en el diagrama está ahí como ejemplo de un esquema de navegación arbitraria.

Ya que la actividad contenedora contiene el cajón, solo tenemos una instancia de cajón, por lo que cada paso de navegación donde el cajón debería ser visible no tienes que iniciarlo nuevamente. ¿Aún no estas convencido de cómo funciona todo? Dale un vistazo a mi aplicación de muestra donde se demuestra el uso de los cajones.

Contras

Mi gran temor siempre ha sido que si utilizo el patrón de navegación de fragmentos en un proyecto, entonces en algún momento encontraré algún problema desconocido que será difícil de resolver alrededor de la complejidad de los fragmentos, las bibliotecas de terceros y las diferentes versiones de Sistema Operativo. ¿Y si tuviera que refractar todo lo que he hecho hasta ahora?

De hecho, tendría que resolver los problemas con nested fragments, bibliotecas de terceros las cuales utilizan fragmentos como ShinobiControls, ViewPagers y FragmentStatePagerAdapters.

Admito que obtener la experiencia suficiente con fragmentos como para resolver estos problemas fue un largo proceso. Pero en cada caso el problema no era que la filosofía es mala, sino que no entendía fragmentos lo suficiente. Pero si entiendes fragmentos mejor que yo en aquel momento entonces no tendrás ningún problema.

El único contra que puedo mencionar ahora es que podemos encontrar problemas que no sean triviales de resolver, debido a que no hay una biblioteca madura que muestre todos los escenarios complejos de una aplicación compleja con navegación basada en fragmentos.

Conclusión

En este artículo, hemos visto una alternativa para implementar navegación en una aplicación Android . Se comparó el patrón con la filosofía de navegación tradicional que utiliza actividades y vimos algunas muy buenas razones por las que es ventajoso usar fragmentos en lugar del enfoque tradicional.

En caso de que no lo hayas revisado aún, chequea la aplicación demo en la implementación GitHub . No temas contribuir en la misma con buenos ejemplos que podrían demostrar de mejor forma su uso.

El artículo original lo pueden encontrar en Totpal.

21 Nov 2016
Desarrollo, Programación, Tecnología, TopTal 0 comment

Guarda la Calma y Transiciona a un Nuevo Equipo de Desarrollo

BY CARLOS RAMIREZ III – FREELANCE SOFTWARE ENGINEER @ TOPTAL

#Development #Onboarding #ProjectManagement

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 consultorí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.

Passing the torch to new developers? Make sure the new team doesn’t get burned and you don’t waste time firefighting.

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.

Good documentation is the cornerstone of any successful transition. Make sure your new team has everything they need to take over.

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.

No technical background? There's no excuse for failing to properly understand the building blocks of your project. It could cost you dearly.

¿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:

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.

Make sure you properly manage the technical and personal aspects of your project handoff. Make your new team feel at home and don’t antagonize your old team.

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.

 

El artículo original lo pueden encontrar en Totpal.

15 Nov 2016
Programación, Python, Tecnología, TopTal 0 comment

Código Buggy Python: Los 10 Errores más Comunes que Cometen los Desarrolladores Python

BY MARTIN CHIKILIAN – PYTHON SOFTWARE ENGINEER @ TOPTAL

#Python

Acerca de Python

Python es un lenguaje de programación interpretado y orientado a objetos de alto nivel con semántica dinámica. Su alto nivel integrado en las estructuras de datos, combinado con escritura y binding dinámicos lo hacen muy atractivo para el desarrollo rápido de aplicaciones, así como para su uso como lenguaje de script o glue para conectar componentes o servicios existentes. Python trabaja con módulos y paquetes, fomentando así la modularidad del programa y la reutilización de código.

Sobre este Artículo

La sintaxis simple y fácil de aprender de Python, puede enviar a los desarrolladores de Python en la dirección incorrecta – especialmente aquellos que están conociendo la lengua – perdiendo en el camino algunas de sus sutilezas y subestimando el poder del lenguaje diverso de Python.

Con esto en mente, este artículo presenta una lista “top 10” de errores sutiles, y difíciles de ver, que pueden tomar desprevenidos incluso a algunos de los desarrolladores de Python más avanzados.

(Nota:Este artículo está dirigido a un público más avanzado que el de Errores Comunes de Programadores Python, que se orienta más hacia aquellos que son nuevos en la lengua.)

Error común # 1: Un Mal Uso de Expresiones como Valores Predeterminados para los Argumentos de la Función

Python permite especificar que un argumento de la función es opcional, proporcionando un valor por defecto para ello. Si bien ésta es una gran característica de la lengua, puede dar lugar a cierta confusión cuando el valor por defecto es mutable. Por ejemplo, considera ésta definición de la función de Python:

>>> def foo(bar=[]):        # bar is optional and defaults to [] if not specified
...    bar.append("baz")    # but this line could be problematic, as we'll see...
...    return bar

Un error común es pensar que el argumento opcional se establecerá en la expresión por defecto específica, cada vez que se llama la función sin necesidad de suministrar un valor para el argumento opcional. En el código anterior, por ejemplo, se podría esperar que llamar a foo() varias veces (es decir, sin especificar un argumento bar) siempre daría de regreso baz, ya que la hipótesis sería que cada vez que foo() se llama (sin un argumento bar especificado) bar está ajustado a [] (es decir, una nueva lista vacía).

Pero vamos a ver lo que realmente sucede cuando se hace esto:

>>> foo()
["baz"]
>>> foo()
["baz", "baz"]
>>> foo()
["baz", "baz", "baz"]

¿Eh? ¿Por qué se siguió añadiendo el valor predeterminado de baz a una lista existente cada vez que foo()era llamado, en lugar de crear una nueva lista en cada oportunidad? La respuesta más avanzada de programación Python es que, el valor por defecto para un argumento de función se evalúa sólo una vez, en el momento en que se define la función. Por lo tanto, el argumento bar se inicializa con su valor por defecto (es decir, una lista vacía) sólo cuando foo() se ha definido por primera vez, pero luego los llamados a foo() (es decir, sin un argumento bar especificado) seguirán utilizando la misma lista a la que bar fue inicializado originalmente.

Por cierto, una solución común para esto es la siguiente:

>>> def foo(bar=None):
...    if bar is None:		# or if not bar:
...        bar = []
...    bar.append("baz")
...    return bar
...
>>> foo()
["baz"]
>>> foo()
["baz"]
>>> foo()
["baz"]

Error común # 2: Uso Incorrecto de las Variables de Clase

Consideremos el siguiente ejemplo:

>>> class A(object):
...     x = 1
...
>>> class B(A):
...     pass
...
>>> class C(A):
...     pass
...
>>> print A.x, B.x, C.x
1 1 1

Tiene sentido.

>>> B.x = 2
>>> print A.x, B.x, C.x
1 2 1

Sí, de nuevo como se esperaba.

>>> A.x = 3
>>> print A.x, B.x, C.x
3 2 3

¿Qué es esto? Sólo cambiamos A.x ¿Por qué C.x cambió también?

En Python, las variables de clase se manejan internamente como diccionarios y siguen lo que se refiere a menudo como Method Resolution Order (MRO). Así que en el código anterior, ya que el atributo x no se encuentra en la clase C, se buscará en sus clases base (únicamente A en el ejemplo anterior, aunque Python apoya herencia múltiple). En otras palabras, C no tiene su propia propiedad x, independiente de A. Por lo tanto, las referencias a C.x son de hecho referencias a A.x. Esto causa un problema Python, a menos que se maneje adecuadamente. Más información sobre atributos de clase en Python.

Error común # 3: Especificación de Parámetros de Forma Incorrecta para un Bloque de Excepción

Supongamos que tienes el siguiente código:

>>> try:
...     l = ["a", "b"]
...     int(l[2])
... except ValueError, IndexError:  # To catch both exceptions, right?
...     pass
...
Traceback (most recent call last):
  File "<stdin>", line 3, in <module>
IndexError: list index out of range

El problema aquí es que el informe except no toma una lista de excepciones que se especifiquen de esta forma. Por el contrario, Python 2.x la sintaxis except Exception, e, se utiliza para enlazar la excepción al segundo parámetro opcional especificado (en éste caso e), con el fin de que esté disponible para una inspección adicional. Como resultado, en el código anterior, la excepción IndexError no está siendo capturada por el informe except; más bien, la excepción termina siendo enlazada a un parámetro llamado IndexError.

La forma correcta de capturar varias excepciones en un informe except, es especificar el primer parámetro como una tupla que contiene todas las excepciones a ser capturadas. Además, para la máxima portabilidad, utiliza la palabra clave as, ya que la sintaxis es apoyada por Python 2 y Python 3:

>>> try:
...     l = ["a", "b"]
...     int(l[2])
... except (ValueError, IndexError) as e:  
...     pass
...
>>>

Error común # 4: No Entender las Reglas de Ámbito de Python

La resolución de ámbito de Python se basa en lo que se conoce como la regla LEGB, que es la abreviatura de Local, Enclosing, Global, Built-in. Parece bastante sencillo, ¿verdad? Bueno, en realidad, hay algunas sutilezas en la forma en que esto funciona en Python, lo que nos lleva al problema común, más avanzado, de programación Python, a continuación.

Considera lo siguiente:

>>> x = 10
>>> def foo():
...     x += 1
...     print x
...
>>> foo()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in foo
UnboundLocalError: local variable 'x' referenced before assignment

¿Cuál es el problema?

El error anterior se debe a que, cuando se hace una asignación a una variable en un ámbito, esa variable es considerada, automáticamente por Python, como local en ese ámbito y sigue cualquier variable de nombre similar, en cualquier ámbito exterior.

Muchos de ellos son, por lo tanto, se sorprenden al conseguir un UnboundLocalError en el código de trabajo anterior, cuando éste se modifica al añadir una instrucción de informe, en alguna parte del cuerpo de una función. (Puedes leer más sobre esto aquí.)

Es particularmente común que esto confunda a los desarrolladores cuando usan listas. Considera el siguiente ejemplo:

>>> lst = [1, 2, 3]
>>> def foo1():
...     lst.append(5)   # This works ok...
...
>>> foo1()
>>> lst
[1, 2, 3, 5]

>>> lst = [1, 2, 3]
>>> def foo2():
...     lst += [5]      # ... but this bombs!
...
>>> foo2()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in foo
UnboundLocalError: local variable 'lst' referenced before assignment

¿Eh? ¿Por qué foo2 falló, mientras que foo1 funcionó muy bien?

La respuesta es la misma que en el problema del ejemplo anterior, pero es sin duda más sutil. foo1 No está haciendo una asignación a lst, mientras que foo2 sí lo está. Recordando que lst += [5] es en realidad la abreviatura de lst = lst + [5], vemos que estamos tratando de asignar un valor a lst (por lo tanto, Python presume que está en el ámbito local). Sin embargo, el valor que estamos tratando de asignar a lst se basa en el mismo lst (de nuevo, ahora presume estar en el ámbito local), que aún no ha sido definido. Boom.

Error común # 5: Modificar una Lista al Iterar Sobre Ella

El problema con el siguiente código debería ser bastante obvio:

>>> odd = lambda x : bool(x % 2)
>>> numbers = [n for n in range(10)]
>>> for i in range(len(numbers)):
...     if odd(numbers[i]):
...         del numbers[i]  # BAD: Deleting item from a list while iterating over it
...
Traceback (most recent call last):
  	  File "<stdin>", line 2, in <module>
IndexError: list index out of range

La eliminación de un elemento de una lista o matriz, mientras que se da iteración sobre ella, es un problema de Python que es bien conocido por cualquier desarrollador de software con experiencia. Sin embargo, aunque el ejemplo anterior puede ser bastante obvio, incluso los desarrolladores avanzados pueden involuntariamente, ser tomados por sorpresa por éste código, el cual es mucho más complejo.

Afortunadamente, Python incorpora una serie de paradigmas de programación elegantes que cuando se utilizan correctamente, pueden resultar en un código significativamente simplificado y racionalizado. Un beneficio secundario de esto es que el código más simple es menos probable que sea sorprendido por el bug eliminación-accidental-de-un-item-de-lista-mientras-iterando-sobre-ella. Uno de estos paradigmas es el de [comprensiones de lista]((https://docs.python.org/2/tutorial/datastructures.html#tut-listcomps). Por otra parte, las comprensiones de lista son particularmente útiles para evitar este problema específico, como se muestra en ésta implementación alternativa del código mostrado arriba, que funciona perfectamente:

>>> odd = lambda x : bool(x % 2)
>>> numbers = [n for n in range(10)]
>>> numbers[:] = [n for n in numbers if not odd(n)]  # ahh, the beauty of it all
>>> numbers
[0, 2, 4, 6, 8]

Error común # 6: La Confusión de Cómo Python Enlaza las Variables en los Cierres

Teniendo en cuenta el siguiente ejemplo:

>>> def create_multipliers():
...     return [lambda x : i * x for i in range(5)]
>>> for multiplier in create_multipliers():
...     print multiplier(2)
...

Deberías esperar el siguiente resultado:

0
2
4
6
8

Pero en realidad obtienes:

8
8
8
8
8

¡Sorpresa!

Esto sucede debido al comportamiento enlace tardío de Python, que dice que los valores de las variables utilizadas en los cierres, se buscan en el momento en el que se llama a la función interna. Así que en el código anterior, cuando cualquiera de las funciones devueltas es llamada, el valor de i se busca en el ámbito que lo rodea en el momento en que se llama (y en ese momento, el círculo se ha completado, por lo que a i ya se le ha asignado su valor final de 4).

La solución a este problema común Python es un poco de hack:

>>> def create_multipliers():
...     return [lambda x, i=i : i * x for i in range(5)]
...
>>> for multiplier in create_multipliers():
...     print multiplier(2)
...
0
2
4
6
8

¡Voilà! Estamos tomando ventaja de los argumentos por defecto para generar funciones anónimas, con el fin de lograr el comportamiento deseado. Algunos llamarían a esto, elegante. Algunos lo llamarían sutil. Algunos lo odian. Pero si eres un desarrollador de Python, es importante entender esto.

Error común # 7: Crear Dependencias de Módulos Circulares

Digamos que tienes dos archivos, a.py y b.py, cada uno de los cuales importa al otro, de la siguiente manera:

en a.py:

import b

def f():
    return b.x
	
print f()

Y en b.py:

import a

x = 1

def g():
    print a.f()

En primer lugar, vamos a tratar de importar a.py:

>>> import a
1

Funcionó muy bien. Tal vez te sorprendió. Después de todo, tenemos una importación circular aquí que presumiblemente debería ser un problema, ¿no?

La respuesta es que la mera presencia de una importación circular no es como tal un problema en Python. Si un módulo ya se ha importado, Python es lo suficientemente inteligente como para no intentar volverlo a importar. Sin embargo, dependiendo del punto en el que cada módulo está intentando acceder a las funciones o variables definidas en el otro, podrías tener problemas.

Así que volviendo a nuestro ejemplo, cuando importamos a.py, no tenía ningún problema al importar b.py, ya que b.py no requiere nada de b.py para definirse en el momento de su importación. La única referencia en b.py a a, es el llamado a a.f(). Pero ese llamado está en g() y nada en a.py o b.py invoca g(). Así que, la vida es bella.

Pero ¿qué ocurre si se intenta importar b.py (claro, sin haber previamente importado a.py):

>>> import b
Traceback (most recent call last):
  	  File "<stdin>", line 1, in <module>
  	  File "b.py", line 1, in <module>
    import a
  	  File "a.py", line 6, in <module>
	print f()
  	  File "a.py", line 4, in f
	return b.x
AttributeError: 'module' object has no attribute 'x'

Uh oh. ¡Eso no es bueno! El problema aquí es que, en el proceso de importación b.py, intenta importar a.py, lo que como resultado llama a f(), que a su vez intenta acceder a b.x. Pero b.x aún no ha sido definida. De ahí la excepción AttributeError.

Al menos una solución a esto es bastante trivial. Simplemente modifica b.py para importar a.py dentro de g():

x = 1

def g():
    import a	# This will be evaluated only when g() is called
    print a.f()

Cuando se importa, todo está bien:

>>> import b
>>> b.g()
1	# Printed a first time since module 'a' calls 'print f()' at the end
1	# Printed a second time, this one is our call to 'g'

Error común # 8: Choque de Nombres con Módulos de la Biblioteca Estándar de Python

Una de las ventajas de Python es la gran cantidad de módulos de biblioteca que trae desde el principio. Pero como resultado, si no estás evitando esto conscientemente, no es tan difícil encontrarse con un choque de nombres, entre el nombre de uno de tus módulos y un módulo con el mismo nombre en la biblioteca estándar que se incluye en Python (por ejemplo, es posible que tengas un módulo denominado email.py en tu código, lo que estaría en conflicto con el módulo de biblioteca estándar del mismo nombre).

Esto puede conducir a problemas muy agresivos, como la importación de otra biblioteca que a su vez intenta importar la versión de bibliotecas estándar Python de un módulo, pero como ya tienes un módulo con el mismo nombre, el otro paquete importa erróneamente tu versión, en lugar de la que se encuentra dentro de la biblioteca estándar Python, y es aquí es donde se producen los errores más graves.

Por lo tanto, se debe tener cuidado para evitar el uso de los mismos nombres que los de los módulos de biblioteca estándar Python. Es mucho más fácil para ti cambiar el nombre de un módulo dentro de tu paquete que presentar una propuesta de mejora de Python (PEP) para solicitar un cambio de nombre upstream y conseguir que lo aprueben.

Error común # 9: El No Poder Hacer Frente a las Diferencias entre Python 2 y Python 3

Considera el siguiente archivo foo.py:

import sys

def bar(i):
    if i == 1:
        raise KeyError(1)
    if i == 2:
        raise ValueError(2)

def bad():
    e = None
    try:
        bar(int(sys.argv[1]))
    except KeyError as e:
        print('key error')
    except ValueError as e:
        print('value error')
    print(e)

bad()

En Python 2, esto funciona muy bien:

$ python foo.py 1
key error
1
$ python foo.py 2
value error
2

Pero ahora vamos a dar un giro en Python 3:

$ python3 foo.py 1
key error
Traceback (most recent call last):
  File "foo.py", line 19, in <module>
    bad()
  File "foo.py", line 17, in bad
    print(e)
UnboundLocalError: local variable 'e' referenced before assignment

¿Qué acaba de ocurrir aquí? El “problema” es que en Python 3 el objeto de excepción no es accesible más allá del alcance del bloque except. (La razón de esto es que, de lo contrario, mantendría un ciclo de referencia con el marco de pila en la memoria hasta que se ejecute el recolector de basura y purgue las referencias de la memoria. Más detalles técnicos sobre esto están disponibles aquí).

Una forma de evitar este problema es mantener una referencia al objeto de excepción fuera del alcance del bloque except, de modo que siga siendo accesible. Aquí hay una versión del ejemplo anterior que utiliza esta técnica, por lo tanto, dosificando el código y haciéndole más compatible con Python 2 y Python 3:

import sys

def bar(i):
    if i == 1:
        raise KeyError(1)
    if i == 2:
        raise ValueError(2)

def good():
    exception = None
    try:
        bar(int(sys.argv[1]))
    except KeyError as e:
        exception = e
        print('key error')
    except ValueError as e:
        exception = e
        print('value error')
    print(exception)

good()

La ejecución de éste es en Py3k:

$ python3 foo.py 1
key error
1
$ python3 foo.py 2
value error
2

¡Yupi!

(Por cierto, nuestra Guía de contratación Python (Python Hiring Guide) analiza una serie de diferencias importantes, que se deben tener en cuenta al migrar el código de Python 2 a Python 3.)

Error común # 10: El Mal Uso del Método __del__

Digamos que tenías esto en un archivo llamado mod.py:

import foo

class Bar(object):
   	    ...
    def __del__(self):
        foo.cleanup(self.myhandle)

Y, luego, trataste de hacer esto desde another_mod.py:

import mod
mybar = mod.Bar()

Obtendrías una fea excepción AttributeError.

¿Por qué? Debido a que, como se informó aquí, al apagarse intérprete, las variables globales del módulo se ajustan a None. Como resultado, en el ejemplo anterior, en el punto que __del__ se invoca, el nombre foo ya se ha ajustado a None.

Una solución a este problema algo más avanzado que la programación Python, sería utilizaratexit.register() en su lugar. De esta manera, cuando el programa se haya ejecutado (al salir normalmente, quiero decir), tus gestores registrados son echados antes de que el intérprete se apague.

Con éste conocimiento, una solución para el anterior código mod.py podría ser algo como esto:

import foo
import atexit

def cleanup(handle):
    foo.cleanup(handle)


class Bar(object):
    def __init__(self):
        ...
        atexit.register(cleanup, self.myhandle)

Esta aplicación ofrece una manera limpia y confiable de llamar a cualquier funcionalidad de limpieza necesaria para después de la terminación normal del programa. Obviamente, le toca a foo.cleanup decidir qué hacer con el objeto unido al nombre self.myhandle, pero se entiende la idea.

Para Terminar

Python es un lenguaje potente y flexible con muchos mecanismos y paradigmas que pueden mejorar considerablemente la productividad. Sin embargo, al igual que con cualquier herramienta de software o lenguaje, el tener una limitada comprensión o apreciación de sus capacidades a veces puede ser más un impedimento que una ventaja, dejándonos en el estado proverbial de “saber lo suficiente como para ser peligroso”.

Familiarizándose con los matices clave de Python, tales como (pero de ninguna manera se limita a) los problemas de programación moderadamente avanzados planteados en este artículo, ayudará a optimizar el uso de la lengua, evitando algunos de sus errores más comunes.

Deberías revisar nuestra Guía a Entrevistas Python (Insider’s Guide to Python Interviewing), para obtener sugerencias sobre preguntas de entrevistas que pueden ayudar a identificar a los expertos en Python.

Esperamos que te sean útiles los consejos en este artículo y apreciamos tus comentarios.

El artículo original lo pueden encontrar en Totpal.

08 Nov 2016
MySQL, PHP, Programación, WEB 0 comment

Codificación de Datos: Una Guía UTF-8 para PHP y MySQL

BY FRANCISCO SANCHEZ CLARIÁ – SOFTWARE ENGINEER @ TOPTAL

#MySQL #PHP #Unicode #UTF8

Como desarrollador PHP o MySQL, una vez que pasas más allá de los confines de los cómodos conjuntos de caracteres sólo en inglés, te encuentras rápidamente enredado en el maravillosamente y extraño mundo de UTF-8.

Una Mirada Rápida UTF-8 Primer

Unicode es un estándar de la industria de computación ampliamente utilizado, que define un mapeo completo de valores únicos de códigos numéricos a los caracteres de la mayoría de los conjuntos de caracteres escritos hoy en día, para ayudar con la interoperabilidad de los sistemas y el intercambio de datos.

UTF-8 es una codificación de amplitud variable (variable-width encoding) que puede representar todos los caracteres en el conjunto de caracteres Unicode. Fue diseñado para mantener la retrocompatibilidad con ASCII y para evitar las complicaciones con Endianness y marcas de orden de bytes en UTF-16 y UTF-32. UTF-8 se ha convertido en la codificación de caracteres dominante para la World Wide Web, lo que representa más de la mitad de todas las páginas Web.

UTF-8 codifica cada carácter utilizando de uno a cuatro bytes. Los primeros 128 caracteres de Unicode corresponden uno a uno con ASCII, haciendo válido el texto ASCII, al igual que el texto con codificación UTF-8. Es por esta razón que los sistemas que están limitados al uso del conjunto de caracteres en inglés, están aislados de las complejidades que de lo contrario pueden surgir con UTF-8.

Por ejemplo, el código hexadecimal Unicode para la letra A es U + 0041, que en UTF -8 simplemente está codificado con el byte único 41. En comparación, el código hexadecimal Unicode para el carácter es U+233B4, que en UTF-8 se codifica con los cuatro bytes F0, A3, B4, 8E.

En un trabajo previo a éste, comenzamos a encontrar problemas de codificación de datos al mostrar biografías de artistas de todo el mundo. Pronto se hizo evidente que había problemas con los datos almacenados ya que a veces los datos se codifican correctamente y otras veces no.

Esto llevó a los programadores a implementar una mezcla de parches, a veces con JavaScript, a veces con etiquetas meta charset HTML, a veces con PHP, y así sucesivamente. Pronto, terminamos con una lista de 600.000 biografías de los artistas, con la información codificada al doble o triple, con datos almacenados en diferentes formas, dependiendo de quién había programado la característica o aplicado el parche. Un clásico nido de ratas técnico.

De hecho, navegar por problemas UTF-8 relacionados con codificación de datos, puede ser una experiencia frustrante. Este post proporciona un “libro de cocina” conciso para abordar estos problemas cuando se trabaja con PHP y MySQL particularmente, basado en la experiencia práctica y las lecciones aprendidas (y con agradecimientos, en parte, a la información descubierta aquí y aquí en el camino).

En concreto, vamos a cubrir lo siguiente en este post:

  • Mods que tendrás que hacer a tu archivo php.ini y código PHP.
  • Mods que tendrás que hacer a tu archivo my.ini y otros problemas relacionados con MySQL que se deben tener en cuenta (incluyendo mods de configuración, necesarias si estás utilizando Sphinx )
  • Cómo migrar datos de una base de datos MySQL previamente codificada en latin1 en lugar de utilizar una codificación UTF-8

PHP y la Codificación UTF-8 – Modificaciones en el Archivo php.ini:

Lo primero que debes hacer es modificar tu archivo ‘php.ini’ para utilizar UTF-8 como el conjunto de caracteres por defecto:

default_charset = "utf-8";

(Nota:Puedes utilizar posteriormente phpinfo()para verificar que éste se haya ajustado correctamente).

Bien, ahora PHP y UTF-8 deberían funcionar bien juntos. ¿Verdad?

Bueno, no exactamente. De hecho, ni están cerca de hacerlo.

Si bien este cambio se asegurará de que PHP siempre de salida a UTF-8 como codificación de caracteres (en los encabezados tipo–contenido de respuesta de navegador), todavía tienes que hacer una serie de modificaciones en tu código PHP, para asegurarte de que procesa y genera caracteres UTF-8 correctamente.

Related: Mejores prácticas PHP y consejos de Desarrolladores Toptal (PHP Best Practices and Tips by Toptal Developers)

PHP y la Codificación UTF-8 – Modificaciones a tu Código:

Para asegurarte de que tu código PHP se maneje bien en el sandbox de codificación de datos UTF-8, aquí están las cosas que debes hacer:

  • Ajusta UTF-8 como el conjunto de caracteres para todas las salidas de los encabezados por tu código PHP.

    En cada encabezado de salida PHP, especifica UTF-8 como la codificación:

    header(‘Content-Type: text/html; charset=utf-8’);

  • Especifica UTF-8 como el tipo de codificación para XML 
      <?xml version="1.0" encoding="UTF-8"?>
  • Elimina caracteres no compatibles de XML

Dado que no todos los caracteres UTF-8 se aceptan en un documento XML, necesitas eliminar cualquier tipo de caracteres de cualquier XML que generes. Una función útil para hacer esto (la cual encontré aquí) es la siguiente:

    function utf8_for_xml($string)
    {
      return preg_replace('/[^\x{0009}\x{000a}\x{000d}\x{0020}-\x{D7FF}\x{E000}-\x{FFFD}]+/u',
                          ' ', $string);
    }

He aquí cómo puedes utilizar esta función en tu código:

    $safeString = utf8_for_xml($yourUnsafeString);
  • Especifica UTF-8 como el conjunto de caracteres para todo el contenido HTML

    Para el contenido HTML, especifica UTF-8 como la codificación:

     <meta http-equiv="Content-Type" content="text/html; charset=utf-8">

    En formularios HTML, especifica UTF-8 como la codificación:

     <form accept-charset="utf-8">
  • Especifica UTF-8 como la codificación de todas las llamadas a htmlspecialchars

    Por ejemplo:

     htmlspecialchars($str, ENT_NOQUOTES, "UTF-8")

Nota:A partir de PHP 5.6.0, el valor default_charset se utiliza por defecto. A partir de PHP 5.4.0, UTF-8 venía por defecto, pero antes de PHP 5.4.0, se usó la norma ISO-8859-1 como predeterminado. Por lo tanto, es una buena idea especificar siempre explícitamente a UTF-8, para estar seguros, a pesar de que éste argumento es técnicamente opcional.

También ten en cuenta que, para UTF-8, htmlspecialchars y htmlentities se pueden utilizar indistintamente.

  • Ajusta UTF-8 como el conjunto de caracteres por defecto para todas las conexiones de MySQL

Especifica UTF-8 como el conjunto de caracteres por defecto para usar al intercambiar datos con la base de datos MySQL, utilizando mysql_set_charset:

$link = mysql_connect('localhost', 'user', 'password');
mysql_set_charset('utf8', $link);

Ten en cuenta que, a partir de PHP 5.5.0, mysql_set_charset está en desuso, y mysqli::set_charset se debe utilizar en su lugar:

  $mysqli = new mysqli("localhost", "my_user", "my_password", "test");

  /* check connection */
    if (mysqli_connect_errno()) {
        printf("Connect failed: %s\n", mysqli_connect_error());
        exit();
    }
    
    /* change character set to utf8 */
    if (!$mysqli->set_charset("utf8")) {
        printf("Error loading character set utf8: %s\n", $mysqli->error);
    } else {
        printf("Current character set: %s\n", $mysqli->character_set_name());
    }
    
    $mysqli->close();
  • Usa siempre versiones compatibles de las funciones de manipulación de cadenas UTF-8

Hay varias funciones de PHP que pueden fallar, o al menos no comportarse como se esperaba si la representación del carácter necesita más de 1 byte (como lo hace UTF-8). Un ejemplo es la función strlen, que devolverá el número de bytes en lugar de la cantidad de caracteres.

Hay dos opciones disponibles para hacer frente a esto:

  • Las funciones iconv que están disponibles por defecto con PHP, proporcionan versiones compatibles de varios bytes de muchas de estas funciones (por ejemplo, iconv_strlen, etc.). Sin embargo, recuerda que las cadenas que suministres a estas funciones deben a su vez ser codificadas correctamente.
  • También existe la extensión mbstring a PHP (información sobre la activación y configuración está disponible aquí). Esta extensión proporciona un conjunto completo de funciones que responden adecuadamente por la codificación multibyte.

MySQL y la Codificación UTF-8 – Modificaciones en el Archivo my.ini:

En el lado de MySQL / UTF-8 de las cosas, modificaciones al archivo my.ini son requeridas de la siguiente manera:

  • Establece los siguientes parámetros de configuración después de cada etiqueta correspondiente: [client] default-character-set=UTF-8 
      [mysql]
  default-character-set=UTF-8
    
  [mysqld]
  character-set-client-handshake = false #force encoding to uft8
  character-set-server=UTF-8
  collation-server=UTF-8_general_ci
    
  [mysqld_safe]
  default-character-set=UTF-8
  • Después de hacer los cambios anteriores en tu archivo my.ini, reinicia el MySQL daemon.
  • Para comprobar que todo ha sido configurado correctamente para utilizar la codificación UTF-8, ejecuta la siguiente consulta: 
      mysql> show variables like 'char%';

El resultado debe ser algo asi:

        | character_set_client        | UTF-8                       
        | character_set_connection    | UTF-8                       
        | character_set_database      | UTF-8                       
        | character_set_filesystem    | binary                    
        | character_set_results       | UTF-8                       
        | character_set_server        | UTF-8                       
        | character_set_system        | UTF-8                       
        | character_sets_dir          | /usr/share/mysql/charsets/

Si por el contrario ves latin1 enumerado para cualquiera de estos, comprueba tu configuración y asegúrate de haber reiniciado correctamente el MySQL Daemon.

MySQL y la Codificación UTF-8 – Otras Cosas a Considerar:

  • MySQL UTF-8 es en realidad una aplicación parcial del conjunto de caracteres UTF-8. En concreto, la codificación de datos MySQL UTF-8, utiliza un máximo de 3 bytes, mientras que se requieren 4 bytes para codificar el conjunto completo de caracteres UTF-8. Esto está bien para todos los caracteres del idioma, pero si necesitas sostener símbolos astrales (cuyos puntos de código oscilan entre U + 010000 a U + 10FFFF), estos requieren una codificación de cuatro bytes que no se puede sostener en MySQL UTF-8. En MySQL 5.5 0.3, esto se discutió con la adición de apoyo al conjunto de caracteres utf8mb4, que utiliza un máximo de cuatro bytes por carácter y por lo tanto sostiene el conjunto completo de caracteres UTF-8. Así que, si estás utilizando MySQL 5.5.3 o posterior, utiliza utf8mb4 en lugar de UTF-8 como conjunto de caracteres de base de datos / tabla / fila. Más información disponible aquí.
  • Si el cliente que se conecta no tiene ninguna forma de especificar la codificación para su comunicación con MySQL, una vez establecida la conexión, puede que tengas que ejecutar el siguiente comando / consulta: 
      set names UTF-8;
  • Al determinar el tamaño de los campos varchar al modelar la base de datos, no te olvides que los caracteres UTF-8 pueden requerir hasta 4 bytes por carácter.

MySQL y la Codificación UTF-8 – Si Utilizas Sphinx:

  • En el archivo de configuración Sphinx (es decir, sphinx.conf):
    • Establece tu definición del índice para tener:

      charset_type = utf-8

    • Agrega lo siguiente a tu definición de fuente:

      sql_query_pre = SET CHARACTER_SET_RESULTS=UTF-8sql_query_pre = SET NAMES UTF-8

  • Reinicia el motor y vuelve a hacer todos los índices.
  • Si deseas configurar la Sphynx de modo que letras como C c Ć ć Ĉ ĉ Ċ ċ Č č sean tratadas como iguales a efectos de búsqueda, tendrás que configurar una charset_table (también conocido como plegado de caracteres) que es esencialmente un mapeo entre los caracteres. Más información está disponible aquí.

MySQL – Migración de Datos de una Base de Datos Que ya Están Codificados en latin1 a UTF-8

Si tienes una base de datos existente ya codificada en latin1, aquí te muestro cómo convertir los latin1 a UTF-8:

  1. Asegúrate que realizaste todas las modificaciones a los ajustes de configuración en tu archivo my.ini, como se describió anteriormente.
  2. Ejecuta el siguiente comando: 
    ALTER SCHEMA `your-db-name` DEFAULT CHARACTER SET UTF-8;
  3. A través de la línea de comandos, comprueba que todo está configurado correctamente para UTF-8 
    mysql> show variables like 'char%';
  4. Crea un archivo de volcado con la codificación latin1 para la tabla que deseas convertir: 
    mysqldump -u USERNAME -pDB_PASSWORD --opt --skip-set-charset --default-character-set=latin1
          --skip-extended-insert DATABASENAME --tables TABLENAME >
          DUMP_FILE_TABLE.sql

    Ejemplo:

    mysqldump -u root --opt --skip-set-charset  --default-character-set=latin1
          --skip-extended-insert artists-database --tables tbl_artist >
          tbl_artist.sql
  5. Haz una búsqueda y reemplazo global del conjunto de caracteres en el fichero de volcado de latin1 a UTF-8:

    Por ejemplo, usando Perl:

    perl -i -pe 's/DEFAULT CHARSET=latin1/DEFAULT CHARSET=UTF-8/' DUMP_FILE_TABLE.sql

Nota para los usuarios de Windows:Esta cadena de reemplazo del conjunto de caracteres (de latin1 a UTF-8) también se puede hacer usando buscar y reemplazar en WordPad (o algún otro editor de texto, como vim). Asegúrate de guardar el archivo tal como es (no como archivo de texto Unicode!).

  1. A partir de este punto, vamos a empezar a jugar con los datos de base de datos, por lo que probablemente sería prudente hacer una copia de seguridad de la base de datos, si no lo has hecho todavía. A continuación, restaura el volcado dentro de la base de datos: 
    mysql> source "DUMP_FILE_TABLE.sql";
  2. Busca cualquier registro que no se haya convertido correctamente y corrígelo. Dado que los caracteres que no son ASCII, son múlti-bytes por diseño, los podemos encontrar mediante la comparación de la longitud de bytes con la longitud de caracteres (es decir, para identificar las filas que pueden contener caracteres UTF-8 de doble-codificado que deben ser corregidos).
    • Ve si hay algún registro con caracteres de varios bytes (si ésta consulta devuelve cero, entonces no debe haber ningún registro con caracteres de varios bytes en la tabla y se puede proceder al Paso 8). 
       mysql> select count(*) from MY_TABLE where LENGTH(MY_FIELD) != CHAR_LENGTH(MY_FIELD);
    • Copia filas con caracteres de varios bytes en una tabla temporal: 
       create table temptable (
     select * from MY_TABLE where
     LENGTH(MY_FIELD) != CHAR_LENGTH(MY_FIELD));
    • Convierte caracteres UTF-8 de doble-codificado a caracteres UTF-8 adecuados.

    Esto es en realidad un poco complicado. Una cadena de doble-codificación es aquella que ha sido codificada adecuadamente como UTF-8. Sin embargo, MySQL luego nos hizo el favor erróneo de convertirla (de lo que pensó era latin1) a UTF-8 de nuevo, cuando fijamos la columna a codificación UTF-8. La resolución de éste, por lo tanto, requiere de un proceso de dos pasos a través del cual “engañamos” a MySQL con el fin de evitar que nos haga este “favor”.

En primer lugar, fijamos de nuevo el tipo de codificación para la columna a latin1, eliminando de este modo la doble codificación:

Ejemplo:

		alter table temptable modify temptable.ArtistName varchar(128) character set latin1;

Nota:Asegúrate de utilizar el tipo de campo correcto para tu tabla. En el ejemplo anterior, para nuestra tabla, el tipo de campo correcto para ArtistName era varchar (128), pero el campo de la tabla podría ser texto o cualquier otro tipo. Asegúrate de especificarlo correctamente.

El problema es que ahora, si fijamos la codificación de la columna de nuevo a UTF-8, MySQL ejecutará el latin1 a la codificación de datos UTF-8 de nuevo, y volveremos al punto de partida. Para evitar esto, se cambia el tipo de columna a blob y luego se fija a UTF-8. Esto explota el hecho de que MySQL no intentará codificar un blob. Y así, podemos “engañar” a la conversión del conjunto de caracteres de MySQL, para evitar el problema de doble codificación.

Ejemplo:

		alter table temptable modify temptable.ArtistName blob;
		alter table temptable modify temptable.ArtistName varchar(128) character set UTF-8;

(Una vez más, como se señaló anteriormente, asegúrate de usar el tipo de campo adecuado para tu tabla.)

  • Elimina filas con sólo caracteres de un solo byte pertenecientes a la tabla temporal: 
          delete from MY_TABLE where LENGTH(MY_FIELD) = CHAR_LENGTH(MY_FIELD);
  • Vuelve a insertar las filas fijas en la tabla original (antes de hacer esto, deberías ejecutar algunas selects en la tabla temporal para verificar que ha sido corregida de forma adecuada, solo por precaución). 
          replace into MY_TABLE (select * from temptable);
  1. Verifica los datos restantes y, si es necesario, repite el proceso del paso 7 (esto podría ser necesario, por ejemplo, si los datos fueron codificados al triple). Más errores, si se encuentran, pueden ser más fáciles de resolver de forma manual.

Código Fuente y Archivos de Recursos

Otra cosa a recordar y comprobar es que los archivos de código fuente, archivos de recursos y así sucesivamente, sean guardados correctamente con codificación de datos UTF-8. De lo contrario, todos los caracteres “especiales” en estos archivos tal vez no sean manejados correctamente.

En Netbeans, por ejemplo, puedes hacer clic derecho sobre tu proyecto, selecciona propiedades y luego en “Fuentes”, encontrarás la opción de codificación de datos (por lo general por defecto es UTF-8, pero es mejor comprobar).

O en Windows Notepad, utiliza la opción “Guardar como…” en el menú de Archivos y selecciona la opción de codificación UTF-8 en la parte inferior del cuadro de diálogo. (Ten en cuenta que la opción “Unicode” que ofrece Notepad es en realidad UTF-16, y eso no es lo quieres.)

Para Terminar

Aunque puede ser algo tedioso, tomarse el tiempo para revisar estos pasos para abordar sistemáticamente tus problemas de codificación de datos MySQL y PHP UTF-8 puede ahorrarte una gran cantidad de tiempo. A la larga, este tipo de enfoque metódico es muy superior a la común tendencia de remendar el sistema.

Espero que ésta guía destaque la importancia de tomar en consideración la definición del conjunto de datos al configurar un entorno de proyecto inicialmente y el trabajar en un entorno de proyecto de software que tiene en cuenta la codificación de caracteres en su manipulación de texto y cadenas.

El artículo original lo pueden encontrar en Totpal.

31 Oct 2016
Programación, Tecnología, TopTal 0 comment

Guía para Desarrolladores iOS: Desde Objective-C hasta Swift

BY MARCO MUSTAPIC – IOS DEVELOPER @ TOPTAL

#Apple #iOS #ObjectiveC #Swift #XCode

En el año 2008 Apple anunció y lanzó el iPhone SDK 2.0. Éste evento inició otra revolución dentro del desarrollo de software y así nació una nueva generación de desarrolladores, quienes ahora son reconocidos como desarrolladores iOS.

Muchos de estos desarrolladores nunca antes habían utilizado Objective-C y ese fue el primer reto que Apple tenía para ellos. A pesar de una sintaxis desconocida y un manejo de memoria manual, éste fue inmensamente exitoso, ayudando a poblar la App Store con decenas de miles de aplicaciones. Apple continuamente mejoraba Objective-C con cada nueva versión, añadiendo bloques y literales (literals), agregando manejo de memoria simplificado con recuento de referencias automático y muchas otras características que indican un lenguaje de programación moderno.

Y después de seis años trabajando y mejorando Objective-C, Apple decidió retar nuevamente a los desarrolladores. Una vez más, los desarrolladores iOS tendrán que aprender un nuevo lenguaje de programación: Swift. Swift elimina la gestión insegura de punter e introduce nuevas e impotentes características, mientras mantiene la interacción con ambos Objective-C y C.

Swift 1.0 es una plataforma de desarrollo estable y fuerte, la cual es seguro que evolucionará de manera interesante en los próximos años. Es el momento perfecto para comenzar a explorar este nuevo lenguaje ya que es, obviamente, el futuro del desarrollo iOS.

El propósito de éste tutorial es dar a los desarrolladores de Objective-C una descripción rápida de las nuevas características del lenguaje Swift, ayudándote a dar el próximo paso y comenzar a adoptar Swift a tu trabajo de todos los días. No voy a pasar mucho tiempo explicando Objective-C, voy a asumir que estás familiarizado con el desarrollo iOS.

Swift changed the game for Objective-C iOS developers.

Probando Swift vs. Objective-C

Para comenzar a explorar Swift lo que necesitas es descargar XCode 6 de la App Store y crear una zona de juegos para experimentar. Todos los ejemplos que se mencionan en éste artículo fueron hechos de ésta manera.

Página web de Apple Swift es la major referencia para aprender sobre programación Swift. Verás que es muy valiosa, y hasta que estés completamente al día con el desarrollo Swift Creo que regresarás aquí a menudo.

Variables y Constantes

Para declarar una variable en Swift se usa la palabra clave var.

var x = 1
var s = "Hello"

Notarás que las dos variables s y x son de diferentes tipos. x es un Número Entero, mientras que “s” es una Cadena de Caracteres. Swift es un tipo de lenguaje seguro y deducirá los tipos de variables del valor asignado. Si deseas que tu código sea más legible, puedes anotar opcionalmente el tipo de variable:

var y: Int
y = 2

Las constantes son similares pero se declaran usando let en lugar de var. No es necesario saber el valor de una constante al momento de la compilación pero debes asignarle un valor exactamente una vez.

let c1 = 1 // Constante conocida al momento de la compilación
 
var v = arc4random()
let c2 = v // Constante conocida solo en momento de ejecución

Como su nombre lo indica, son inmutables, por esto el siguiente código causará un error al momento de compilación.

let c = 1
c = 3        // error

Otros tipos también pueden ser declarados como constantes. Por ejemplo, el siguiente código declara una matriz como una constante y, si intentas modificar cualquiera de los elementos, el compilador Swift reportará un error:

var arr2 = [4, 5, 6]
arr2[0] = 8
print (arr2)    // [8, 5, 6]
   
let arr = [1, 2, 3]
a[0] = 5    // error

Opcionales

Es necesario inicializar las constantes cuando se están declarando, al igual que es necesario inicializar las variables antes de usarlas. Así que, ¿dónde está el equivalente nil de Objective-C? Swift introduce valores opcionales. Los valores opcionales pueden tener un valor o ser nil. Si observas el siguiente código, vas a notar que x fue asignada como valor Opcional de 2014. Esto significa que el compilador Swift sabía que xpodría ser nil.

var s = "2014"
var x = s.toInt()
print(x)    // Optional(2014)

Si haces un cambio en éste código y asignas el valor "abc" a s, el cual no se puede convertir a un número entero, vas a notar que x es ahora un nil.

var s = "abc"
var x = s.toInt()
print(x)    // nil

¿El tipo de retorno de la función toInt() es Int?, el cual es un Int opcional. Vamos a tratar de llamar a una función estándar en x:

var x = "2014".toInt()
print(x.successor()) // error

El compilador señala un error, ya que x es un opcional y podría ser potencialmente nil. Debemos probar xprimero, y asegurarnos de que la función sucessor sea invocada en un número real, y no en un valor nil:

var x = "2014".toInt()
if x != nil
{
print(x!.successor())    // 2015
}

Ten en cuenta que debemos desenvolverxañadiendo un signo de exclamación (!). Cuando nos aseguramos que x contiene un valor, podemos acceder a él. De lo contrario, obtendremos un error de ejecución. También podemos hacer lo que Swift llama optional binding, convirtiendo así lo opcional a una variable no-opcional

let x = "123".toInt()
if let y = x
{
print(y)
}

El código de la instrucción if solo se ejecutará si x tiene un valor, y es asignada a y. Ten en cuenta que no necesitamos desenvolver y, su tipo no opcional, ya que sabemos que x no es nil.

Revisa el tutorial Swift de Apple donde podrás leer en detalle sobre opcionales e interesantes características como optional chaining

Interpolación de Cadenas

En Objective-C, una cadena de formateo usualmente se hace con el método stringWithFormat::

NSString *user = @"Gabriel";
int days = 3;
NSString *s = [NSString stringWithFormat:@"posted by %@ (%d days ago)", user, days];

Swift tiene una característica llamada interpolación de Cadenas que hace lo mismo, pero es más compacta y fácil de leer:

let user = "Gabriel"
let days = 3
let s = "posted by \(user) \(days) ago"

También puedes usar expresiones:

let width = 2
let height = 3
let s = "Area for square with sides \(width) and \(height) is \(width*height)"

Para aprender más sobre la interpolación de cadenas de Swift, ingresa aquí.

Funciones

La definición de Función en Swift es diferente a la de C. Una muestra de definición de función es la siguiente:

func someFunction(s:String, i: Int) -> Bool
{
...    // code    
}

Las funciones Swift son tipos de primera clase. Esto quiere decir que puedes asignar funciones a las variables, hacerlas pasar como parámetros para las funciones o hacerlas regresar tipos:

func stringLength(s:String) -> Int
{
    return countElements(s)
}

func stringValue(s:String) -> Int
{
    if let x = s.toInt()
    {
        return x
    }
    return 0
}

func doSomething(f:String -> Int, s:String) -> Int
{
    return f(s).successor()
}

let f1 = stringLength
let f2 = stringValue

doSomething(f1, "123")    // 4
doSomething(f2, "123")    // 124

De nuevo, Swift infiere los tipos de f1 and f2 (String -> Int), Aunque los pudimos haber definido explícitamente:

let f1:String -> Int = stringLength

Las funciones también pueden regresar otras funciones:

func compareGreaterThan(a: Int, b: Int) -> Bool
{
    return a > b
}

func compareLessThan(a: Int, b: Int) -> Bool
{
    return a < b
}

func comparator(greaterThan:Bool) -> (Int, Int) -> Bool
{
    if greaterThan
    {
        return compareGreaterThan
    }
    else
    {
        return compareLessThan
    }
}

let f = comparator(true)
println(f(5, 9))

Una guía para las funciones en Swift se encuentra aquí.

Enumeraciones

Las enumeraciones en Swift son mucho más ponderosas que en Objective-C. Como lo estructura Swift, pueden tener métodos y se pasan como valores:

enum MobileDevice : String
{
    case iPhone = "iPhone", Android = "Android", WP8 = "Windows Phone8", BB = "BlackBerry"

    func name() -> String
    {
        return self.toRaw()
    }
}
let m = MobileDevice.Android
print(m.name())    // "Android"

A diferencia de Objective-C, las enumeraciones Swift pueden asignar cadenas, caracteres o flotantes como valores para cada miembro, aparte de números enteros. El método conveniente toRaw() regresa el valor asignado a cada miembro.

Las enumeraciones también se pueden parametrizar:

enum Location
{
    case Address(street:String, city:String)
    case LatLon(lat:Float, lon:Float)
    
    func description() -> String
    {
        switch self
        {
        case let .Address(street, city):
            return street + ", " + city
        case let .LatLon(lat, lon):
            return "(\(lat), \(lon))"
        }
    }
}

let loc1 = Location.Address(street: "2070 Fell St", city: "San Francisco")
let loc2 = Location.LatLon(lat: 23.117, lon: 45.899)
print(loc1.description())        // "2070 Fell St, San Francisco"
print(loc2.description())        // "(23.117, 45.988)"

Puedes encontrar más información sobre las enumeraciones aquí.

Tuplas

Las tuplas agrupan valores múltiples en un único valor compuesto. Los valores dentro de una tupla pueden ser de cualquier tipo y no tiene que ser del mismo tipo entre ellos.

let person = ("Gabriel", "Kirkpatrick")
print(person.0) // Gabriel

También puedes darle nombre a los elementos de tuplas individuales:

let person = (first: "Gabriel", last: "Kirkpatrick")
print(person.first)

Las tuplas son extremadamente convenientes como tipos de regreso para funciones que necesitan regresar más de un valor:

func intDivision(a: Int, b: Int) -> (quotient: Int, remainder: Int)
{
    return (a/b, a%b)
}
print(intDivision(11, 3))    // (3, 2)
let result = intDivision(15, 4)
print(result.remainder)    // 3

A diferencia de Objective-C, Swift apoya la búsqueda de patrones en case statement o switch case:

let complex = (2.0, 1.1)    // real and imaginary parts

switch complex
{
    case (0, 0):
        println("Number is zero")
    case (_, 0):
        println("Number is real")
    default:
        println("Number is imaginary")
}

En el segundo caso, no nos importa la verdadera parte del número así que usamos un _ para que pueda coincidir con cualquier cosa. También puedes comprobar si hay condiciones adicionales en cada caso. Para esto, es necesario unir los valores de patrón:

let complex = (2.0, 1.1)

switch complex
{
    case (0, 0):
        println("Number is zero")
    case (let a, 0) where a > 0:
        println("Number is real and positive")
    case (let a, 0) where a < 0:
        println("Number is real and negative")
    case (0, let b) where b != 0:
        println("Number has only imaginary part")
    case let (a, b):
        println("Number is imaginary with distance \(a*a + b*b)")
}

Nota como necesitamos unir solo los valores que vamos a usar en la comparación o en el switch case.

Puedes leer más sobre Tuplas aquí.

Clases y Estructuras

A diferencia de Objective-C, Swift no requiere que crees documentos de interfaz e implementación por separado para clases y estructuras personalizadas. Mientras aprendes sobre Swift, aprenderás a definir una clase o estructura en un solo documento y la interfaz externa para esa clase o estructura se hace disponible automáticamente para el uso de otro código.

Definir Clases

Las definiciones de clase son my sencillas:

class Bottle
{
   var volume: Int = 1000
   
   func description() -> String
   {
       return "This bottle has \(volume) ml"
   }
}
let b = Bottle()
print(b.description())

Como puedes ver, declaración e implementación están en el mismo documento. Swift ya no utiliza un encabezado ni documentos de implementación. Agreguemos una etiqueta a nuestro ejemplo:

class Bottle
{
   var volume: Int = 1000
   var label:String
   
   func description() -> String
   {
       return "This bottle of \(label) has \(volume) ml"
   }
}

El compilador se quejará, ya que la etiqueta es una variable no-opcional, y ésta no mantendrá un valor cuando se ejemplifica una Bottle (Botella). Necesitamos agregar un inicializador:

class Bottle
{
   var volume: Int = 1000
   var label:String
   
   init(label:String)
   {
       self.label = label
   }

   func description() -> String
   {
       return "This bottle of \(label) has \(volume) ml"
   }
}

O podríamos usar tipo Opcional para una propiedad, el cual no necesita ser inicializado. En el siguiente ejemplo convertimos en volumen un Número entero Opcional:

class Bottle
{
   var volume: Int?
   var label:String
   
   init(label:String)
   {
       self.label = label
   }

   func description() -> String
   {
        if self.volume != nil
        {   
               return "This bottle of \(label) has \(volume!) ml"
           }
           else
           {
               return "A bootle of \(label)"
           }
   }
}

Estructuras

El lenguaje Swift también tiene structs, pero son mucho más flexibles que en Objective-C. El siguiente tutorial de código define un struct:

struct Seat
{
    var row: Int
    var letter:String
    
    init (row: Int, letter:String)
    {
        self.row = row
        self.letter = letter
    }
    
    func description() -> String
    {
        return "\(row)-\(letter)"
    }
}

Como las clases en Swift, las estructuras pueden tener métodos, propiedades, inicializadores y se ajustan a los protocolos. La diferencia principal entre clases y estructuras es que las clases se pasan por referencia, mientras que las estructuras lo hacen por valor.

Este ejemplo demuestra el pasar las clases por referencia:

let b = Bottle()
print(b.description())    // "b" bottle has 1000 ml

var b2 = b
b.volume = 750
print(b2.description())    // "b" and "b2" bottles have 750 ml

Si intentamos hacer algo similar con struct, notarás que las variables se pasan con valores:

var s1 = Seat(row: 14, letter:"A")
var s2 = s1
s1.letter = "B"
print(s1.description())    // 14-B
print(s2.description())    // 14-A

¿Cuándo debemos usar struct y cuándo usamos class? Al igual que en Objective-C y C, usa structs cuando necesites agrupar algunos valores y espera que sean copiados en vez de referenciados o colores RGB.

La instancia de una clase es conocida tradicionalmente como un objeto. Sin embargo, las clases y estructuras Swift son mucho más cercanas en funcionalidad que en otros lenguajes y se puede aplicar mucha funcionalidad a instancias de tipo estructura o clase. Por esto, el término más general utilizado en referencia Swift es instancia, el cual se aplica a cualquiera de estos dos.

Aprende lo básico sobre las clases y estructuras Swift aquí.

Propiedades

Como vimos anteriormente, las propiedades en Swift se declaran con la palabra clave var dentro de la definición de una clase o estructura. También podemos declarar con la instrucción let.

struct FixedPointNumber
{
    var digits: Int
    let decimals: Int
}

var n = FixedPointNumber(digits: 12345, decimals: 2)
n.digits = 4567    // ok
n.decimals = 3     // error, decimals is a constant

También ten en cuenta que las propiedades de la clase son fuertemente referenciadas, a menos que uses el prefijo weak como palabra clave. Sin embargo, hay algunas sutilezas con propiedades no-opcionales de weak, así que lee el capítulo Contabilidad de referencia automática en la Guía Swift de Apple..

Propiedades Calculadas

Las propiedades calculadas no almacenan un valor. Por el contrario, proporcionan un getter y un setter opcional para recuperar y establecer otras propiedades y valores indirectamente.

El siguiente código proporciona un ejemplo de un valor calculado sign:

enum Sign
{
    case Positive
    case Negative
}

struct SomeNumber
{
    var number:Int
    var sign:Sign
    {
        get
        {
            if number < 0
            {
                return Sign.Negative
            }
            else
            {
                return Sign.Positive
            }
        }
        
        set (newSign)
        {
            if (newSign == Sign.Negative)
            {
                self.number = -abs(self.number)
            }
            else
            {
                self.number = abs(self.number)
            }
        }
    }
}

También podemos definir propiedades de solo lectura con solo implementar un getter:

struct SomeNumber
{
    var number:Int
    var isEven:Bool
    {
        get
        {
            return number % 2 == 0
        }
    }
}

En Objective-C, las propiedades usualmente se respaldan con una variable de instancia, declarada explícitamente o creada automáticamente por el compilador. Por otra parte, en Swift, una propiedad no tiene una variable de instancia correspondiente. Es decir, no se puede acceder directamente al almacén de respaldo de una propiedad. Supón que tenemos esto en Objective-C:

// .h
@interface OnlyInitialString : NSObject

@property(strong) NSString *string;

@end

// .m

@implementation OnlyInitialString

- (void)setString:(NSString *newString)
{
    if (newString.length > 0)
    {
        _string = [newString substringToIndex:1];
    }
    else
    {
        _string = @"";
    }
}

@end

Ya que en Swift las propiedades calculadas no tienen un almacén de respaldo, necesitamos algo como esto:

class OnlyInitialString
{
    var initial:String = ""
    var string:String
    {
        set (newString)
        {
            if countElements(newString) > 0
            {
                self.initial = newString.substringToIndex(advance(newString.startIndex, 1))
            }
            else
            {
                self.initial = ""
            }
        }
        get
        {
            return self.initial
        }
    }
}

Las propiedades se explican con más detalle aquí

 

Continuará

Hay muchas cosas más importantes y nuevas que aprender en Swift como programación genérica, interacción con las bibliotecas Objective-C, cierres, optional chaining y sobrecarga de operadores. Un solo tutorial no puede describir completamente un nuevo lenguaje, pero no tengo dudas de que se escribirá mucho más sobre programación Swift. Sin embargo, creo que esta lectura rápida ayudará a muchos desarrolladores Objective-C, quienes no han encontrado el tiempo, ni detalles de aprendizaje sobre el lenguaje Swift, ponte en marcha y deja que el pájaro Swift te lleve a nuevas alturas.

 

El artículo original lo pueden encontrar en Totpal.