Estuve allí en directo, muy buena charla. De mucha utilidad para los que trabajamos en proyectos legacy ofreciendo técnicas simples pero efectivas. Quizá por el final se te fue un poco de las manos con el tema de los eventos y su persistencia (se nota que te gusta y te ha solucionado muchos problemas) que hizo que se desviara un poco del objetivo de la charla. En general muy buena calidad, no cualquiera puede hacer live coding de esta manera. Espero poder acudir a alguna charla más tuya. Saludos, David Hernando
Gracias por el comentario! El tema es que la parte de testing está cubierta en el resto de los videos. La parte de eventos aporta algo más y son los próximos videos que iré publicando.
Muy interesante. Me surge una duda sobre el workersito que saca eventos de la BBDD y los publica a RabbitMQ. Comentas que se guarda cuál fue el último evento visto. ¿Dónde se lo guarda? ¿BBDD? ¿No tenemos el mismo problema de transacción que estamos intentando solucionar? ¿Es aceptable publicar a RabbitMQ dentro de la transacción de BBDD por ser un proceso en background? Gracias de antemano.
Una charla muy útil, hay una cosa que no acabo de entender respecto a los eventos en DB: si durante el ciclo de vida del producto vamos incorporando distintos tipos de eventos, cómo aseguramos la consistencia de la información que proporcionan respecto a la DB desde 'el inicio de los tiempos'? Habría que simular eventos anteriores, devolver fecha de inclusión del evento en la API, o? Gracias!
Hola Sava! Gracias por el comentario. Lo trataré en los siguientes videos. Tu pregunta cae en la parte de versionado de Eventos de Dominio. Te puedes ir mirando: leanpub.com/esversioning :) Nos vemos por la oficina! :)
Gracias por el comentario Emilio. Era una pequeña broma. Laravel es tan válido como otros, no tengo tanta experiencia con él para no recomendar su uso.
Creo que no es tanta broma. Si quien lo usa no tiene los conocimientos que promueve Carlos (suele ser lo normal) lo que te encuetras es código que no usa DI con llamadas a los facades y las helpers functions a todos los niveles de la App. Con toda la lógica en el controllador o en el modelo de Eloquent(de este mejor ni hablar) y teniendo que hacer test funcionales sí o sí para que toda la magia del Framework funcione. De hecho es normal que miles de lines de código PHP con la lógica de negocio solo funcionen si es Laravel quien las usa (app('service'), DB::foo(), Model::find() y esas mierdas). Para crear un worker que consuma una cola AMQP tienes que levantar una instancia de Laravel por worker... "Y cual es el problema? Laravel es el framework que usamos..."
Estuve allí en directo, muy buena charla. De mucha utilidad para los que trabajamos en proyectos legacy ofreciendo técnicas simples pero efectivas. Quizá por el final se te fue un poco de las manos con el tema de los eventos y su persistencia (se nota que te gusta y te ha solucionado muchos problemas) que hizo que se desviara un poco del objetivo de la charla.
En general muy buena calidad, no cualquiera puede hacer live coding de esta manera. Espero poder acudir a alguna charla más tuya.
Saludos,
David Hernando
Gracias por el comentario! El tema es que la parte de testing está cubierta en el resto de los videos. La parte de eventos aporta algo más y son los próximos videos que iré publicando.
Muy interesante.
Me surge una duda sobre el workersito que saca eventos de la BBDD y los publica a RabbitMQ.
Comentas que se guarda cuál fue el último evento visto.
¿Dónde se lo guarda?
¿BBDD?
¿No tenemos el mismo problema de transacción que estamos intentando solucionar?
¿Es aceptable publicar a RabbitMQ dentro de la transacción de BBDD por ser un proceso en background?
Gracias de antemano.
Una charla muy útil, hay una cosa que no acabo de entender respecto a los eventos en DB: si durante el ciclo de vida del producto vamos incorporando distintos tipos de eventos, cómo aseguramos la consistencia de la información que proporcionan respecto a la DB desde 'el inicio de los tiempos'? Habría que simular eventos anteriores, devolver fecha de inclusión del evento en la API, o? Gracias!
Hola Sava! Gracias por el comentario. Lo trataré en los siguientes videos. Tu pregunta cae en la parte de versionado de Eventos de Dominio. Te puedes ir mirando: leanpub.com/esversioning :) Nos vemos por la oficina! :)
buenas, en los primeros 5 minutos haces un comentario: no useis laravel (como en broma). podrias explicar la razon?
el video muy bueno.
Gracias por el comentario Emilio. Era una pequeña broma. Laravel es tan válido como otros, no tengo tanta experiencia con él para no recomendar su uso.
Pues yo me lo había tomado en serio xD
Creo que no es tanta broma. Si quien lo usa no tiene los conocimientos que promueve Carlos (suele ser lo normal) lo que te encuetras es código que no usa DI con llamadas a los facades y las helpers functions a todos los niveles de la App. Con toda la lógica en el controllador o en el modelo de Eloquent(de este mejor ni hablar) y teniendo que hacer test funcionales sí o sí para que toda la magia del Framework funcione. De hecho es normal que miles de lines de código PHP con la lógica de negocio solo funcionen si es Laravel quien las usa (app('service'), DB::foo(), Model::find() y esas mierdas). Para crear un worker que consuma una cola AMQP tienes que levantar una instancia de Laravel por worker... "Y cual es el problema? Laravel es el framework que usamos..."