LinuxParty

El código de JavaScript que se ejecuta en un navegador no necesariamente significa que funcionará en otros. Sin hacer pruebas de unidad en este código, las organizaciones pagan dinero para probar y volver a probar aplicaciones web al decidir actualizar o soportar nuevos navegadores. En este artículo, aprenda cómo las pruebas de unidad eficientes de su JavaScript pueden reducir los costos de pruebas y facilitarle el soporte de más navegadores.

JavaScript es uno de los lenguajes de programación más usados de la actualidad, gracias a este, tenemos acceso a múltiples características que se ofrecen en los sitios web que visitamos regularmente y que hacen nuestra experiencia de navegación mucho más agradable, simple y entretenida.

Los navegadores que usamos a diario llevan integrados sus propios motores JavaScript, con el fin de aprovechar al máximo sus bondades y tratar de ofrecer al usuario, un mayor rendimiento en aplicaciones web que lo implementan de forma exhaustiva.

Resumen: Las mejores aplicaciones Python de fuente abierta tienen un excelente empaquetamiento. Aprenda más sobre lo que es el empaquetamiento y su implementación básica. Luego, vaya un paso más allá y descubra la asignación de versiones y la distribución en cuanto a cómo se relacionan con el empaquetamiento.

El primer plano de un proyecto exitoso de fuente abierta es el empaquetamiento. Un ingrediente clave para el buen empaquetamiento es la asignación de versiones. Como el proyecto es de fuente abierta, usted deseará publicar su paquete para hacer realidad todos los beneficios que ofrece la comunidad de fuente abierta. Las diferentes plataformas y lenguajes tienen diferentes mecanismos para empaquetamiento, pero este artículo se enfoca específicamente en Python y su ecosistema de empaquetamiento. El artículo trata la mecánica de empaquetamiento para darle una base sobre la cual crecer y proporciona suficientes ejemplos gráficos para que usted comience de inmediato.

¿Es posible escribir un programa JavaScript que no tenga más longitud que la de un tweet? un sitio web llamado 140bytes dice que si, que es posible y tiene una implementación del Tetris para probarlo ¡Ok!, sólo tiene dos tipos de bloque -. por lo tanto su título de "Binary Tetris"-. es un tanto ambicioso, no hay rotación, pero funciona! caen los bloques de la pantalla y puede guiarlos, puede probarlo. Puede jugar a la demo. Por supuesto, la verdadera diversión está en averiguar cómo funciona. y hay un montón de ayuda en el sitio - por lo que si estás aburrido ¿qué tal el reto de 140 caracteres "?

En el último podcast de Java Hispano han publicado una entrevista a Jorge Aliss (@jaliss) y Sebastián Scarano (@develsas), dos entusiastas miembros de la comunidad Play y asiduos colaboradores de playlatam.wordpress.com.

Hace apenas tres meses anunciábamos en la lista de discusión en idioma español de Play Framewor, que junto con varios colegas iniciábamos la traducción de la documentación de Play Framework, y al mismo tiempo invitábamos a todos los usuarios de este framework a sumarse a la tarea.

En este momento, los editores de contenidos que desean llegar a los lectores a través de aplicaciones móviles, tienen que contratar a un equipo de ingenieros independientes para construir cada aplicación --uno para iOS (basado en Objective-C), otro para Android (Java), y un tercero para Windows Phone (C#), etc. El Grupo de Plataforma Tecnológica de Yahoo está trabajando en una alternativa: una serie de JavaScripts y HTML basado en herramientas que se ocuparían de núcleo de interfaz de usuario y las tareas de gestión de datos dentro de aplicaciones móviles para cualquier sistema operativo, pasando al nirvana de los desarrolladores de "escribir una vez, ejecuta en todas partes."

Estoy a punto de embarcarme en el desarrollo de contenido activo (bases de datos, y servicios web), por primera vez para mi sitio web y he aprendido a amar PHP. Se que hay otras plataformas de desarrollo web disponibles, y me doy cuenta del cierto desdén para PHP que existe en algunos círculos, tengo curiosidad por saber qué plataformas prefieren los LinuxPartydarios, junto con las razones para usarlas. Antes de empezar en el desarrollo me gustaría obtener algunas opiniones y más hechos. ¿Por qué no puedo usar PHP?

Resumen: La gestión del código fuente para un proyecto de desarrollo de software no es menos importante que la escritura en sí, en primer lugar. UNIX® y Linux® ofrecen una amplia selección de paquetes para los sistemas de control de versiones (VCS), cada uno de ellos tiene un enfoque ligeramente diferente. Este artículo se centra en el sistema de gestión de código fuente Mercurial, más comúnmente conocida como hg. Mercurial ofrece una solución potente, moderna y ligera para el control del código fuente que facilita a los desarrolladores trabajar y depurar sus cambios en un proyecto de software, mientras que el mantenimiento de un repositorio estable, centralizando el código fuente que todos los miembros del proyecto pueden depender.

Gestión de código fuente de UNIX y Linux

La Identificación y el seguimiento de los cambios realizados por varios desarrolladores y su fusión en una sola, la actualización del código hace visible la colaboración entre varios desarrolladores. Los VCS software, también conocida como la Revisión de Sistemas de Control (RCS) o de Gestión de Código Fuente (SCM), permiten a varios usuarios enviar los cambios a los mismos archivos o proyectos sin que uno de ellos sobrescriba accidentalmente los cambios respectivos.

Linux® y UNIX® son ágiles en los VCS, que van desde los dinosaurios, como el RCS y el Concurrent Versions System (CVS) a los sistemas más modernos, como Arch, Bazaar, Git, Subversion y Mercurial. Como Git, Mercurial comenzó su vida como un reemplazo de fuente abierta para un sistema de gestión de fuentes comerciales de código llamado BitKeeper, que fue utilizado para mantener y gestionar el código fuente del kernel de Linux. Desde su creación, Mercurial se ha convertido en un popular sistema de VCS que es utilizado por muchas fuentes abiertas y proyectos comerciales. El uso de Mercurial incluyen proyectos como Mozilla, IcedTea, y el wiki MoinMoin. Ver Recursos para los enlaces a estos y muchos ejemplos más.

Los sistemas VCS generalmente se refieren a cada colección de código fuente que pueden realizar cambios y el seguimiento como un depósito. Cómo los desarrolladores interactúan con un repositorio es la diferencia clave entre los sistemas VCS más tradicionales, como CVS y Subversion, que son los sistemas centralizados de VCS más conocidos, y los sistemas VCS más flexibles, Mercurial y Git, que se conocen como sistemas distribuidos VCS. Los desarrolladores interactuan con los sistemas centralizados de VCS con un modelo cliente/servidor, donde los cambios en la copia local del código fuente sólo pueden ser enviados de nuevo al repositorio central. Con los sistemas distribuidos de VCS utilizan un modelo peer-to-peer, donde cualquier copia de un repositorio central en sí es un repositorio para que los cambios se puedan cometer y de la que se puede compartir con ninguna otra copia. Los sistemas distribuidos de VCS en realidad no tienen la noción de una central, repositorio principal, pero casi siempre se definen en la política para que exista un único repositorio para crear, probar y mantener una versión maestra de su software.

¿Por qué Mercurial?

Mercurial es un sistema distribuido VCS pequeño y potente en el que es fácil de empezar a trabajar con, sin dejar de ofrecer los comandos avanzados que los usuarios de VCS puede ser necesario para su uso. La Naturaleza distribuida de Mercurial hace que sea fácil trabajar en proyectos a nivel local, el seguimiento y la gestión de los cambios a través de locales y compromete a impulsar los cambios en repositorios remotos siempre que sea necesario.

Entre los sistemas VCS modernos y distribuidos, el sistema más cercano a Mercurial VCS es Git. Algunas diferencias entre Mercurial y Git son los siguientes:

• Múltiple, una función de deshacer las operaciones: Mercurial revert , backout y rollback son comandos que hacen fácil volver a las versiones anteriores de archivos de los cambios confirmados. Git proporciona un único integrado comando "revert" con su típicoal rocket-scientist-only syntax.
• Incorporada en el servidor web: Mercurial ofrece un simple, servidor web integrado que hace que sea fácil para albergar un depósito de forma rápida para que otros los puedan sacar. Sacarlos requiere seguridad ignorando o una configuración más compleja que soporta Secure Sockets Layer (SSL).
• Preservación de la historia durante las operaciones de copiar / mover: Los comandos de Mercurial copy y move conservan la información de la historia completa, mientras que Git no conserva la historia en ambos casos.
• Branches (sucursales): Mercurial comparte automáticamente todas las ramas, mientras que Git requiere que cada repositorio creado sus propias oficinas (ya sea la creación de forma local o mediante la asignación a sectores específicos en un repositorio remoto).
• Variables globales y locales: Mercurial soporta variables globales que se comparten entre los repositorios, que hacen más fácil compartir información acerca de puntos específicos en el desarrollo de código sin ramificaciones.
• El soporte nativo en plataformas Windows: Mercurial está escrito en Python, que es compatible con Microsoft® Windows®. Mercurial es por lo tanto disponible como un ejecutable de Windows (ver Recursos ). Git en Windows es más complejo, sus opciones son msysgit, usando git estándar bajo Cygwin, o utilizando un sistema basado en web hosting y repositorio.
• Automatic repository packing (Embalaje depósito automático): Git requiere que usted mismo empaquete y recoja sus depósitos, mientras que Mercurial realiza sus operaciones equivalentes de forma automática. Sin embargo, los repositorios de Mercurial tienden a ser más grandes que los repositorios Git para el mismo código base.