Feda /dev/ - No Javascript allowed

los webdev por lo general son inofensivos y cuando la cagan no tiene mucho impacto. yo el problema lo tengo con los javeros y muy especialmente la nueva especie de los frikis de la programacion funcional y el ddd (nueva escision de la revolucion puritana del GoF)

trabajar en sre y tener que explicarle por cuarta vez a un senior conceptos basicos sobre por que su aplicacion chupiguay hexagonal 100% test coverage best practices twelve factor esta petando por oom en produccion constantemente cambia mucho la perspectiva

#24097 Y digo yo, sólo digo eh, ¿no existen entornos de pre-prod dónde normalmente toda esta gente se queda estampada?

Desde que modificamos toda la infraestrucura de despliegues para añadir pre-prod todo han sido risas y fiestas. Algunas de las cosas más hilarantes que me he encontrado, de mano de esos "javeros medios", pero que me duplican de edad al strugglear contra preprod:

• Los parámetros de la JVM son una especie de vudú jamaicano insondable e inescrutable.
• La JVM sabe por arte de magia que hacer con los file descriptors, no problem mai friend, open fail, de yi-vi-em güil clous dem, everizing is okei
• Usar profiles para evitar conflictos entre el SO de dev y el SO de prod es pedante y superficial
• Test de black box mal hechos a propósito para justificar luego que el soft no funcione. Oye Juan, si este servicio espera procesar bulks de 10 millones de registros, ¿por qué los tests solo soportan use cases de 10 registros como máximo?
• Usar implementaciones acopladas al SO, sobre todo para el manejo de ficheros

#24108 Te voy a hacer una pregunta en serio.

Que caso de uso, necesitas leer 10M de registros de una db relacional/horziontal? Que periodicidad tiene?

No se, yo con series temporales trabajo con muchos mas en druid de db, pero en relacional no me entra en la cabeza porque cojones necesitas sacar tantos registros.

#24109 Cuando empezamos en un nuevo cliente, hay que migrar toda su información de sus sistemas a los nuestros. En municipios de 100.000+ habitantes, analizar la info de los últimos 4 años de, por ejemplo, el impuesto de bienes inmuebles urbanos, supera esa cifra de largo. La información debe sacarse siempre en bulk para poder hacer los cuadres de migración, no es tan sencillo como, por ejemplo, ir extrayendo los datos agrupados por DNI.

El proceso de migración actual es un autentico infierno porque se desarrolló teniendo en mente clientes mucho más pequeños, por lo que tenemos este tipo de problemas continuamente.

#24112 A ver como lo resumo para que sea entendible.

Tenemos un cliente, A, con su sistema informático, y que nos contrata a nosotros, B, con nuestro sistema informatico. Mover la info de A => B es el objetivo. ¿Dónde está la dificultad? En esencia, que aunque la información debería tratarse de la misma manera en ambos sistemas (por ejemplo, cobrar un recibo de Basura debería seguir la misma lógica en ambos sistemas, aunque las estructuras de datos / funcionamientos internos sean distintos) no se hace. En el municipio A, el IBIU, que es un impuesto estatal, se gestiona como les sale de los cojones y en el municipio B, como les sale de las narices, a pesar de que deberían gestionarse exactamente igual. Si fuese así, migrar esa información sería trivial. Pero no es así, nunca.

Como los datos de partida son inconexos, heterogéneos y el 90% de las veces, incoherentes incluso desde el punto de vista legal, no podemos establecer reglas para crear esas representaciones intermedias. Pongo un ejemplo muy sencillote:

• Las tasas de agua se cobran según regulación nacional + regulaciones municipales. Algunos municipios cobran canon de saneamiento, otros alcantarillados, pero todos deben cobrar el IVA. Lo normal es crear una regla para toda liquidación que sea de Aguas, su importe se debe separar en los conceptos definidos por el Ayto + el concepto del IVA que es obligatorio.

Pues bien, llegas, creas la regla, cuadras los importes y ves que en el cliente A, su sistema dice que tienen 3 millones de euros en tasas de agua, y a ti te salen 2,7. Luego te pones a mirar y que encuentras? Que hay partidas de Aguas donde no han cobrado el IVA. En su lugar, esas partidas han cobrado el IVA en otro concepto que está en otro sitio. Y en ese otro sitio, están mezclados con otros conceptos que nada tienen que ver con Aguas. ¿Cómo lo discriminamos? Ya te lo digo: no se puede. Tienes que sacar toda la información en bruto y empezar a filtrar. Pero claro, tienes que filtrar no solo las tasas de Agua, sino todas las putas tasas que cobren IVA. Pues nada, a sacar toda la info de tasas. Y así, empiezas a tirar del hilo y tienes burradas como la que te digo.

Por otra parte, también tenemos el problema de que no podemos asumir ningún % de error. Si el cliente dice que en su sistema hay 3 millones de euros, nosotros debemos mover esa info y presentar un informe de nuestro sistema donde también están esos 3 millones.

mmm software para secretarias

#24116 ójala software para secretarias, no sabes cuanto hecho de menos picar cruds y poner botoncitos de "Aceptar" y "Cancelar"