#32607 en el proyecto en el que estoy se permite hacer insert/update/delete de un porron de registros (hasta 500mb o más ) en una misma operación. Lo que hacemos es crear una transacción por cada "registro" y una global a nivel de operación pero que las transacciones hijas no interfieren con la padre, esta última sirve para el chequeo inicial del mensaje completo (estructura, dependencias entre los registros ) y poco más. Al final si le devuelve una respuesta con el estado ok/nok de cada registro.
#32609 generas una cabecera y el contenido que es una tabla independiente con relación tanto al albarán como al artículo.
Si yo creo un albarán de pedido con una cantidad de artículos y nada más generar el albarán, gestionan la entrada en otra parte, no puedo editar el albarán añadiendo más artículos. Porque cuando se gestiona el albarán se restan unidades en el stock tanto en origen y se suman en el destino y no puedo estar desvirtuando los datos por errores del alta.
Me voy a ahorrar el tocho y me voy a ir a tomar por culo. Da igual, soy de FP y <1.4k, no sé nada.
#32609 Que yo cambie una factura y diga que se han vendido 4 y no 1... implica movimientos en modelos de contabilidad, quizás movimientos en almacén, y un largo etc... no usar la estrategia del rollback sería una puta locura, sin más. Ponte tu a revertir los cambios de que al hacerse un movimiento de almacen el sistema dio un pete. A revertir a mano movimientos en contabilidad (que para la parte de contabilidad todo estaba de puta madre hecho) y tal y cual... Me sale mil veces más barato tirar de rollback.
Piensa en sistema modulares, donde se pueden estar disparando acciones que tu como programador no controlas. Tienes el modulo de super-almacen que esta a la "escucha" de movimientos en el modelo de almacen para hacer operaciones en sus propios modelos...
#32615 en la app en la que trabajo las facturas/albarnes se pueden realizar de hasta 500k artículos. Just saying. No va a dar la casualidad porque al final gestionamos movimientos entre almacenes de grandes cantidades de stock. Pero sí que se puede llegar a dar el caso de tener que gestionar el movimiento de una entrada bastante tocha de publicaciones.
En MV mi opinión es bait,
En el mundo real mi opinión es un hecho.
Cuando dije que cualquier junior (bueno) programa mejor que cualquiera de vosotros...
Hay que llevar el leetcode al toque.
Me molan a muerte los animes, sobretodo la historia del héroe del que todos se ríen, humillan y apalizan hasta que en medio de la pelea tiene dos capítulos recordando las promesas que se hizo hace años y saca todo su ki para convertirse en el más fuerte de la serie.
@desu hermano estoy contigo a fuego
#32623 Y? El viernes estuve refactorizando código de un "senior" con "5 años de experiencia" en una "conocida multinacional"... que buscaba elementos entre arrays en tiempo N2... Lo pasé a N.
for (element in a):
for (element in b):
if(a.id == b.id) result.push(a)
for (a in A) set.put(a)
for (b in B): if (b.id in set) result.push(set.get(b.id))
xd
#32625 Lo que digo es que preparar preguntas de entrevistas hace que pases entrevistas, no que aprendas a programar. Algo así como cuando uno se saca el permiso de conducir xD
#32625 Y al que sustituyo se ha ido de analista a Mercadona, y no ha usado un patrón de diseño en su puta vida (por lo qu ehe visto manteniendo sus proyectos) y usando conversion de int a string añadiendo punto y de ese string con punto a float. Y mil mierdas así.
Que trabajes con un inútil no te hace a ti mejor
#32626 Pff ni puta idea tienes si lo dices enserio. Debes tener un nivel por los suelos para afirmar eso.
#32629 Tienes razón, era un ejemplo básico, te puedo poner otro...Seguro que si te planteo el problema y te digo que me hagas la solución optima estarás un par de días... yo tardé 1 semana.
La mayoría de código del día a día son patrones, cuanto más programas los ejercicios más los ves y más fácil llegas a las soluciones óptimas.
#32627 Para que... con coger el coche, entrar en el despacho, saludar, sentarse... ya ha cumplido con el 80% de la entrevista... cuando le pregunten si sabe programar y diga que no... da igual, el resto es válido... ya aprenderá a programar o no... eso ya que lo diga cuando salte un error.
#32631 En ningún lado dice eso.
coding questions = coding en general
en ese articulo no habla de diseño de clases o arquitectura, donde ahí la experiencia si aporta. aunque en system design creo que como no lleves al día las arquitecturas de los mejores( mirando conferencias) te quedas desfasado rápido y aplicas técnicas incorrectas.
#32633 Lo que está diciendo es que no te flipes por tener exp porque eso no es lo que se valora en las preguntas de código de las entrevistas, por tanto no vas a saber resolverlas de forma consistente si no las has preparado especificamente (porque la vida real no es una pregunta de entrevista). La cosa es que en ningún caso de ese texto se puede concluir que
cualquier junior (bueno) programa mejor que cualquiera de vosotros
y tal
#32634 "new grads generally outperforms experienced engineers in coding questions"
Lo que dices es que no te flipes por llevar 10 años programando porque si no has estado practicando ya no te acuerdas ni de hacer un bubble sort.
Que poquito picais algunos
