Autor:

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

28 Jun 2016

Init.js: Una guía de los Por Qué y Cómos en el conjunto de tecnologías de JavaScript

 

La Historia

Entonces, tú y tu cofundador tienen esta genial idea para un negocio, ¿verdad?

Has estado agregando características en tu cabeza.

Frecuentemente, le preguntas a tus potenciales clientes sus opiniones, y todos ellos la aman.

Ok, entonces la gente la quiere. Hay hasta un poco de dinero para hacer. Y la única razón por la cual ellos no pueden obtenerla es porque no las has implementado—todavía.

Entonces, finalmente, te sientas un día y dices “¡Hagámoslo!”. Pronto, estás tratando de averiguar cómo aplicar la lógica de negocio de tu aplicación, la funcionalidad asesina que va a llevar adelante al producto: tienes una idea de cómo hacerlo, y ahora sabes que puedes hacerlo.

“¡Listo!¡Funciona!” dices. ¡Tu prueba de concepto es un éxito! Todo lo que queda por hacer es empaquetarlo en una aplicación web.

“Ok, hagamos el sitio”, dices.

Y entonces, te das cuenta de la verdad: necesitas elegir un lenguaje de programación; necesitas elegir una plataforma (moderna); necesitas elegir algunos frameworks (modernos); necesitas configurar (y comprar) espacio, base de datos y proveedores de alojamiento; necesitas una interfaz de administración; necesitas un sistema de permisos; necesitas un administrador de contenidos.

Quieres ser escueto, quieres ser ágil. Quieres usar tecnologías que te ayudaran a tener éxito en el corto-y largo-plazo. Y no son siempre fáciles de elegir

Tienes que tomar decenas y decenas de decisiones de arquitectura . Y quieres tomar las correctas: quieres usar tecnologías que te permitan desarrollo rápido, iteración constante, máxima eficiencia, velocidad, robustez y más. Quieres ser escueto, quieres ser ágil. Quieres usar tecnologías que te ayudaran a tener éxito en el corto-y largo-plazo. Y no son siempre fáciles de elegir.

“Estoy abrumado”, dices, mientras te vas sintiendo abrumado. Tu energía no es la misma de antes. Tratas de encajar las piezas, pero es demasiado trabajo.

Tu prueba de concepto se marchita y muere lentamente.

La Propuesta

Luego de abandonar toneladas de ideas de esta forma, decidí diseñar una solución. La llamo el proyecto ‘Init’ (Inicio)(ó init.js).

El corazón de la idea es tener un simple proyecto que inicie todos los demás, dejar que el desarrollador o el fundador técnico tomen esas decisiones al mismo tiempo y recibir una plantilla apropiada para empezar basada en esas decisiones. Se lo que van a decir los detractores, “Una solución no puede aplicarse a todos los problemas” (Odiadores odiarán). Y puede que estén en lo cierto. Pero podemos hacer nuestro mejor esfuerzo para crear una solución aproximada, y creo que Init se acerca bastante.

Para lograr mejor este objetivo, tenemos que tener algunas ideas claves en mente. Cuando estaba desarrollando Init, consideré:

  • ComponentesLa modularización es una característica clave de cualquier sistema ya que te permite reusar componentes de software a través de distintos proyectos—lo cual es el principal objetivo de Init. Pero la modularización también viene con una “reemplazabilidad” por producto, la cual será nuestra mejor aliada a la hora de atacar varios tipos de problemas con “casi” la misma solución.
  • Facilidad de DesarrolloPara algunos problemas, en algún lado hay una mejor solución escrita en [Brainf*ck](https://en.wikipedia.org/wiki/Brainfuck). ó jodecerebros). Pero implementar esa solución (en Brainf*uck) sería casi imposible de escribir, y mucho menos de leer. Te costaría tiempo y una enorme cantidad de esfuerzo. En general, deberías usar lenguajes y plataformas que hagan al desarrollo fácil, y no difícil para tí (o alguien que puede trabajar con él más tarde).
  • ComunidadCualquier plataforma que elijas, asegúrate que tenga una gran comunidad, y una que te pueda ayudar con los problemas más comunes y con los que no lo son tanto. Recuerda: jQuery puede no ser la librería másrápida, la más limpia, o la más elegante—pero es un ganador sólo por su comunidad.

Teniendo estos objetivos en mente, voy a mostrarte como hice mis propias decisiones al crear Init.

En su núcleo, Init se aprovecha del paradigma ‘full-stack JavaScript’ (algunas personas se refieren a él, o a una parte de él, como el MEAN Stack). Al trabajar con este conjunto, Init es capaz de usar solamente un sólo lenguaje mientras crea un ambiente increíblemente flexible y con todas las funciones para desarrollar aplicaciones web. En resumen, Init te permite usar JavaScript no solamente para desarrollo del lado cliente y servidor, pero también para construir, testear, maquetar, y más.

Pero bajemos un poco la velocidad y preguntémonos: ¿es realmente una buena idea usar JavaScript?

Por qué elegí JavaScript

Soy desarrollador web desde 1998. Por esas épocas usabamos Perl para la mayoría de nuestro desarrollo del lado del servidor, y aún desde esos tiempos teníamos JavaScript del lado del cliente. Las tecnologías web del lado servidor han cambiado inmensamente desde entonces: fuimos a través de oleada tras oleada de distintas tecnologías y lenguajes cómo PHP, ASP, JSP, .NET, Ruby, Python, solo por nombrar algunas. Los desarrolladores comenzaron a darse cuenta que usando dos distintos lenguajes para ambientes cliente y servidor estaba complicando las cosas. Los intentos iniciales para unificar bajo un mismo lenguaje intentaban crear componentes cliente del lado del servidor y compilarlos en JavaScript. Esto no funcionaba como se esperaba y muchos de esos proyectos fallaron (por ejemplo, ASP MVC reemplazando los formularios web de ASP.NET, y podría decirse queGWT será reemplazado por Polymer). en un futuro cercano). Pero era una excelente idea, en esencia: un lenguaje único en el cliente y el servidor, permitiéndonos reusar componentes y recursos (esta es la clave:recursos).

La respuesta era simple: usar JavaScript en el servidor.

De hecho, JavaScript nació con JavaScript Server Side en Netscape Enterprise Server, pero el lenguaje simplemente no estaba listo en esa época. Luego de años de prueba y error, Node.js finalmente emergió, lo cual no solo puso a JavaScript en el servidor, pero además promovió la idea de programación no-bloqueante, cambiando la forma en la que escribimos “fread”(I/O) para siempre (lee más aquí.

En una oración: la programación no-bloqueante apunta a poner tareas que consumen tiempo a un lado, usualmente especificando que se debería hacer una vez que estas tareas se hayan completado, y permitiendo que el procesador maneje otros pedidos mientras tanto.

Pero esas ideas no eran nuevas—entonces, ¿por que se volvieron tan populares con Node.js? Simple, la programación no-bloqueante puede ser alcanzada de distintas formas. Tal vez la más fácil es usar callbacks y un evento en bucle. En la mayoría de los lenguajes, esa no es una tarea fácil: mientras que los ‘callbacks’ son una característica común en algunos lenguajes, un evento en bucle no lo es y usualmente te encuentras aferrándote a librerías externas (por ejemplo: Python, con Tornado). Pero en JavaScript, los callbacks son construidos dentro del lenguaje, como también el evento en bucle, y casi cualquier programador que haya incursionado en JavaScript está familiarizado con ellos (o al menos los han usado, aunque no entiendan del todo que significa un evento en bucle). De repente, cada una de las startup en el Planeta Tierra podía reusar desarrolladores (por ej., recursos) tanto en el lado cliente cómo en el lado del servidor, resolviendo el problema de “Se necesita Gurú Python”.

De repente, cada una de las startup en el Planeta Tierra podía reusar desarrolladores (por ej., recursos) tanto en el lado cliente cómo en el lado del servidor, resolviendo el problema de “Se necesita Gurú Python”.

Entonces, ahora tenemos una plataforma increíblemente rápida (gracias a la programación no-bloqueante) con un lenguaje de programación que es increíblemente fácil de usar (gracias a JavaScript). Pero, ¿Es suficiente? ¿Perdurará? Estoy seguro que JavaScript va a tener un importante lugar en el futuro. Déjame decirte por qué:

  • Programación FuncionalJavaScript fue el primer lenguaje de programación que llevó el paradigma funcional a las masas (por supuesto, Lisp llegó primero, pero la mayoría de los desarrolladores nunca han construido una aplicación en Lisp lista para ser usada en producción). Lisp y Self, influencias principales de Javascript, están llenos de ideas innovadoras. Esas ideas pueden liberar nuestras mentes para explorar nuevas técnicas, patrones y paradigmas. Y todos ellos llevan a JavaScript. Mira monads, codificación Church, o incluso (para un ejemplo más práctico) la colección de funciones](http://underscorejs.org/#collections), de Underscore.js las cuales pueden salvarte líneas y líneas de código.
  • Objetos Dinámicos y herencia PrototipadaLa programación orientada a objetos sin clases (y sin las interminables herencias de clases) permite rápido desarrollo (crear objetos, agregar métodos y usarlos) pero, lo más importante, reduce el tiempo de refactorización durante tareas de mantenimiento dejando que el desarrollador modifique instancias de objetos en vez de clases. Esta velocidad y flexibilidad pavimenta el camino para el desarrollo rápido.
  • JavaScript es InternetJavaScript fue diseñado para Internet, ha estado aquí desde el principio, y no va a irse. Todos los intentos por destruirlo han fallado, mira, por ejemplo, la caída de los Applets Java, el reemplazo de VBScript de Microsoft, TypeScript (que compilaba a JavaScript), y la caída de Flash en manos del mercado móvil y HTML5. Es imposible reemplazar Javascript sin romper millones de páginas web, así que nuestro objetivo a largo plazo debería ser el de mejorarlo. Y no hay nadie mejor para esa tarea que el Technical Committee 39 de ECMA.Ok, alternativas a JavaScript nacen todos los días, cómo CoffeeScript, TypeScript, y los los millones de lenguajes que compilan a JavaScript. Esas alternativas pueden ser útiles para etapas de desarrollo (por medio de mapeos de código fuente), pero fallarán al tratar de suplantar JavaScript a largo plazo por dos razones: sus comunidades nunca serán más grandes, y sus mejores funcionalidades serán adoptadas por el script de ECMA (por ej., JavaScript). JavaScript no es como un lenguaje ensamblador: es un lenguaje de programación de alto nivel con código fuente que puedes entender—entonces deberías entenderlo.
Ahora, gracias al proyecto Esprima, puedes crear tus propias herramientas para jugar con el código fuente, modificándolo, cambiando su estilo, agregando comentarios, instrumentando, y todo de tipo de cosas que puedas imaginar al jugar con el Árbol de Sintaxis Abstracta de tu programa como si estuvieses jugando con un Árbol DOM.

JavaScript de extremo a extremo: Node.js y MongoDB

Entonces, esas son las razones para usar JavaScript. Ahora, voy a usar JavaScript como una razón para usar Node.js y MongoDB.

  • Node.jsNode.js es una plataforma para construir aplicaciones de red rápidas y escalables—eso es básicamente lo que dice el sitio de Node.js. Pero Node.js es más que eso: es el entorno de ejecución preferido por cualquier aplicación con acceso de E/S en JavaScript. Incluso si no planeas escribir tu aplicación del servidor principal con Node.js, puedes usar herramientas creadas construidas encima de Node.js para mejorar tu proceso de desarrollo. Por ejemplo: Mocha.js para unit testing, Grunt.js para tareas de construcción automatizadas, o incluso Brackets para completar edición de código.Entonces, si vas a escribir aplicaciones de JavaScript para servidor o cliente, deberías familiarizarte con Node.js, porque vas a necesitar usarlo diariamente. Hay algunas interesantes alternativas), pero ninguna de ellas llega siquiera al 10% de la comunidad de Node.js.
  • MongoDBMongoDB es una base de datos NoSQL basada en documentos que usan JavaScript como su lenguaje de consultas, permitiendo completar de extremo-a-extremo la plataforma JavaScript. Pero esa no es siquiera la razón principal para elegir esta base de datos.MongoDB es una base de datos sin esquema que permite persistir tus objetos de una manera flexible y por lo tanto adaptarse más rápidamente a los cambios en los requisitos. Además, es altamente escalable y basado en map-reduce, lo cual lo hace adecuado para aplicaciones con muchos datos. MongoDB es tan flexible que puede ser usado como una base de datos de documentos sin esquema, un almacén de datos relacional (aunque le faltan transacciones),o incluso almacenamiento de clave-valor para respuestas de caché.

Modularización de Servidor con Express.js

Modularización en el lado del servidor nunca es fácil. Pero con Express.js (y Connect.js) vino la idea de‘middleware’(ó software intermedio). En mi opinión, middleware es la mejor forma de definir componentes en el servidor. Si quieres compararlo con un patrón conocido, se acerca bastante a los tubos y filtros.

La idea básica es que tu componente es parte de una tubería. La tubería procesa el pedido (entrada) y genera una respuesta (salida), pero tu componente no es responsable por la respuesta completa. En cambio, solo modifica lo que necesita y luego delega hacia la otra pieza de la tubería. Cuando la última pieza de la tubería termina su proceso, la respuesta se envía al cliente.

Nos referimos a estas ‘piezas de tubería’ como ‘middleware’. Claramente, podemos crear dos tipos demiddleware:

  • Intermedios: Esos que procesan el pedido y la respuesta, pero no son del todo responsables por la respuesta en sí, entonces delegan al siguiente middleware.
  • Finales: Esos que toman la responsabilidad por completo en la respuesta final. Ellos procesan y modifican el pedido y la respuesta, pero no necesitan delegar al siguiente middleware. En la práctica, se recomienda que delegues a un siguiente middleware, de todas maneras, para permitir flexibilidad en la arquitectura (por ej., agregar más middleware después), aunque ese middleware no exista (en ese caso la respuesta irá directamente al cliente)

Como ejemplo concreto, considera un componente ‘usuario administrador’ en el servidor. En términos de middleware, tendríamos tanto finales como intermediarios. Para nuestros finales, tendríamos características tales como crear un usuario y listar usuarios. Pero antes que podamos realizar esas acciones, necesitamos nuestros intermediarios para autenticación (ya que no queremos pedidos que creen usuarios sin autenticar). Una vez que creamos estos intermediarios para autenticación, podemos simplemente conectarlos en cualquier lado que queramos para convertir una característica sin autenticación existente en una con autenticación.

Aplicaciones de una sóla página

El proyecto Init enfoca en crear aplicaciones de una sóla página (SPAs-Single-Page Applications). Muchos desarrolladores web se han tentado más de una vez en probar construir SPAs. Desarrollé usando varias (principalmente propietarias), y puedo decir con confianza que son simplemente el futuro de las aplicaciones web. ¿Alguna vez comparaste una SPA con una aplicación web regular en una conexión móvil? La diferencia de respuesta es de decenas de segundos.

¿Alguna vez comparaste una SPA con una aplicación web regular en una conexión móvil? La diferencia de respuesta es de decenas de segundos.

Las SPA son el futuro de la web—¿entonces por que harías tu producto en un formulario antiguo? Un argumento común que escucho es que la gente está preocupada por el SEO. Pero si manejas las cosas correctamente, esto no debería ser un problema: Google mismo tiene un muy buen tutorial sobre como hacerlo, y hay muy buenos comentarios aquí también.

MV* del lado del cliente con Backbone.js, Marionette.js y Twitter Bootstrap

Mucho se ha dicho acerca de los MVC* frameworks para SPAs. Es una decisión complicada, pero voy a decir que el top 3 son Backbone.js, Ember.js, y Angular.js.

Los tres son bien considerados. ¿Pero cual de ellos es el mejor para tí?

Desafortunadamente, tengo que admitir que tengo una experiencia muy limitada con Angular.js, así que voy a dejarlo fuera de esta discusión. Ahora, Ember.js y Backbone.js representan dos maneras distintas de atacar el mismo problema.

Backbone.js es minimalista, simplista y te ofrece lo suficiente para crear una simple SPA. Por otro lado, Ember.js es un framework completamente profesional para crear SPAs. Tiene más adornos, pero también una curva de aprendizaje más grande.

Dependiendo del tamaño de tu aplicación, la decisión puede ser tan fácil como mirar el ratio de featuresUsed/featuresAvailable(características Usadas/Disponibles), lo cual te dará una gran pista.

En el caso de Init, quería cubrir la mayoría de los escenarios, así que elegí Backbone.js para creación fácil de SPAs, con Backbone.Marionette.View para modularización. De esta forma, cada componente es una simple aplicación, y la aplicación final puede ser tan compleja como queramos que sea.

Estilizar es también un desafío, pero podemos, de vuelta, contar con frameworks para rescatarnos. Para CSS, no hay nada mejor que Twitter Bootstrap, que ofrece un completo set de estilos que ya están listos para usar y sonfáciles de personalizar.

Booststrap fue creado usando el lenguaje LESS que es de código abierto, así que podemos modificarlo si así lo necesitasemos. Viene con una tonelada de controles de usabilidad que están bien documentados en el sitio de Bootstrap. Además, hay un modelo de personalización que te permite crear tus propios controles. Definitivamente es el hombre para este trabajo.

Mejores prácticas: Grunt.js, Mocha.js, Chai.js, RequireJS y CoverJS

Finalmente, deberíamos definir algunas de nuestras mejores prácticas, y buscar en como Init puede ayudarte a implementarlas y mantenerlas. Nuestra solución está centrada en varias herramientas, que están basadas en Node.js.

  • Mocha.js and Chai.js:Estas herramientas te permiten mejorar tu proceso de desarrollo aplicando TDD o BDD, proveyendo la infraestructura para organizar tus tests unitarios y un lanzador para correrlos automáticamente.Hay miles de frameworks para test unitarios para JavaScript. ¿Entonces, por que usar Mocha.js? La respuesta corta: es flexible y completo.La respuesta larga: tiene dos características importantes (interfaces, reporters) y una ausencia importante (assertions). Déjenme explicarles.
    • Interfaces: tal vez estés acostumbrado a los conceptos de TDD de suites y tests unitarios, o tal vez prefieras ideas BDD de especificaciones de comportamiento con “describe” y “it should”. Mocha.js te permite usar los dos acercamientos.
    • Reporters: correr tu test generará reportes de resultados, y puedes darle formato a esos resultados usando varios reporters. Por ejemplo, si tienes que alimentar un servidor de Integración Continua, puedes encontrar un reporter para hacer exactamente eso.
    • Falta de una librería de assertions: : lejos de ser un problema, Mocha.js fue diseñado para dejarte usar la librería de assertions que prefieras, ofreciendo más flexibilidad. Hay muchas opciones, pero ahí es donde Chai.js entra en acción.

    Chai.js es una librería de assertions flexible que permite usar cualquiera de los tres más importantes estilos de assertions:

    • Assert: Estilo de assertion clásico de la vieja escuela. Ej.:
        assert.equal(variable, ”valor”);  
      
    • Expect: Tipo de assertion encadenable más comúnmente usado en BDD. Ej.:
        expect(variable).to.equal(“valor”);
      
    • Should: También usado en BDD, pero prefiero Expect porque Should porque suena repetitivo con la especificación de comportamiento _’it _(“should do something..”-” eso debería hacer algo”). Ej.:
        variable.should.equal(“valor”);
      

    Chai.js se combina perfectamente con Mocha.js. Usando solamente estas dos librerías, puedes escribir tus test en TDD, BDD, o cualquier estilo imaginable.

  • Grunt.js:Grunt.js permite automatizar tareas de construcción, cualquier cosa desde simples archivos concatenados copiados y pegados, a plantillas precompiladas, estilo compilado de lenguaje (por ej., SASS y LESS), test unitario (con mocha.js), linting y compresión de código (ej., con UglifyJS o Closure Compiler). Puedes agregar tu propia tarea automatizada a Grunt, o buscar en el registro de Grunt, donde hay cientos y cientos de plugins disponibles (de vuelta, usando herramientas con grandes comunidades detrás paga bien). Grunt también puede monitorear tus archivos y disparar acciones cuando estos son modificados.
  • RequireJS:RequireJS puede sonar como otra forma de cargar modulos con AMD, pero puedo asegurarte que es mucho más que eso. Para entender por qué, primero debemos mencionar la idea del namespacing de modulos (ej., demo.views.hola), lo que evita contaminar el namespace global envolviendo cada módulo en su propio namespace. El problema es, estos módulos no son reusables: si modificas el namespace de una ‘instancia’, estás modificando el namespace de todas las ‘instancias’. En contraste con eso, RequireJS permite definir módulos reusables desde el principio. (Además, te ayudará a adoptar Dependency Injection para evitar que tus modulos accedan variables globales).
  • CoverJS:Cobertura de código es una medida métrica para evaluar tu testing. Como el nombre implica, te dice cuanto código está cubierto en tu conjunto de tests actual. CoverJS mide la cobertura de código de tus tests instrumentando declaraciones (en vez de líneas de código cómo JSCoverage) y generando una versión instrumentada de tu código. También genera reportes para alimentar tu servidor de integración continua.

Usando _Branches_ (_ramas_) para alternar características

Cuando empecé Init, necesitaba una manera para que los usuarios activen y desactiven varias características que podrían llegar a querer en su proyecto. Decidí tomar un enfoque radical con el sistema de ramas de git para implementar esta funcionalidad.

En esencia, cada rama representa una característica o funcionalidad que un usuario podría querer incluir. Si estás empezando un proyecto desde el principio, empieza por la rama mínima que necesitas, y luego agrega otras tecnologías fusionando la rama con las otras deseadas. Por ejemplo, digamos que quieres empezar tu proyecto con Backbone.js y Marionette.js. Bueno, puedes empezar en la rama Backbone.js y fusionarla con la rama Marionette, continuando desde ahí para cada pedazo de funcionalidad que quieras agregar.

Por ahora, la idea de fusionar para agregar funcionalidad puede solo ser usada para plantillas de tecnología (ej., Backbone, Node, Express). Pero en el futuro, serás capaz de alternar entre back-end (ej., desde MongoDB a Postgres) e implementaciones del lado cliente.

Empieza un proyecto con Init y haz un deploy en Heroku hoy

Nunca ha habido una manera más fácil de empezar un proyecto. Dirígete al repositorio de GitHub, fijate la rama con los últimos commits (ahora mismo es usermanager, aunque esto puede cambiar en el futuro) y entonces:

  1. Crea un directorio para tu proyecto (o usa uno existente).
  2. Crea tu repositorio con “git init” (o usa un repositorio existente)
  3. Agrega un servidor remoto con Init
     git remote add init git: //github.com/picanteverde/init.git
    
  4. Descarga la rama que quieras
    git pull init usermanager
    
  5. Obtén el archivo de procesos de Heroku
     git pull init heroku-webprocess
    
  6. Con el Heroku Toolbelt instalado, crea una aplicación
     heroku create
    
  7. Haz un push a la rama master a Heroku
     git push heroku master
    
  8. Visita tu aplicación en funcionamiento en Heroku!

Ahora puedes empezar a desarrollar tu característica asesina con solo unas líneas de código. No solo eso, sino que estarás desarrollando con las últimas y más eficientes tecnologías en una suite de desarrollo lo más automatizada posible.

Espero que puedas usar Init para comenzar tu próxima gran idea. Recuerda Revisar el repositorio de Init para ver correcciones y características—su desarrollo es bastante activo, y espero con ansias escuchar sus comentarios.

 

fuente: https://www.toptal.com/javascript/init-js-una-gu-a-de-los-por-qu-y-c-mos-en-el-conjunto-de-tecnolog-as-de-javascript/es

28 Feb 2016

Maqueteando proyectos rápidos con Yeoman

¿Has tenido que cumplir con plazos ridículos para generar una maqueta que te permita capturar una oportunidad de negocios?  ¿Que tal esos benditos demos construidos en base a requerimientos entregados por un comercial drogado que siempre salen mal y son reemplazados en último momento por una PPT?

Hay que reconocer que nada vende tan bien como un prototipo funcionando, lo cual no solamente nos da la oportunidad de sorprender al potencial cliente (o a nuestros jefes), sino que nos permite capturar requerimientos y hacer una mejor gestión de expectativas.

La comunidad lo ha entendido así y últimamente han surgido muchas herramientas para hacer maquetas y prototipos funcionales de proyectos con diversas configuraciones.

Una de mis alternativas favoritas es Yeoman, herramienta que te permite realizar maquetas rápidas de aplicaciones web en diferentes lenguajes y con diferentes configuraciones.

Generadores

La base de Yeoman son los generadores. Pero, ¿Que es un generador? Dentro de este contexto, son patrones funcionales que le dicen a yeoman como debe ser construido el proyecto. Estos «planos» incluyen la estructura de directorios del proyecto, conectores a bases de datos, diversas tecnologías, patrones de extensiones, comandos personalizados, buenas prácticas y otros.

Entre los generadores mas populares podemos encontrar:

  • Angular-Fullstack: Generador para aplicaciones de Javascript full stack. Es decir, aplicaciones donde la tecnología detrás de cada una de sus capas es javascript (MongoDB, Express Framework, AngularJS, Node.js).
  • Loopback: Generador de aplicaciones para IBM Loopback.
  • AspNET: Generador de aplicaciones para ASP.NET 5
  • JHispter: Genera una base de aplicaciones Java con Spring, JPA y AngularJS.

 

Actualmente existen sobre 3500 diferentes generadores.

Un Ejemplo

Para ver la potencia de yeoman y sus generadores, vamos a instalar el generador Javascript Fullstack y generar una aplicación completa y funcional en cosa de minutos.

Es necesario tener instalado Node.js y MongoDB. Hay varias maneras de instalar estos componentes, enumeradas en sus respectivas páginas para distintos sistemas operativos.

Una vez instalados, necesitamos instalar Yeoman, dependencias y el generador seleccionado por medio de la interfaz de comandos:
npm install -g yo grunt-cli gulp-cli bower generator-angular-fullstack

Necesitamos crear un directorio para el proyecto de ejemplo

mkdir pruebayeoman

Para generar el proyecto, tenemos que ingresar al directorio e invocar el generador

cd pruebayeoman
yo angular-fullstack prueba

Yeoman te hará unas preguntas iniciales para configurar el proyecto:

  1. Quieres usar javaScript o coffeeScript para la programación de la lógica de negocios?
  2. Html o Jade como lenguaje de templates?
  3. Css, Sass, Stylus o Less para el estilo?
  4. ngRouter o uiRouter como manejador de rutas de AngularJS?
  5. Quieres Twitter Bootstrap integrado para el diseño de la UX?
  6. Quieres Ui Bootstrap integrado para el comportamiento de la UX?
  7. Quieres usar Mongoose para modelar los datos sobre mongoDB?
  8. Quieres un sistema de autenticación de usuarios?
  9. Quieres incluir Oauth con Facebook, Twitter o Google?
  10. Usarás Socket.io?

 

Una vez contestadas todas estas preguntas, Yeoman instalará las dependencias requeridas. Puede tardar algunos minutos en la descarga.  Vale mencionar que el generador no solo instalará muchas dependencias y generará una estructura de archivos bastante comprensible (Ej. El directorio «client» tiene la lógica del cliente en HTML y AngularJS, El directorio «server» tiene la lógica del API en node.js, express y mongo) sino que también, varios archivos de utilidad entre los cuales se encuentran:

  • .gitignore: Archivo ignore para GIT
  • package.json: Gestión de dependencias de Node.js
  • bower.json: Gestión de dependencias de AngularJS
  • gruntfile.js: Descripción de tareas automatizadas para Grunt

 

Y archivos de pruebas por defecto para codificar tus pruebas.

Una vez finalizado el proceso de creación y descarga, podemos iniciar el servidor con el comando

grunt serve

Cuando la aplicación se inicie, abrirá automáticamente una página del navegador y te dará acceso a la aplicación, junto con algunos ejemplos de sus funcionalidades.

Captura de pantalla 2016-02-28 a las 4.19.03 p.m.

 

 

Captura de pantalla 2016-02-28 a las 4.18.48 p.m.

La documentación para el generador y sus comandos personalizados se encuentra aquí.

Ahora, con un mínimo de configuraciones extras, tenemos una excelente base para comenzar nuestro demo, prototipo o MVP.