El proceso de selección

Tiempo de lectura aprox: 5 minutos, 20 segundos

… para un puesto de ingeniera de software en una gran corporación en la industria automovilística sueca.

2020: De la Patagonia Chilena a Alemania.

2020 fue un año complicado y trajo cambios inesperados. Tras cinco meses de viaje por la salvaje Patagonia chilena y una excepcionalmente revolucionada Santiago, regresamos un 14 de febrero a Nuremberg (Alemania).

Volvíamos del aeropuerto y saliendo del U3 (metro) sentía, equivocadamente, que al fin mi vida volvía a una tranquila normalidad.

Pandemia 2020

La locura colectiva del Coronavirus se desató en Europa un mes después de nuestro aterrizaje. Las guarderías cerraron, el ocio quedó cancelado y cada semana se decretaban nuevas prohibiciones para realizar cualquier tipo de actividad. Lo que parecía que iba a durar un par de semanas se convirtió en un desvarío de estrictas medidas y un sistema educativo cerrado que nos sobrecargaba a los padres trabajadores con niños pequeños.

Cada día comprobábamos cuál era la incidencia de contagios y qué complicadas restricciones (Maßnahmen) aplicaban en nuestra ciudad y la contigua Fürth. El panorama era agotador y aburrido.

Corona Maßnahmen Burnout

Esta situación que duró varios meses arruinó nuestra vida social, salud mental y vacaciones, y fue decisiva para considerar emigrar a corto plazo.

El próximo destino estaba claro: Suecia.

Aplicando a una gran corporación en Suecia

Tras diez minutos de búsqueda en linkedin observé que una gran corporación automovilística ofrecía varias posiciones para ingeniero de software C++. Mi perfil era algo más orientado a embedded C, drivers y a linux User Space, pero las ofertas se veían atractivas y se despertó mi interés por la empresa.

Redactar una carta de presentación y completar mi curriculum supuso bastante trabajo. Para ello investigué cómo adaptarme al modelo esperado del país e invertí bastantes horas en la apariencia estética del CV.

Tan sólo la plantilla, es decir, la disposición de los textos, iconos, fuentes y colores me llevó tres días.

Noches en vela peleando con LibreOffice

Hacia principios del noviembre del 2020 envié todos los documentos necesarios y rellené formularios varios para un puesto de C++ Core System Senior Software Engineer (o algo similar).

Dos días después el predictor mostró dos líneas y casi me desmayo. Corrí a la farmacia a comprar uno nuevo para comprobar que era un falso positivo. (En verano del siguiente año nacería mi preciosa Klaris.)

Los falsos positivos no existen.

La buena noticia complicaba los planes

La primera llamada

Pasaron dos meses desde el evento anterior hasta que recibí un correo del departamento de Recruitment anunciándome que mi candidatura les interesaba y querían hablar conmigo. Casi vuelvo a desmayarme.

La primera llamada telefónica fue muy bien, el señor de recursos humanos me habló sobre la empresa, sus valores y me describió brevemente el puesto solicitado. Tras su monólogo me preguntó si estaba interesada en comenzar con el proceso de selección. (!? ) Siii!!!!!

Dos semanas más tarde tuve la primera entrevista con el que sería mi manager.

La entrevista con el Manager

Unos días antes de la entrevista, mi futuro manager me propuso varios timeslots (horarios) en los que él tenía disponibilidad para entrevistarme.

El tema del Coronavirus en realidad facilitó todo ya que al haber restricción y puntualmente prohibición de vuelos, el proceso de selección fue completamente online. Por otro lado, trabajando obligadamente en homeoffice (Heimarbeit!) era muy sencillo ausentarse un rato para realizar una entrevista.

Me llegó un correo con un enlace a una reunión en «Microsoft Teams». Creo que comprobé unas cinco veces que el audio, vídeo y el enlace funcionaban antes del día acordado.

Una característica de los suecos, especialmente si se comparan con los alemanes, es que son muy simpáticos, tienen empatía y se les da bien el smalltalk preliminar antes de sumergirse en detalles técnicos y preguntas.

Cultura «lagoom»

Tuve una muy buena impresión tras esa primera reunión y quedé contenta al ver que mi perfil, pese a no encajar del todo con el puesto, les interesaba bastante. Yo mostré todo mi entusiasmo por seguir con el proceso de selección, aunque en realidad estaba aterrada por dos motivos: mis conocimientos de C++ no eran excelentes y mi embarazo de algo menos de dos meses, todavía muy temprano para ser desvelado!

Los tests psico-técnicos

El siguiente paso consistía en una serie de test a contrareloj.

Me proporcionaron un enlace a una página proveedora de estos test de selección. Una vez hice «click» en el botón de comienzo, el temporizador inició la cuenta atrás y ya no era posible pausarlo o resetearlo. Constaba de varias partes: lógica de formas, problemas matemáticos, comprensión lectora, lenguaje y test de personalidad. El tiempo estaba muy limitado y la dificultad iba en aumento conforme avanzaba la prueba.

Fue realmente estresante completarlo y muy frustrante el hecho de que en las áreas en las que yo me consideraba más fuerte (lenguaje y personalidad) resultaron especialmente complejas.

Si volviera a aplicar a una gran corporación prepararía con algún libro especializado este tipo de prueba.

Nota mental

Las náuseas y el atontamiento por insomnio afectaron de alguna manera al resultado, pero afortunadamente no fueron determinates y mi justita inteligencia bastó para aprobar aquel terrible examen.

El home assignment

La noticia de que mi puntuación había sido adecuada para continuar con el proceso fue muy satisfactoria, yo diría que inesperada. Sorprendentemente la parte que peor había realizado había sido el test de personalidad, pero pude justificarlo por un mal entendido con el término «Stakeholder«.

Hacia mediados de diciembre del 2020 me llegó un correo con la descripción del «home assignment«, es decir, la tarea que yo debía realizar y que sería evaluada por ingenieros de la empresa.

El home assignment

Tuve la gran suerte de que las vacaciones de Navidad se aproximaban y me dieron una semana adicional para realizar la entrega. Pasé varios días leyendo para informarme de cuál era la manera más elegante y eficiente de programar el ejercicio que me habían propuesto. No puedo desvelar exactamente en qué consistía la aplicación que yo debía programar, sólamente diré que implicaba el uso de entre otras cosas IPC, hilos, C++ …

Cuando el programa compiló, lo testeé, documenté y finalmente envié a principios de enero. Fueron unas Navidades bastante inusuales: vuelo a España perdido por una de prueba negativa de Covid que recibí media hora tarde, un susto con el embarazo y una Nochebuena programando.

La entrevista técnica

Ésta era para mí la prueba más crítica del proceso ya que el código del home assignment sería evaluado por un ingeniero de software y me haría preguntas. Mi punto débil era obviamente la complejidad de C++ y temía no poder responder a las preguntas más específicas sobre este lenguaje. Por ello dejé claro desde el principio que mi punto fuerte había sido otro lenguaje, C y que en el último año había trabajado con C++ algunos meses sin profundizar demasiado en el mismo.

Hubo varias preguntas sobre software general que me resultaron sencillas de explicar como:

  • Diferencias entre heap y stack
  • Cómo analizar un memory leak
  • Cómo hacer debug

Otras preguntas trataban sobre tests de software que hasta entonces había realizado muy puntualmente y que contesté con algo de torpeza:

  • Experiencia con unittesting
  • Google test framework for C++

Y algunas más específicas sobre C++:

  • Smartpointers , qué son y cuándo los usas
  • Funciones de la librería standard para manipular arrays.

La buena noticia

El proceso de selección estaba siendo muy largo y cuando ya mi embarazo sobrepasaba los tres meses y medio decidí que lo justo era contárselo a mi supuesto futuro empleador.

Dos semanas después de la evaluación técnica con el ingeniero de sofwtare, me reuní de nuevo con el manager. Él me transmitió la buena noticia de que yo podía, si así lo deseaba, continuar con el proceso.

Me invadió un sentimiento profundo de alegría mezclado con un algo de pánico por comunicar la noticia de mi embarazo.

La reacción de mi manager fue inesperada: en primer lugar me felicitó sonriendo y en segundo me preguntó en qué fecha podría incorporarme. Si lo deseaba podría comenzar antes del nacimiento, tomarme la baja maternal y continuar después, o si lo prefería podría comenzar directamente tras la misma.

Suecia es un país donde realmente se respeta a la familia y a la infancia y es habitual que los padres tomen largas bajas parentales para cuidar de sus hijos hasta el primer año de edad.

El drugtest

Curiosamente una fase obligada del proceso de selección fue realizar un test de drogas. Algo que en Alemania era impensable, probablemente ilegal, en Suecia parecía ser algo habitual.

Encontrar un lugar que hiciera este tipo de pruebas fue una odisea por dos motivos: todos los laboratorios estaban ocupados analizando Covid-19 en palitos y los tests de drogas en Alemania sólo se realizaban para procesos criminales. Tras diez llamadas telefónicas (auf Deutsch, natürlich) generando mucho desconcierto por mi petición, conseguí encontrar un lugar, bastante tétrico, que me tomó una muestra y me envió un certificado de papel.

La situación en aquel laboratorio de Rechtmedizin fue tragicómica: yo era la única clienta no convicta y además con una barriga de 5 meses.

Das drogenscreening

El contrato

Tras enviar el certificado que confirmaba que yo no había consumido ningún tipo de sustancia de una larga lista de drogas, recibí finalmente, en abril de 2021 , el contrato por correo electrónico.

El proceso duró 5 largos meses y el primero de Septiembre de 2021 aterrizamos en Gotemburgo.

Y aquí seguimos, dos años después, en este país de luminosos veranos y tenebrosos inviernos.

Refactorizando «legacy code»

Tiempo de lectura aprox: 1 minutos, 39 segundos

Las tres últimas semanas previas a las vacaciones de verano han sido intensas: a las 7:30 tenía ya los auriculares puestos y una playlist sonando a todo volumen para aislarme de las conversaciones de la oficina y poder concentrarme en el código. Ha sido una pelea diaria «refactorizando legacy code«.

Hacía algún tiempo que no me encontraba con una tarea aparentemente tan sencilla que resultara tan laboriosa.

«Legacy» qué?

Por «legacy code» se entiende un código desconocido (o también obsoleto) complejo , talvez caótico, y que necesita muchos «cambios» para convertirse en «código de producción«. Tras la restructuración, simplificación y mejora de su calidad el software puede ser mantenido, es decir, modificado cuando sea preciso añadir funcionalidad y sencillo de reparar en caso de bugs.

El hecho de que el código sea mantenible y cumpla con los exigentes estándards de calidad es un requerimiento esencial cuando el producto desarrollado es un automóvil.

La story (2 points): crear una «wrapper class»

La «story» o tarea que me fue asignada hace un par de sprints fue la de implementar, integrar y testear una simple clase envolvente, o sea, una «wrapper class» para abstraer la interfaz de una librería de un proveedor y simplificar su uso.

El objetivo de la misma, junto con otro par de tareas asignadas a mis compañeros, era convertir el código de muestra (sample code) entregado por un proveedor en código de producción.

El software en cuestión cumplía con su funcionalidad, el problema era que esas miles de líneas de código no tenían una garantía del proveedor y en ese estado en el que habían sido entregadas (una implementación rápida y con propósito de muestra) no eran mantenibles por nuestra parte.

Durante la planificación definimos unas pocas stories para refactorizar el código de C a C++ , implementar algunos unit tests , documentar con diagaramas UML y por supuesto cumplir con las directrices de Autosar .

El objetivo parcía sencillamente alcanzable y realista.

Nunca subestimes una refactorización

La realidad de la «sencilla» refactorización

Conforme avanzaban los días enfrentándonos a un código que no sabíamos cómo funcionaba, nos dimos cuenta que era preciso un análisis profundo y un cuidadoso re-diseño .

Modificar un código algo caótico que además no se entiende implica un enorme riesgo de cometer errores.

Fault report high severity risk!

Así nos surgió la necesidad de invertir más tiempo en la estrategia del desarrollo y cumplir rigurosamente con la revisión de requerimientos, diseño de arquitectura, definición de nuevas y sencillas unidades, ampliación de la cobertura de los unit tests, test de integración, system tests…Además de un FMEA para identificar y corregir o mitigar todos los posibles riesgos.

Merecidas vacaciones

Afortunadamente hoy llegaron mis vacaciones y puedo desconectar de mi playlist de programar.

Tres semanas al sol para retomar con energía esa refactorización, los tediosos «merge conflicts» derivados de trabajar con «relation chains» y las intensas asesorías con ingenieros de seguridad.

Los juniors

Tiempo de lectura aprox: 2 minutos, 26 segundos

Hace algún tiempo el jefe nos comunicó que durante la segunda mitad del año se incorporarían a nuestro equipo tres ingenieros junior. Nuestra labor en los próximos meses sería, además de entregar las stories planificadas para cada sprint, formar y ser mentores de estos fichajes recién salidos de la universidad.

La idea de formar y motivar a los a juniors me produjo pereza infinita.

El jefe continuó:

«Recordad cuando comenzasteis a trabajar, qué frustrante fue creer saberlo todo al salir de la universidad y de repente venirse abajo al no entender cómo funcionan los procesos, proyectos y día día en las empresas.»

Y para finalizar nos inspiró :

«Los juniors os necesitan como mentores, vuestro apoyo es esencial»

Flashback activado

Esas palabras me dieron escalofríos y fue ahí cuando advertí que me estaba haciendo mayor y ya estaba viviendo la historia del lado oscuro, es decir, desde la perspectiva de la senior cascarrabias a quien le carga formar juniors.

Y los flalshbacks comenzaron.

De becaria a ingeniera junior.

Allá por el año 2008 obtuve con orgullo mi título en Ingeniería Superior en Telecomunicación que vino acompañado de cuatro dipotrías y cierta adicción al café que desarrollé para sobrevivir a la terrible carrera.

Mi primer contacto con la empresa fue como becaria en un Centro de Innovación Tecnológico y aunque la experiencia fue pésima, aquellos meses merecieron la pena por el simple hecho de rellenar un par de líneas en mi vacío curriculum.

La tarde que me comunicaron que yo era la finalista en el proceso de selección de ingeniero I+D junior de una multinacional fue memorable. Al colgar el teléfono sentí una alegría y orgullo de mi misma sin medida.

Atrás quedaba la frustrante etapa como becaria, al fin comenzaba una carrera profesional real.

Memorias de una Becaria

La realidad del junior

Mi primera tarea como ingeniera junior fue realizar una hoja Excel con información y referencias de partes de un sistema domótico. Un auténtico coñazo que duró varios meses. Después me asignaron las aburridas Especificaciones de Validación Funcional y finalmente llegó el esperado momento de hacer debug en el firmware y analizar una Máquina de Estados que funcionaba mal.

Durante esos primeros años como ingeniera necesité el soporte de mis compañeros más vetaranos, los cuales en ocasiones debido a su carga de trabajo y falta de pedagogía no siempre respondían de la manera más adecuada.

Ésa era al menos mi perspectiva de junior.

Aceptando la frustración y a los seniors cascarrabias

Creo que fue en algún botellón, probablemente en Sanfermines, donde tuve una de conversación reveladora con una amiga mientras arreglábamos el mundo con sabiduría y propiedad. María, con el katxi Absolut-limón en la mano y expresión reflexiva a me afirmó:

«El trabajo en empesa es la culminación de la frustración profesional.«

Revelaciones de botellón.

Las dos habíamos firmado contratos hacía pocos meses y la desviación entre nuestras espectativas y la realidad eran tremendas.

No importa lo bien que analizaras circuitos, resolvieras problemas de magnetismo o escribieras programas en C durante la Universidad, porque en la empresa comienzas de cero, necesitas mucha formación que no recibes y las tareas que te asignan suelen ser las menos interesantes desde el punto de vista técnico. Y el peor de los puntos : algunos seniors, los muy cascarrabias, en ocasiones te tratan como si entorpecieras los proyectos y les robaras tiempo.

Es un proceso frustrante comenzar en el mercado laboral y es necesario aceptarlo, tener paciencia y esforzarse para desarrollarse profesionalmente.

La deuda con mis mentores

Encontrar un compañero de trabajo que esté dispuesto a compartir su conocimiento, explique bien y dedique tiempo en formarte es encontrar un tesoro. Y éstos escasean, sin embargo gruñones que explican poco y mal los hay a montones. Por éso ser junior es tan duro y frustrante.

A lo largo de estos 14 años he tenido la suerte de encontrarme con varios ingenieros excepcionales de los que además de aprender conocimientos técnicos me han sabido transmitir la pasión que ellos tenían por la programación y la electrónica.

A estos gurús que fueron en momentos puntuales mis mentores ya no puedo pagarles la deuda, así que supongo que me toca esforzarme e invertir mi tiempo en los juniors por mucha pereza que me de.

Danke schön liebe Kollegen.

¿Es lo justo no?

¿Gerrit?

Tiempo de lectura aprox: 2 minutos, 6 segundos

Advertencia: apto sólo para desarrolladores de software con sentido del humor.

Gerrit: descripción objetiva

Para aquellos dinosaurios (como yo) que no tengan el placer de conocer a Gerrit les resumiré de manera objetiva que se trata de una herramienta colaborativa para realizar revisión de código.

Su interfaz web expone el código para que los demás desarrolladores aprueben o rechacen los cambios votando positiva o negativamente tras cada git push.

Integra la función git difftool para comparar cada uno de los patches con cualquiera de los otros pusheados para un mismo commit. Además, pueden anotar sus comentarios de sugerencias o exigencias de mejora, errores encontrados o incluso felicitaciones y caritas sonrientes para reconocer el esfuerzo realizado.

» Transparencia, colaboración, difusión del conococimiento, trabajo en equipo«. – Gerrit – .

(Fuente https://gerrit-review.googlesource.com/Documentation/intro-gerrit-walkthrough.html)

Gerrit: mi primera impresión

Mi primer contacto con Gerrit fue durante un workshop de onboarding en la nueva empresa. Un colega nos explicó qué política había establecido el equipo agile para el uso de esta herramienta, es decir, cuál era el proceso a seguir desde el primer push del código hasta que éste fuera fusionado en la rama master.

Para los otros dos asistentes todo parecía tener sentido y estaban entusiasmados con la charla, mientras que yo, con mis más de diez años de experiencia de desarrollo de embedded software, estaba algo confundida con el proceso. La terminología con las que nos bombardearon durante el workshop me perturbaba y resultaba rimbombante: «maintaniner reviewer, amend, patch, vote, +2, – 2, commit ID, relation chain, topic, ownership, merge queue, verification, gate check«.

De nuevo me sentía un dinosaurio, uno lento y grande: soy una ingeniera-diplodocus de software.

Quién diría que se podía echar de menos a IBM Clear Case y a las soporiferas code reviews en una en sala de reuniones un par de veces al año.

Gerrit: esa heramienta diabólica

Me parecía sencillamente terrorífico que mi código quedara públicamente expuesto a todos los equipos de software y que cualquier desarrollador pudiera comentar libremente, sin restricciones ni filtros, sobre mi código y votar positiva o negativamente si mis cambios eran aptos para ser fusionados en master.

Me vinieron a la mente dos episodios de una de mi series preferidas, «Black Mirror» : el «Nosedive – (Likes) » y el de «Hated in the nation -(Abejas)» .

Si no ves la analogía y encuentras que Gerrit es una herramienta fantástica te felicito porque no tendrás un schock de adaptación como el mío.

Seis meses después me sigue abrumando el proceso de revisión del software con Gerrit.

Gerrit: la adaptación.

Debo reconocer que no me gusta que todo desarrollador pueda hacer anotaciones sobre mi código en cualquier momento y en ocasiones, cuando el objetivo es realizar el delivery a tiempo y éste escasea, me resulta muy muy muy molesto.

Veo que esta herramienta abre una ventana a que algunos desarrolladores adictos a las beautifications, normas y coding guidelines entren en bucle infinito comentando y repartiendo dislikes cuando están aburridos sin mucho que hacer. Yo soy fan del Keep it Simple, especialmente cuando se acerca el final del Sprint...

Por otro lado, me parece muy útil el hecho de que el código sea analizado desde puntos de vista diferentes y por ingenieros con diferentes destrezas, de manera que deba ser comprendido por todos y se puedan detectar diferentes tipos de errores: de funcionalidad, conformidad con las normas, calidad de los comentarios explicativos del código…

Si pudiera elegir diría sí a Gerrit, pero con moderación y un buen filtrado a los continuos comentarios de formatting (sobretodo de los fanáticos de la llave «{» sin salto de línea) y otros cambios cosméticos.

Sr. Gerrit, necesito un botón de bloqueo (reversible) a ciertos usuarios, como la de Microsoft Messenger del principios de milenio...

Agile, todo un shock

Tiempo de lectura aprox: 2 minutos, 34 segundos

Hace unos meses comencé a trabajar como ingeniera de desarrollo software en una gran corporación. Pese a acumular más de cuatro años de experiencia profesional en España y ocho en Alemania, he vuelto a entrar en schock con la nueva cultura laboral, esta vez la Sueca.

Emigrando por primera vez

Allá por 2012, tras haber estudiado Ingeniería, pasado por la etapa de becaria y finalmente conseguido un puesto en I+D sin moverme de mi ciudad natal, decidí a mis 28 años conocer finalmente el mundo. La búsqueda de empleo internacional fue un proceso lento y a veces frustrante, pero en unos pocos meses conseguí firmar un contrato con una pequeña empresa supplier del sector de automoción. En mayo de ese año aterricé en Nuremberg con una maleta y un pesado portátil dispuesta a aprenderlo todo sobre dispositivos embebidos para cockpit del automovil y perfeccionar mi todavía muy macarrónico alemán.

Los primeros años fueron muy interesantes e intensos, tanto desde el punto de vista personal como profesional. Con esfuerzo pude adaptarme a la estructura laboral claramente jerarquizada, altamente especializada, burocrática y muy formal. Tras casi nueve años llegué a dominar el terrible y maravillosamente preciso idioma, aunque nunca dejé de sentirme extranjera cuando lo hablaba.

Aterrizando en Suecia

En 2021 llegué a Suecia, esta vez con marido, dos hijas y un camión de mudanza que transportaba treinta y tres cajas de ropa, cuatro bicicletas y trastos diversos .

En Noviembre pisé por primera vez la nueva oficina y me incorporé a un equipo Agile. La primera impresión superó positivamente todas mis expectativas: el lugar se veía increiblemente moderno y tecnológico y mis nuevos colegas muy profesionales y sociables. En la entrada del edificio, aún no siendo el principal, se respiraba estilo, tecnología, corporativismo y una sensación de ambiente cálido y acogedor con música chillout de fondo… Nada que ver con las espartanas y funcionales recepciones alemanas donde la sobriedad, formalismo y burocracia reinan.

Los primeros días en mi nuevo trabajo fueron algo desconcertantes y volví a sentirme como aquella recién llegada del pueblo que emigraba por primera vez, aunque esta vez con arrugas incipientes.

La oficina era inmensa con cientos de ingenieros de apariencia muy profesional, internacional y joven, se escuchaban idiomas varios de fondo, salas de reuniones futuristas… vi claro que iba a tener que hacer un gran esfuerzo para estar a la altura. Me sentí algo abrumada y el síndrome de la impostora atacó brutalmente.

La primera ceremonia, la Daily

La primera ceremonia Agile con la que me encontré fue la Daily, una reunión diaria de un cuarto de hora en la cual cada miembro del equipo usaba un par de minutos para describir «qué hice ayer, qué planifico hacer hoy y si necesito soporte».

Para facilitar la comunicación y sincronización utilizaban una herramienta software que mostraba gráficamente las tareas (Stories) ordenadas por estado (TODOs, In progress, Done) y además asignaba a modo icono la foto del ingeniero que la implementaba. Todo muy claro, práctico y transparente. ¿O no?

Y el shock llegó

Tras varios días asistiendo a la Daily estaba completamente desconcertada y me surgían demasiads dudas sobre la gestión y jerarquías del proyecto como…

¿Cuál es la diferencia entre el Scrum Master y el habitual lider del proyecto?

¿La documentación detallada de proyecto dónde está ?

¿Puedo tomar yo la story que quiera o me asignarán una el próximo Sprint?

¿Por qué mi calendario está lleno de reuniones con nombres rimbombantes como: «Backlog refinement», «Sprint Review, «Sprint restrospective» «Sprint Demos»?

¿Donde está el Gant del año completo?

Agile tenía las respuestas a mis preguntas, pero obviamente no eran inteligibles para mi…

Tremendo Shock laboral del «Way of Working»…. Wow

Así es, soy un dinosaurio

Y ahí empecé a darme cuenta de que hasta entonces yo había trabajado en lo que denominan metodología «Waterfall«, que estaba según algunos manuales Agile un poco obsoleta. Yo me había quedado desactualizada, convertida en un dinosaurio que miraba atrás pensando en los ‘good old times‘ y desconfiando de los nuevos Trends. Me vi reflejada en mis colegas más viejos y gruñones del pasado. La adaptación iba a ser larga y tortuosa.

Comencé a echar terriblemente de menos la clara jerarquía de las empresas Alemanas, el liderazgo y determinación del jefe de proyecto, la hermosa documentación de cientos de páginas y lo directos, concretos y a veces abruptos que eran mis colegas germanos al decir las cosas. Incluso he llegado a echar de menos el idioma.

Ich vermisse Dich … pero me encanta el concepto del Fika sueco, que poco tiene que ver con la Kaffe Pause, pero eso es otra historia.

Compartir archivos en red local entre Windows como Host y Ubuntu como Guest (en VirtualBox).

Tiempo de lectura aprox: 2 minutos, 48 segundos

La situación es la siguiente: tenemos instalado en el PC Windows y una máquina virtual Ubuntu corriendo en Virtual Box y queremos compartir carpetas y archivos en red entre ambos.

En esta entrada se verá cómo compartir archivos entre el Host(1) (Windows) y el Guest (2) (vm Ubuntu) creando una «red virtual local « entre ambos e instalando un servidor Samba para compartir directorios y archivos almacenados en la máquina virtual Ubuntu.

(1,2)NOTA: Se define «Host» al sistema anfitrión en el que instalamos todo lo demás, en este caso Windows. Ubuntu aqui es el «Guest» y correrá en Virtual Box.

Creación del directorio compartido en Ubuntu

En primer lugar es necesario crear el directorio que será compartido en red. Dentro del éste se creará un archivo llamado «archivo.txt» en el que se escribirá «hola». Al directorio lo llamaré «compartido«.

amaia@vm-ubuntu:~$ mkdir compartido
amaia@vm-ubuntu:~$ cd compartido
amaia@vm-ubuntu:~$ touch archivo.txt
amaia@vm-ubuntu:~$ echo hola > archivo.txt 

La ruta del directorio que va a ser compartido se puede obtener con el comando pwd (print working directory). Recuerda esta ruta ya que habrá que definirla más adelante en un archivo de configuración de Samba.

amaia@vm-ubuntu:~$ pwd
/home/amaia/compartido

Instalación del servidor Samba en Ubuntu

Antes de instalar actualizo la información de paquetes instalables:

amaia@vm-ubuntu:~$ sudo apt-get update

Para instalar el servidor Samba:

amaia@vm-ubuntu:~$ sudo apt-get install

Cuando termine la instalación habrá que configurar Samba. Para ello abro el archivo de configuración con el programa de edición de texto «gedit«

amaia@vm-ubuntu:~$ sudo gedit /etc/samba/smb.conf

Se abre un archivo de texto en el que voy a añadir las siguientes líneas bajo «Share Definitions«:

=============== Share Definitions ===================

[sambaShare]
path = /home/amaia/compartido
read onlny = no
browseable = yes

A continuación reinicio el servicio Samba:

amaia@vm-ubuntu:~$ sudo service smbd restart

Si el firewall estuviera habilitado podemos configurarlo para que éste permita la conexión a Samba:

amaia@vm-ubuntu:~$ ufw allow samba

El siguiente paso es crear usuarios que puedan acceder a los recursos compartidos por Samba. Es preciso que estos usuarios existan ya en mi sistema. En mi caso, tengo un usuario llamado «amaia«, así que la añado para que se pueda autenticar en Samba.

amaia@vm-ubuntu:~$ sudo smbpasswd -a amaia

Creación de una red local virtual

Para que el «Guest» ( la máquina virtual «Ubuntu«) y mi «Host» (la máquina real con Windows 10) estén en red, debo crear un nuevo adaptador de red en Virtual Box. Éste será del tipo «Host only» y creará una red entre la máquina virtual y el Host. Así los archivos compartidos por Samba en Ubuntu serán accesibles desde Windows.

Pasos:

  1. Apagar Ubuntu
  2. Ir al menú «Settings» de Virtual Box
  3. Seleccionar «Network»
  4. Hacer click sobre las pestañas hasta encontrar el primer adaptador que no esté habilitado. En mi caso el «Adapter 1» está asignado a «NAT» y el «Adapter 2» está sin utilizar.
  5. Habilitar el nuevo adaptador y asígnale el valor «Host only adapter«
  6. Presionar OK y salir.
  7. Inicia Ubuntu (estaba apagado)

Una vez creada esta nueva red virtual vemos que en Windows se ha creado un nuevo adaptador de red:

En Ubuntu también aparece ahora configurado un nuevo adaptador de red. Ejecutando el comando «ip addr show» vemos esta informacion:

amaia@vm-ubuntu:~$ ip addr show

En mi caso el nuevo adaptador creado es el número 3:

3: enp0s8: mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 08:00:27:ff:42:c5 brd ff:ff:ff:ff:ff:ff
inet 192.168.56.101/24 brd 192.168.56.255 scope global dynamic noprefixroute enp0s8
valid_lft 514sec preferred_lft 514sec
inet6 fe80::95a8:d748:35b8:cf88/64 scope link noprefixroute
valid_lft forever preferred_lft forever

Esta IP es la que necesitaremos desde Windows para acceder a los archivos compartidos por Samba.

Acceder a los archivos compartidos desde Windows

Puedo mapear la Unidad de red de dos maneras diferentes, desde el explorador de archivos o desde la consola de Windows.

1.- Mapeo desde el Explorador de archivos

Sobre «Network» hacer click derecho y en el menú contextual seleccionar «Map network drive…«

En el primer campo desplegable se selecciona una unidad «drive» que esté libre y se quiera mapear la unidad compartida. (Yo he utilizado la «A»).

En el campo «Folder» se introduce el nombre de red del recurso compartido. Su formato es el siguiente:

\\ip-servidor-samba\nombre-dir-compartido-definido-configuracion

La dirección IP del Servidor (la que hemos mirado antes en Ubuntu) y el nombre del directorio compartido que definimos en el archivo de configuración de samba /etc/samba/smb.conf, es decir, ése que estaba entre corchetes [ ]. Una vez escrito este campo pulsar enter.

2.- Mapeo desde la consola de Windows

Pulso teclas «Windows + r» y cuando se abra la venta » Run » (ejecutar) introduzco «cmd«

Yo voy a mapear en la unidad B (que la tengo libre) el directorio compartido. Para ello, en la consola escribo lo siguiente:

net use b: \\192.168.56.101\sambaShare /user: amaia amaia

Mi usuario para Samba se llama «amaia» y su contraseña (ya sé que no es segura, es sólo para el ejmeplo…) es «amaia«.

Después de «/user:» escribo el nombre de usuario, un espacio en blanco y después la contraseña.

El nombre «sambaShare» es el que he definido en el archivo de configuración /etc/samba/smb.conf

Vacaciones en tiempos de Pandemia

Tiempo de lectura aprox: 1 minutos, 12 segundos

La llamada «Nueva Realidad» se ha apoderado de mis vacaciones de verano de 2020 para darme, la muy canalla, la oportunidad de pasar más tiempo en el salón de casa estudiando. Dos semanas completas entre libros y fragmentos de código en las que la frustración por no poder volar para ver a la familia e ir de pintxos ha hecho que aproveche el tiempo más que nunca.

Mi planazo.

Desde hace unos días Youtube me viene bombardeando con tutoriales sobre WordPress, Hosting y ese tipo de cosas que además de no interesarme no conocía en absoluto. Ayer entendí porqué me los sugería: «Él «, o la AI(1) o lo que sea Youtube, sabe que soy una freak de la documentación de mis proyectos: en el trabajo escribo mucho no … ¡Demasiado! Y en una página web podría escribir, dibujar y re-editar sin límite. (3 GB)

Así que aquí dejo compartida la información que voy inspeccionando sobre los temas que me interesan Linux/C/Kernel/User Space/Drivers y que quiero estructurar a modo de «Mi Biblioteca» para tenerla siempre conmigo digitalmente.

Aplicaré la misma estrategia que con mi canal de Youtube : explicando temas que a mi me interesan de la manera más sencilla, con dibujos «bonitos», y aplicando mi versión del «Método de Feynamn»(2). El resutlado con Youtube ha sido óptimo: aprendo muchísimo y además el trabajo que realizo les sirve a otras personas.

Por cierto, monetizaré(3), si Google lo aprueba, la página para costear el precio del Hosting(4) y del Domino(5).

.

.

.

Glosario

(1) AI = Inteligencia Artificial… ¿Es Youtube una AI? ni idea, Google seguro lo sabe, aunque Youtube pertenece a Google…

(2)Richard Feynman fue un físico que recibió el Premio Nobel y se dice que era un profesor excelente. Él desarrolló una metodología para estudiar, poder entender y explicar de manera sencilla cualquier cosa independientemente de lo compleja que fuera.

(3) Monetizar: mostrar publicidad. En Google se hace con el servicio «AdSense«

(4)Domino Web: el mío es whiletruethendream.com

(5) Hosting: la empresa que me ofrece, previo pago, el servicio de almacenamiento de la web y una serie de herramientas para que yo pueda gestionarla. En mi caso es https://sered.net/ y se encuentra ubicada en Galicia.

Esta web utiliza cookies propias para su correcto funcionamiento. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Configurar y más información
Privacidad