Comienzo ésta entrada comentando que no niego la existencia de un Dios, incluso tengo una creencia muy particular que no encaja en ninguna religión que conozco, pero si apoyo la opinión de Stephen Hawking. Mi opinión completa se puede conseguir en: http://bit.ly/bZHNPp

Atentamente:

Ing. Manuel Pérez P.

Saludos, el día de hoy acaba de salir a la luz pública el primer beta de la nueva versión de Ubuntu -Maverick Meerkat- el cual ya comencé la descarga y posteriormente publicaré mi impresión. Mientras tanto pueden revisar más información en el siguiente enlace: http://bit.ly/ckgZd6

Atentamente:

Ing. Manuel Pérez P.

Por fin, gracias a un blog que leí por ahí :) me di cuenta lo que faltaba en mi .emacs para que funcione cedet, ede, semantic y todo eso (que sirve para que te revise si el código está bien en sintaxis, autocompletado, etc)

primero, verificar tener cedet-common instalado... y quizá cedet-contrib

La parte en mi .emacs para que eso funcione la copié textual del blog ya mencionado y funcionó (otro día lo pulo :)

(require 'cedet)
(global-ede-mode 1)

;; smart completion - disabled
(require 'semantic-ia) ;; nil t

;; additional options
(require 'semantic-sb)
(require 'semanticdb)

;; * This turns on which-func support (Plus all other code helpers), remove if not X server
;; (semantic-load-enable-minimum-features)
;;(semantic-load-enable-code-helpers) ;; It is nice but i really dislike completion splitting window in 2
(semantic-load-enable-excessive-code-helpers)
;; (semantic-load-enable-gaudy-code-helpers)
(setq senator-minor-mode-name "SN")

;; Be careful to add lines for semantic-idle because weird tooltip box appears again :(
(global-semantic-idle-summary-mode 1) ;Display a tag summary of the lexical token under the cursor.
(global-semantic-show-unmatched-syntax-mode 1)

;; Add menu to navigate faster between tokens
(add-hook 'semantic-init-hooks (lambda ()
(imenu-add-to-menubar "TAGS")))

;; Enable semantic cache, search functions only first time
(global-semanticdb-minor-mode 1)

(defun semanticdb-cache-directory-p(directory)
(cond
((search "/ArraySaver/" directory) nil)
((search "@@" directory) t)
(t nil)))

(add-hook 'semanticdb-project-predicate-functions 'semanticdb-cache-directory-p)

(setq semanticdb-default-save-directory "~/.emacs.d/semantic")

For da record :)

Happy Hacking!

Resumen: Una filosofía de trabajo focalizada en actuar, más que en pensar o planificar y que actualmente utilizan muchos proyectos web de éxito.

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.

 

Eres de esas persona que siempre han pensado que el rock alternativo ha muerto y que nunca mas volverá, o que el grunge is DEAD... con la muerte de Kurt.. pues les traigo a uds. la oportunidad de conocer a Silversun Pickups un relevo a la musica Indie Alternativa y Grunge de hoy en dia, y es justo ahora cuando la musica necesita un apoyo y esta banda se las trae...

cabe mencionar que han sufrido bastante para subir escalones ya que hacen musica independiente....

Aqui su pagina, y Aqui su Discografia.

 

Saludos, la presente es para invitarlos a formar la Comunidad PingüinoVE en Maracay, la cual busca fomentar el uso de ésta herramienta de trabajo, su estudio y su difusión.

Más información: http://bit.ly/9x4zqq

Atentamente:

Ing. Manuel Pérez P.

 

 

Revise quienes fueron los que aprobaron la destrucción de la Reserva Nacional Pingüino de Humboldt en la Caleta Punta de Choros. Estas personas votaron hoy a favor de una Central Termoeléctrica. ¿Qué cargos tienen? ¿De qué partidos políticos son?

 

VOTOS A FAVOR

1. Sergio Gahona – Intendente Regional, sgahona@gorecoquimbo.cl
2. Pablo Argandoña (UDI) – Gobernador Provincia de Elqui
3. Susana Verdugo (UDI) – Gobernador Provincia de Limarí
4. Iván Cisternas (RN) – Gobernador Provincia Choapa
5. Gustavo Mallat (UDI) – Seremi de Economía
6. Fernando Herman Herrera (UDI) – Seremi de Vivienda
7. Mario Burle (UDI) – Seremi de Bienes Nacionales
8. Marcelo Chacana (UDI) – Seremi de Agricultura
9. Jocelyn Lizana (RN) – Seremi de Minería, jlizana@minmineria.cl
10. José Ready (RN) – Seremi de Educación, josemanuelready@mineduc.cl
11. Alejandro Cornejo (RN) – Seremi de Planificación, acornejo@mideplan.cl
12. Juan Fuenzalida (UDI) – Seremi de Transportes y Telecomunicaciones, jfuenzalida@mtt.cl
13. Osvaldo Iribarren (UDI) – Seremi de Salud, osvaldoiribarren@redsalud.gov.cl
14. Luis Cobo (RN) – Seremi del MOP
15. Claudia Rivera (RN) – Directora CONAMA, crivera.4@conama.cl

 

VOTOS EN CONTRA:

1. Consejero regional Raúl Godoy (PRSD)
2. Consejero regional René Olivares (RN)
3. Consejero regional Nathan Trigo (PC)
4. Consejero regional José Montoya (DC)

 

Siéntanse bienvenidos a escribirles y manifestarles su repudio, por favor.

 

Fotos: Radio Bío-Bío (CC, By-SA-NC) y CONAF

 

Saludos, la presente es para compartir información referente a Proyecto Pinguino, el cual es un clon de Arduino, que busca la liberación del Harware.

Más información en: http://bit.ly/9DzsvT

Atentamente:

Ing. Manuel Pérez P.

Saludos, la presente es para compartir con ustedes una gran noticia para la Comunidad del Software Libre Venezolano, la liberación de la nueva versión de Turpial (1.3.4) la cual brinda mayor estabilidad a ésta iniciativa.

Más información en: http://bit.ly/c5QLg7

Atentamente: Ing. Manuel Pérez P.