Seleccion de _armas_ para un proyecto.

¡¡ Hola a todos !!

Espero me puedan ayudar con sus comentarios.

Estoy escribiendo una serie de post reflexivos basandome en el libro:
97 Things.Things Every Software Architect Should Know
(Libro pequeño pero altamente recomendable)

Y uno de los próximos post's tiene que ver con:
'Cómo seleccionamos nuestras "armas" para un desarrollo'

Por lo que, me tomo la libertad de preguntarles:

• ¿Cómo seleccionan una tecnología?
• ¿Eligen la que más dominan sin importar el alcance de la tecnología/lenguaje en sí?
• ¿Cuando prueban una nueva?
• ¿Eligen la que tiene mayor respaldo por una comunidad?
• ¿Ocupamos la de moda?
• ¿Creamos propias (un editor "especial" por ejemplo)?

Saludos a todos y gracias por sus comentarios,

RuGI

<comercial>
Por si alguien esta interesado, aquí pueden ver los post's que ya llevo XD
http://weblogs.javahispano.org/rugi/category/97things
</comercial>

#1   

En mi caso, que seguramente no es relevante, pero no me importa, es un poco una combinación de cosas.

Elegir un lenguaje o plataforma depende de lo que se vaya a hacer, como punto de partida. Se prueban nuevas cosas si tengo tiempo y/o dudo, y lo hago basado en una mezcla de popularidad y comentarios encontrados en algún buscador. Personalmente valoro que haya estabilidad, buena documentación disponible, una comunidad activa (no necesariamente grande, pero sí activa) y que la gente hable bien y hable mal de la "herramienta/arma". Si sólo hablan bien no me suele convencer... pero supongo que es algún tipo de complejo mecanismo de mi cerebro que me costaría poner en pocas palabras...

Lo de crear herramientas propias... pues también, pero no termino de ver la relación... Quiero decir, para mi son casos bastante distintos. Las herramientas genéricas cubren necesidades genéricas. Las herramientas propias son mucho más específicas. No siempre, claro, porque siempre tiene cada uno esa pequeña librería de soluciones propias que va llevando a cada proyecto. Pero generalmente si tengo que llegar a hacer algo como "un editor especial" normalmente es algo que tiene unas necesidades bastante específicas, ¿no?

Por cierto, la serie que estás escribiendo es muy interesante :)

#2   

Creo que lo que más valoro últimamente es la agilidad. Por ejemplo no me gusta usar servidores de aplicaciones pesados, bases de datos mastodónticas, etc. Para elegir el lenguaje de programación también suele pesar mucho la agilidad. Un lenguaje que conozca me da más agilidad, y dentro de los que conozco elijo el que creo que me va a ser más rápido de usar. Por ejemplo suelo usar Java para cosas medias/grandes, y para cosas pequeñas a veces uso Python.

A veces me creo herramientas propias cuando creo que las que hay no solucionan mis necesidades o considero que necesito algunas características que no obtengo con las soluciones existentes. Pero por supuesto siempre si el esfuerzo compensa. Algunas herramientas que he ido desarrollando han sido: un generador de código, una implementación de markdown, una implementación de JSON, un API de persitencia.

#3   

Hola @Venkman!!

Siendo sinceros, "abrí" las preguntas así para no dejar fuera algún comentario, en mi caso, de repente por el karma que tengo de, ademas de programar siempre algo con swing,
me toca "transformar" logs en algo más legible, entonces, de repente me di cuenta que me ayudaría una especie de "editor" sencillo con substituciones de textos, funcionalidad que seguramente tienen ya algunas herramientas pero que puedo invocar de una manera más personal.

Lo que comentas de una comunidad activa, alguna vez lo leí en algún artículo y mencionaban que un indicador interesante era la cantidad de proyectos activos que tuviera (en el caso de un lenguaje) en sourceforge

Por cierto, espero poder mantener el ritmo de los post de la serie jeje ;)

@gimenete !!!
Creo que das un ejemplo claro de los "curioso efectos secundarios" de ir generando una "herramienta propia": Siena, supongo de origen, la concebiste como algo "para ti" y que ahora que está "madura" se puede compartir con el mundo.

¡¡¡ Gracias por sus comentarios !!!

:)

#4   

Para mi tiene bastante peso el dominio de un arma, por que te hace sentirte más seguro, aunque me gusta hacer algo novedoso siempre que puedo por aprender algo en cada batalla. Pero está claro que no se puede ir con una espada si el enemigo lleva una pistola XD.

Probar una tecnología completamente nueva, sólo me lo planteo para pruebas de concepto o para algo de uso personal donde la presión es mucho menor, o para algo más "serio" si sé que puedo volver a utilizar tecnologías que domino con cierta facilidad si la cosa se pone fea.

Respecto al respaldo de la comunidad a una tecnología, estoy con la opinión de Venkman, más que grande considero importante lo activa que sea. Si tiene mucha actividad, para mi es el signo más claro de que goza de buena salud y es un muy buen punto a su favor. Y aquí creo que entra de rebote el punto moda, si la comunidad es activa puede hacer mucho ruido y creo que ahí es interesante perder algo de tiempo para ver si hay señal ;). Por otro lado, creo que no conozco ninguna tecnología de la que sólo se hable bien XD

Y herramientas propias, no recuerdo haber creado nada lo suficientemente genérico para considerarse una herramienta, sí algún parche/extensión de herramientas genéricas o alguna librería muy concreta de consumo propio en algunos momentos. También creo que en muchos casos de creación de estas herramientas se peca de NIH, ¿seguro que no hay una herramienta similar en el mercado que cubre tus necesidades, que puedes usar/comprar o incluso colaborar en su desarrollo? ¿de verdad? Ok, pues creala.

Edito:

Se me olvidaba, este último año, en las ocasiones donde he tenido más libertad de elección, he tenido que tener en cuenta el factor precio. Hay tecnologías más baratas, y para clientes con recursos muy limitados era uno de los factores con más peso.

#5   

Por otro lado, creo que no conozco ninguna tecnología de la que sólo se hable bien XD

Mmmm... Bueno, sí, quizá tienes razón xD
Pensaba, cuando lo dije, más bien en que es importante leer también las críticas negativas y valorar todo el conjunto, no sólo las positivas. Es decir, fijarse en qué quejas hay, si son importantes, si son repetidas, cómo se responde a ellas, etc.

#6   

En eso coincido contigo.... recuerdo mucho, por poner un ejemplo, esas discusiones que luego se dan con java sobre si es o no "lento" (e independientemente del escenario en que esa frase sea o no cierta), era común leer a personas que con solo leer "java" pedían la hoguera!! XD sin siquiera dar razones válidas o, mucho menos, tener experiencia en el tema.

#7   

Como han comentado, lo principal es la familiaridad con la tecnología.

Cuando leo sobre temas interesantes, intento sacar tiempo para algunas pruebas, pero no suelo incluirlo como base de un nuevo proyecto.

En cuanto a experimentar con cosas más pequeñas sobre una base conocida... eso suelo hacerlo más a menudo, pero intento reducir el número de "cosas nuevas" (aunque mi experiencia reciente con Ruby ha hecho que el número de gemas en mis desarrollos crezca sin control... y apenas sé lo que hacen).

A la hora de elegir entre varias opciones, no te comento nada nuevo... el criterio para Open Source sería el de actividad (¿hay releases o commits recientes?) y velocidad de respuesta a dudas/errores.

#8   

En mi caso, depende un poco del proyecto a realizar y sus circunstancias. Si el proyecto es importante y el tiempo no sobra, los experimentos con gaseosa y en casa. Es decir, en estos casos a no ser que tenga que hacer algo que no he hecho nunca antes, me dedico principalmente a resolver el problema, no a buscar nuevas formas de resolverlo.
No quiere decir que no puedas añadir alguna novedad que pienses que irá mejor, pero sí que eso no es lo importante y procuro no perder mucho el tiempo con temas colaterales.

Si el proyecto no corre tanta prisa o no es tan crítico, entonces si que me gusta introducir cosas nuevas para probar en proyectos reales los candidatos a formar parte del arsenal de buenas prácticas, aunque siempre me gusta hacerlo teniendo una ruta alternativa por si la cosa sale rana.

Por último, ¿de donde saco los candidatos? Pues para eso tengo un par de proyectos básicamente experimentales que uso de conejillos de indias para probar cosas, y donde perder una semana con algo que no funciona o descubrir que en realidad no es tan bueno pues no es ninguna tragedia si no un resultado posible.
De entre todo lo que hay por el mundo, suelo escoger los proyectos, como dice Venkman, que estan activos y parecen estar vivos, aunque sea a nivel de usuario. Lo primero que hago es irme al tutorial inicial y eso ya me deja una imagen del producto. Que a veces puede ser algo erronea, pero es lo que hay.

Personalmente me gustan los proyectos adaptables que me dejan usarlos "a mi estilo", y no los que me imponen una forma de trabajar "por que lo digo yo". Eso incluye, por ejemplo, que funcionen en diferentes contenedores web, que se dejen usar desde un IDE o desde Ant... etc.

Y le tengo tirria a los fanatismos, así que según la documentación y las listas, a veces me quitan las ganas simplemente viendo la "filosofía" detras de un producto, por que eso implica menos amplitud de miras.

Es una receta complicada.

#9   

Listo el post ;)

[15 de 97] Elige bien tus armas, renuncia a ellas de mala gana.

Mil gracias por sus comentarios y disculpen la atropellada edición ;)

Saludos!!!