Muy buen artículo Joaquín!! ¿Alguien más se anima a compartir su opinión?
El 3 de octubre de 2016, 10:28, Joaquin Ferrero <[email protected] > escribió: > > > El 02/10/16 a las 14:12, Pablo Rodriguez escribió: > >> Buenos días >> >> En las cañas posteriores a la reunión hablabamos de las dependencias de >> los módulos, y que a veces era un criterio muy importante para elegir un >> módulo u otro. Es decir, elegiamos un módulo porque no tenía dependencias >> frente a otros que sí tenían. >> >> > La carga de la complejidad informática que resuelve un problema es casi la > misma -el número de líneas que necesitamos para resolver un problema es > casi el mismo si usamos muchas o pocas dependencias: no hay atajos en la > resolución del problema-. Pero solemos pensar que si usamos un módulo con > pocas dependencias reducimos otra complejidad: la de la administración de > los módulos de terceros. ¿Realmente es un problema, si estamos seguros que > esos módulos funcionan en nuestro entorno? > > > Otro tema que salió por parte de Roberto es que tenían hecho una > herramienta que analizaba un directorio cualquiera para sacar las > dependencias del código Perl encontrado. ¿Era así, verdad? > > En CPAN encontré Module::Dependency <https://metacpan.org/release/ > Module-Dependency>, más en concreto, Module::Dependency::Indexer, que > parece que hace algo parecido, pero no lo he probado. Y posiblemente habrá > más. > > > Comenté también que había un módulo que permitía cargar un módulo en CPAN > en tiempo real: > > CPAN::AutoINC <https://metacpan.org/pod/CPAN::AutoINC> - Download and > install CPAN modules upon first use > > Mejor dicho: detecta que un programa necesita un módulo que no está en el > sistema, y en ese momento lo baja, instala, y el programa continúa en ese > punto. > > > A mi me gusta tener funcionalidad reutilizable, es decir, partiendo de una >> serie de componentes construir sobre ellos. Personalmente creo que tiene >> más ventajas que inconvenientes, y no tengo ningún problema en utilizar >> módulos con muchas dependencias. Si además los autores de los módulos se >> adhieren a alguna convención, por ejemplo: https://metacpan.org/pod/SemVe >> r mejor todavía. >> >> ¿Qué opinais? >> > > Por lo que he visto en algunos sitios, a medida de que dependes de más > módulos, se te hace imprescindible usar un gestor de módulos, como Pinto y > Carton, y no depender exclusivamente de CPAN. > > Un ejemplo: Una vez usé el módulo *Date::Set*, para hacer operaciones de > conjuntos con periodos de tiempo (en concreto, "unir" conjuntos de meses). > Pues bien, un día ese módulo desapareció de CPAN: el autor lo renombró a > *DateTime::Set*. Eso podría provocar un problema a la hora de hacer una > reinstalación, si el administrador no se da cuenta del cambio. > > Este artículo es un buen resumen de las herramientas actuales con las que > contamos en desarrollo Perl, incluida la gestión de módulos propios y de > terceros: https://engineering.semantics3.com/2016/06/15/a-perl- > toolchain-for-building-micro-services-at-scale/ > > -- > JF^D > > > _______________________________________________ > Madrid-pm mailing list > [email protected] > http://mail.pm.org/mailman/listinfo/madrid-pm >
_______________________________________________ Madrid-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/madrid-pm
