Una explicación sobre la trama de espionaje que ha sacudido la F1 este año y en la que McLaren ha sido multado con 100 millones de dólares y la pérdida de todos sus puntos este año en el mundial de constructores.

La animación está hecha con muñecos de Lego XD

Ver animación

Black Hat SEO son técnicas y métodos que no son “legales” y aunque se obtiene un buen posicionamiento al principio Google puede penalizar la página. Algunas de estas técnicas son:

• Google Attacks
• Cloaking
• Link Baiting
• Texto Oculto
• Uso de “noscript” y “noframes”
• Keyword “Spamming” y alta densidad
• Red propia de enlaces o Páginas Traseras
• Granjas de Enlaces “Link Farms”
• Clonar contenidos
• Intercambio de Enlaces con Portales no Relacionados
• Comprar enlaces

En webstylemallorca.com se explican cada una de estas técnicas.

La siguiente función modifica el contenido de un String buscando una secuencia de caracteres y reemplazándolos por otros:

Se trata de una función muy corta pero que puede ser muy útil. Veamos algún ejemplo de utilización:

Yo tengo este tipo de funciones agrupadas en una misma clase como funciones estáticas. De este modo puedo utilizar estas funciones en todos mis proyectos sin tener que copiar y pegar la función en cada proyecto nuevo. Tan sólo tengo que importar mi clase StringUtils (es el nombre de la clase, no es muy original pero se entiende bien lo que contiene) que tengo guardada en mi librería de clases.

Juas, esto es una crítica constructiva O_o sobre lo que puedes encontrar en cualquier fotolog o página de MySpace:

Visto en soyborracho.com

Bajar películas es robar. Si lo haces te enfrentarás a las consecuencias...

Por cierto, os recomiendo que veáis The IT Crowd, una serie muy geek y muy divertida. Por aquí teneis enlaces para descargarse The IT Crowd.

Hoy 8 de septiembre se celebra el día de Extremadura, la fiesta de mi región ^^

Les invito a que vean el vídeo y conozcan un poco los paisajes y la cultura extremeña

Y ya que estamos de fiesta... ¡ barra libre para tod@s ! :beer:

Vídeo con fotos de Extremadura, de diversos autores. El poema "Aquí no tenemos mieo" es del poeta castuo, Javier Feijóo, de Badajoz y la música del maestro, también pacense, Candido de Quintana, "Tierra de Conquistaores".

La programación extrema o XP es una metodología de desarrollo que se englobaría dentro de las denominadas metodologías ágiles en la que se da máxima prioridad a la obtención de resultados y reduce la burocracia que se produce al utilizar otras 'metodologías pesadas'.

Todo en el software cambia. Los requisitos cambian. El diseño cambia. El negocio cambia. La tecnología cambia. El equipo cambia. Los miembros del equipo cambian. El problema no es el cambio en sí mismo, puesto que sabemos que el cambio va a suceder; el problema es la incapacidad de adaptarnos a dicho cambio cuando éste tiene lugar.

Kent Beck.

El autor de la XP es Kent Beck, entre otros, que con su larga experiencia como programador eligió las mejores características de las metodologías y profundizó en las relaciones de éstas y como se reforzaban unas a otras. Por tanto, la XP no se basa en principios nuevos, sino que todas, o casi todas, sus características ya se conocen dentro de la ingeniería del software, las cuales se complementan para minimizar los típicos problemas que pueden surgir en todo desarrollo de proyectos software.

Objetivos de la programación extrema

El objetivo principal de la XP es la satisfacción del cliente. Se le trata de dar al cliente lo que quiere y cuando quiere. Por tanto, se debe responder rápidamente a las necesidades del cliente, aunque realice cambios en fases avanzadas del proyecto. Como metodología ágil que es, se pueden producir modificaciones de los requisitos del proyecto a lo largo de su desarrollo, sin que esto produzca un buen dolor de cabeza.

Otro de los objetivos es el trabajo en grupo. Tanto los jefes del proyecto, clientes y desarrolladores forman parte del equipo y deben estar involucrados en el desarrollo.

Valores de la programación extrema

Para garantizar el éxito de un proyecto, los autores de XP han considerado como fundamentales cuatro valores:

• Comunicación. Muy importante. La XP ayuda mediante sus prácticas a la comunicación entre los integrantes del grupo de trabajo: jefes de proyecto, clientes y desarrolladores.
• Sencillez. Los programas deben ser los más sencillos posibles y tener la funcionalidad necesaria que se indican en los requisitos. No hay que añadir algo que no se necesite hoy. Si se necesita añadir más funcionalidad mañana pues ya se hará entonces.
• Retroalimentación. Las pruebas que se le realizan al software nos mantiene informados del grado de fiabilidad del sistema.
• Valentía. Asumir retos, ser valientes ante los problemas y afrontarlos. El intentar mejorar algo que ya funciona. Aunque gracias a las pruebas unitarias no existe el riesgo de 'meter la pata'.

Algunas voces, añaden además un quinto valor: la humildad. Con la compartición de código, la refactorización y el trabajo de equipo tan estrecho una buena dosis de humildad siempre es de agradecer.

Prácticas de la programación extrema

12 son las prácticas de la XP:

• El juego de la planificación (the planning game). Es un permanente diálogo entre las partes empresarial (deseable) y técnica (posible).
• Pequeñas entregas (small releases). Cada versión debe de ser tan pequeña como fuera posible, conteniendo los requisitos de negocios más importantes, las versiones tiene que tener sentido como un todo, me explico no puedes implementar media característica y lanzar la versión.
  Es mucho mejor planificar para 1 mes o 2 que para seis meses y un año, las compañías que entregan software muy voluminoso no son capaces de hacerlo con mucha frecuencia.
• Metáfora (metaphor). Una metáfora es una historia que todo el mundo puede contar a cerca de cómo funciona el sistema. Algunas veces podremos encontrar metáforas sencillas “Programa de gestión de compras, ventas, con gestión de cartera y almacén”. Las metáforas ayudan a cualquier persona a entender el objeto del programa.
• Diseño sencillo (simple design). Cuando implementamos nuevas características en nuestros programas nos planteamos la manera de hacerlo lo mas simple posible, después de implementar esta característica, nos preguntamos como hacer el programa mas simple sin perder funcionalidad, este proceso se le denomina recodificar o refactorizar (refactoring). Esto a veces nos puede llevar a hacer mas trabajo del necesario, pero a la vez estaremos preparando nuestro sistema para que en un futuro acepte nuevos cambios y pueda albergar nuevas características. No debemos de recodificar ante especulaciones si no solo cuándo el sistema te lo pida.
• Pruebas (testing). No debe existir ninguna característica en el programa que no haya sido probada, los programadores escriben pruebas para chequear el correcto funcionamiento del programa, los clientes realizan pruebas funcionales. El resultado un programa mas seguro que conforme pasa el tiempo es capaz de aceptar nuevos cambios.
• Refactorización (refactoring). Cuando implementamos nuevas características en nuestros programas nos planteamos la manera de hacerlo lo mas simple posible, después de implementar esta característica, nos preguntamos como hacer el programa mas simple sin perder funcionalidad, este proceso se le denomina recodificar o refactorizar (refactoring). Esto a veces nos puede llevar a hacer mas trabajo del necesario, pero a la vez estaremos preparando nuestro sistema para que en un futuro acepte nuevos cambios y pueda albergar nuevas características. No debemos de recodificar ante especulaciones si no solo cuándo el sistema te lo pida.
• Programación por parejas (pair programming). Todo el código de producción lo escriben dos personas frente al ordenador, con un sólo ratón y un sólo teclado. Cada miembro de la pareja juega su papel: uno codifica en el ordenador y piensa la mejor manera de hacerlo, el otro piensa mas estratégicamente, ¿Va a funcionar?, ¿Puede haber pruebas donde no funcione?, ¿Hay forma de simplificar el sistema global para que el problema desaparezca?
  El emparejamiento es dinámico, puedo estar emparejado por la mañana con una persona y por la tarde con otra, si tienes un trabajo sobre un área que no conoces muy bien puedes emparejarte con otra persona que si conozca ese área. Cualquier miembro del equipo se puede emparejar con cualquiera.
• Propiedad colectiva (collective ownership). Cualquiera que crea que puede aportar valor al código en cualquier parcela puede hacerlo, ningún miembro del equipo es propietario del código. Si alguien quiere hacer cambios en el código puede hacerlo. Si hacemos el código propietario, y necesitamos de su autor para
  que lo cambie entonces estaremos alejándonos cada vez mas de la comprensión del problema, si necesitamos un cambio sobre una parte del código lo hacemos y punto. XP propone un propiedad colectiva sobre el código nadie conoce cada parte igual de bien pero todos conoce algo sobre cada parte, esto nos preparará para la sustitución no traumática de cada miembro del equipo.
• Integración continua (continuos integration). El código se debe integrar como mínimo una vez al día, y realizar las pruebas sobre la totalidad del sistema. Una pareja de programadores se encargara de integrar todo el código en una maquina y realizar todas las pruebas hasta que estas funcionen al 100%.
• 40 horas semanales (40-hour week). Si queremos estar frescos y motivados cada mañana y cansado y satisfecho cada noche. El viernes quiero estar cansado y satisfecho para sentir que tengo dos días para pensar
  en algo distinto y volver el lunes lleno de pasión e ideas. Esto requiere que trabajemos 40 horas a la semana, mucha gente no puede estar más de 35 horas concentrada a la semana, otros pueden llegar hasta 45 pero ninguno puede llegar a 60 horas durante varias semanas y aun seguir fresco, creativo y confiado. Las horas extras son síntoma de serios problemas en el proyecto, la regla de XP dice nunca 2 semanas seguidas realizando horas extras.
• Cliente en casa (on-site costumer). Un cliente real debe sentarse con el equipo de programadores, estar disponible para responder a sus preguntas, resolver discusiones y fijar las prioridades. Lo difícil es que el cliente nos ceda una persona que conozca el negocio para que se integre en el equipo normalmente estos elementos son muy valiosos, pero debemos de hacerles ver que será mejor para su negocio tener un software pronto en funcionamiento, y esto no implica que el cliente no pueda realizar cualquier otro trabajo.
• Estándares de codificación (coding standards). Si los programadores van a estar tocando partes distintas del sistema, intercambiando compañeros, haciendo refactoring, debemos de establecer un estándar de codificación aceptado e implantado por todo el equipo.

Algunas de estas prácticas reciben muchas críticas, sobre todo la programación por parejas. Muchos jefes de proyecto no aceptan que dos desarrolladores tengan un único ordenador, ya que creen que esto minimizará la productividad, sin saber que de este modo puede producirse el mismo código que dos personas trabajando en solitario pero con un código de mayor calidad.

Se dice que si no se realizan estas doce prácticas no se está realizando XP. Yo, a mi modo de verlo, creo que nosotros no tenemos que adaptarnos a ninguna metodología, sino que ellas se tienen que adaptar a nosotros dependiendo del tipo de proyecto que estemos desarrollando.

Bueno, esta ha sido una 'breve' introducción a la programación extrema. Seguro que algunas de las prácticas que se han visto anteriormente la has utilizado. Como dije al principio, la XP es más una filosofía de trabajo que recoge lo mejor de las distintas metodologías y las junta para que se refuercen unas a otras.

En ActionScript 2.0 teníamos la clase Number para manejar números, tanto enteros como reales. Ahora en AS 3 seguimos manteniendo la clase Number pero se han añadido 2 nuevos tipos de datos: int y uint.

Si utilizamos números enteros que se encuentren dentro del rango que tienen estos dos tipos de datos es mejor usarlos al tipo Number ya que es más rápido y eficaz.

Una breve descripción de estos tipos de datos:

• int. Entero con signo de 32 bits.
  • Valor predeterminado: 0.
  • Valor mínimo: -2147483648
    Código
    Actionscript:

    1. trace(int.MIN_VALUE);  // output: -2147483648

  • Valor máximo: 2147483647
    Código
    Actionscript:

    1. trace(int.MAX_VALUE);  // output: 2147483647

• uint. Entero sin signo de 32 bits.
  • Valor predeterminado: 0.
  • Valor mínimo: 0
    Código
    Actionscript:

    1. trace(uint.MIN_VALUE);  // output: 0

  • Valor máximo: 4294967295
    Código
    Actionscript:

    1. trace(uint.MIN_VALUE);  // output: 4294967295

Cuando se declara e inicializa una variable de tipo int o uint se puede hacer de dos formas: con un literal o utilizando el operador new. Las dos líneas siguientes son equivalentes: