Programando

Visita nuestros facebook, canal de youtube y blogger

Video tutoriales de Dev C++

Videos con ejemples de problemas desarrollados.

Páginas para entrenar

Problemas analizados.

Proyectos de programación

Se desarrollan proyectos de programación.

Diseño web

Se diseña webs y se sube a hosting.

miércoles, 30 de noviembre de 2016

Publicación


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


El mercado de las aplicaciones móviles está saturado de competencia. Las tendencias cambian rápidamente, pero ningún nicho de mercado puede durar mucho tiempo sin que varios competidores entren en juego. Estas condiciones dan lugar a una alta tasa de fracaso en todos los ámbitos para el mercado de las aplicaciones móviles. Sólo el 20% de las aplicaciones descargadas ven regresar a los usuarios después del primer uso, mientras que sólo el 3% de las aplicaciones permanecen en uso después del primer mes.
Si cualquier parte de una aplicación no es deseable, o el proceso de entenderla es lento, los usuarios son más propensos a instalar una nueva, en lugar de esperar hasta el final con el producto imperfecto. El consumidor no pierde nada cuando se deshace de una aplicación - excepto los esfuerzos de los diseñadores y desarrolladores. Así que, ¿por qué fallan tantas aplicaciones? ¿Es un fenómeno predecible que los diseñadores de aplicaciones y desarrolladores deben aceptar? Para los clientes, ¿es aceptable ésta tasa de éxito? ¿Qué se necesita para llevar tus diseños al 3% de las aplicaciones prósperas?
Los errores más comunes van desde no mantener la constancia a lo largo de la vida útil de una aplicación, hasta atraer a los usuarios en primer lugar. ¿Cómo pueden ser diseñadas las aplicaciones con una simplicidad intuitiva, sin llegar a ser repetitivas y aburridas? ¿Cómo puede una aplicación ofrecer todos los detalles agradables, sin perder de vista un propósito mayor? La mayoría de las aplicaciones viven y mueren en los primeros días, así que aquí están los diez errores más comunes que los diseñadores pueden evitar.
Sólo el 3% de las aplicaciones móviles se mantienen en uso después de ser descargadas.
Sólo el 3% de las aplicaciones móviles se mantienen en uso después de ser descargadas.

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

A menudo, el primer uso, o el primer día con una aplicación, es el período más crítico para atraer a un potencial usuario. La primera impresión es tan crítica que podría ser un punto de partida para el resto de éste top 10. Si algo no está bien, o parece confuso o aburrido, los usuarios potenciales pierden interés rápidamente; aunque, el equilibrio apropiado para la primera impresión es difícil de lograr. En algunos casos, un largo proceso de integración (onboarding), o un proceso para descubrir características necesarias pueden aburrir a los usuarios.
Sin embargo, una aplicación que sea tentadora instantáneamente puede pasar por alto la necesidad de un tutorial adecuado, y promover la confusión. Se debe encontrar el equilibrio entre una aplicación que es inmediatamente intuitiva, y que también introduzca a los usuarios a las características más divertidas y atractivas con rapidez. Ten en cuenta que cuando los usuarios llegan a tu aplicación, la están viendo por primera vez. Es importante tener un proceso de prueba adecuado para determinar cómo los demás perciben tu aplicación desde el principio. Lo que parece obvio para el equipo de diseño, puede que no lo sea para los recién llegados.

Integración Inadecuada

La integración o incorporación es el proceso paso a paso de la introducción de un usuario a tu aplicación. Aunque puede ser una buena manera de orientar a alguien de forma rápida, la integración también puede ser un proceso prolongado que se interpone en el camino de tus usuarios y su contenido. A menudo, estos tutoriales son demasiado largos, y es probable que los lean por encima.
A veces, los usuarios han visto que tu aplicación es utilizada en público o en algún otro lugar, de tal manera que llegan a entenderla de una vez y quieren usarla a la primera. Por lo tanto, permite una especie de estrategia de salida rápida para evitar por completo el bloqueo de la aplicación a partir de su primer uso. Para asegurarte que el proceso de incorporación es de hecho efectivo, debes tener en cuenta qué valores esto puede comunicar y cómo hacerlo. El proceso de integración debe demostrar el valor de la aplicación con el fin de enganchar un usuario, en lugar de sólo una explicación.

No Sobrecargues la Animación en el Inicio

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

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

Evita entrar en el proceso de diseño sin intenciones concisas. Las aplicaciones son a menudo diseñadas y desarrolladas con el fin de seguir las tendencias, en lugar de resolver un problema, llenar un nicho, u ofrecer un servicio distintivo. ¿Cuál es la ambición de la aplicación? Para el diseñador y su equipo, el sentido de propósito afectará cada paso de un proyecto. Esta sensibilidad guiará cada decisión de la marca o la comercialización de una aplicación, con el formato de wireframe, y un botón estético. Si el propósito es claro, cada pieza de la aplicación comunicará y funcionará como un todo coherente. Por lo tanto, asegúrate de que el equipo de diseño y desarrollo considere continuamente sus decisiones dentro de un objetivo mayor. A medida que avanza el proyecto, la ambición inicial puede cambiar. Esto está bien, siempre y cuando la visión siga siendo coherente.
Transmitir esta visión a tus usuarios potenciales significa que van a entender qué valor traerá la aplicación a sus vidas. Por lo tanto, esta visión es algo importante que se debe transmitir en la primera impresión. La pregunta es, ¿qué tan rápido puedes convencer a los usuarios de tu visión para la aplicación? Cómo se va a mejorar la vida de una persona, o proporcionar algún tipo de goce o comodidad. Si esta ambición es difundida eficazmente, entonces, siempre y cuando tu aplicación sea en realidad útil, llegará al 3%.
A menudo, unirse a un mercado pre-existente, o una aplicación del nicho de mercado, significa que hay aplicaciones que estudiar, mientras diseñas tu propia aplicación. Por lo tanto, ten cuidado de cómo eliges ‘dar nuevo propósito’ a lo que ya está en el mercado. Estudia el mercado de las aplicaciones existentes en lugar de solo revisar. Entonces, mejora a partir de productos existentes, en lugar de imitar sin pensar.

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

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

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

Tan pronto como se dibuja la base de la aplicación, es un buen momento para obtener un presupuesto del equipo de desarrollo. De esta manera no se llega al final del proyecto y de repente se necesita empezar a eliminar características críticas. A medida que desarrollas tu carrera de diseño, siempre toma nota de los costos regulares de construcción de tus conceptos para que tu pensamiento de diseño corresponda con restricciones económicas. Los presupuestos deben ser las restricciones de diseño útiles dentro de las cuales se puede trabajar.
Muchas aplicaciones fallidas tratan de cargar demasiadas funciones desde su lanzamiento.
Muchas aplicaciones fallidas tratan de cargar demasiadas funciones desde su lanzamiento.
Like what you're reading?
Get the latest updates first.
No spam. Just great engineering and design posts.

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

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

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

Aunque las condiciones de la mayoría de las oficinas de diseño prácticamente operan en un vacío, los diseñadores de aplicaciones deben estar al tanto de contextos más amplios. Aunque el propósito y la ambición son importantes, se vuelven irrelevantes si no se dirigen en el contexto adecuado. Recuerda que aunque tú y tu equipo de diseño conocen la aplicación muy bien, y les parezca evidente la interfaz del usuario, esto puede no ser el caso para los nuevos usuarios, o diferentes grupos demográficos.
Ten en cuenta el contexto inmediato o situación en la que se pretende utilizar la aplicación. Teniendo en cuenta la situación social, ¿cuánto tiempo puede la persona considerar utilizar la aplicación? ¿Qué otra cosa podría ser útil para ellos encontrar dada la circunstancia? Por ejemplo, la interfaz UBER sobresale ya que se utiliza con mucha rapidez. Esto significa que en su mayor parte, no hay mucho espacio para otro tipo de contenido. Esto es perfecto porque cuando un usuario está fuera con sus amigos y necesita reservar un viaje, su conversación es poco interrumpida en el proceso. UBER esconde una gran cantidad de contenido de soporte dentro de la aplicación, pero sólo aparece una vez que el escenario lo requiere.
¿Quién es el público objetivo de la aplicación? ¿Cómo podría el tipo de usuario influir cómo es el diseño de la aplicación? Tal vez, debes considerar que una aplicación específica para un usuario más joven puede ser capaz de tomar más libertades asumiendo un cierto nivel de intuición por parte del usuario. Considerando que muchas funciones pueden necesitar ser señaladas específicamente para un usuario menos conocedor de la tecnología. ¿Tu aplicación está destinada a ser visitada de forma rápida y por un corto período de tiempo? O, ¿es una aplicación con una gran cantidad de contenido que permite a los usuarios quedarse en ella un tiempo? ¿Cómo será el diseño para transmitir este tipo de uso?
Un buen diseño de aplicación debe considerar el contexto en el que se utiliza.
Un buen diseño de aplicación debe considerar el contexto en el que se utiliza.

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

A menudo, las aplicaciones se desarrollan rápidamente como respuesta a los cambios del mercado o competidores que avanzan. Esto suele resultar en contenido web siendo arrastrado a la plataforma móvil. Un tema constante, lo que se podría pensar sería ampliamente entendido ahora, sucede tan a menudo que las aplicaciones y otros contenidos para móviles hacen transiciones pobres entre el escritorio, o plataformas móviles. Ya no es posible que el diseño móvil haga reducción gradual de contenido web sin consecuencias con la esperanza de conseguir rápido un negocio en el mercado móvil. La transición de web a móvil no sólo significa reducir todo, sino también ser capaz de trabajar con menos. Las funciones, navegación y el contenido deben ser transportados con mínima estrategia.
Otro problema común aparece cuando un equipo de desarrollo de aplicación aspira a lanzar un producto al mismo tiempo en todas las plataformas, y través de diferentes tiendas de aplicaciones. Esto a menudo resulta en una compatibilidad pobre, o en general, una aplicación con errores y sin pulir. La gimnasia que implica un equilibrio de múltiples plataformas puede ser demasiado para sumarse al lanzamiento de una aplicación. Sin embargo, a veces no hace daño llevarlo lentamente con un sistema operativo a la vez y corregir los problemas principales, antes de preocuparse por la compatibilidad entre plataformas.

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

El famoso arquitecto Mies Van der Rohe dijo una vez: “Es mejor ser bueno que ser único”. Asegúrate de que tu diseño esté cumpliendo con lo acordado antes de empezar a romper la caja o agregar adornos. Cuando un diseñador se encuentra a sí mismo añadiendo detalles a fin de hacer una composición más atractiva o emocionante, estas opciones, es probable, que carezcan de mucho valor. Seguir preguntando a lo largo del proceso de diseño, ¿cuánto puedo quitar? En lugar de diseñar de forma aditiva, diseña de forma reductora. ¿Qué no se necesita? Este método está dirigido tanto hacia el contenido, el concepto y la función, como a la estética.
La complejidad excesiva es a menudo el resultado de un diseño que innecesariamente rompe convenciones. Varios símbolos e interfaces son estándar dentro de nuestro lenguaje visual y táctil. ¿Tu producto realmente podrá beneficiarse de la reelaboración de estos estándares? Iconos Estándar han demostrado ser universalmente intuitivos. Por lo tanto, a menudo son la forma más rápida de proporcionar indicaciones visuales sin llenar innecesariamente una pantalla. No dejes que tus detalles de diseño interrumpan el contenido real ni el funcionamiento de la aplicación. A menudo, a las aplicaciones no se les da suficiente espacio en blanco. La necesidad de espacio en blanco es un concepto gráfico que ha trascendido tanto lo digital como lo impreso, por lo que no debe subestimarse. Mantén un espacio entre los elementos en la pantalla, de modo que todo el trabajo que pusiste en la navegación y UX se pueda sentir.
El proceso de diseño de aplicaciones puede ser reductor, en lugar de aditivo
El proceso de diseño de aplicaciones puede ser reductor, en lugar de aditivo

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

En cuanto a la simplicidad, si un diseño va a introducir nuevos estándares, deben ser por lo menos equilibrados en toda la aplicación. Cada nueva función o parte del contenido no necesariamente tiene que ser una oportunidad para introducir un nuevo concepto de diseño. ¿Los textos están formateados de manera uniforme? ¿Los elementos de la interfaz se comportan de manera predecible, pero agradable a lo largo de la aplicación?
La coherencia del diseño debe encontrar el equilibrio entre la existente dentro del lenguaje visual común, así como evitar estar estéticamente estancada. El equilibrio entre la consistencia intuitiva y el aburrimiento es una línea muy fina.

Error Común # 10: Desaprovechar App Beta Testings

Todos los diseñadores deben analizar el uso de sus aplicaciones con algún tipo de ciclo de retroalimentación con el fin de aprender lo que está y no está funcionando. Un error común en las pruebas es que un equipo haga sus pruebas beta con sus propios miembros. Es necesario traer ojos frescos con el fin de excavar realmente en los borradores de la aplicación.
Envía un anuncio buscando probadores beta y trabaja con un grupo selecto antes de anunciarlo al público. Esto puede ser una gran manera de limar detalles, editar características, y encontrar lo que falta. A pesar de que las pruebas beta pueden llevar mucho tiempo, puede ser una mejor alternativa que desarrollar una aplicación que fracase. Anticipa que las pruebas a menudo toman 8 semanas para algunos desarrolladores para poder hacerlo correctamente. Evita el uso de amigos o compañeros de trabajo como probadores, ya que no pueden criticar la aplicación con la honestidad que necesitas. El uso de los blogs de aplicación o páginas web para revisar tu aplicación es otra manera de probar la aplicación en un lugar público sin un lanzamiento completo. Si estás teniendo dificultades al disminuir características para tu aplicación, esta es una buena oportunidad para ver qué elementos importan o no.
El mercado de diseño de aplicaciones es un campo de batalla, por lo que el diseño de productos que son sólo adecuados simplemente no es suficiente. Encuentra una manera de conectar a los usuarios desde el principio - comunicar y demostrar los valores críticos y características tan pronto como sea posible. Para poder hacer esto, el equipo de diseño debe tener una visión coherente de lo que la aplicación desea lograr. Para establecer esta ambición, un proceso de story-boarding riguroso puede limar lo que es y no es imprescindible. Considera qué tipos de usuarios encajarían mejor con la aplicación. Y luego, refina y perfecciona hasta que absolutamente nada más puede ser eliminado del proyecto sin que éste se caiga a pedazos.

miércoles, 9 de noviembre de 2016

Publicación

La nueva ola del emprendedorismo


La economía del siglo XXI, con un coste de varios billones de dólares, ha permitido que la tecnología tenga una mayor apertura. Esta ha sido impulsada por tendencias que han cambiado la naturaleza de los empresarios; especialmente, cómo estos serán caracterizados en un futuro. Asimismo, serán los ejecutivos industriales con potencial en el ámbito tecnológico, los más demandados por startups emergentes.
En el 2007, Apple reformó completamente la industria tecnológica con el lanzamiento del iPhone. Es difícil imaginar que tan sólo han pasado ocho años desde el lanzamiento del primer smartphone mejor vendido, sin embargo, no se puede negar su impacto en todo el mundo. Más allá de la creación de una nueva dimensión científica, surgió un fenómeno mundial que cambió tanto el destino de los teléfonos móviles como el de la industria tecnológica. Mediante la creación de tecnología intuitiva para las masas, los consumidores empezaron a verla como algo más que una simple herramienta laboral. Economistas, abogados, médicos,ingenieros y personas de todos los sectores económicos no sólo tenían una herramienta para la productividad, sino una indispensable pieza tecnológica que adoptaron como algo indispensable en sus vidas.
Por eso mismo, estos consumidores pueden ahora apuntar hacia ahora hacia un nuevo estándar de ciencia utilizable. Hay que recordar que la tecnología es un fenómeno cambiante que necesita de constante renovación. El software legal engorroso que no permita al abogado buscar casos fuera de la oficina ya no es aceptable. Para aquellos fuera del silo de Silicon Valley, entre las conversaciones que se pueden escuchar durante el almuerzo, un trabajador podrá decir: “¿No sería bueno si hubiera una aplicación para… ?”. Por desgracia, estas conversaciones ocurren a menudo demasiado lejos de los oídos de Silicon Valley; que todavía está dominada por la charla de lo que será el próximo WhatsApp o Instagram. Aun así, un nuevo tipo de empresario está emergiendo y reaccionando a los retos que desafían a su sector. No obstante, a pesar de que estos empresarios cuenten con bastante iniciativa y con oportunidades de hacer un impacto para cambiar el mundo, muchas veces, estos ejecutivos no encajan dentro del arquetipo fundador que muchos inversores de Silicon Valley buscan.
Décadas anteriores vieron cambios similares en las caracterizaciones del empresario. Durante los años 90, cobra auge el MBA de Harvard el cual aplica técnicas de gestión tradicionales para aprovechar las tecnologías novedosas de internet. Por otra parte, la primera década del siglo XXI trajo consigo la “Ciencia de la Computación de Stanford de 22 años” la cual aplicó tecnología a una industria inestable. Ahora, en esta década, estamos respondiendo a una nueva ola de la iniciativa empresarial compuesta por ejecutivos de la industria de la ciencia, con la intención de impulsar la tecnología aún más y deshacerse de cualquier industria no tecnológica.
Durante los últimos 2 años he tenido la oportunidad de ver de primera mano este cambio como el socio gerente de Silicon Valley Software Group (SVSG), una firma de directores enfocada en ayudar a las empresas con su estrategia de tecnología. SVSG ha visto empresarios que van desde productores de cine y vocalistas de las bandas de rock más famosas, hasta ejecutivos de viajes y gerentes de fondos; todos tratando de mejorar en su área a través del uso de la tecnología. Después de una serie de compromisos similares, surgieron algunas observaciones:
En cada compañía, los empresarios miran como la adopción de la tecnología crea nuevas oportunidades. Por consiguiente, los ejecutivos se concentran en un producto en específico el cual surja de esta apertura científica. Sin embargo, he podido notar que estos empresarios no tenían mayor experiencia con la tecnología. Es más, la mayoría de estos empresarios no tenían conexiones pertinentes con la comunidad de Silicon Valley. Y fue entrar a este círculo lo cual les permitió darse cuenta de las oportunidades que la ciencia de la tecnología presenta.
La combinación de capital de crecimiento, el talento multidisciplinar y mentores que fomentan mejores prácticas en base a cómo crear un hiper-crecimiento, es comúnmente dado por sentado por empresarios que forman parte del ecosistema. Sin embargo, la desconexión entre los que forman parte de Silicon Valley y los que se encuentran afuera es impactante. Muchas de las empresas que SVSG ha encontrado no tienen la capacidad de reunir capital estratégico en un primer inicio debido a que sus negocios son demasiado arriesgados en cuanto a ciertos errores comunes que las compañías de Silicon Valley no cometen. Por esto mismo, conceptos tan simples como la metodología de lean startup son bienvenidos para impulsar a estos empresarios no nativos de Silicon Valley.
Estos nuevos fundadores tienen ahora como misión crear un vínculo más fuerte con Silicon Valley. Hasta la fecha, esto se ha visto obstaculizado debido de la mentalidad estrecha de esta región. Sin embargo, las fuerzas del capitalismo se impondrán y estos nuevos empresarios encontrarán su propia comunidad para colocarse alrededor. Los inversores de Keen guiarán a la manada y aprovecharán los mercados existentes para generar el cambio. Incubadoras y aceleradores surgirán con enfoque en los empresarios con experiencia en la industria tecnológica. Nos encontramos en un boom de tecnología el cual ha permitido la apertura de un sinnúmero de maneras de aplicar esta a industrias las cuales no han demostrado ningún cambio en las últimas décadas. Para los que están sentados en la oficina de la esquina, ha llegado el momento de salir porque hay mercados para interrumpir.

Publicacion

¿Por que hay tantos Pythons?

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:
  1. CPython compila tu código Python a bytecode
  2. 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:
  1. Identificar bytecode que es ejecutado frecuentemente.
  2. Compilar a código binario.
  3. Almacenar el resultado en memoria caché.
  4. 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.
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:
  1. 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.
  2. 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 cualquierlenguaje, 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:
  1. Correr el interpretador e interpretar todo (sin agregar nada de JIT)
  2. Perfilar levemente el código interpretado.
  3. Identificar operaciones que hayas realizado antes.
  4. 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:

Apéndice: Otros nombres que tal vez hayas oído

  • Python 3000 (Py3k): nombre alternativo para Python 3.0, un mayor, compatible-con-versiones-anterioreslanzamiento 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.

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