Podcast appearances and mentions of ana medina

Hoy hablamos con la Psicóloga Ana Medina sobre los trastornos del neurodesarrollo TDN. Intentaremos contestar las siguientes preguntas: 1.¿Qué es una Trastorno del Neurodesarrollo? 2.¿En qué momento puede desarrollarse un Trastorno del Neurodesarrollo? 3.¿Puede ser hereditario o adquirido? 4.¿Hay una edad específica para su diagnóstico? 5.¿Cuáles son los tipos de Trastornos del Neurodesarrollo? Ademas definiremos los siguientes trastornos: Trastornos del desarrollo intelectual: -Discapacidad intelectual. -Retraso global del desarrollo o Retraso psicomotor -Discapacidad intelectual no especificada. Trastornos de la comunicación: -Trastorno del lenguaje-Trastorno fonológico-Trastorno de la fluidez-Trastorno de la Comunicación Social-Trastorno de la comunicación no especificada Trastorno del Espectro Autista: -Trastorno por Déficit de Atención con Hiperactividad Trastornos del desarrollo motor: -Trastorno del desarrollo de la coordinación-Trastorno de Movimientos estereotipados-Trastornos de Tics: Trastorno de Tourette, Tics motores o vocales persistentes, Tics transitorio, Tics no especificado Trastornos específicos del aprendizaje: -Dificultad en la lectura (dislexia) -Dificultad en la escritura (disgrafía)-Dificultad matemática (discalculia) #autismo #tdn #neurodivergent #podcast Nuestras redes: FB: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://www.facebook.com/T2BTeam⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ Spotify: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://spoti.fi/3CxLbf7⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ TY: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://bit.ly/3msDu4j⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ IG: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://www.instagram.com/tony_t2b/ ⁠⁠

Arranca una nueva temporada de La Alternativa, con José Luis Escarabajano. Hoy nos visitan las Hinds después de sacar su nuevo disco 'Viva Hinds'. Además, también charlamos con Ana Medina sobre el Festival Jardín de Las Delicias de Madrid y con Kike Paz sobre el Imposible Sound de Almagro. Aprovechamos también para escuchar novedades de la mano de Tu Otra Bonita y de Veintiuno junto a Enol.See omnystudio.com/listener for privacy information.

Esta semana en SOLO Staff Arantxa Sánchez, nos trae a una novela bajo el nombre de "Escucha esta canción", y como no podía ser de otra manera charlamos con la autora de esta historia musical. Se llama Ana Medina y lleva trabajando en comunicación muchos años, en comunicación de grupos, de artistas. Vamos, en la industria musical y también con varios festivales. Pero como dice ella, entre tantas experiencias y tantas historias que ha vivido, tenía muchas ganas de contar una historia para la que se inspira en todas esas noches de conciertos, en todas esas salas o en los viajes para ver conciertos. Y así es como nace ·Escucha esta canción".

Aquí llega el último programa del año en la Alternativa, con José Luis Escarabajano. Empezamos recibiendo a los chicos de Sidecars, que nos hablan de su nuevo tema 'Hasta que cierro los ojos', de su próxima gira de teatros llamada 'Modo Avión' y del concierto en el WiZink Center anunciado para el próximo año. También recibimos a Ana Medina, periodista y escritora que acaba de publicar 'Escucha esta canción', su primera novela en la que la historia de Carla se mueve a través de la música y los conciertos como hilo conductor.See omnystudio.com/listener for privacy information.

Fernando Neira nos cuenta la historia de 'Escucha esta canción' el libro de Ana Medina, a través de las canciones que lo componen. Después nos visita el cantautor Javier Ruibal y nos presenta su último álbum 'Saturno Cabaret', un disco con 14 canciones que nos transportan a la Barcelona de los años 50. Para terminar los oyentes nos cuentan sus historias musicales y presentamos, en exclusiva, tres novedades.

Repasamos en La Biblioteca con Antonio Martínez Asensio novedades, donaciones, y celebramos la entrada de Ricardo Menéndez Salmón con "Los Muebles del Mundo". También hay tiempo para la música en las Historias Musicales con Fernando Neira, con el que repasamos "Historia de una canción", de Ana Medina. Estrenamos "Saturno Cabaret con Javier Ruibal en directo desde Sevilla. Aitor Albizua repasa la semana en Hoy por Hoy en La Auditoría. 

Since we won't get to Bong Joon-ho's "Parasite" on this podcast for a few years, we thought we'd have a look at this one while we're still choosing the movies.Support us at our podcasting network, Podcastio Podcastius at https://www.patreon.com/podcastiopodcastius.  You'll get early episodes of this and out other podcasts, along with a live chat here and there.Speaking of our other podcasts - seriously, you could only listen to various other configurations of us:Luke Loves Pokemon: https://lukelovespkmn.transistor.fm/Time Enough Podcast (Twilight Zone): https://timeenoughpodcast.transistor.fm/Game Game Show (a game show gaming games): https://gamegameshow.transistor.fm/Occult Disney: https://occultdisney.transistor.fm/Podcast: 1999 (where Mark and Matt rap about Space: 1999): https://podcast1999.transistor.fm/And Matt makes music here:https://rovingsagemedia.bandcamp.com/Coming Soon:November 23: The EditorAnd SAG strike is now over, so back to the list:November 30: Toy StoryDecember 7: The Love GuruDecember 14: The Hunt

If you don't have these four around, is it really a Halloween party?Support us at our podcasting network, Podcastio Podcastius at https://www.patreon.com/podcastiopodcastius.  You'll get early episodes of this and out other podcasts, along with a live chat here and there.Speaking of our other podcasts - seriously, you could only listen to various other configurations of us:Luke Loves Pokemon: https://lukelovespkmn.transistor.fm/Time Enough Podcast (Twilight Zone): https://timeenoughpodcast.transistor.fm/Game Game Show (a game show gaming games): https://gamegameshow.transistor.fm/Occult Disney: https://occultdisney.transistor.fm/Podcast: 1999 (where Mark and Matt rap about Space: 1999): https://podcast1999.transistor.fm/And Matt makes music here:https://rovingsagemedia.bandcamp.com/Coming Soon:In support of the SAG-AFTRA strike, we will be recording non-"struck" movies for the time being.November 9: Salt of the EarthNovember 16: The GorillaNovember 23: The Editor

Buenas vibras para este martes con el vudú hecho bien de Nacho García, Arturo Paniagua repasa los hitazos de Cher, Nerea Luis se estrena como colaboradora para hablarnos de ciencia y tecnología, Ana Medina -comunicadora y fanática empedernida- nos presenta su libro 'Escucha esta canción' y los chicos de La M.O.D.A colapsan el estudio para presentar nuevo single y confesar lo muchísimo que les gusta llenar plazas de pueblos. 

#saludmental #habilidadessociales #podcast El día de hoy junto a nuestra invitada la Psicóloga Ana Medina continuamos discutiendo sobre las principales habilidades sociales que deberíamos conocer, manejar y administrar de la mejor manera. Analizamos las habilidades sociales como ser; Auto control emocional, Automotivación, Resolución de conflictos, Empatía, etc. Nuestras redes: FB: ⁠⁠⁠⁠⁠https://www.facebook.com/T2BTeam⁠⁠⁠⁠⁠ Spotify: ⁠⁠⁠⁠⁠https://spoti.fi/3CxLbf7⁠⁠⁠⁠⁠ TY: ⁠⁠⁠⁠⁠https://bit.ly/3msDu4j⁠⁠⁠⁠⁠ IG: ⁠⁠⁠⁠⁠https://www.instagram.com/tony_t2b/ ⁠⁠ --- Send in a voice message: https://podcasters.spotify.com/pod/show/open-team/message

#saludmental #habilidadessociales #podcast El día de hoy junto a nuestra invitada la Psicóloga Ana Medina discutimos sobre las principales habilidades sociales que deberíamos conocer, manejar y administrar de la mejor manera. Analizamos las habilidades sociales como ser; Auto control emocional, Automotivación, Resolución de conflictos, Empatía, etc. Nuestras redes: FB: ⁠⁠⁠⁠https://www.facebook.com/T2BTeam⁠⁠⁠⁠ Spotify: ⁠⁠⁠⁠https://spoti.fi/3CxLbf7⁠⁠⁠⁠ TY: ⁠⁠⁠⁠https://bit.ly/3msDu4j⁠⁠⁠⁠ IG: ⁠⁠⁠⁠https://www.instagram.com/tony_t2b/ ⁠⁠ --- Send in a voice message: https://podcasters.spotify.com/pod/show/open-team/message

Tras un parón vuelve a la carga La Alternativa, tu programa musical en Radio MARCA. Volvemos con la visita de un grupazo que acaba de sacar su segundo disco. Hablamos de Anabel Lee, que nos presentan 'Ganamos Perdiendo'. Además, también hablamos con Ana Medina, responsable de comunicación del festival Jardín de las Delicias, que se celebra el próximo 22 y 23 de septiembre en Madrid. Completamos el programa escuchando las novedades de Neverland Bari, Amatria, Mauri e Inazio.See omnystudio.com/listener for privacy information.

Cómo funciona la cooperativa de mujeres y diversidades que vincula lo público y lo privado para la fabricación de productos textiles. Ana Medina, secretaria de Género municipal.

Dra. Ana Medina, especialista en farmacia: Rol del farmacéutico en el cuidado de pacientes

En esta edición de ''De Show del mes de Octubre tenemos a la sirena de las redes Ana Medina. Hablamos con ella de cual es el secreto para irse viral en las redes, de la aplicación de Tik-Tok y nos da el secreto de como hace los video de bajo del agua. No dejamos fuera algunas cosas que quizás no sepas como que estudio música y actuación. De sus proyectos futuros entre otros temas mas. REDES Ana Medina ''IG''👇 https://instagram.com/anamdn?igshid=YmMyMTA2M2Y= Desde La Linea Podcast 👇 https://linktr.ee/DesdeLaLineaPod Melo @m3lolmr ''IG''

Discusion profunda sobre la inclusion, la inclusion forzada y por que si no no la serenity puede ser negra. ¿Los video juegos fomentan la violencia? Este programa es presentado por: @Abogado.Dago https://www.instagram.com/abogado.dago/ @Ncp Envios https://www.instagram.com/ncpenvios/ @pristine365 https://www.instagram.com/pristine365/ concepts_hair_salon1 https://www.instagram.com/concepts_ha... @dyfriesburger https://www.instagram.com/dyfresburger/ @c4everdmv https://www.instagram.com/c4everdmv/ @Leoactivao https://instagram.com/leoactivao?igsh.... _ @elcasiquec https://www.instagram.com/elcasiquec/​​​ _ @Brutalmentehonestos https://instagram.com/brutalmentehone....

Ana Medina es una tiktoker que ha tomado a las redes por sorpresa con sus elaborados videos debajo del agua, convirtiéndose en una sensación dentro de la plataforma. Brindando con un tequila, nos platica sobre su vida en Cancún, su increíble habilidad de actuar debajo del agua, de dónde salió la idea de convertirse en la 'sirena' de TikTok y el nuevo foco que le quiere dar a su carrera musical e interpretativa. Conducido por Tere Aguilera (@tereaguilera). Para conocer más sobre Ana Medina síguela en sus redes sociales: Instagram: @anamdn TikTok: @anamedinarz Creado por The Urbanda Magazine Instagram: @theurbandamagazine Facebook: The Urbanda Magazine Producido por Genuina Media.

In this podcast, Ana Medina, senior chaos engineer at Gremlin, sat down with InfoQ podcast co-host Daniel Bryant. Topics discussed included: how enterprise organisations are adopting chaos engineering with the requirements for guardrails and the need for “status checks” to ensure pre-experiment system health; how to run game days or IT fire drills when everyone is working remotely; and why teams should continually invest in learning from past incidents and preparing for inevitable failures within systems. You can read the transcript here: https://bit.ly/3JSR7T0 Subscribe to our newsletters: - The InfoQ weekly newsletter: https://bit.ly/24x3IVq - The Software Architects' Newsletter [monthly]: https://www.infoq.com/software-architects-newsletter/ Upcoming Events: QCon Plus online: https://plus.qconferences.com/ - May 10-20, 2022 - Nov 29 - Dec 9, 2022 QCon San Francisco: https://qconsf.com/ - Oct 24-28, 2022 - Oct 2-6, 2023 InfoQ Live: https://live.infoq.com/ - June 21, 2022 - July 19, 2022 - August 23, 2022 Follow InfoQ: - Twitter: https://twitter.com/InfoQ - LinkedIn: https:// www.linkedin.com/company/infoq - Facebook: https://bit.ly/2jmlyG8 - Instagram: https://www.instagram.com/infoqdotcom/ - Youtube: https://www.youtube.com/infoq

A ponteira da equipe de valinhos bateu um papo comigo e contou como foi a sua primeira superliga A, como foi jogar ao lado de grandes estrelas no Osasco e como está sendo a experiência de jogar na equipe de Valinhos.

En el programa de esta semana nos hacemos eco de la reunión que han mantenido esta semana el Presidente de la CEE, Monseñor Omella y el Presidente del Gobierno, Pedro Sánchez. También comentaremos el Informe Foessa sobre las consecuencias de la pandemia en la sociedad española. Para finalizar, conversamos y hablamos de oración en forma de música y poesía con Maite López y Ana Medina. Escuchar audio

En este 5º ‘Artesanos de la fe', en nuestra cuarta temporada, hablamos los primeros minutos con Laura Cañete que junto a su esposo han adoptado valiente y generosamente tres hijos de China: Marcos, Rocío y Teresa. Nos recuerda que estos niños son suyos desde toda la eternidad porque así lo ha querido Dios; lo único que para encontrarse tuvieron que recorrer una gran distancia. Que el Señor les había pensado y que estaba todo perfectamente orquestado para que milagrosamente se produjera ese abrazo eterno. Como dice Laura, si tener hijos es una bendición, tenerlos por adopción es una caricia especial.En el tiempo de literatura nos acompaña la periodista Ana Medina para presentarnos “Vagón silencio. Oraciones desde el tren” editado por PPC. Versos que nos invitan a profundizar en nosotros mismos, a despojarnos de lo que no es esencial; conversaciones con el Señor en lo más profundo. Como ella misma cuenta, es Dios quien escribe, el que hilvana esa poesía alumbrándole palabras.Y en los minutos dedicados a la música estará con nosotros Pablo Sanz, joven cantante católico que con solo 15 comenzó a componer canciones. Cinco años después se consagró a Dios en el Instituto Secular Cruzados de Santa María. Desde...

En este 5º ‘Artesanos de la fe', en nuestra cuarta temporada, hablamos los primeros minutos con Laura Cañete que junto a su esposo han adoptado valiente y generosamente tres hijos de China: Marcos, Rocío y Teresa. Nos recuerda que estos niños son suyos desde toda la eternidad porque así lo ha querido Dios; lo único que para encontrarse tuvieron que recorrer una gran distancia. Que el Señor les había pensado y que estaba todo perfectamente orquestado para que milagrosamente se produjera ese abrazo eterno. Como dice Laura, si tener hijos es una bendición, tenerlos por adopción es una caricia especial.En el tiempo de literatura nos acompaña la periodista Ana Medina para presentarnos “Vagón silencio. Oraciones desde el tren” editado por PPC. Versos que nos invitan a profundizar en nosotros mismos, a despojarnos de lo que no es esencial; conversaciones con el Señor en lo más profundo. Como ella misma cuenta, es Dios quien escribe, el que hilvana esa poesía alumbrándole palabras.Y en los minutos dedicados a la música estará con nosotros Pablo Sanz, joven cantante católico que con solo 15 comenzó a componer canciones. Cinco años después se consagró a Dios en el Instituto Secular Cruzados de Santa María. Desde...

Hablamos con Ana Medina (@asidesastre) sobre el Sonorama en época pandémica y otros entresijos de su trabajo.  Sugerencias musicales: Paul Wagner - https://open.spotify.com/artist/7vtoLCbAcNV4aSjSEuDUhT?si=CxObdFUpSLa5TXcA1ijgaw&dl_branch=1 The brook & the bluf - https://open.spotify.com/artist/4dWtsQvuME6tCWFycaTvO7?si=ufQff9gvQ2aTCsDfowVwAw&dl_branch=1 Dani - https://open.spotify.com/artist/4sYXzPulKYxOYuDKS1px8Y?si=-qVyy-bKRJKvlnY1fEyWMA&dl_branch=1 Jack Bisonte - https://open.spotify.com/artist/6eSj17rHHO3POzZrdmBYMT?si=RzDJ6dZGRpe9fNJ4vvmoYQ&dl_branch=1 Bruna - https://open.spotify.com/artist/7bcpRI8DlLBkUfRqPTOUZ3?si=jCTtJJvzTtSVOCq2ZZLVfg&dl_branch=1 Noticias: Xoel López reúne a la banda de Deluxe Apple presenta SPARK empezando por Under the sun Festival Rio Babel 2022 presenta a C. Tangana como cabeza de cartel Red Hot Chili Peppers anuncia que su gira pasará por España  Contacto @Cablesyteclas cablesyteclas@gmail.com www.cablesyteclas.com Youtube: bit.ly/CyTYoutube --- Send in a voice message: https://anchor.fm/cablesyteclas/message

Hoy con Ana Medina al frente y con el análisis de Fernando Vidal y M.ª Teresa CompteHoy con Ana Medina al frente y con el análisis de Fernando Vidal y M.ª Teresa Compte.Entrevistas a María Berazaluce, integrante de la parroquia Virgen del Camino en Collado Villaba (Madrid); a Enrique Alarcón, presidente de Frater España; y a Mons. Jonny Eduardo Reyes, obispo del Vicariato Apostólico de Puerto Ayacucho, en Venezuela.

In this episode, we cover: Intro and an Anecdote: 00:00:27 Early Days of Chaos Engineering: 00:04:13 Moving to the Cloud and Important Lessons: 00:07:22 Always Learning and Teaching: 00:11:15 Figuring Out Chaos: 00:16:30 Advice: 00:20:24 Links: Apex: https://www.apexclearing.com LinkedIn: https://www.linkedin.com/in/mdcsaenz TranscriptJason: Welcome to the Break Things on Purpose podcast, a show about chaos engineering and operating reliable systems. In this episode, Ana Medina is joined by Carmen Saenz, a senior DevOps engineer at Apex Clearing Corporation. Carmen shares her thoughts on what cloud-native engineers can learn from our on-prem past, how she learned to do DevOps work, and what reliable IT systems look like in higher education.Ana: Hey, everyone. We have a new podcast today, we have an amazing guest; we have Carmen Saenz joining us. Carmen, do you want to tell us a little bit about yourself, a quick intro?Carmen: Sure. I am Carmen Saenz. I live in Chicago, Illinois, born and raised on the south side. I am currently a senior DevOps engineer at Apex and I have been in high-frequency trading for 11 out of 12 years.Ana: DevOps engineers, those are definitely the type of work that we love diving in on, making sure that we're keeping those systems up-to-date. But that really brings me into one of the questions we love asking about. We know that in technology, we sometimes are fighting fires, making sure our engineers can deploy quickly and keep collaboration around. What is one incident that you've encountered that has marked your career? What exactly happened that led up to it, and how is it that your team went ahead and discovered the issue?Carmen: One of the incidents that happened to us was, it was around—close to the beginning of the teens [over 00:01:23] 2008, 2009, and I was working at a high-frequency trading firm in which we had an XML configuration that needed to be deployed to all the machines that are on-prem at the time—this was before cloud—that needed to connect to the exchanges where we can trade. And one of the things that we had to do is that we had to add specific configurations in order for us to keep track of our trade position. One of the things that happened was, certain machines get a certain configuration, other machines get another configuration. That configuration wasn't added for some machines, and so when it was deployed, we realized that they were able to connect to the exchange and they were starting to trade right away. Luckily, someone noticed from external system that we weren't getting the positions updates.So, then we had to bring down all these on-prem machines by sending out a bash script to hit all these specific machines to kill the connection to the exchange. Luckily, it was just the beginning of the day and it wasn't so crazy, so we were able to kill them within that minute timeframe before it went crazy. We realized that one of the big issues that we had was, one, we didn't have a configuration management system in order to check to make sure that the configurations we needed were there. The second thing that we were missing is a second pair of eyes. We need someone to actually look at the configuration, PR it, and then push it.And once it's pushed, then we should have had a third person as we were going through the deployment system to make sure that this was the new change that needed to be in place. So, we didn't have the measures in place in order for us to actually make sure that these configurations were correct. And it was chaos because you can lose money because you're down when the trading was starting in the day. And it was just a simple mistake of not knowing these machines needed a specific configuration. So, it was kind of intense, those five minutes. [laugh].Ana: [laugh]. So, amazing that y'all were able to catch it so quickly because the first thing that comes to mind, as you said, before the cloud—on-prem—and it's like, do we start needing to making ‘BC', like, ‘Before Cloud' times when we talk about incidents? Because I think we do. When we look at the world that we live in now in a more cloud-native space, you tell someone about this incident, they're going to look at us and say, “What do you mean? I have containers that manage all my config management. Everything's going to roll out.”Or, “I have observability that's going to make us be resilient to this so that we detect it earlier.” So, with something like chaos engineering, if something like this was to happen in an on-prem type of data center, is there something that chaos engineering could have done to help prepare y'all or to avoid a situation like this?Carmen: Yeah. One of the things that I believe—the chaos engineering, for what it's worth, I didn't actually know what chaos engineering was till 2012, and the specific thing that you mentioned is actually what they were testing. We had a test system, so we had all these on-prem machines and different co-locations in the country. And we would take some of our test systems—not the production because that was money-based but our test systems that were on simulated exchanges—and what would we do to test to make sure our code was up-to-date is we actually had a Chaos Monkey to break the configuration.We actually had a Chaos Monkey and it would just pick a random function to run that day. It would be either send a bad config to a machine or bring down a machine by disconnecting its connection, doing a networking change in the middle to see how we would react. [unintelligible 00:05:01] with any machine in our simulation. And then we had to see how it was going to react with the changes that was happening, we had to deduce, we had to figure out how to roll it back. And those are the things that we didn't have at the time. In 2012—this was another company I was working for in high-frequency trading—and they implemented chaos engineering in that simulation, specifically for them, we would catch these problems before we hit production. So yeah, that's definitely was needed.Ana: That's super awesome that a failure encountered four years prior to your next company, you ended up realizing, wait, if this company actually follows what they do have of let's roll out a bad deploy; how does our system actually engage with it? That's such an amazing learning experience. Is there anything more recent that you've done in chaos engineering you'd want to share about?Carmen: Actually, since I've just started at this company a couple of months ago, I haven't—thankfully—run into anything, so a lot of my stories are more like war stories from the PC days. So.Ana: Do you usually work now, mostly on-prem systems or do you find yourself in hybrid environments or cloud type of environments?Carmen: Recently, in the last three to four years I spent in cloud-only. I rarely have to encounter on-prem nowadays. But coming from an on-prem world to a cloud world, it was completely different. And I feel with the tools that we have now we have a lot of built-in checks and balances in which even with us trying to manually delete a node in our cluster, we can see our systems auto-heal because cloud engineering tries to attempt to take care of that for us, or with, you know, infrastructure as code, we're able to redeploy at will. So, with the cloud infrastructure, a lot of what would cause me anxiety and give me more white hairs is slightly less than [unintelligible 00:06:51].Ana: I love the way of putting it the less amount of white hairs is because of cloud. So, thank you all, cloud providers. As this comes to mind and we think about your background of coming in from on-prem systems, is there anything that you've encountered in this cloud world that you think that's a gotcha? Like, I've had an incident in bare metal that cloud is not really necessarily having a use case or reliability mechanism built-in, just out of the box.Carmen: It's easy to catch, but it's a gotcha at the same time. So, when you come from on-prem into Cloud, the networking is… not all the same. The words are there from networking, like ‘gateway,' and ‘firewall,' click a few buttons, as opposed to you running [Arista 00:07:38] commands versus on a router. [laugh]. And then you have your VPC, which you can say that's your little world and your internal network.The words are there, but they're different in cloud, and that's the got me part of that transition. But at the same time, you have an easier way to visualize those things. For example, if my machine can't connect to another machine, are they in the same subnet? I don't have to run Arista commands to figure that out, or look at the logs on the router; it's literally right there in front of me. So, a lot of that pain that we would have to going—you know, switching from—going to your Linux machine to then getting into the router and then running these different commands, I feel like you needed to learn more commands and more different types of languages of the things that you were using in order to interact with, as opposed to now in the cloud, I feel that those things are more blatantly in front of you to fix.And they were a little bit more abstract in on-prem and that's why you would need someone like a network engineer more as opposed to a DevOps engineer who—I feel like it's easier in that sense. So, once you know it, you're able to solve those problems that you would need a networking engineer for.Ana: I guess now when we look at the DevOps site reliability engineers have this cloud world or this hybrid world, you end up wearing a lot of hats and you end up having to master, to an extent, various levels of networking, or knowing at least the operator side of how a lot of our infrastructure is running. It does bring me to the next question where you get a chance to come from that BC world—Before Cloud—and we now see that a lot of DevOps SREs that are joining in, they come into the magic of the cloud. What do you think is one of the things that the engineers that are just getting started and are just touching the cloud are not getting a chance to dive into, that the cloud abstraction layer really misses out on this amazing fundamental of the work that we do.Carmen: I think it goes down to the nitty-gritty. With DevOps, you wear many hats. You're good at everything, but not a master of one thing. You're a little bit everything [unintelligible 00:09:49]. Before cloud, even though the term DevOps didn't exist and you were called, like, an operations developer, operations engineer, you worked closely with the people who wore that one hat and you were working with them.And now that people are coming into the cloud only with no on-prem, they get the layers abstracted on what is the three-way handshake in networking? What is indexes really used for in databases? How do you know that you're not using—doing a linear search because your indices are incorrect in your database, versus doing an algorithmic search with that specific algorithm, that specific query language is using. Those are things that are so abstracted but are still very necessary because you may have to work with an on-prem system that connects to your cloud infrastructure and you may need to use Wireshark.Who still uses that? But you do. There's systems, older mainframe systems that mainly finance uses, or there's still COBOL systems out there. So, I feel that's what's missing from being in cloud. But I hope that education and other programs like Courseras and Lindas that if people feel like they're lacking in something, they're able to go and learn those fundamentals somewhere.Ana: I know you love learning. Two things come to mind. Do you have any resources where DevOps and SREs can start learning more? And do you want to share with our listeners a little bit more about your passion and your path in learning?Carmen: Sure. So, a lot of the things that people look at are common things like Udemy. I feel that Udemy has a lot of great DevOps courses, believe it or not. I have used them to study, I've used them for refreshers. I came in with Amazon cloud experience but no Google Cloud experience, so I basically took a Udemy to get my feet wet, as you would say, to get into that world.Linda is also good. If you have your student ID email, you can get it for free. So, [laugh] as a student, now, I use that. And then there's just various resources. A good thing, also, like, finding groups like Techqueria DevOps, as well as Latinas in Tech, and TECHNOLOchicas that if you join groups where you meet other people who are starting in that space or have been in that space for a long time, they have the resources as well. But those are the resources.Ana: Do you want to share a little bit more about your path on learning about DevOps and what you're up to now?Carmen: With DevOps, since I'm passionate in learning—because in DevOps, you have to always keep learning—as I was going through my education, and even now being in industry, is that I don't know that many Latinas, especially back in the 2000s. What I noticed when I was in school is also that the majority of my teachers were men, they went to Harvard and MIT, and their great schools, majority of them, were [unintelligible 00:12:35] and I never had a Latina teacher or any of that. And I said to myself that I wanted to be that teacher that I didn't have. So, I started teaching part-time at my alma mater, at Loyola University. And I loved it.And I loved—I taught, like, data structures in [C+ 00:12:55] and Java. I've taught DevOps classes, I've taught bash scripting, I've taught open-source computing, intro to object-oriented programming. And I just loved engaging with students. I've noticed that I knew I was missing something and then I realized it was teaching, being that difference, being that change, being the face that I didn't have. And I figured, what's the best place than my alma mater to start that at?As I was doing this for my fifth year, I realized that if I love it so much, I should do something about it. So, I decided to get a Ph.D. So, 10 years later [laugh], I went back to the school, and I'm currently in my third year at DePaul University in Chicago as a Ph.D. student, working in the American Sign Language Lab Avatar Project, creating an avatar to do not just American Sign Language but other sign languages—yes, there are many different ones. And that's where I'm currently at now because I would love to teach again somewhere, full time, be it after industry or maybe at the same time I'm still in industry. Who knows what the path is. I love teaching, and I love helping, and I love engaging, and I love technology, so that's why I wanted to go back to school and become a teacher, at one point.Ana: So, amazing to see your passions and your background come together into that mission of pushing forward the industry and bringing more representation to it.Carmen: Definitely. Thanks. It's still a [ride 00:14:19]. I don't know what the outcome will be, but [unintelligible 00:14:22] so I just hope that I pass my second exam for my Ph.D. that's coming up in September. [laugh].Ana: I wish you a lot of luck, and I'm sure our listeners are also rooting for you. Are we going to be seeing Dr. Carmen Saenz that's going to be teaching DevOps, teaching [unintelligible 00:14:39], teaching chaos engineering, or would you stick to something more in ASL?Carmen: I think a little bit of both. I think that the experience that I bring as a DevOps engineer is that some of these systems don't exist. Some of the stuff that I was doing that I brought to the lab was, they already have the programmers, but they don't have—they're running on, like, a Windows machine in an internal network at school. So, how can we make this widely available? One of my posters that I did my second year was specifically in engineering, and architecting, and infrastructure that can handle creating high visualizations with, you know, a GPU graphics card, but also being scalable and then it has to be [GDP 00:15:22] compliant because we work with European schools.So, there is DevOps in my Ph.D.; it's just a little hidden. But I'm hoping that I continue to bring that to the table in my lab and the work that I have won't just be on an internal network in three years. I hope in three years, you'll be able to—you all—can connect to it to be like, “That's the work her lab did, and we all know that the reason why it's visually seen by everybody was because Carmen was the one that created the infrastructure for it to work, with a group of other engineers.” So, I'm hoping that I can bring my two loves together in that sense, in three years' time.Ana: I mean, I think you're already doing it. It's super amazing to just even hear when you get those learning stories of someone is an engineer in the industry, has 10-plus years, and then they go and they help assist them that is not tied to our technology space, that is not running on the cloud, that they're running on just one Windows Server and they're hoping to reach, what, 3000 people a month; like, how is that possibly even going to scale for them to be successful? So, I think even you just going into the lab and putting in some of those DevOps principles. And I love also what you mentioned, you know like, how do you make it be a highly scalable system when you're running with so much GPUs, and you have all this different types of compliance in it? Which I think is always interesting when we talk about certain industries, whether it's healthcare or finance, that it's like, yes, we need to have compliancy based on data that we store, but then there's certain regulations and government that might tell us we also might need to have a certain uptime or you might be breaching this type of service-level-agreement.Carmen: So, a lot of the things I'm used to is more internal in the sense of we need to keep our logs X amount of years, and we need to know who logs into what machines. And so a lot of the compliance is pretty standard across the board for a lot of internal networks. But for something as big as this project for the Ph.D. that I'm doing on, our group has to make sure that [GDR 00:17:27] compliance is very different. And what PIA, what data do we have and how can we abstract it or break it down enough where then it won't actually go back to a person? And those are the things that I feel that I personally don't really have to deal with right now at work, but I have to deal with them at school.So, there is a trade-off, something that I'm lacking at my position at work, I actually have to think about, working with different countries, to have this software and the things that they're lacking like now having a scalable uptime system that people can communicate with, that is something that I do here at work; I'm trading off in both places. And compliance is very difficult to [ticket 00:18:10]. That's chaos engineering, too, because you're going to have to hire someone, or third-party company, or yourself have to literally attack your own system and see what you're missing and make sure you're compliant. And I think that's the beauty of—also—chaos engineering, trying to figure that out and making sure [laugh] that you're good, you know?Ana: For these highly visual systems that you have in your Ph.D. program, what are some of the unknowns that you've had to encountered as you're working on them since they're not very similar to the stuff that you work on your day-to-day?Carmen: I actually had to backtrack to my on-prem experience to a point. Unfortunately, the code was written in the late '90s and it's still [unintelligible 00:18:54] like that now, some of it. And it uses an executable; it had to be built by my professor, they gave me the EXE, I had to put it on the machine. And one of the things is, in Amazon, they have your GPU systems, right, and you could say, “I want this server with this graphics card and AMD and so forth.” One of the things that a lot of people don't recall if they never worked on on-prem systems is that drivers are problematic.And as I was trying to run this executable, I kept getting this error and I was like, “This has to be a driver issue, but how do we troubleshoot a driver on a cloud system that is pre-built for you?” So, [laugh] I was trying to figure it out? I'm like, “Is it the executable and how it was built on whatever machine? Or is it the machine that's in the cloud? And if it is, how do I update the driver? How do I downgrade the driver?”And so I had to Google how to downgrade drivers in VMs in the cloud. There's specific commands that you have to run that are AWS only. You don't have the manageability that you had when it's your own on-Prem system. Like, you just know, you run a general AMD command or a general package installer for the driver. It's not the case, all the time, for cloud systems.You have to run a specific AWS command. Luckily, what I found out was my professor, I brought it up to him, and he's like, “Oh, I have this driver. You're using this driver. I need to do some magic on my end to build this executable and it should work on the driver for this VM.” And I was like, “Sure.” But I didn't know how to troubleshoot those things in the cloud. But I knew how to troubleshoot them from back in the day when it was my on-prem system so there—it's weird understanding that drivers are still an issue, you just didn't think so because they're so abstracted nowadays.Ana: It's always interesting to remember where the abstraction layers push us forward in so many ways, but that they always bring this kind of catch on the other side of it of, “Wait, no, now you actually don't get a chance to just drive over to your data center, switch out a certain type of resource. Oh, the cable is starting to look a little hot, maybe we should stretch it out.” We now assume that a lot of these things are being handled for us.Carmen: Yes.Ana: Do you have any advice on how do you maintain systems that you don't build, or how is it that you can hand over things better when you're working with systems that are maybe even BC, Before Cloud? I'm going to trademark this. [laugh].Carmen: You should trademark it because, seriously, that is such a great way to explain it. That was literally what you do when you started a new job, right? They're like, “There's this old system.” I asked if there's any documentation, they usually laugh and chuckle at you. And then [laugh] they give you some notes that tech that some person left for you to look at. “Do you have any infrastructure as code?” They also might slightly chuckle at you and just give you some version that's 15 versions behind, that if you try to [unintelligible 00:21:52], they'll tell you, you're missing 50 other things.So, you do have to work with what you've got. And you're the whole point of being a DevOps engineer is that you investigate, investigate. And you shouldn't be afraid to ask questions. And I think that's something I learned as I got older. I was always afraid to ask questions.And I always felt like people were going to judge the crap out of me because I was asking questions. But how are you going to understand the system that you didn't build, and try to get into the head of the person that did build it in order for you to make it better? And… that's okay to ask those questions. And you should get those notes, that tech, and that rando Terraform that only works for a quarter of the things that were built. And see what's missing and try to see if you can devise a plan of attack of how are you going to break this down for yourself.And then, there may not be no diagrams. So, I'm not telling you, use Creately or anything like that to diagram, but it's also good just to have a piece of paper and a pen and just start drawing some of that stuff out. And then, a lot of it also is okay, let's make a test. On Saturday, I'm going to bring this down—chaos engineering—and I'm going to see who yells about it. Who's going to care?Who's going to care if I break this. And that's how you know who are the stakeholders. Sometimes, that's what you need to do; you need to create a little chaos, to understand what your next steps are in order to get rid of all that technical debt to make your company and your product better. That's how you have to start, and then from there, you'll get more stakeholders that are going to care because you caused a little chaos, in order to bring the system up-to-date, that is not yours, that now is yours. [laugh].Ana: You actually touched upon something that I was telling someone about two weeks ago where it's that we have this mental model of what our system looks like, they gave us an architecture diagram because, you know, this was only built five years ago, but we now have the thought that all of this is perfect, and until you start unplugging things, you start doing some chaos engineering of what in this architecture diagram is actually correct? What is not? Do I really have a database in my high critical services, or do I not? And then you can kind of really start thinking about understanding your system and build it to be better.Carmen: And also, one of the things that is just because it says dev, don't assume it's dev. It might be prod. Just because it's called dev doesn't mean that it's dev. That is one of my biggest rules now that I've learned recently in the last three years. Because with cloud, it's a little bit different than on-premise: if that's the name, that's what it's going to stay and most likely it is what it is. But here, because we're iterating so quickly, we try to fail fast in order for us to learn from our mistakes and build our product, dev becomes prod. [laugh]. More so now than it did before, you know?Ana: It brings me to that portion you mentioned also earlier: always ask questions. Always poke holes at it. If someone tells us, “Oh, no, don't worry, nothing is running here on production,” take a deep dive and try to find out what are some of those services, or what are some of those dependencies that could be going on. I know from my time at Uber, it took forever for us to find out which of the 2000 microservices are needed to just take a trip on the cloud. And it was like, “Uh, we don't know. We know they're running on prod, they're running on dev, but what is needed for this service to actually happen?”Carmen: Exactly. Sometimes just getting on the machine. And if you have root—which you should—if you're a DevOps engineer, usually—look at the history and then look at the directories of who has a home directory. People don't realize the history can give you so much good nuggets about what's going on in the system. And those are the things that help you figure out, like you said at Uber, what's running on here, and who's using it, and what is the systemd daemon telling me? And like… I mean, right?Ana: And it's funny, you mentioned that of take a look at the history because that was actually one of the things that I've always done, like, reading post-mortems—Carmen: Yeah.Ana: Understanding history that's being run on systems, understanding past PRDs to try to get a better understanding. And a lot of it actually is because of that other point that you also touched upon, being afraid of ask questions. Like, similar to you, I've also been one of the only Latinas in the room, and I'm like, “I don't want to raise my hand in this class, or in this meeting. I don't want to be the person that has to ask.” But if I have ways of starting to do my own searching so I make a more informed question, that gave me confidence. So, that was one of the things that I was always doing. But now I tell people, “No. Just ask the questions. Don't spend those five hours trying to look at history because the person next to you might actually know the answer in just two minutes.”Carmen: Yeah, exactly. And I noticed that. Just asking that question was literally like, “Oh, it was because of X, Y, and Z.” “Okay, cool.” And then, now that I know that, at least when I look at the history, I have some background of why this was this way, and now I can just pull out what I really care about in the history, as opposed to saying, “Why is this happening in the [unintelligible 00:26:59] in the first place?”But it's sucks being the first person to ask that question. And especially if it's just, like, you and a bunch of dudes—which usually it was, and at the time I was usually the youngest, too. I was, like, 22. Up until now, obviously; now I'm one of the oldest, but at one point, I was the youngest. And also age was a thing, and being the only Latina in the room, and it—you know, and it's finance; it was scary. [laugh].Ana: [laugh]. That's the awesome part. We got to have folks like you, like me, organizations like TECHNOLOchicas and Techqueria that allow for us to create spaces that are going to say, “You're welcome here. Ask as many questions as you want. No question is going to be stupid.”Because we've all had to start somewhere. And maybe you do get a chance to have Carmen as your teacher and get to pick their brain on what DevOps is. For that, I think that's all the questions that I had. Do you have anything else you want to share with our listeners that you have upcoming for you? Or just any words of advice?Carmen: My advice is just keep trucking along. There's many Carmens, there's many Anas, there's many Jason's out there that are willing to help. And there's spaces now where we can ask those deep questions, like you said, like Techqueria, Latinas in Tech, TECHNOLOchicas, [unintelligible 00:28:17] Girls Can Code, Girls Who Code. There's so many places now where you can really dig in and find the community to uplift you and keep pushing you forward in your technology inquiries and your technology career path. So, stick with it, keep going.Ana: I love it. What are some ways that folks can get in touch with you?Carmen: You can go to my LinkedIn, and the LinkedIn will be the slash name, slash M-D-C-S-A-E-N-Z. Or you can find me under Carmen Saenz at Techqueria Slack, or in Latinas in Tech Slack.Ana: Awesome. Thank you so much, Carmen.Carmen: Thank you so much for having me. I had such a great time with both of you.Jason: For links to all the information mentioned, visit our website at gremlin.com/podcast. If you liked this episode, subscribe to the Break Things on Purpose podcast on Spotify, Apple Podcasts, or your favorite podcast platform. Our theme song is called, “Battle of Pogs” by Komiku, and it's available on loyaltyfreakmusic.com.

Hoy con Ana Medina al frente y con el análisis de José Beltrán y Ricardo BenjumeaHoy con Ana Medina al frente y con el análisis de José Beltrán y Ricardo Benjumea. Entrevistas a Manuel Gestal, director de Cáritas Diocesana de Ceuta, al cantautor católico Jesús Cabello y al P. Paul-Fils Belotte, S. J, director de Fe y Alegría en Haití.

La Linterna de la Iglesia con Ana Medina, Julio Ruiz y Laura DanieleLa Linterna de la Iglesia con Ana Medina, Julio Ruiz y Laura Daniele. Conectamos con la corresponsal en El Vaticano, Ángeles Conde. Entrevistas: María Solano, decana de la facultad de Periodismo de la Universidad San Pablo CEU. Paloma Saborido, cofrade, pregonera de la Semana Santa y directora del Comité Científico del IV Congreso Internacional de Cofradías. Carlos Balbé, responsable del departamento de deportes de la Conferencia Episcopal Española

About JasonJason Yee is Director of Advocacy at Gremlin where he helps companies build more resilient systems by learning from how they fail. He also leads the internal Chaos Engineering practices to make Gremlin more reliable. Previously, he worked at Datadog, O'Reilly Media, and MongoDB. His pandemic-coping activities include drinking whiskey, cooking everything in a waffle iron, and making craft chocolate.Links: Break Things On Purpose podcast: https://www.gremlin.com/podcast/ Twitter: https://twitter.com/gitbisect TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored by ExtraHop. ExtraHop provides threat detection and response for the Enterprise (not the starship). On-prem security doesn't translate well to cloud or multi-cloud environments, and that's not even counting IoT. ExtraHop automatically discovers everything inside the perimeter, including your cloud workloads and IoT devices, detects these threats up to 35 percent faster, and helps you act immediately. Ask for a free trial of detection and response for AWS today at extrahop.com/trial.Corey: This episode is sponsored in part by LaunchDarkly. Take a look at what it takes to get your code into production. I'm going to just guess that it's awful because it's always awful. No one loves their deployment process. What if launching new features didn't require you to do a full-on code and possibly infrastructure deploy? What if you could test on a small subset of users and then roll it back immediately if results aren't what you expect? LaunchDarkly does exactly this. To learn more, visit launchdarkly.com and tell them Corey sent you, and watch for the wince.Corey: Jason, thanks for joining me.Jason: Thanks for having me, Corey.Corey: So, you're one of those people that we've always passed at conferences and other events, sort of like ships in the night. We hang out in group settings, but strangely, for whatever reason, despite traveling in the same circles for years now, we've never really sat down had an in-depth conversation with each other to the point where I feel like both of us are sort of wondering on some level, “Does he just not like me?” It's been one of those items for me of, I want to catch up with Jason at some point and learn what makes him tick. And then pandemic happened. Well, no more. Thank you for talking to me.Jason: Yeah. And again, thanks for having me. I've always felt the same way. We're always at these speaker dinners, or just hanging out with friends, and for some reason, I'm, like, at one end of the table, and you're at the other. And we've just never had this opportunity.Corey: Exactly. Because you actually do a lot of good in the community, and I'm usually at the kids table. Which is, frankly, what happens, and honestly, it's the right call. But you and I, I guess, are aligned in a few weird and interesting ways. And—well, let's talk about what you do. You're the Director of Advocacy at Gremlin. What is Gremlin, first off, and then what is a Director of Advocacy really do?Jason: So, Gremlin is a chaos engineering platform, or a reliability platform as we're trying to sell it now. Because we started out doing chaos engineering, so some of the folks that were doing chaos engineering back at Netflix and back at Amazon, decided, most people aren't Netflix, most people aren't Amazon; let's build something that everybody can use. So, Kolton and Forni, our founders, got together, they started this up. And the idea is really, how can we help people make things more reliable? And obviously, chaos engineering is one of those ways, so that's what they started off with.And we've got a platform that really just makes that easy and safe to do. So, the second question about what is Director of Advocacy? I know you like to make fun of AWS naming, and I feel like it is sort of a weird, nonsense name because it doesn't actually explain anything. But essentially, it's developer relations. So, I have the task of talking to all sorts of folks who aren't customers—really, just anybody in tech—about chaos engineering and why they should be doing it, and how to make applications and systems more reliable.And then, aside from that, I also get to interact with our customers and help them out. So, I'm a combination of customer success or success engineer slash support slash the advocate side is advocating for their needs within the organization. So, when they make a product request, I pass that on, see what we can do about that. So, it's sort of a mishmash of all these different roles.Corey: I want to draw a bit of a parallel that DevRel slash advocacy slash evangelism universe to the sysadmin world where then we started calling ourselves DevOps and that led to an enormous schism around is DevOps a job title or not? “No, but it pays a lot better, so yes.” Then SRE. “Well, you're not real, SRE,” and the rest. It comes down to quibbling over definition of terms instead of, you know, doing work. And I feel like, on some level, the whole DevRel space has, in some respects, gotten twisted around something that resembles the same axle. Is that unfair?Jason: No, that's absolutely correct. There is that question of what is DevRel? How do you define it? And part of that is how do I justify my job? And on top of that, how did—at least pre-pandemic, how do I justify the company spending tens of thousands, if not hundreds of thousands of dollars, not only for my salary but to fly me around the world to get on stage and say things.Corey: Right. And it looks from a distance, an awful lot like, okay, you cost as much as an engineer, you don't write any code to make what we do any better. Your expense budget is about the same as your salary in some cases, and then you travel far away to what looks like a giant party to hang out with your friends. And you get on stage and say, “I work at company X. Thanks. They're great. Now, for the next 45 minutes, let's talk about the right standing desk for you.” And it becomes a very difficult sell internally. And for a group that prides itself on advocating for its company. They don't often seem to do as good of a job advocating for themselves, internally.Jason: Absolutely. There's always the discussion of KPIs. How do we measure the impact of what developer evangelism, DevRel does? And it's a hard thing, partly because every company is a little bit different. Because nobody's really defined this, DevRel often is very fluid and just fills in the cracks of whatever a company needs.So, for some companies that might be doing support, right? I've heard people being called DevRel, and they literally are just on forums all day answering questions, or writing documentation, or speaking. So, it's really just this nebulous thing of whatever a company needs.Corey: It becomes almost this weird expression, in some respects, of marketing. Of course, a lot of DevRel folks will scramble at the objection, “Oh, we are not in marketing.” And that's always said with a very sneering tone towards marketing because those people are terrible. I argue that marketing is, A) wildly misunderstood, B) incredibly valuable, and C) where DevRel in many respects finds its spiritual home because it's very hard to tie your marketing budget as a company to definable results and do attribution effectively, but there's clear value to the company in things that can't necessarily be measured, or at least not without a heck of a lot of work. That is the piece, in many respects, the DevRel is missing. But the first thing that they want to make clear is that we don't work for marketing. It's a very weird feeling.Jason: It's very weird because as I explain that DevRel often is filling in the cracks and is very fluid, that's because my personal perspective of DevRel is inclusive. I try to get involved in as many teams as I can, so I'm constantly working with engineering, and with marketing, and with customer success, and really everybody. And then on the flip side, you have people that define it by what it's not. I'm not marketing, I'm not this. And you end up cutting yourself off.Corey: And neither are you an accountant, but I didn't ask if you were, so yeah.Jason: But at the same time, you're not an accountant, but you should have some sort of notion of what the finances of the company are because that gives you some sort of indication on whether you're going to get laid off, for one, but also just for the success of the company. And I think maybe it's just the engineering mindset that I've had from being an engineer of you take everything that and you try to learn everything that you can and put it together. And so, for me, that comes from having experience working in marketing, having experience working in engineering; how can I put these things that I know together to solve a problem? So, rather than saying, “I'm not marketing,” I'm going to ignore that because as you mentioned, marketing's super valuable, especially the way that they've done data-driven marketing now. It used to be like madmen days, you'd throw up a billboard, and who knows if it works, but you paid a bunch of money for it. And now they're so data-driven, and everything's tracked. And, yeah, you may not be able to directly connect a few things, but you get a much better sense of where your value is, and where your time should be spent.Corey: Absolutely. And you can get—I don't know—the 80% of the way there, and then the last 20% will drive you mad, so at some point, you just shrug, give up, and that's okay. Similar in many respects to an AWS bill. It just becomes such a weird process to explore. And from a certain lens, when you have those cross-cutting functional types who are doing DevRel, they start to sound almost enthusiastic amateurs in the various disciplines that they bring together.“Yes, I'm an engineer, but not as deep on the engineering side, as some of my colleagues who do engineering 40 hours a week and then some.” “Oh, we're part of product.” But strangely, to work in product you usually have significant experience and training in how to conduct user experience studies and user interviews, whereas an awful lot of the DevRel input back to product is ‘word on the street style' stuff.Jason: Yeah. And both are extremely valuable. It's obviously very valuable to have that process of doing user studies and actually getting that hard data, but as we all know, that word on the street and what's the general vibe of folks at a conference or folks at a meetup really informs things that usually doesn't get asked in those formal user studies.Corey: Completely. And telling stories from my own world, back when I was, you know, having a real job and able to be fired by a whole bunch of different people—and was—there was the constant justification story of why should you go to that conference and speak? Why would we spend that money? Why shouldn't it just be a personal thing that you take vacation for? Now that I own the company, it's a different story because I know that when I go out and participate in the community, good things happen, but I don't have the need anymore to justify it, other than to myself and possibly to my business partner.There are very real stories that I've looked at here where I go to a conference, I start talking to someone, we keep in touch, they wind up changing companies, we continue to talk, suddenly, they have an AWS bill problem, and now they become a customer. Yeah, it turns out that's super hard to predict when you're looking at flight prices to go to that conference in the first place. And there are many other conferences that nothing came out of it, I think, but you never really know.Jason: Yeah. One of the nice things about my job and one of the reasons that I joined Gremlin was the idea that chaos engineering is still pretty new. And so in my past experience with DevRel, it very much was your exact experience; how has what you said on stage or the introduction of our brand to an audience made an impact? And since chaos engineering has been so new, I've gotten to take a little bit of a step back from that. Obviously, I want people to get Gremlin or to try Gremlin, but even if folks just try chaos engineering and have a better understanding of it, that's a big goal of my job. That means that I win if you try chaos engineering, even if that's with an open-source tool. So, that's one of the reasons that I'm super happy about where I'm at right now in terms of DevRel is, I get to be DevRel for an entire practice, rather than just a company.Corey: And, on some level, you get to define what success and failure looks like among your team. But turn it around for a second; how do you wind up articulating the value and story of what you do to the larger business? Because I've seen the approach if you can't measure DevRel that way—regardless of what that way is—and it's always this, don't ask us for metrics. Don't ask us to really, functionally, be accountable for much. And from a business strategic point of view, where you're not deeply involved with aspects of what that leads to, “Okay, so it rounds to zero, and wow, I'm spending an awful lot of money on something that doesn't really add any value. I could spend that money on things that do instead.” And then you see a bunch of negative things happen. Like, as soon as there's a layoff or a downturn, that entire group winds up getting decimated in some cases, even when, in reality, that's the thing that should be invested in the most.Jason: Absolutely, yeah. One of the things that I've always loved is people talk about metrics. And yes, we definitely get that from the marketing side. And so I do have metrics on things like how many workshops we run. And those people are obviously, we capture those leads, they go through the marketing funnel, et cetera, et cetera.But then there's the idea of how many engineers out there have those same metrics? We always complain about you shouldn't count the number of lines of code because that's stupid. You shouldn't count all these other things. But generally, most engineering teams are working off of quarterly OKRs or some sort of time period, what those goals are and the product that they're going to ship. And so I've tried to adopt the same thing in every DevRel organization that I've been in, is what are the high-level goals?And if you can get leadership to buy off on those, for example, we're currently working on an online learning platform. We don't have tight metrics about how many people should be registered and complete the course and be certified yadda, yadda, but we have a good sense that if we build this, it's going to be very beneficial in a number of ways. And leadership agrees, and they've bought off on that, and they've signed their names to it. And so for us, what does success look like in terms of this is actually implementing that and shipping it.Corey: It's a really strange and really powerful thing, but you take a look at so many different companies who have done well and companies that haven't done well, and the way that they engage not just with the ecosystem, but with the community specifically, in many cases seems to be the path that it follows. I mean, not to pick on them unnecessarily, but Chef had a wonderful community; they engaged absolutely flawlessly, from what I could tell, even when I didn't agree with people or particularly like them in some cases, the people who worked at Chef almost demanded respect, and it was pretty clear, even as someone who didn't use it myself, that they were a force to be reckoned with. And then they wind up effectively losing a lot of the people that made it special, the community moved on, they sold it to a company no one had ever heard of, and now it's one of those, oof, they deserved a better end. Maybe that's unfair, but that is the perception.Jason: Yeah, I would say the same thing sort of happened with Puppet, the idea that they built a nice community, and back to my point of, like, you have a project, you work on shipping that, you don't really track those numbers. That's what I saw from both communities Chef and Puppet is they had these strong communities, they were doing things, and the goal was the community. And I don't know—I haven't talked to Nathan, I haven't talked to folks at Puppet, but I suspect that they weren't simply about how many people—like, what's the total number of people that we would say are in our community? There was a value on, we want to do this thing and we have a sense of the quality of the community, and how much people just are engaged, and interested, and want to help each other.Corey: The piece that also gets lost as well is companies are out there to turn a profit. And building a vibrant open-source community who loves your open-source offering but aren't in a position to either champion or purchase the thing is often viewed as a complete waste of time by the business. So, they in turn, then pivot business models and do things that insult or alienate the community, and suddenly are perplexed by the massive groundswell of negative publicity they get, of people actively advocating that companies not use them. And their position is somewhat understandable in a form of, “What the hell is this? You weren't spending money on us before. Now, you're still not spending money on us, but you hate us. What gives?” Community is a weird thing to wrap your arms around.Jason: Absolutely. I would say it's hard to wrap your arms around it when you're not valuing the relationship. It's like any relationship where you have ulterior motives. If you can't actually connect with people, it's never going to go right.Corey: No. And it also can't be self-serving, or seem to be self-serving—spoiler, the best way to make sure you're not perceived a certain way is to not actually be that way—we take a look at Last Week in AWS, my newsletter, it is explicitly aimed at people who want to keep up with what's going on in the world of AWS, which is fair. It is not aimed at people who have a big AWS bill and don't know what to do about it. And sure I reference periodically in that newsletter what I do, but it's not a sales piece. It's not every week hammering home, buy whatever it is I'm selling because that's how you alienate and lose the audience.I've always felt that by being top-of-mind for the problem and reminding people I exist every week with something that's useful and ideally a bit funny, then, when they have that expensive problem, they'll think of me. That was my theory four years ago, and I'm still here, so apparently, it wasn't completely off base.Jason: Yeah, well, that works, right, because nobody wants to subscribe to a newsletter to hear about the service. If they knew they needed your service, they would just buy your service. So, what's the value of the newsletter? What's the value that you're offering to people? And that is, well, the fact that there's so much freaking news about AWS every week that it does require a newsletter.Similarly for me, what's the value? Well, if people knew that they needed Gremlin, they would just come talk to me. But they don't. They were concerned about the needs that they have, about how do I build a more reliable application, “My stuff's always breaking. I'm having too many incidents. I've done everything that I can think of. What's next.” So, it's just offering that.Corey: If your mean time to WTF for a security alert is more than a minute, it's time to look at Lacework. Lacework will help you get your security act together for everything from compliance service configurations to container app relationships, all without the need for PhDs in AWS to write the rules. If you're building a secure business on AWS with compliance requirements, you don't really have time to choose between antivirus or firewall companies to help you secure your stack. That's why Lacework is built from the ground up for the Cloud: low effort, high visibility and detection. To learn more, visit lacework.com.Corey: And let's be very clear here, you have a much harder challenge than I do. Because it turns out that you don't need to be deep into the weeds of corporate finance, to understand the concept of wasting money on the AWS bill might not be the best thing in the world. Once you get more into the nuances, you start to realize, “Oh, being able to predict the AWS bill sounds super awesome, too.” But none of those are a particularly heavy lift, whereas, “Wow, your site is crappy and falls over a lot. Have you considered breaking it on purpose?” Sounds deranged the first time someone hears it.Jason: Absolutely, yeah. That's the number one thing that I hear all the time is—and people joke about it. I don't need chaos engineering; I do regular deploys.Corey: That sounds almost like someone was sitting in a blameless post mortem and got carried away trying to keep it blameless because otherwise, it was going to be their fault, and accidentally invented entire field.Jason: Yeah, yeah. I mean, it's definitely blameless if everybody is causing things to break; then we all share the blame. It is a funny thing. It's a tricky thing to sell the people and I think it's tricky because we have these misconceptions about what that actually means, the idea of breaking things on purpose. And trying to move away from that because the breaking really isn't the goal.And oftentimes, they're not actually even breaking things; you're stressing them out or you're simulating things, so nothing's really broken. But once you start thinking of it as that idea of I'm going to test my assumptions, right? I think that things work this way, but I don't know, I'm not super confident that it actually will do that. And we do that all the time when we're developing applications or infrastructure. I set things up, I'm pretty sure that it's going to work a certain way.Documentation says that this app works this way. Does it actually do that? Well, I can either find out when it doesn't do that at some random point, or I can actually try to force it to act in that way, or to encounter that bad environment that I'm a little suspect about. And so we do this all the time with other things. And oftentimes, we'll do this just mentally as, “What would happen if—” and you kind of play it out in your mind.And that's actually a great way to start with chaos engineering, rather than actually doing it, just that mental game. “What do you think would happen if this goes wrong?” Play that out in your head? Cool. Once you're comfortable with that you're like, I think this is what my next steps would be. I'm pretty sure there's documentation here, or I've gone and checked and assured that there's docs, or run books, or whatever, why not give it a try?Corey: It's one of those areas where what have you got to lose? I mean, as you just said, your site breaks all the time anyway, before you even touch it's stability, what happens if the database just suddenly increases latency through the roof? What happens if suddenly all of us-east-1 is hard down? In many cases the answer is, we don't really care about our website anymore because the world is not going to care about the internet not working that day, in the context of what we do. In other shops, yeah, that matters, and we kind of still need the power grid to work.So, there's a definite question of what failure modes are worth planning for and what aren't, but even going through that exercise is fantastic. I used to do things like that from a sysadmin perspective, asking companies when I was asked to build out a mail server. “Great, how much downtime is acceptable?” And they said, “Absolutely none.” I said, “Great. I'll need a budget of $20 billion to start, and when that runs out, I'll come back for more.” And they said, “Wait, what are you talking about?”And we said, “Oh, now we're negotiating with the business.” And it turned out what they really meant was, “It would be nice if the mail server worked during business hours most of the time.” And, “Oh, okay. I can do that for slightly less.” And it really just came down to what do you value? What is important to your business?Jason: Yeah. How much reliability do you need? Although one of the key things that I always point out is, a lot of times people are like, “Oh, you don't need 99.9% reliability; you could probably get by with less than 90 because people aren't using your application at night, they're not using it on the weekends, yadda, yadda.” The other problem with that, though, is you rarely control when those outages happen.So sure, if it happens in the middle of the night, and nobody's using it, great. Just keep sleeping. As you start to work on this, though, there is the idea of it could happen at any time, so let's actually test things to ensure that if it happens at the least opportune time, things actually work the way that we expect.Corey: And that's an incredibly valuable thing. See, you're already convincing me on this. And clearly, you're very effective at that advocacy role. How do you hire and how do you determine who's a great fit? Because I'm imagining that bringing someone in, in an advocate role, and their position being, “Oh, at no point, can you ever measure me on any context, and just assume that what I'm doing is amazing and great.”That becomes a hard thing to do. When I was talking to companies about possibly doing evangelist style roles, years ago, I asked, “How will you know if I'm being successful in this job?” And one of the answers was, “Well, you speak at a certain number of tier-one conferences a year.” “Cool, what are those?” And, they listed off a bunch and cool, there's only one in that list that I'm not scheduled to speak at this year, so do I get a raise?People try and aim at the wrong thing in their quest to articulate what they really value, but what they really value is hard to measure. So, how do you evaluate people on a basis of are they doing what they should be doing, or are there ways that they can be coached to improve, or are they just not effective in the role at all?Jason: Yeah. Well, I think you mentioned two great things, are they doing what they're supposed to be doing? And it comes back to every quarter, we're laying out the goals of what do we want to accomplish this quarter? And we make them achievable, so hopefully, by the end of the quarter, you've achieved this thing that not only the team, but senior leadership has decided is a good thing for the company. And to that point, if it's not, if we do that thing and nothing happens, and it's—or it's bad for the company, at least we can say, “Hey, senior leadership, you are the people that thought this was a good idea, too.” But that said, we try not to do the blame. We try to iterate on things and experiment a lot. Especially at Gremlin, we're all about experimentation, so we're constantly trying things. But ultimately, it's are you getting this thing done that we've agreed that we're going to get done?But you also mentioned that second thing about growth. I think that's something that I always look for with anybody, whether that's DevRel or engineering. I want people that are interested enough in the job that they want to do it well. There's something about it that they really love or they're really into, and they want to master that. And so part of my goal as a leader is trying to help people along that path of what do you find interesting? For example, last year, we were working on those tiers, as we're trying to figure out what does it actually look like. Because we're really small team at Gremlin, and so as I'm starting to consider how do I promote people?What are the various, like, levels or tiers of going from an advocate, to a senior advocate, to whatever is beyond that? So, I asked the team, really, “What do you think that would look like? What do you think the next level for your career is? What is the thing that you want to master?” Because ultimately, people have more investment when they're choosing their destination and they're choosing their direction.And so if I can help people do that, just define what's the next thing that you want to tackle? What do you think mastery or the next level of your career looks like? How can we help you get there? So, that's what I am for.Corey: For better or worse, it seems to be working. I remember back when Gremlin was a rando startup idea a couple people had and now I'm starting to see you folks, basically everywhere.Jason: Yeah. Again, we've got a small team, but it's a great team. So, Ana Medina has been on the team, actually, before I joined, but she's been doing a fantastic job and she has been working on a lot of our educational outreach. And then Pat Higgins on the team actually started on the engineering side. So, he was one of our front-end engineers; he's been working on a lot of really great tools.He helped me restart the Break Things On Purpose podcast. So, we're into season two of that now—and by the way, we should have you on that show as well. But yeah, we're doing a lot of fun stuff, and folks are happy. So, try to keep them challenged, and we'll see what's next.Corey: Yeah, I'm really looking forward to seeing how the story continues to evolve. It's a fascinating field that went from, “That is ridiculous,” to, “Oh, that's great but it would not apply to what I do,” to, in my case, it actually would not help me in any way with what I do because it turns out, well, what if an AWS region goes down and you can't produce your newsletter the usual way? Oh, I'll write it by hand that way because suddenly I have a much bigger story to talk about that week.Jason: I am curious, though, speaking of having you on the podcast. Oftentimes, we talk about reliability, and having never had to deal with AWS bills because they always go to somebody else in finance, I am curious how reliability ties into the cost of what you're paying for AWS? Because I can imagine things like—a common thing that we hear about is, “I'm moving a lot of stuff to Lambdas.” Like, great. Serverless. It's cool, it's hot. How is that charged?Corey: Right.Jason: Obviously, by time.Corey: Oh, yeah.Jason: So, if it's charged by how long something takes, what if your latency goes up? What if your resources are constrained? How does this actually affect things? And how does that impact how you think about reliability not just from a is it up or down? How's my customer looking at it? But maybe from what your AWS bill looks like?Corey: I love where you're going with that. And it's the conversations everyone loves to have as about three levels beyond where most companies actually are. Easy example that sounds like something in the distant past, but it's very real today: I want to store data in multiple availability zones for durability purposes and making sure that we are reliably up. Well, every time a gigabyte crosses an availability zone boundary, that cost two cents. And then you have to pay to store it twice.So, there's a question of how much is having multiple sets of that data worth? And the cloud-native answer to that is, “Oh, put it in S3. There's no cross-charges there. Their durability is ridiculous, and you can access it a whole bunch of different ways, provided your application supports it.” But that's not a fit for everything.And you find that saving money, and being reliable, are at some point completely at odds with each other. And this is incidentally, why we don't do this as a tool, we do it as a consulting engagement. There are times where, for business purposes, you will want to spend more on reliability. Because saving money that accidentally takes your company down for a month is not money you should be saving.Jason: Yeah.Corey: Now, the real fun thing I want to see from Gremlin one of these days from a implementation perspective is, just for fun, we're going to run a chaos injection experiment where we decide to cancel the credit card tied to the account and then also remove the increasingly frantic alerts from your email when that happens, and see how long it takes you to realize the giant single point of failure that no one really thinks about existing, but absolutely does.Jason: So, I am curious, for folks that are listening who are engaged with the chaos engineering community, or at least follow Corey's newsletter and have seen updates, AWS has announced their own chaos engineering tool, the Fault Injection Simulator, which to Coreys skill of poorly named things, that actually isn't a simulator. It does inject real faults, so it may be—S should be service. One of their faults, though, that they can do is API throttling, which essentially could simulate the idea of, you haven't paid your bill; we're turning things off. So, Gremlin is working with the AWS folks, we're trying to figure out great ways that we can work together so that people can use both Gremlin and AWS FIS. So, I'll let you know if that becomes a thing, and maybe we can get some API access to billing as well.Corey: I'd love to see it. Please keep me looped in. Thanks so much for taking the time to basically go all over the world of DevRel and probably make some lifelong enemies in the process. If people want to hear more about what you have to say, where can they find you?Jason: Yeah, I'm on Twitter. My Twitter handle is @gitbisect—and by the way, if anybody tweets about Git bisect, it is a fantastic tool, fantastic utility within Git—oftentimes, I will respond. But that's where to find me on Twitter. Otherwise, you can find me on [unintelligible 00:31:30] podcast, Break Things On Purpose. It's available in all the platforms.Corey: Excellent. We will, of course, put links to that in the [show notes 00:31:37]. Thanks so much for taking the time to speak with me. I really do appreciate it.Jason: Yeah, thanks, again. It's been long overdue, and I'm glad we finally made it happen.Corey: Awesome. Jason Yee, Director of Advocacy at Gremlin, I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you hated this podcast, please leave a five-star review on your podcast platform of choice, along with a comment saying that the best thing to test breaking in production is your DevRel team.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.This has been a HumblePod production. Stay humble.

¿Cuánto tiempo pasas al día mirando pantallas? ¿Cuáles son las aplicaciones que más tiempo tienes abiertas en tu móvil, en tu celular? Tal vez te sorprendas cuando seas consciente de la realidad. Y ese es el primer paso. En este episodio nos preguntamos acerca del uso que hacemos de las tecnologías. Intervienen amigos de todo el mundo (¡GRACIAS INMENSAS, sois geniales!).También invito a mis amigos “podcasteros” Pablo Juanarena (autor de series como “BOXKAMPF” o “La vida puede ser maravillosa”), Ana Medina (parte del equipo de “Los Teloneros” y responsable de comunicación de ETM) y Álex Fidalgo (la voz de “Lo que tu digas”). Además le pido ayuda a Antonio Gallego (antoniogallego.me), instructor de mindfulness.

Nobody has foreseen the global pandemic that put a lot of chaos in all our lives recently. Let’s just hope we learn from 2020 to better prepare on what might be next.The same preparation and learning also goes for Chaos in our distributed systems that power our digital lives. And to learn from those stories and better prepare for common resiliency issues we brought back Ana Medina (@ana_m_medina), Chaos Engineer at Gremlin. As a follow up to our previous podcast with Ana, she is now sharing several stories from her chaos engineering engagements across different industries such as finance, eCommerce or travel. Definitely worth listening in as Chaos Engineering was also put into the Top 5 Technologies to look into 2021 by CNCF.https://twitter.com/Ana_M_Medinahttps://www.spreaker.com/user/pureperformance/why-you-should-look-into-chaos-engineerihttps://twitter.com/CloudNativeFdn/status/1329863326428499971

Daylight savings can bring chaos to systems such as rogue processes consuming CPU or memory and therefore impact your critical systems. The question is: how do you systems react to this chaos? How can you test for this? And how can you make your systems more resilient against this chaos?In this episode we talk with Ana Margarita Medina, Chaos Engineer at Gremlin. In her previous job, Ana (@Ana_M_Medina) was a Site Reliability Engineer at Uber where she helped coping with the “chaos” on New Years Eve or Halloween. Ana gives us great insights into the discipline of Chaos Engineering, that its really about running controlled experiment and that everyone can get started that has an interest in contributing to more resilient systems.Here the additional links we promised during the recording: Drift into failure, Chaos Engineering Community, Chaos Engineering and System Resilience in Practice.https://www.linkedin.com/in/anammedina/https://twitter.com/Ana_M_Medinahttps://eng.uber.com/nye/https://www.amazon.com/Drift-into-Failure-Sidney-Dekker/dp/1409422216https://www.gremlin.com/community/https://www.amazon.com/Chaos-Engineering-System-Resiliency-Practice/dp/1492043869

Daylight savings can bring chaos to systems such as rogue processes consuming CPU or memory and therefore impact your critical systems. The question is: how do you systems react to this chaos? How can you test for this? And how can you make your systems more resilient against this chaos?In this episode we talk with Ana Margarita Medina, Chaos Engineer at Gremlin. In her previous job, Ana (@Ana_M_Medina) was a Site Reliability Engineer at Uber where she helped coping with the “chaos” on New Years Eve or Halloween. Ana gives us great insights into the discipline of Chaos Engineering, that its really about running controlled experiment and that everyone can get started that has an interest in contributing to more resilient systems.Here the additional links we promised during the recording: Drift into failure, Chaos Engineering Community, Chaos Engineering and System Resilience in Practice.https://www.linkedin.com/in/anammedina/https://twitter.com/Ana_M_Medinahttps://eng.uber.com/nye/https://www.amazon.com/Drift-into-Failure-Sidney-Dekker/dp/1409422216https://www.gremlin.com/community/https://www.amazon.com/Chaos-Engineering-System-Resiliency-Practice/dp/1492043869

In this podcast, Ana Medina, senior chaos engineer at Gremlin, sat down with InfoQ podcast co-host Daniel Bryant. Topics discussed included: how enterprise organisations are adopting chaos engineering with the requirements for guardrails and the need for “status checks” to ensure pre-experiment system health; how to run game days or IT fire drills when everyone is working remotely; and why teams should continually invest in learning from past incidents and preparing for inevitable failures within systems. Listen to the podcast for more. Curated transcript and more information on the podcast: https://bit.ly/2Pmsq7F Follow us on Facebook, Twitter, LinkedIn, Youtube: @InfoQ Follow us on Instagram: @infoqdotcom Stay informed on emerging trends, peer-validated early adoption of technologies, and architectural best practices. Subscribe to The Software Architects’ Newsletter: https://www.infoq.com/software-architects-newsletter/

For more mental health resources, please go to wewillgetthroughthis.org or facebook.com/wewillgetthroughthis2020. --- Send in a voice message: https://anchor.fm/we-will-get-through-this/message

Ryan interviews Ana Medina who is a Shadow Worker, Pranic Healer and Subconscious Excavator. --- Send in a voice message: https://anchor.fm/thegaggle/message

Hablamos sobre salud infantil y el manejo de crisis en niños desde la convención de la Sociedad Puertorriqueña de Pediatría con las prestigiosas especialistas, Dra. Carmen Suárez, la Dra. Iris Cardona y la Dra. Ana Medina. #SomosCiencia #MSP #LaCienciaesNoticia - - - Ver entrevista en Youtube: https://youtu.be/tNq74ILri_4 - - - Conoce más sobre el cuidado pediátrico: https://pediatriayfamilia.com/ - - - Visíta nuestro sitio web: https://www.medicinaysaludpublica.com/ - - - Síguenos en Facebook: https://www.facebook.com/revistamsp/

Mucha música desde distintos ángulos presiden la 3Luna338. Os presentamos las BASIK SESSIONS de la mano de su fundador ÁLVARO PÉREZ, un evento de música en directo en formato acústico que cada mes da a conocer nuevo talentos de nuestra música. Con él os descubrimos las maravillosas canciones de ASTRO FONDA. De música también hablan LOS TELONEROS el podcast que presentan QUEQUÉ, MIGUEL MARTIN y ANA MEDINA en PHI BETA LAMBA que dan protagonismo a profesionales de distinto perfil dentro de la industria musical de una forma desenfadada y divertida. Y cerramos con una banda que comienza a recoger el trabajo a la sombra de muchos años como es VEINTIUNO. Mucha música desde distintos ángulos presiden la 3Luna338. Os presentamos las BASIK SESSIONS de la mano de su fundador ÁLVARO PÉREZ, un evento de música en directo en formato acústico que cada mes da a conocer nuevo talentos de nuestra música. Con él os descubrimos las maravillosas canciones de ASTRO FONDA. De música también hablan LOS TELONEROS el podcast que presentan QUEQUÉ, MIGUEL MARTIN y ANA MEDINA en PHI BETA LAMBA que dan protagonismo a profesionales de distinto perfil dentro de la industria musical de una forma desenfadada y divertida. Y cerramos con una banda que comienza a recoger el trabajo a la sombra de muchos años como es VEINTIUNO.

LOS TELONEROS en el podcast musical que presentan de nuevo en su segunda temporada QUEQUÉ, MIGUEL MARTIN y ANA MEDINA en PHI BETA LAMBA. Un espacio que da cabida a profesionales de diferente perfil dentro de la industria musical con los que conversan de forma relajada y divertida. El resultado es una entrevista donde hablamos de estudios de radio del extrarradio, de cómo colarse en los conciertos y de fotografías en el cuarto de baño. Y de Malú. Y de Andrea Levy. Allá vamos... LOS TELONEROS en el podcast musical que presentan de nuevo en su segunda temporada QUEQUÉ, MIGUEL MARTIN y ANA MEDINA en PHI BETA LAMBA. Un espacio que da cabida a profesionales de diferente perfil dentro de la industria musical con los que conversan de forma relajada y divertida. El resultado es una entrevista donde hablamos de estudios de radio del extrarradio, de cómo colarse en los conciertos y de fotografías en el cuarto de baño. Y de Malú. Y de Andrea Levy. Allá vamos...

Perfecting his craft for over more than 2 decades, Technique has gained notoriety as one of the most versatile DJ/Turntablists coming out of Hawai’i. His versatility has earned him residencies respectively in the Mainstream Club, Underground Hip-Hop & EDM scenes performing at almost every nightspot in Hawai'i and has taken his talent to the states & abroad. He has opened up & spun alongside world-class artists DJ Qbert, DJ Craze, Rakaa Iriscience (Dilated Peoples), Talib Kweli & DJ Hi-Tek, Mos Def, Jeru The Damaja, Hieroglyphics/Souls Of Mischief, Xzibit, 112, Baby Bash, Mr. Vegas, Nick Cannon, Russ, Fifth Harmony, Dillon Francis, Diplo, Excision, Laidback Luke, Deadmau5, Steve Aoki, NGHTMRE, AJR and mor Currently he is a Mixer for Hawai'i radio Stations 102.7 Da Bomb - The Friday Night Mix (CHR/Top 40) & The Super Awesome Mixshow Show (EDM), 93.1 Da Paina - Da Reggae Traffic Jam Aloha Friday Mix (Island/Reggae) & ALT 1059 - The Friday Night Fix (Alternative/Rock).Aside from DJing, Technique had the honor of releasing his remix service production work through the world famous New York based record label, AV8 Records (Crooklyn Clan, Fatman Scoop, Disco Fries) from 2008-2012! Some of his tracks have gotten world class support. Most notably his collab with Pickster One aka Ønami “Hit The Clurb” was featured on Diplo’s BBC Radio 1Xtra radio show Diplo And Friends and his mashup of Taylor Swift’s “Shake It Off” & A-Ha’s “Take On Me” was featured multiple times on Barstool Sports’ Pardon My Take podcast, the #1 sports podcast in America. In 2017 he joined The Crooklyn Clan's roster of producer/remixer/editors . Now you can find all his edits, remixes & mashups exclusively on their record pool website crooklynclan.netI'm very grateful to do this interview with Deejay Technique !

In episode 11 of O11ycast, Charity Majors and Liz Fong-Jones speak with Gremlin chaos engineer Ana Medina. They discuss the relevance of breaking things in order to engineer them more efficiently, monitoring vs observability, and chaos engineering at scale.

In episode 11 of O11ycast, Charity Majors and Liz Fong-Jones speak with Gremlin chaos engineer Ana Medina. They discuss the relevance of breaking things in order to engineer them more efficiently, monitoring vs observability, and chaos engineering at scale.

In episode 11 of O11ycast, Charity Majors and Liz Fong-Jones speak with Gremlin chaos engineer Ana Medina. They discuss the relevance of breaking things in order to engineer them more efficiently, monitoring vs observability, and chaos engineering at scale. The post Ep. #11, Chaos Engineering with Ana Medina of Gremlin appeared first on Heavybit.

Fin de temporada de los Teloneros, el podcast musical de Quequé, Miguel Martín y Ana Medina. Terminamos temporada con Sean de Dinero y su manager Marcos Ayuken, todo en familia. Hoy hablamos hasta de Heidi.

Vuelve una semana más los Teloneros, el podcast musical de Quequé, Miguel Martín y Ana Medina. Manager, booker, parte del equipo de Mad Cool y reconocida "workalcoholic", Cindy nos cuenta su experiencia en la música. Y Gentleman Clef nos contarán cómo es eso de tocar delante de Harrison Ford. Cosas de la vida.

Vuelve una semana más los Teloneros, el podcast musical de Quequé, Miguel Martín y Ana Medina. ¿Cómo funciona el cerebro de un músico? Tenemos una experta en neuromarketing que nos lo cuenta y además viene acompañada por uno de los bajistas más demandados: Chapo (M-Clan, Tarque, Leiva, Sabina, Zahara...)

Vuelve una semana más los Teloneros, el podcast musical de Quequé, Miguel Martín y Ana Medina. A veces, trabajar en la música te lleva a vivir situaciones surrealistas. Pepo Márquez nos cuenta algunas, habla de su proyecto musical: The Secret Society y mucho más.

Matty (with special guest host Jessica DeVita) is joined by Ana Medina, Dan Barker, Ben Clayton, and Monica Hart at DevOpsDays Kansas City 2018.