a

Cuanto sensacionalismo, luego lees la noticia y resulta que han analizado 700 y pico proyectos en github, analizando errores reportados y los parches que solucionan esos errores. Vamos que para lo único que puede servir es para detectar patrones comunes de error y más que para arreglarlos automaticamente sería util para mostrar avisos de posibles errores si detecta esos patrones o para inferir algunas prácticas que pueden inducir a errores y sacar algún pequeño catalogo de buenas prácticas u olores a evitar.

Hay cientos de herramientas y proyectos de investigación en la misma linea, pero en general las herramientas de analisis estatico como esta tienen un uso bastante limitado, los bugs importantes son los que tienen que ver con la lógica del problema o incluso con no resolver el problema adecuado.

a

El manifiesto del "handmade dev" no lo conocía pero es una soberana estupidez. Es tomar una sóla de las dimensiones del problema del desarrollo de software, el rendimiento, y ponerla por encima del resto de dimensiones sin tener en cuenta el contexto.

Pobre del que tenga que mantener el codigo que vayan dejando a su paso estos lumbreras. Velocidad de desarrollo, mantenibilidad, extensibilidad, robustez, escalabilidad (que no es lo mismo que rendimiento)... vamos a olvidarnos de estas cosas y a escribir toneladas de código en lenguajes de bajo nivel optimizando chorradas que no le interesan a nadie!, gran idea.

a

Hoy en día existen lenguajes como Rust o Go que pueden sustituir a C en casi cualquier escenario y están mucho mejor preparados para la programación multihilo. Salvo para sistemas legacy donde no quede más remedio que seguir usando C es difícil pensar un escenario donde iniciar un nuevo proyecto con C tenga sentido la verdad.

J

La elección de un lenguaje de programación en un proyecto (o parte) raramente depende del gusto de quien lo use. Supongo que no hace falta listar la cantidad de factores que deciden qué lenguaje hay que usar para implementar la solución.

Cada uno se sentirá más cómodo en un lenguaje u otro dependiendo de su conocimiento, experiencia, rendibilidad, etc. Personalmente, no veo motivo para evitar C cuando sea posible usarlo si se cumplen las condiciones necesarias.

#57 Intuyo muchos más escenarios en los que iniciar un proyecto en C tenga mucha más ventaja que hacerlo en Rust o Go. Cuenta sólo la probabilidad de que un programador sepa C o Rust/Go, o la probabilidad que tengas librerias ya desarrolladas en C (aprovechables) y quieras tener un entorno homgeneizado.

alcornoque

#145 No homogeneizado, pero totalmente operativo. Rust FFI http://doc.rust-lang.org/book/ffi.html

a

El problema desde un punto de vista técnico,sin entrar en valoraciones de posibles sobres y corruptelas varias en las adjudicaciones de proyectos, lo primero que hay que entender es que un proyecto como este no tiene un principio y un fin, el software necesario para gestionar los impuestos de ayuntamiento u otras cuestiones esta en constante evolución, este software se tendrán que mantener y evolucionar mientras exista un ayuntamiento para irlo adaptando a las distintas necesidades, normativas que van cambiando etc,etc. No es un producto cerrado que se pueda externalizar y me lo entreguen en una cajita listo para usar.

Decía alguien que el software es el sistema nervioso de cualquier empresa/administración, si dejamos que el conocimiento de ese sistema nervioso se quede fuera de la organización esa organización siempre estará lastrada porque no podrá aplicar cambios si no es capaz de modificar el software para que los refleje. Es fácil verlo en este caso, entra un equipo de gobierno al ayto y quiere cambiar X e Y en lo que respecta a los impuestos, pues más les vale poder modificar el software que gestiona estos impuestos, porque si no por mucha voluntad politica que tengan para cambiarlo no van a poder hacerlo o lo van a hacer con muchisimo dolor de por medio (dolor que es dinero del contribuyente).

Lo razonable sería construir esto dentro del propio ayto por personal contratado, se pueden contar con ayuda externa para formar estos equipos, ayudarles con buenas practicas, con tecnologías, pero el conocimiento se tiene que quedar dentro de la organización si queremos construir una organización moderna y efectiva que pueda adaptase a los cambios con cintura suficiente. Este camino no es fácil, porque hay que formar al personal existente o contratar personal que tenga la capacidad para llevar proyectos complejos de este tipo, pero hay que empezar a andarlo en algún momento, el camino de la externalización en proyectos que son el core de una administración es, en mi opinión, una barbaridad que tiene que ver con no entender la naturaleza del software y su papel en las organizaciones.

WarDog77

#67 logico

a

Pues esta vez no se si estoy muy de acuerdo con bonilla, 5000 al mes es una buena facturación para un freelance si tienes pocos gastos, un informático que trabaje en su casa no tiene excesivos gastos salvo los 300 euros de seguridad social, gestoria si no quieres hacer todos los papeleos tu sólo, algo de luz, el equipo informático que muy probablemente tendrías igualmente. Es cuestión de echar cuentas, otra cosa es que tengas muchos gastos por ejemplo en viajes, alojamientos fuera de tu ciudad etc, etc. Entonces los 5000 se te pueden quedar muy cortos.

Más que reglas de brocha gorda lo que hay que hacer es informarse como dios manda de lo que cuesta ser freelance, tener claro cuanto se paga de SS, cuanto se paga de IRPF, cuanto cuesta una gestoria, cuantos gastos vas a tener y si los puedes imputar como gastos (que no siempre es tan facil... esa es otra), tener claro que no todas las horas que trabajes las facturas (reuniones previas, negociaciones, desplazamientos, gestión de papeleos varios).

Al final, como freelance lo que estas haciendo es eliminar un intermediario, así que no se porque debería ser tan extraño que un freelance pida 50 o 60 euros la hora cuando una consultora te cobra eso y más por alquilarte la misma persona, en realidad las empresas ya pagan la hora de "informático" (habría mucho que hablar claro, de la especialización, la experiencia y mil cosas más) a ese precio.

Al final lo más complicado es tener clientes y un flujo de trabajo constante, ahora mismo en este país no somos tantos los freelance y o te haces conocer de algún modo o es difícil que vayan a confiar en un freelance en lugar de acudir a la consultora de turno. Un mercado donde la figura del freelance fuera más habitual y las empresas se habitúen a contratar así es bueno para todos, menos intermediarios que no aportan ningún valor fuera de la ecuación, bueno tanto para los clientes como para los profesionales de este sector, y es facil de constatar mirando como funciona el tema de UK o EEUU por ejemplo.