Lanzamiento mundial de windows vista

Pues bien, el día de hoy fué el lanzamiento mundial de windows vista, para quien lo ama y para quien lo odia nimodo, aquí unos links interesantes.

Windows Vista a Fondo
Un post que realiza un análisis de qué es Windows Vista con un poco de historia y todas sus nuevas versiones

Windows XP contra Windows Vista: Comparación de Rendimiento
En ésta pagina se realizaron una serie de pruebas de rendimiento entre ambos sistemas operativos con una serie de aplicaciones y juegos, con interesantes resultados.

Sistema de Protección de Contenidos de Windows Vista
Enlaces sobre la protección de reproducción de multimedia pirata, explica como y por qué de la protección de contenidos.

Video de Windows Vista para quien no lo ha visto


Video de Mac OSX para quien no lo conoce


Video de Linux KDE



jajjajaaj este video me encantó deberas

Sistema de Protección de Contenidos de Windows Vista

Además de otros temas que ya todos conocemos como la exagerada utilización de recursos de Windows Vista, el problema de compatibilidad con muchas aplicaciones, etc. hay otro tema del que se ha hablado poco, ya que el que no este de acuerdo es porque gusta de hacer copias de contenidos, pero en resumen....windows vista no permitira copiar, reproducir, ni almacenar ningun tipo de información con derechos de autor, como musica, videos, etc.

articulo completo
A Cost Analysis of Windows Vista Content Protection

Padre Rico Padre Pobre video

Un libro muy bonito, aqui va un video sobre el mismo, para quien no lo ha leído y por supuesto un refresco de memoria para que aquel que yá lo conoce.

fuente aqui

programadores según el cine

Por qué en peliculas como matrix, los codigos son innumerables simbolos verdes sobre un fondo negro? o por qué en swordfish y otros tantos se representa la intrusión en sistemas como un juego de counter strike?

acaso no la computación y la programación es completamente diferente a lo que el cine dice?

por qué en el cine creen que los codigos fuentes se mueven?

post interesante
What code DOESN'T no in real life

Anecdota

Un consejo (aprendido para variar despues del golpe), cuando andes de visita en un pais del que no conoces siquiera el nombre de las calles mas importantes, asegurate de recordar al menos el nombre de tu hotel.......sino te costara mucho........muchisimo regresar :(

Análisis Estático de Código

En Sistemas donde es muy importante la fiabilidad, o en aquellos donde se necesite el cumplimiento de estándares de calidad, o bien para analizar codigo fuente no documentado o mal finalizado se precisa la utilización de herramientas de análisis de código. Éstas permiten la verificación y corrección del código. Una metodología indispensable para desenmarañar código antiguo.


enlace aqui

Convertir una IP dinámica en una IP fija con DynDNS (actualizado)

Este resumen no está disponible. Haz clic aquí para ver la publicación.

Mensaje

Ésta imagen ya la habia colocado antes, pero me gusta mucho :)

mensaje original aqui

Desarrollo Agil

Desarrollo ágil es una filosofía, no una metodología

El desarrollo ágil no es una metodología con pasos establecidos, es simplemente una manera de pensar y de trabajar.



El desarrollo ágil se puede resumir en una frase “ejecuta rápidamente”. La rapidez no es un método infalible a aplicar a rajatabla, es una manera de enfocar las tareas enfocada a dar prioridad a la ejecución sobre la planificación.

Planificas o actúas

El tiempo no es infinito. No puedes hacer todo al mismo tiempo, optar por una opción o la otra conlleva muchas cosas. Claro, puedes hacer ambas cosas, pero entonces harás ambas a medias.



Especular o probar en real




¿Funcionará una web que busca en 23 webs de vuelos simultáneamente como Trabber? A priori la idea tiene sentido, pero quién sabe si funcionaría, si captaría tráfico, si generaría fidelidad... A posteriori se ha visto que sí, que funciona, pero a posteriori todo parece siempre evidente. La única manera de saberlo ha sido desarrollar el proyecto.



En un entorno donde las innovaciones envejecen en apenas meses, donde todo evoluciona a la velocidad de la luz, no está siempre clara la utilidad de dedicar excesivamente tiempo a investigar que puede funcionará y qué no, o a planificar al detalle. Es divertido especular con ideas en el aire, pero no se obtiene nada en concreto.

Investigar e innovar

Innovar también es investigar



Innovación significa crear algo que no existía antes, ejecutar para obtener algo físico. Investigar es averiguar información útil para el proyecto, crear algo intangible, conocimiento.



La ventaja de innovar sobre investigar, es que a la vez que obtienes algo físico funcionando, también puedes averiguar información útil para el proyecto, en muchos casos una información mucho más fiable que te proporciona la pura investigación. En conclusión, innovando también investigas.




Tras investigar y planificar puedes tardar 8 meses en tener la primera beta impoluta para lanzarla a público o tardar 1 mes con algo hecho rápidamente sin refinar. En la segunda opción 7 meses más tarde puedes tener cientos o miles de usuarios, una versión refinada y mucha más información real, no especulaciones. En la primera opción nada te garantizaría que la beta impoluta no sea después un fiasco.



Internet facilita innovar y hacer experimentos con usuarios reales, basta con públicar la web y tener un poco de tráfico.

Reacción rápida

Rectificar puede ser percibido negativamente, significa que has cometido un error o lo puedes percibirlo positivamente como que has aprendido y eres capaz de reaccionar rápidamente para arreglarlo.



Cuanto más rápidamente ejecutes, antes descubrirás qué es bueno, qué es malo, qué es suficientemente bueno y podrás hacer mejoras. Rectificar no es fácil, conlleva ser humilde y modesto.



Cuando el área del proyecto está muy trillada y se conoce bastante sobre lo que funciona, si puede tener sentido investigar y planificar para mejorar lo que ya existe. La filosofía de desarrollo ágil funciona mejor cuando se trata de hacer algo desde 0 o rediseñarlo totalmente, por el contrario es menos recomendable cuando quieres mejorar algo que ya sabes que funciona.

Ideas sobre desarrollo ágil

Lo mejor es enemigo de lo bueno



¿Cuando tienes algo suficientemente bueno para sacar a público? En cuanto funcione de manera técnicamente aceptable.



Lo mejor es enemigo de lo bueno, pero lo mejor aún es peor enemigo cuando ni siquiera sabes qué es. No dudes, sácalo a real y verás si funciona o no.



Resuelve los problemas cuando los tengas



No tiene sentido preocuparse de problemas de escalabilidad en el futuro al principio de un proyecto, deberías preocuparte de las cosas más urgentes en ese momento. Además de quitarte tiempo muy valioso, seguramente las soluciones a las que llegues distarán de ser óptimas. Por ejemplo, hasta que no sepas exactamente que problemas de escalabilidad vas a tener no sabrás cuál será la mejor opción.




Lo mismo pasa con los temas legales. Si no hay ingresos, ni pagos, ni información personal muy delicada almacenada no creo que valga la pena que te quiten el sueño. La última cosa de la que me preocuparía sería de como declarar una pequeña cantidad de ingresos de Adsense.



Los grandes planes nunca funcionan



No es una ley de Murphy, pero como si lo fuera. Planificar excesivamente aleja de la realidad, es muy fácil escribir en un papel ideas, pero muy difícil ejecutarlas. Conforme una planificación se complica es más probable que no funcione como se espere.



Es positivo tener unas ideas básicas y generar algunos documentos concisos, pero hay que evitar la complicación excesiva. Jesús Encinar cuenta como redujeron el plan de negocio de Idealista de 150 páginas a solo 7.



Logs y estadísticas de servidor




Para saber qué funciona y qué no funciona de los cambios realizados, tu gran aliado serán las estadísticas. Son la manera más rápida, ágil y barata de obtener información fiable del mundo real.



No se trata de manejar mil datos estadísticos, sino centrarte en los realmente relevantes y sensibles a los cambios. Los test de usuarios de guerrilla son útiles especialmente cuando tienes dudas o hay grandes cambios.



No es algo nuevo



La filosofía de desarrollo ágil no es nueva en absoluto. Cualquiera que comienza un proyecto puede optar por planificar bien o actuar rápido, ya sea construyendo un puente o diseñando una web. Simplemente en algunos proyectos puede ser más adecuado hacerlo que en otros.



No es recomendable arriesgarse a tener accidentes construyendo un puente, todo tiene que estar bien planificado y aguantar mucho más de lo necesario. Sin embargo una web inicialmente no la creas para resistir mucho más tráfico del necesario y si un día cae un par de horas se puede resolver fácilmente.



Es un medio, no un fin




La metodología de desarrollo web ágil, como cualquier otra metodología es un medio, no un fin. No se trata de aplicarla a rajatabla, sino cuando nos ayude a conseguir nuestro objetivo. Nadie debería seguir esta filosofía en su proyecto porque lo ha leído este artículo, ni en ningún otro, sino porque es lo más adecuado para su proyecto en ese momento y en esas condiciones.



Hay servicios que deben funcionar perfectamente desde el primer día porque por su propia naturaleza solo aportan si funcionan bien, no se les daría una segunda oportunidad, para esto no vale el desarrollo ágil. Si desarrollas un servicio de pago tampoco te recomiendo experimentar demasiado con desarrollo ágil.



Sin marketing masivo



Hacer cambios de manera rápida no significa forzosamente la presencia de bugs, pero ciertamente con desarrollo ágil puede ser más proclives a tenerlos. Además puede que el aspecto del sitio no sea muy refinado cuando lo sacas a público tras un mes de desarrollo.



Por estas razones no es bueno aparecer en grandes medios porque entonces como comentaba Joel on Software en Massive Frontal PR is incompatible with Ship Early and Often” tendrías dos problemas a) un proyecto inacabado b) todo el mundo lo sabría.




Para un proyecto que utiliza desarrollo ágil es mejor el marketing de guerrilla, de blogs, el boca-oreja y en general cualquier técnica enfocada a un público más pequeño y limitado. Este público especialmente interesado en la idea es más comprensivo y da mucho feedback, sugiere, comenta, etc.



Motivación y abandono



El desarrollo ágil disminuye la probabilidad de abandono del proyecto porque lo hace más motivador.



Cualquier proyecto desde 0 requiere un volumen de motivación impresionante, no es extraño que un proyecto se abandone sin ser completado, lo que sucede mucho más frecuentemente en proyectos que tardan muchos meses en salir a público.



Un desarrollo ágil tiene una primera versión mucho antes con lo que minimiza el riesgo de abandono previo. Luego al no parar de sacar cambios y recibir feedback de los usuarios se obtiene más motivación positiva y se reduce la probabilidad de que sea abandonado.



Con pocos recursos es más fácil




Cuanto menos tengas, menos tienes que perder. Si no tienes inversión más que tu tiempo, eso será lo único que perderás si te arriesgas. Si te alguien te paga mucho dinero o invierte en tu proyecto, te dará más miedo arriesgarte a experimentar y probar cosas nuevas.



La conclusión es sencilla, aunque paradójica, tu escasez de recursos te abre la puerta de grandes oportunidades. Para llegar a innovar radicalmente hay que experimentar y probar haciendo cosas que grandes empresas ni podrían, ni se atreverían a hacer.



Utilizando desarrollo web ágil un equipo pequeño y sin recursos convierte sus debilidades en ventajas. Hay que evitar entrar a competir con las grandes con sus mismas armas y sus mismas metodologías de trabajo, es muy complicado tener opciones entrando en su terreno.



Equipo inicial minúsculo



No hablo de un equipo pequeño de 5 o 6, me refiero a un equipo minúsculo de 2 o 3 personas inicialmente.



Si hay mucha gente tardas demasiado en ponerte de acuerdo y sobre todo es complicado que nadie se moleste cuando parece que das “bandazos” con tanto experimento y cambio de opinión. A menos gente más agilidad de implementar y menos discusiones.




Lo que no recomiendo en absoluto para un proyecto así es depender de patas físicas, de acuerdos con terceros, de demasiada gente, etc. es complicado utilizar desarrollo ágil en esas circunstancias.



¿Es serio un proyecto llevado así?



Sucede que algunas personas no toman en serio un proyecto que cambia cada dos por tres, donde algunas cosas no son tan estables como debieran y que no tiene inicialmente un nivel de refinamiento muy alto. Se puede llegar a pensar que es un proyecto de “amiguetes”, algo poco serio, un juego.



En realidad nada tiene que ver una cosa con la otra. Cualquier experimento tiene mucho de juego, de descubrir que funciona y que no funciona, de ser como un niño curioso que prueba y prueba.



En realidad es positivo que sea divertido y que el ambiente sea relajado porque es solo es posible tener ideas nuevas y atreverse a implementarlas rápidamente en un ambiente flexible y donde se acepte la alta incertidumbre como normal, justamente lo que no sucede en un ambiente de trabajo clásico. Creo que no sería positivo para un proyecto desarrollado de manera ágil el parecer “serio”. Las camisetas y la ausencia de trajes no son casualidad o una moda en este ambiente.



El desarrollo ágil no es para siempre




El desarrollo ágil es especialmente útil al principio del proyecto, cuando hay que crear algo de la nada y aprender lo antes posible.



Más tarde, al cabo de un año o dos, cuando ya empiezas a tener claro lo que funciona y lo que no, la filosofía forzosamente cambia. Empieza a haber más gente en el equipo, se empieza a discutir más y se hace menos. Es normal e inevitable, no es lo mismo jugarte perder usuarios cuando empiezas y solo tienes un par de miles que más tarde cuando tienes un par de cientos de miles.



Cuando tienes muchos usuarios además se complican los cambios, la gente se acostumbra a las cosas y prefieren estabilidad, no les gustan los cambios, aunque realmente sean positivos para ellos.

Una filosofía de trabajo que no es para todos ni para todo

Tu carácter personal es importante



Para aplicar desarrollo ágil debes tolerar niveles altos de incertidumbre e incluso de caos en ocasiones. No te debe poner excesivamente nervioso no saber qué va a pasar en el futuro. Es una filosofía que funciona bien con personas que necesitan respuestas rápidas, hacer algo y ver los cambios, que no les gusta esperar.




Si tu estilo de trabajo es muy organizado y planificado, te incomoda la incertidumbre, pero por el contrario eres capaz de mantener alta tu motivación en un largo proyecto donde los resultados no se visualizan hasta meses más tarde, seguramente esta filosofía de trabajo no es para ti.



Cuando tienes ideas muy claras, te entusiasman ciertos autores y te encantan las metodologías, seguramente encajarás muy bien en otros proyectos, pero no en uno de desarrollo web ágil. Al contrario, la gente más óptima para desarrollo ágil, es la que peor encaja en grandes organizaciones con muchas jerarquías y procesos. No opino que un perfil sea mejor que otro, simplemente son diferentes para casos diferentes.

El caso de Panoramio

El caso de Panoramio es bastante claro de las ventajas que tiene aplicar metodología de desarrollo ágil.



Comenzó con un equipo de solo 2 personas, que ahora es de 3 personas con la reciente incorporación de José Florido. Más sería una multitud en un proyecto así.




Los cambios y rediseños han sido constantes en Panoramio, por ejemplo, hemos cambiado 3 veces radicalmente de homepage en un año, el último hace 4 días escasos.



En un tema como las mash-ups que usan el API de Google Maps no hay estándares porque están siendo inventadas ya mismo. No se sabe lo que funciona y lo que no, no hay referencias. En nuestro caso no hay más de 5 webs que posicionen fotos en mapas. Supongo que esto habrá facilitado que Google Earth recomiende Panoramio en su página de descarga, nos esté ayudando con el hosting y nos invitase al Googleplex.



Ningún método de investigación te dirá si una idea como la de Panoramio funcionará, es demasiado nueva, es más rápido obtener información de la gente que utiliza la web realmente.




Por la evolución del proyecto y su rápida salida a público en etapas muy iniciales, quizás algunas personas han tomado poco en serio el proyecto como de “amiguetes” o como un juego. Ciertamente lo pasamos bien, es divertido, pero eso no quita que trabajemos en Panoramio más horas que tiene el día y que nuestro nivel de implicación sea muy alto.



Panoramio salió sin modelo de negocio claro lo que puede parecer inadecuado. Por supuesto nosotros pensamos que lo ideal es tener un modelo de negocio claro desde el principio, pero siendo un equipo inicialmente de dos personas, o te centras en crear un proyecto útil y que funcione, o te centras en crear un modelo de negocio, no puedes estar en todo. Si creas algo útil seguro que luego hay una manera de rentabilizarlo. Actualmente con la publicidad Adsense el sitio cubre costes y da beneficios, lo que no es banal en un sitio que hospeda fotos.



Si hubiéramos utilizado el método clásico de desarrollo hubiéramos tardado 6 meses como mínimo en salir a público. Sin embargo en ese tiempo ya teníamos 15.000 fotos y muchos miles de usuarios probando algo en real y dándonos información. El número de fotos actual es cercano a las 60.000.



La ventaja de haber salido a público tras solo dos meses de desarrollo no es solamente que a día de hoy tenemos mucho más tráfico, miles de fotos y de usuarios que si lo hubieramos hecho más tarde. La gran ventaja es que además de eso hemos aprendido mucho, un año es un mundo en estas áreas y este aprendizaje nos permitirá hacer grandes mejoras en un futuro próximo que de otro modo hubieran llegado mucho más tarde.



Respecto al marketing, hasta ahora nos habíamos limitado al marketing de guerrilla, puesto que inicialmente habían muchas cosas que corregir y mejorar, no era conveniente saltar a grandes medios. El boca a boca nos permitió aparecer citados en más de 800 blogs lo que nos trajo muchas personas interesadas y motivadas para dar mucho feedback e información para mejorar el sitio. Ciertamente, aún queda mucho que mejorar, pero ahora el proyecto esta mucho más definido y preparado para salir en grandes medios masivamente, de hecho ayer lo hizo por primera vez (Panoramio en Google News)




A partir de ahora las cosas irán cambiando en Panoramio, pero no tan radicalmente y muchos cambios lo serán en la parte invisible, por ejemplo la velocidad de interacción de las fotos con el mapa. Más allá de preferir unas filosofías de trabajo u otras lo importante es ser flexible y buscar la mejor manera de alcanzar los objetivos buscados.

ver tambien aqui

fuente original aqui

Innovar también es investigar

Innovación significa crear algo que no existía antes, ejecutar para obtener algo físico. Investigar es averiguar información útil para el proyecto, crear algo intangible, conocimiento.

La ventaja de innovar sobre investigar, es que a la vez que obtienes algo físico funcionando, también puedes averiguar información útil para el proyecto, en muchos casos una información mucho más fiable que te proporciona la pura investigación. En conclusión, innovando también investigas.

Tras investigar y planificar puedes tardar 8 meses en tener la primera beta limpia para lanzarla a público o tardar 1 mes con algo hecho rápidamente sin refinar. En la segunda opción 7 meses más tarde puedes tener cientos o miles de usuarios, una versión refinada y mucha más información real, no especulaciones. En la primera opción nada te garantizaría que la beta limpia no sea después un fiasco.

Internet facilita innovar y hacer experimentos con usuarios reales, basta con públicar la web y tener un poco de tráfico.