Categoría: Sin categoría

27 Ago 2020

Contra la Corriente: Concurso que busca premiar a creadores emergentes bajo pandemia

Este Concurso Nacional de Música y Literatura, busca fomentar y apoyar artistas chilenos bajo pandemia. El jurado a cargo de la selección de canciones estará integrado por figuras destacadas como Claudio Narea y la cantautora Paz Court, mientras que Mauricio Redolés participará en la selección de cuentos.

La crisis del COVID-19 ha dañado a los más diversos sectores de la sociedad siendo el mundo artístico uno de los más perjudicados y, probablemente, uno de los últimos que volverá a reactivarse. Por eso un grupo de emprendedores reunidos en la firma tecnológica 33° SUR han lanzado un concurso de incentivo para creadores, músicos y escritores, que están generando contenido propio y nuevo «contra la corriente» a pesar de la adversidad.

En 33° Sur -empresa de tecnología e innovación, especializada en la creación y adaptación de sistemas de retail-, somos artesanos de procesos tecnológicos y creativos. En este contexto, hoy queremos fomentar de manera decidida las artes y la cultura chilena actual, brindando espacio y oportunidades a todos aquellos creadores de música y literatura popular.

Este Concurso Nacional de Música y Literatura: “Contra La Corriente”, busca fomentar de manera decidida las artes y la cultura chilena actual, brindando espacio y oportunidades a todos aquellos que deseen presentar sus obras a este concurso.

Como parte de los requisitos, los participantes deben ser agrupaciones o solistas en el ámbito musical, o escritores individuales en la categoría literatura. Podrán participar todas las personas mayores de 18 años (cumplidos al 19 de julio de 2020) y residentes en Chile, enviando sólo una única postulación.

 

Plazos y premios

Quienes quieran participar deben registrarse y completar el formulario en el sitio web https://contralacorriente.33sur.cl, y responder de manera escrita a la pregunta ¿Cómo cambias el mundo? El plazo de postulación es hasta este 31 de agosto a las 23:00 horas, Chile Continental.

Para la selección de canciones el jurado estará integrado por destacados nombres de la escena nacional como los guitarristas Claudio Narea y Andrés Godoy, las cantautoras Paz Court y Natisú y el músico Jaime Medel. Y en la categoría literaria los jurados son el cantautor y poeta Mauricio Redolés, la periodista Claudia Farah, la escritora Gabriela Aguilera V, la historiadora Gisela Sanhueza y el escritor Faiz Mashini.

En cada categoría el primer lugar recibirá $1.500.000 (un millón y medio de pesos chilenos) y $1.000.000 (pesos chilenos) para el segundo ganador, tanto para selección de canciones y cuento. Además, habrá un premio de $1.000.000 (pesos chilenos) por votación de público para ambas categorías.

Las bases están disponibles a través del enlace https://contralacorriente.33sur.cl/bases/ y el plazo para recepción de los cuentos y canciones es el próximo lunes 31 de agosto a las 23:00 horas de Chile. Invitamos a todos los amantes de la literatura y la música a participar y enviarnos sus relatos -en formato de texto o música-, explicándonos porqué quieren cambiar el mundo.

 

20 Dic 2016

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.

06 Dic 2016

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

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.

 

29 Jun 2016

La H-1B: El viaje de un desarrollador iOS desde Honduras hasta Silicon Valley

Por estos días, vivo en la gran ciudad de San Francisco. Obtuve un trabajo que amo, y uno con el cual soñé con tener durante mucho tiempo. Parece fácil ahora, pero no siempre fue así.

Cómo empezó todo

Nací en San Pedro Sula, un pequeño pueblo en la esquina noroeste de Honduras. Comencé a programar cuando tenía 12 años. Todo empezó con BASIC. Un día, estaba jugando un vídeo juego y se colgó. Cuando ví la pantalla llena de códigos de error y mensajes, me picó la curiosidad—entonces comencé a aprender algunos comandos BASIC, que eventualmente me llevaron a comprar libros de programación sobre Clipper, Turbo Pascal, C, C++, etc. Fue genial. Tenía todo el tiempo del mundo para gastar programando cualquier cosa que quisiera: sin limites de tiempo (aparte de la escuela, que no era tan demandante como un trabajo de tiempo completo) o responsabilidades de adulto.

file

Muchos años más tarde, a la edad de 15 años, mi padre estaba teniendo problemas con una aplicación defectuosa de contabilidad. Le dije que podía crear una versión mejor—sin realmente entender en dónde me estaba metiendo (nunca había abierto una base de datos SQL). Entonces compré algunos libros más y me puse a trabajar. (Nota: Esto sucedía en la época en donde Internet no era algo predominante como lo es hoy: estaba viviendo en un país del tercer mundo, e Internet llegó a finales de 1997, 5 años después de haber comenzado a programar).

Sueños y ambiciones

Recuerdo que me dije a mí mismo: “Quiero ser un ingeniero informático”. Por supuesto, no tenía idea exactamente qué es lo que eso abarcaba, pero sabía que me gustaban las computadoras (estoy hablando de esos viejos y cuadrados monitores de fósforo verde, PCs lentas con DOS—horribles, por supuesto, ahora que tenemos de esos brillantes nuevos sistemas operativos).

Entonces, siendo un ingenuo de veinte y tantos, decidí que quería emigrar hacia los EEUU—pero por supuesto, eso es un camino largo e inestable.

Recuerdo muy claramente que en mi segundo o tercer viaje a los EEUU (solíamos ir de vacaciones), decidí que quería vivir ahí. Todo era tan avanzado! Por supuesto que hoy, con la globalización e Internet, las diferencias no son tan vastas, pero brechas en el crecimiento y en el progreso pueden seguir viéndose en el desarrollo de infraestructura, la inestabilidad política, el índice de delincuencia, etc.

file

Entonces, siendo un ingenuo de veinte y tantos, decidí que quería emigrar hacia los EEUU—pero por supuesto, eso es un camino largo e inestable.

Por esos tiempos, mi padre tenía una empresa de contabilidad, y habían empezado a tener problemas con su aplicación contable. El desarrollador era obstinado y sin deseos de ayudar, entonces mi padre empezó a buscar alternativas. El quería que me ponga al día como programador, fue a la universidad local—el único lugar donde vendían libros avanzados de programación—y se abarrotó de recursos. Fue un mundo nuevo para mí: tenía una de esas nuevas (en esa época) PCs de monitor de fósforo verde con un procesador de 5 MHz, 256kb de memoria RAM y un disco rígido de 10mb de capacidad. Usaba de esos viejos discos mecánicos, por lo que podías oír todo lo que estaba procesando. El teclado era también mecánico y el sonido al teclear era placentero. 10 años más tarde todavía seguía trabajando en la misma aplicación contable; ahora, sin embargo, lo vendía a clientes, con una interfaz en Windows, una base de datos SQL y conectividad vía Internet.

Yendo a la quiebra

Por esos tiempos, decidí dejar la universidad y empezar mi propia compañía. Había estado trabajando con mi padre, de alguna manera: dividíamos las ganancias de la aplicación contable (a pesar de que era mi idea y ejecución, el invirtió mucho tiempo enseñándome contabilidad). Así que tomamos caminos separados: él seguía vendiendo la versión actual de la aplicación y yo me embarqué a crear una nueva. Pero como descubriría pronto, el negocio de desarrollo de software en Honduras no es ningún paseo en el parque: los clientes no quieren pagar por tus servicios, y ellos ven siempre el desarrollo de software como una tarea relativamente fácil dado que no requiere trabajar con un producto tangible; a menudo, no perciben el valor en el software al no crear ganancias inmediatas, haciéndolo más difícil de vender.

Del lado del negocio, había contratado a algunos de los mejores estudiantes de la carrera (a quienes encontré cuando volví a la universidad). Pero con el tiempo, comencé a usar demasiados títulos: CEO, contador, Representante de RRHH, Servicio y Soporte al cliente, Jefe de proyecto, y (mi favorito) Desarrollador. Yo sólo quería programar, pero se volvió demasiado difícil mientras mantenía todos esos roles. Eventualmente, nos encontramos con problemas, como que nuestros clientes no estaban pagando a tiempo y luchábamos para encontrar nuevos proyectos: cuando tienes a los mejores talentos alrededor, estos quieren ser bien pagados, y estábamos pagando bien; pero los clientes no estaban respondiendo como esperábamos. Además, el vivir en un país del tercer mundo había desalentado cualquier tipo de interés de inversión. Tendría que haber ido con un modelo de negocio distinto, pero estaba demasiado ocupado haciendo malabares con todos mis títulos. Al final, la compañía quebró, y a mi me quedó una tonelada de deudas, empleados enojados y un gusto amargo en la boca. Tenía que empezar de nuevo desde el principio.

El SDK de iPhone

file

150mil descargas de aplicaciones pagas después, demostré que tenía razón.

Lo que más importa es cómo nos levantamos de vuelta cuando enfrentamos la derrota, y cómo aprendemos de nuestros errores. Empezar de nuevo y re-pensar todo es desalentador, pero eso es lo que tenía que hacer. Mi esposa me ayudó durante esos momentos difíciles y me empujó a hacer cosas que no pensé que podría ser capaz. Así que empecé a trabajar en mi aplicación contable de nuevo, pero sin ningún dinero para marketing era muy difícil de promover. Los ingresos eran escasos, y necesitaba mantener a mi familia. Tuve que cambiar de marcha. Alrededor de la misma época, Apple introdujo el SDK de iPhone. Sonaba como una plataforma arriesgada para mí; además, era nuevo con el Mac en sí. (mi transición al Mac empezó con el iPhone y unHackintosh, que me dejó probar el sabor de OS X sin desembolsar dinero en una máquina costosa). Algunos de mis amigos se reían y me ignoraban por completo cuando decía que iba a desarrollar para el iPhone; pero realmente creía que había dinero de por medio en la App Store. 150mil descargas de aplicaciones pagas después, demostré que tenía razón; aunque, por supuesto, esos números solos no cuentan la historia completa:la economía de la App Store es compleja, realmente necesitas invertir en tu producto y encontrar clientes para crear valor a largo plazo. Y para eso, necesitas un equipo. Así que aunque le estuviera yendo bien a mi aplicación, no era sostenible (desde el punto de vista del negocio) para seguir desarrollándola por mi cuenta. A pesar de todo, había demostrado lo que podía hacer—entonces, un día, me levanté y me dije a mi mismo que finalmente emigraría a los EEUU.

Como pude descubrir, emigrar a los EEUU no era una tarea fácil. Probablemente la ruta más simple era conseguir una Green Card por medio de un miembro de la familia, pero mi opción más cercana era mi hermano, que había nacido en los EEUU; sin embargo, el vivía con nosotros en Honduras y no podía pedir por nadie ya que no estaba trabajando en ese momento. Y aunque pudiera, el proceso podría llegar a tomar 15 años (Nota:los hermanos tienen menor preferencia en lo que respecta a miembros familiares para el patrocinio de la Green Card). Mi solución era crear una compañía estadounidense. Conseguí que un amigo invirtiera y empezamos a crear juegos para iPhone y iPad. En los papeles, todo parecía genial; pero, por supuesto, la economía de la App Store nos demostró lo contrario. Pronto, estábamos necesitando más dinero; mi amigo no había anticipado eso. Al final, publicamos una aplicación (había otra en desarrollo, pero nunca fue finalizada debido a problemas de financiación). De vuelta, las cosas parecían poco prometedoras. Decidí perseguir lo que creí que era mi último recurso: trabajar para una compañía de EEUU.

Consiguiendo un empleo

Es duro ser contratado por una compañía de EEUU desde el extranjero. Me postulé para varias posiciones, pero el primer problema era que requerían relocación: ellos tendrían que solicitar y patrocinar una visa de trabajo. El proceso era caro en términos de tiempo (hasta un año, si no hay visa disponible en ese momento) y dinero (por ej., honorarios de abogados). Así que, en vez de eso, comencé buscando trabajo por medio de un sitio de trabajo independiente online. En teoría, es un buen servicio. Pero, al principio, debes empezar por construir confianza—lo cual es duro. Hay también hordas de desarrolladores que cobran menos que el promedio sólo para llamar la atención; por esto, es difícil ser bien pagado. Terminé haciendo un sólo proyecto por medio del sitio, que valía 8 horas de trabajo.

Más tarde, fui contactado por Toptal con lo que parecía una muy buena oportunidad: ellos contratan grandes programadores y los conectan con los clientes. Además, puedo trabajar desde casa, y para una empresa de EEUU. Aparecí en sus radares por medio de mi trabajo en la App Store, pero todavía tenía que pasar un estricto proceso de selección, haciendo de todo, desde comprensión de textos hasta trivia de programación, desde algoritmos de optimización hasta sesiones de programación cronometradas. Lo más memorable fue la entrevista final, que incluía discutir uno de mis proyectos y guiando a un ingeniero de Toptal por algunas partes de mi código para demostrar que era realmente mío.

Luego de que Toptal me aceptara dentro de su red de desarrolladores, fui puesto en una lista de espera. Una vez que el cliente muestra interés en un desarrollador en particular, este entrevistará a ese candidato (cómo en una entrevista de trabajo normal) para asegurarse que es el adecuado. Antes de mi primer entrevista, estaba bastante nervioso. Comenzó con el cliente explicando lo que se esperaba de mí, así como también el proyecto en general, y haciendo preguntas todo el tiempo para comprobar sí había entendido todo. Mientras la entrevista avanzaba, las cosas no estaban yendo como esperaba, y las preguntas se fueron volviendo cada vez más específicas y técnicas. Terminaron contratando a alguien más. En retrospectiva, fue bueno que no me hayan querido: una semana después, fui entrevistado por quien, eventualmente, terminó siendo mi empleador a tiempo completo.

Me preparé mejor para la siguiente entrevista, la cual fue tan bien como podría haber esperado: hablamos más sobre mi experiencia cómo desarrollador, y la compañía se familiarizó con mi enfoque para solucionar problemas. Tres días después, había firmado contrato y comencé a trabajar para este nuevo cliente via Toptal.

Trabajé para Life360 via Toptal al menos 9 meses. Su producto estrella es una aplicación móvil de localización de familiares, pero inicialmente estuve trabajando sólo en algunos proyectos paralelos: la primera, una aplicación de alertas de terremotos; y la segunda, un escáner policial. Por algunos meses, mi flujo de trabajo consistía principalmente en: recibir requerimientos de alto nivel de Life360, devolviendo bocetos y preguntas, e integrando sus respuestas dentro de esas aplicaciones, repetía este ciclo varias veces. Estaba en contacto con un diseñador y algunos empleados de Life360 (la compañía tenía sólo cinco o seis en esa época), pero tenía mucha autonomía. Era liberador trabajar desde casa: no tenía que viajar a diario y había creado un ambiente de trabajo sin distracciones.

Pronto me encontré más y más profundamente integrado con el equipo—había demostrado mi valor, por decirlo de alguna manera, con estos dos proyectos iniciales. Para Diciembre, me preguntaron si quería formar parte del equipo a tiempo completo en San Francisco—Acepté con entusiasmo y ellos empezaron el papeleo. Para Enero, estaba atendiendo reuniones diarias de Scrum (virtualmente, ya que estaba todavía en Honduras), describiendo mi trabajo del día anterior y mi lista de tareas para lo que seguía. Mi flujo de trabajo se volvió más organizado, y me comprometí más con la empresa.

Reubicación

Era un sueño hecho realidad: había hecho un gran trabajo para una compañía de EEUU, y estaba en camino de reubicarme—pero todavía faltaban varios obstaculos a superar. En primer lugar, nunca había completado mi carrera universitaria. Aunque no es estrictamente necesario para trabajar en una empresa de tecnología en estos días, sí se necesita el título de bachiller para calificar para una visa de tipo H-1B. Así que tuve que terminar mi carrera; esto requería de un compromiso de seis meses a un proyecto de mayor escala, el cual tenía justo el tiempo necesario para completar.

Aunque no es estrictamente necesario para trabajar en una empresa de tecnología en estos días, sí se necesita el título de bachiller para calificar para una visa de tipo H-1B

El abogado llenó el papeleo el 1ero de Abril, el día en el que el proceso de la visa tipo H-1B abre (al momento del envio, dejó la sección del diploma cómo “pendiente”, dado que el tipo de visa H-1B es limitado y podía enviar la documentación más tarde). Terminé mi proyecto a tiempo, atendí a mi ceremonia de graduación y recibí un diploma.

Desde ese punto en adelante, la compañía que te contrata tiene que ser muy abierta, por sobre todo, y muy paciente. El proceso para la aplicación de la visa empieza en Abril; si optas por la opción del proceso premium, obtienes tus resultados de la USCIS en dos semanas. Luego de eso, todavía tienes que pasar por un proceso de entrevistas, punto en el cual todavía te pueden denegar la visa; pero si todo sale bien, puedes entrar a los Estados Unidos después del 1ero de Octubre — seis meses después de la fecha de la aplicación, y no antes. Esto significa que no puedes trabajar para esa compañía hasta que realmente consigas la visa de tipo H-1B, lo cual puede ser un problema: la compañía necesita resolver como continuar trabajando remotamente mientras esperan que la visa se active. En mi caso, la compañía decidió contratarme como un desarrollador independiente, facturar mis horas como servicios profesionales, y no rompió ninguna ley de inmigración y trabajo.

Volé a San Francisco el 1ero de Octubre de 2012. El objetivo que había ansiado desde que puedo recordar fue finalmente completado.

Fuente: https://www.toptal.com/freelance/el-viaje-de-un-desarrollador-ios-desde-honduras-hasta-silicon-valley/es

28 Jun 2016

¿Por qué hay tantos Pythons?

 

Toptal blog screen shot 2013 09 18 at 1.33.10 pm

BY CHARLES MARSH – HEAD OF COMMUNITY @ TOPTAL (TRANSLATED BY PABLO FABREGAT)
#IronPython #Jython #PyPy #Python #RPython #RubyPython
110
SHARES

This article was originally written in English

Python es asombroso.

Sorprendentemente, esa es una declaración bastante ambigua. ¿A qué me refiero con ‘Python’?, ¿Me refiero a la interfaz abstracta de Python?, ¿Me refiero a CPython, la implementación común de Python (y no confundir con Cython, que son similares en sus nombres)?, ¿O me refiero a algo completamente distinto? Tal vez me esté refiriendo indirectamente a Jython, o IronPython, o PyPy. O tal vez me he ido al extremo y estoy hablando de RPython o RubyPython (los cuales son cosas muy, muy distintas).

Mientras las tecnologías mencionadas anteriormente son llamadas de formas parecidas y referenciadas de la misma manera, algunas de ellas sirven para propósitos completamente distintos (o, al menos, operan de maneras completamente distintas).

A lo largo de mi tiempo trabajando con Python, me topé con toneladas de estas herramientas .*ython. Pero no hasta hace poco me tomé el tiempo de entender qué es lo que son, cómo funcionan y por qué son necesarias (a sus maneras).

En este artículo, voy a empezar desde cero y recorreré varias implementaciones de Python, concluyendo con una introducción detallada a PyPy, el cual creo es el futuro del lenguaje.

Todo empieza con entender que es lo que ‘Python’ realmente es.

Si tienes un buen entendimiento sobre código binario, máquinas virtuales y parecidos, siéntete libre de saltarte esta parte.

“Python es interpretado o compilado?”

Este es un punto común de confusión para principiantes en Python.

La primera cosa que hay que saber es que ‘Python’ es una interfaz. Existe una especificación sobre lo que Python debería hacer y cómo debería comportarse (cómo con cualquier interfaz). Y hay múltiples implementaciones (como en cualquier interfaz).

Lo segundo que hay que saber es que ‘interpretado’ y ‘compilado’ son propiedades de una implementación, no de una interfaz.

Entonces, la pregunta no está realmente bien formada.

¿Python es interpretado o compilado? La pregunta no está realmente bien formada.
Dicho esto, para la implementación más común (CPython: escrito en C, usualmente llamado simplemente ‘Python’, y seguramente lo que estás usando si no tienes idea de lo que estoy hablando), la respuesta es: interpretado, con algunas partes compiladas. CPython compila** el código fuente de Python a *bytecode, y en ese momento interpreta ese bytecode, ejecutándolo sobre la marcha.

* Nota: no es una ‘compilación’ en sentido tradicional de la palabra. Normalmente, decimos que ‘compilar’ es tomar el código de alto nivel y convertirlo en código binario. Pero es un tipo de ‘compilación’.

Veamos la respuesta un poco más de cerca, ya que nos permitirá entender algunos de los conceptos que surgirán más adelante en el artículo.

Bytecode vs. código binario

Es muy importante entender la diferencia entre bytecode y código binario (o nativo), tal vez mejor ilustrada con ejemplos:

C compila a código binario, que luego es ejecutado directamente en tu procesador. Cada instrucción le indica a tu CPU que mueva cosas alrededor.
Java compila a bytecode, que luego es ejecutado en la máquina virtual de Java(Java Virtual Machine, ó JVM), una abstracción de una computadora que ejecuta programas. Cada instrucción es entonces manejada por la JVM, que interactúa con tu computadora.
En términos breves: código binario es más rápido, pero bytecode es más portable y seguro.

El código binario se ve distinto, dependiendo de tu máquina, pero bytecode se ve igual en todas las maquinas. Se podría decir que el código binario está optimizado para tu configuracion.

Volviendo a CPython, el proceso en el conjunto de herramientas sucede de la siguiente manera:

CPython compila tu código Python a bytecode
Ese bytecode es entonces ejecutado en la Máquina Virtual CPython
Los principiantes asumen que Python es compilado a raíz de los archivos .pyc. Hay alguna verdad en esto: el archivo .pyc es bytecode compilado, que es después interpretado. Entonces si haz ejecutado código Python y ya tienes un archivo .pyc disponible, el mismo va a ejecutarse más rápido la segunda vez ya que no necesitará recompilar el bytecode.
Maquinas virtuales alternativas: Jython, IronPython, y más

Cómo mencioné anteriormente, Python tiene varias implementaciones. De vuelta, como mencioné antes, la más común es CPython. Ésta es una implementación de Python escrita en C y es considerada la implementación ‘por defecto’.

¿Pero, qué pasa con las alternativas? Una de las más prominentes es Jython, una implementación en Java que utiliza la JVM. Mientras CPython produce bytecode para ser corrido en la VM de CPython, Jython produce bytecode de Java para correr en la JVM (esto es lo mismo que es producido cuando se compila un programa en Java).

“¿Por qué usaría alguna vez una implementación alternativa?”, podrías preguntar. Bueno, para empezar, esas diferentes implementaciones juegan muy bien con diferentes conjuntos de tecnologías.

CPython hace muy fácil el escribir extensiones C para tu código Python porque al final es ejecutado por un intérprete de C. Por otro lado, Jython, facilita trabajar con otros programas en Java: puedes importar cualquier clase de Java sin mayor esfuerzo, evocando y utilizando tus clases Java dentro tus programas Jython. (Nota aparte: si no pensaste en esto detalladamente, es una locura. Estamos en un punto donde puedes mezclar y triturar diferentes lenguajes y compilarlos todos en una misma esencia. Como fue mencionado por Rostin, los programas que mezclan código Fortran y C están desde hace un tiempo. Así que, por supuesto que esto no es algo necesariamente nuevo. Pero sigue siendo genial.)

Cómo ejemplo, esto es código Jython válido:

[Java HotSpot(TM) 64-Bit Server VM (Apple Inc.)] on java1.6.0_51
>>> from java.util import HashSet
>>> s = HashSet(5)
>>> s.add(«Foo»)
>>> s.add(«Bar»)
>>> s
[Foo, Bar]
IronPython es otra implementación popular de Python, escrita enteramente en C# y apuntando a la tecnología .NET. En particular, corre con lo que se podría llamar la Máquina Virtual .NET,Common Language Runtime (CLR)de Microsoft, comparable con la JVM.

Podrías decir que Jython : Java :: IronPython : C#. Corren en sus respectivas VMs, puedes importar clases C# en tu código IronPython y clases Java desde tu código Jython, etc.

Es totalmente posible sobrevivir sin tocar alguna vez una implementación de Python no-CPython. Pero hay ventajas que se obtienen desde el cambio, muchas de ellas son dependientes de la tecnología que uses. ¿Usas muchos lenguajes basados en la JVM? Jython puede ser para tí. ¿Todo lo que haces es sobre la tecnología .NET? Tal vez debas probar IronPython (y tal vez ya lo hayas hecho).

Por cierto: mientras que esto no sería una razón para usar una implementación diferente, nota que estas implementaciones sí difieren en comportamiento más allá de como tratan tu código fuente en Python. Sin embargo, esas diferencias son comúnmente menores, y se disuelven o emergen con el tiempo mientras estas implementaciones se encuentran bajo un activo desarrollo. Por ejemplo, IronPython usa cadenas Unicode por defecto; Sin embargo, CPython, por defecto usa ASCII para versiones 2.x (fallando con un error de codificación UnicodeEncodeError para caracteres no-ASCII), pero sí soporta cadenas Unicode por defecto para las versiones 3.x.

Compilación Justo-a-Tiempo: PyPy y el futuro

Por lo tanto, tenemos una implementación de Python escrita en C, una en Java una en C#. El próximo paso lógico: una implementación de Python escrita en… Python. (El lector educado encontrará esta notación levemente engañosa).

Aquí es donde las cosas se ponen confusas. Primero, discutamos sobre compilación Justo-a-Tiempo (Just-in-Time, ó JIT).

JIT: El por qué y el cómo

Recordemos que el código binario es mucho más rápido que bytecode. Bueno, ¿y si pudiéramos compilar algunas partes de nuestro bytecode y luego correrlo como código nativo? Tendríamos que pagar algún precio al compilar a bytecode (por ej., tiempo), pero si el resultado fuese más rápido, eso sería genial! Esa es la motivación de la compilación JIT, una técnica híbrida que mezcla los beneficios de los interpretadores y los compiladores. En términos básicos, JIT quiere utilizar compilación para acelerar un sistema interpretado.

Por ejemplo, un enfoque común tomado por la compilación JIT:

Identificar bytecode que es ejecutado frecuentemente.
Compilar a código binario.
Almacenar el resultado en memoria caché.
Siempre que el mismo bytecode sea encontrado para ejecutar, en vez de usarlo, ejecutar el código binario precompilado y cosechar los beneficios (por ej., aumentos de velocidad)
De esto se trata PyPy: llevar JIT a Python (mira el Apéndice para ver esfuerzos anteriores). Hay, por supuesto, otros objetivos: PyPy apunta a ser multiplataforma, bajo en consumo de memoria e independiente del conjunto de tecnologías. Pero JIT realmente se vende por si solo. Como promedio de un puñado de pruebas de tiempo, se dice que mejora el rendimiento a un factor de 6.27. Para un mayor análisis, véase este cuadro del PyPy Speed Center:

Like what you’re reading?Get the latest updates first.

Enter your email address…
Get Exclusive Updates
No spam. Just great engineering and design posts.
PyPy es difícil de entender

PyPy tiene un gran potencial, y a estas alturas es muy compatible con CPython (así que puede correr Flask, Django, etc.).

Pero hay mucha confusión alrededor de PyPy (véase, por ejemplo, esta propuesta sin sentido para crear un PyPyPy…). En mi opinión, eso es principalmente porque PyPy es actualmente dos cosas:

Un intérprete de Python escrito en RPython (no Python (he mentido antes). RPython es un subconjunto de Python con tipos estáticos. En Python, es “prácticamente imposible” razonar rigurosamente acerca de tipos (¿Por que es tan difícil? Bueno, considera el hecho que:

x = random.choice([1, «foo»])
sería código Python válido (créditos a Ademan). ¿De qué tipo es x? ¿Cómo podemos razonar acerca de tipos de variables cuando los tipos ni siquiera son estrictamente forzados?). Con RPython, sacrificas algo de flexibilidad, pero a cambio es muchísimo más fácil razonar sobre manejo de memoria y demás, lo cual permite optimizaciones.
Un compilador que compila código RPython para varios objetivos y agrega JIT. La plataforma por defecto es C, por ej., un compilador RPython-a-C, pero también puedes apuntar a JVM y otros.
Únicamente para mayor claridad, me referiré a ellos como PyPy (1) y PyPy (2).

¿Por qué necesitarías esas dos cosas, y por qué bajo el mismo techo? Piénsalo de esta manera: PyPy(1) es un intérprete escrito en RPython. Entonces toma el código Python del usuario y lo compila a bytecode. Pero el interpretador en sí (escrito en RPython) tiene que ser interpretado por otra implementación de Python para poder correr, ¿Verdad?

Bueno, podríamos simplemente usar CPython para correr el intérprete. Pero eso no sería lo suficientemente rápido.

En cambio, la idea es que usemos PyPy(2) (también conocido cómo RPython Toolchain)-Set de herramientas RPython) para compilar al interpretador de PyPy a código que otra plataforma (por ej., C, JVM o CLI) pueda correr en nuestra máquina, agregando también JIT. Es mágico: PyPy agrega dinámicamente JIT a un interpretador, generando su propio compilador! (De vuelta, esto es una locura: estamos compilando un interpretador y agregando otro compilador independiente por separado).

Al final, el resultado es un ejecutable independiente que interpreta el código fuente Python y explota las optimizaciones de JIT. Que es lo que justamente queríamos! Es un gran bocado, pero tal vez este diagrama ayude:

Reiterando, la verdadera belleza de PyPy es que podemos escribir nosotros mismos un puñado de interpretadores Python distintos en RPython sin preocuparnos por JIT (salvo algunas sugerencias). PyPy entonces implementaría JIT por nosotros usando el set de herramientas de RPython/PyPy(2).

De hecho, si nos ponemos aún más abstractos, podrías, teóricamente, escribir un interpretador para cualquier lenguaje, alimentar a PyPy con él, y obtener un JIT para ese lenguaje. Esto es porque PyPy se enfoca en optimizar el interpretador actual, en vez de los detalles del lenguaje que está interpretando.

Podrías, teóricamente, escribir un interpretador para *cualquier* lenguaje, alimentar a PyPy con él, y obtener un JIT para ese lenguaje.
Divagando un poco, me gustaría mencionar que JIT en sí mismo es absolutamente fascinante. Usa una técnica llamada tracing (ó seguimiento), la cual se ejecuta de la siguiente manera:

Correr el interpretador e interpretar todo (sin agregar nada de JIT)
Perfilar levemente el código interpretado.
Identificar operaciones que hayas realizado antes.
Compilar esos pedazos a código binario.
Para más información, este documento es altamente accesible y muy interesante.

Para ir concluyendo: usamos el compilador RPython-a-C de PyPy (u otra plataforma) para compilar el interpretador implementado RPython de PyPy.

Concluyendo

¿Por qué es tan genial? ¿Por qué vale la pena perseguir esta idea tan loca? Creo que Alex Gaynor lo describió muy bien en su blog: “[PyPy es el futuro] porque ofrece mejor velocidad, más flexibilidad y es una mejor plataforma para el crecimiento de Python.”

En resumen:

Es rápido porque compila código fuente a código nativo (usando JIT).
Es flexible porque agrega JIT a tu interpretador con muy poco trabajo adicional.
Es flexible (de nuevo) porque puedes escribir tus interpretadores en RPython, lo cual hace que sea más fácil de extender que, digamos, C de hecho, es tan fácil que hay un tutorial para escribir tus propios intérpretes.
Apéndice: Otros nombres que tal vez hayas oído

Python 3000 (Py3k): nombre alternativo para Python 3.0, un mayor, compatible-con-versiones-anteriores lanzamiento de Python que alcanzó la escena en 2008. El equipo de Py3k predijo que llevaría alrededor de cinco anos para que esta versión sea completamente adoptada. Y mientras que la mayoría (cuidado: se dice que es anecdótico) de los desarrolladores de Python siguen usando Python 2.x, la conciencia de Py3k entre la gente está incrementándose.
Cython: un super set de Python que incluye bindings (ó enlaces)para llamar funciones de C.
Objetivo: permitirte escribir extensiones en C para tu código Python
Además te permite agregar tipos de variables estáticos a tu código Python, permitiéndole que sea compilado y alcanzar rendimiento parecido al de C.
Es similar a PyPy, pero no es lo mismo. En este caso, estás forzado a escribir el código del usuario antes de pasarlo al compilador. Con PyPy, escribes simplemente código Python, y el compilador maneja cualquier optimización.
Numba: : un “compilador especializado justo-a-tiempo” que agrega JIT a código Python anotado. En términos más básicos, le das algunas indicaciones y acelera partes de tu código. Numa viene como parte de la distribución Anaconda,un set de paquetes para manejo y análisis de datos.
IPython: muy diferente a todo lo que hemos discutido hasta ahora. Es un ambiente de procesamiento para Python. Interactivo y con soporte para herramientas gráficas y experiencia de navegador, etc.
Psyco: un modulo de extensión de Python, y uno de los primeros esfuerzos de JIT en Python. De todas formas, ha sido marcado como “sin mantenimiento y muerto”. De hecho, el desarrollador principal de Psyco, Armin Rigo, ahora trabaja en PyPy.
Enlaces de lenguaje

RubyPython: un puente entre las máquinas virtuales de Ruby y Python. Permite embeber código de Python dentro de tu código de Ruby. Defines donde Python comienza y termina, y RubyPython calcula los datos entre las VMs.
PyObjc: enlaces de lenguaje entre Python y Objetive-C, actuando como un puente entre ellos. Prácticamente, eso significa que puedes utilizar librerías de Objective-C (incluyendo todo lo que necesitas para crear aplicaciones de OS X) desde tu código Python, y módulos de Python desde tu código Objective-C. En este caso, es conveniente que CPython esté escrito en C, el cual es un subconjunto de Objective-C.
PyQt: mientras PyObjc te ofrece una interfaz para los componentes gráficos de OS X, PyQt hace lo mismo para el framework de QT, permitiendote crear completas interfaces gráficas, acceso a bases de datos SQL, etc. Otra herramienta dirigida a traer la simplicidad de Python a otros frameworks.
Frameworks JavaScript

pyjs (Pyjamas): un framework para crear aplicaciones web y de escritorio en Python. Incluye un compilador Python-a-Javascript, un conjunto de widgets, y algunas herramientas más.
Brython: una máquina virtual de Python escrita en JavaScript para permitir que el código de Py3k sea ejecutado en navegadores.

Contenido traducido por Pablo Fabregat, miembro de TransBunko, un mercado de traducciones técnicas.

 

Fuente: https://www.toptal.com/python/por-que-hay-tantos-pythons/es

22 Abr 2016

¿Te sientes Solo? Hagamos un chat con Node y Angular !!

Seguro que te pasa como a mi.

Te sientes solo y no tienes amigos con quienes hablar. Tratas de conectarte a ICQ y todos tus amigos ya se mudaron a otras aplicaciones, entras a IRC y los únicos que se dignan a hablarte son BOTS sin sentimientos.

Y si hacemos un chat ?

Para ello, usaremos 3 componentes: Node.js, Angular y una librería de node para websockets llamada sockjs.

 

El proyecto se compondrá de 2 archivos

  • server.js: que contendrá la lógica del servidor
  • chat.html: que tendrá la presentación y la lógica del cliente integrada.

 

Empecemos

 

Para nuestro servidor

[snippet id=»66″]

La magia sucede en la linea 6, donde se crea el handler de sockjs.

En la siguiente linea se configura el evento generado cada vez que un nuevo usuario se conecta. La función entrega el objeto conexión que es almacenado en una lista. Cada vez que se registra una conexión, se envía un saludo.

En el evento de recibir un mensaje por parte de un usuario (Linea 11), se recorre la lista de conexiones y a cada usuario se le envía un mensaje con el mensaje, usuario que origina y fecha de recepción.

Finalmente, para el evento de desconexión (Linea 16), se envía a todos los usuarios una advertencia de que el usuario ha abandonado el chat.

Las últimas 3 lineas crean el servidor y vinculan la ruta ‘/chat’ al handler de sockjs .

 

Luego el cliente

[snippet id=»67″]

Gran parte de este archivo contiene estructura HTML para el formateo de los datos y CSS para el estilo.

Las partes importantes son:

  • Lineas 65-66 donde se incluyen las librerías de cliente de sockjs y angular
  • Linea 69 donde conectamos el cliente con el servidor
  • Linea 70 a 82 donde definimos el controlador de angularjs. Iniciamos la lista que almacenará los mensajes, definimos el método ‘sendMessage’ que enviará nuestros mensajes al servidor y finalmente, nos subscribimos al evento de recepción de mensajes-.
  • Linea 88 donde por medio de la directiva «ng-controller» vinculamos el controlador de angularjs con la presentación.
  • Linea 102 donde recorremos los mensajes y los dibujamos

Fácil, cierto?

Si quieres revisar el código, puedes explorarlo en nuestro repositorio:

https://github.com/cristiansalinas/33SurChat

Si quieres ver el programa terminado, entra a chatear con nosotros:

http://chat.33sur.cl

 

Nos vemos !

 

14 Mar 2016

Microservicios en Javascript – Parte I

Ultimamente se ha hablado mucho de microservicios. Pero, ¿Qué son los microservicios?.

En palabras simples, el concepto se refiere a un estilo o patrón de arquitectura de software donde la lógica se distribuye entre procesos independientes que se comunican entre si por medio de APIs agnósticas.  Las características de estos procesos es que son pequeños, no tienen dependencias entre sí y se enfocan en realizar tareas pequeñas y específicas.  En la práctica, cada uno de estos procesos podría estar escrito en un lenguaje diferente o residir en una maquina diferente.

¿Cuales son las ventajas de una arquitectura como esta?

Generalmente cuando iniciamos un proyecto, el desarrollo es realizado por un equipo encargado de la totalidad del código. A medida que el código se hace más grande y requiere modificaciones, éstas van adquiriendo mayor complejidad y cada alteración se transforma en un riesgo. El proyecto se vuelve dependiente del equipo en cuestión y dependiendo de las decisiones originales, el proyecto puede o no ser escalable.

Una arquitectura de microservicios nos permite dividir las responsabilidades fácilmente, llegando al punto, en casos extremos, de tener un equipo por cada servicio. Las alteraciones, al ser realizadas dentro de un contexto de partes independientes, son mas simples y por defecto, en caso de requerir escalar el sistema, los servicios se pueden distribuir en distintas máquinas. La integración de nuevos servicios es trivial.

Una aplicación

No existe mejor manera para entender e ilustrar los conceptos que ponerlos en práctica. Para ello vamos a construir una pequeña pero funcional aplicación utilizando Node.js para el servidor y AngularJS para el cliente.

Las bases

Para construir la aplicación, necesitamos tener instalado Node, Yeoman y Bower, que son respectivamente :

  • Un framework en Javascript orientado a eventos para crear aplicaciones de red
  • Una aplicación para crear bases y maquetas de proyectos
  • Un gestos de dependencias

 

Existen muchas maneras de instalar Node, dependiendo del sistema operativo que tengas. Las distintas alternativas están enumeradas en su página Web (http://Node.js).

Una vez que tenemos instalado Node, Yeoman y Bower se pueden instalar por medio de la interfaz de comandos:

npm install -g yo

npm install -g bower

Una vez que tenemos todo instalado, procedemos a la instalación del generador de Yeoman para proyectos sobre un framework de microservicios para Node llamado Seneca.

(Si quieres aprender lo básico de Yeoman, aquí hay un artículo útil  http://www.33sur.cl/maqueteando-proyectos-rapidos-en-js/)

 

npm install -g yo generator-seneca

 

Y para generar la base del proyecto, basta con crear un directorio, acceder al mismo y ejecutar el siguiente comando:

yo seneca

 

Esto va a crear una estructura de directorios como esta:


test-seneca
|
|-- client  (Lógica cliente en angularJS)
| |-- css
| |-- js
| |-- partials
| |-- index.html
|-- server (Lógica de microservicios en el servidor sobre Node)
| |-- api.js
|-- test
| |-- functional
|-- bower.json
|-- package.json
|-- server.js

 

Con el comando:

npm start

Se puede iniciar la aplicación de prueba generada por yeoman. Para poder verla, es posible acceder por medio del navegador con la URL http://localhost:4000 y deberías ver una pantalla como esta:

Captura de pantalla 2016-03-13 a las 5.01.08 p.m.

 

En el siguiente artículo, investigaremos el funcionamiento de la aplicación de ejemplo y crearemos nuestra propia API