DEV Community: elena

Activar semanticsDebugger en Flutter

elena — Sun, 23 Mar 2025 18:31:12 +0000

Hacer tus apps accesibles tiene muchísimas ventajas, entre las cuales se encuentra alcanzar a más personas que también son tu público objetivo. Si estás creando tu app con Flutter, puedes mejorar fácilmente apps para que sean mejores para lectores de pantalla.

¡Vamos allá!

En Flutter, tenemos una herramienta llamada semantics tree. Esto es nada más y nada menos que una forma de visualizar nuestras apps que nos muestra cómo se interpreta y recorre a través de lectores de pantalla, que son la forma que las personas invidentes pueden consumir productos digitales.

Le arrebata la parte más visual a los widgets en pantalla y lo muestra como contenedores con un texto. Este texto es la forma en la que va a ser consumido por los lectores de pantalla, que en una primera instancia, descubrirás que no es muy útil si te pones en la piel de una persona que no puede ver.

Esta representación se puede modificar para que el lector de pantalla ignore el widget en específico, cambiar el texto que muestra o definir que dos o más widgets deben ser leídos en conjunto… entre otras muchas características que pueden ser modificadas para mejorar la accesibilidad.

¿Y cómo se activa?

Flutter es un framework que tiene estas features integradas de forma nativa, y habilitar el semantics tree es muy sencillo:

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      debugShowCheckedModeBanner: false,

      // Habilitando el semantics debugger
      showSemanticsDebugger: true,

      theme: ThemeData(
        colorSchemeSeed: Colors.blue,
      ),
      home: const MyHomePage(title: 'Flutter Demo Home Page'),
    );
  }
}

Fácil, ¿verdad?

Lo he habilitado pero no veo el semantics tree.

¿Este es tu caso? En mayo de 2024, descubrí que en las aplicaciones Flutter (versión 3.19.6) no estaban mostrando el semantics tree a la hora de añadir esa línea, y se lo comunicaba al equipo de desarrollo a través de un issue de GitHub.

La solución temporal o workaround es añadir, previa ejecución del widget principal, añadir la instrucción que vemos en la línea 3 del siguiente código:

void main() {
  // Forzando a mostrar semantics tree
  WidgetsFlutterBinding.ensureInitialized().ensureSemantics();
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      debugShowCheckedModeBanner: false,

      // Habilitando el semantics debugger
      showSemanticsDebugger: true,

      theme: ThemeData(
        colorSchemeSeed: Colors.blue,
      ),
      home: const MyHomePage(title: 'Flutter Demo Home Page'),
    );
  }
}

Con esto, podrás visualizar el semantics tree y empezar a usar los semantic widgets para hacer tus apps más accesibles. Espero que sea útil.

seeU!

Fluttereando, el viaje

elena — Wed, 06 Sep 2023 08:44:56 +0000

Han pasado unos meses desde esta publicación en mi página de Facebook, donde hablaba sobre mis primeras impresiones sobre Flutter, en contraposición a .NET MAUI, un framework del que venía heredando desde mis tiempos con WPF.

Desde entonces, seguí con otros tipos de desarrollos, con otras tecnologías y para diferentes propósitos… pero eventualmente volví a probar Flutter. Le di una segunda oportunidad después de hablar con la comunidad de MálagaMobile, en la que había varios fans y que me invitaron a hacerlo.

Y a diferencia de la primera vez, decidí seguir una serie de cursos, conocimientos estructurados y organizados… en lugar de experimentar sin un orden validado por otra entidad.

Esta es mi experiencia.

Primera oportunidad: el caos

Si retrocedo en el tiempo, visitaba la documentación oficial, buscaba tutoriales para casuísticas muy concretas para hacer proyectos relativamente pequeños. La experiencia era limitada y agridulce, desordenada y sin proyección. Podía hacer cosas como las que muestro en el siguiente tweet, sí, pero nada del otro mundo:

// Detect dark theme var iframe = document.getElementById('tweet-1608856246576373760-270'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1608856246576373760&theme=dark" }

Para quien no pueda ver Twitter/X, se trata de una aplicación sencilla, una to-do list, sin persistencia donde se pueden añadir/eliminar items, además de marcar/desmarcar como completados. No tiene ordenación ni los elementos nuevos se stackean.

Entonces decidí probar, esta vez de forma estructurada, ordenada… para hablar definitivamente con conocimiento de causa.

Segunda oportunidad: la esperanza

No necesitaba tutoriales sueltos, si no un curso completo (o lo más completo posible).

Buceando en la red, encontré la escuela de London App Brewery a través de LinkedIn Learning. Esta escuela ofrece diferentes cursos de programación con diferentes tecnologías para web y mobile… que hasta donde sé está bastante inactiva (al menos en sus redes sociales). Pero el contenido permanece.

A medida que fui completando los cursos, fui encontrando inconsistencias y errores con versiones actuales del framework, pues no se han ido actualizando en el tiempo. Pero nada que no se pueda resolver buscando documentación.

También he asistido a algunos eventos, sumergiéndome en la comunidad malagueña alrededor de este framework… y es muy diferente. Tener una comunidad cerca, con la que poder compartir, aprender y también refrescar entusiasmo, me parece clave con una tecnología que no utilizas diariamente para tu trabajo.

Actualmente: la curiosidad

Sigo avanzando a partir de otras escuelas y formadores. Todavía me quedan cursos por consumir de LondonAppBrewery y también aprendo con Fernando Herrera.

El roadmap me indica que tengo mucho que aprender sobre bases de datos, state management, navegación, testing, arquitectura… y creo que me apetece seguir.

No sé cuál sería la herramienta a utilizar en proyectos profesionales, pero para experimentar, aprender y probar… Flutter parece un buen lugar en el que quedarme.

Veremos qué ocurre en esta etapa.

seeU!

Novedades .NET en mayo 2022

elena — Tue, 17 May 2022 19:09:00 +0000

El ecosistema .NET está más que vivo, porque estamos viendo una cantidad de novedades increíbles en varias áreas: móvil, Entity Framework, eventos...

En este post vamos a descubrir algunas de ellas, ¡empezamos!

Sobre MAUI

Por si no lo conoces, NET Multi-platform App UI (MAUI para las amistades) es el framework que evoluciona de Xamarin.Forms. Sigue en desarrollo, y nos abrirá la puerta para desarrollar apps para Windows, Android, iOS y Mac.

Pues bien, al momento de escribir este post ya se ha publicado la Release Candidate 3.

Además, Visual Studio Installer ya incluye el workload específico de MAUI en la preview de Visual Studio 2022:

// Detect dark theme var iframe = document.getElementById('tweet-1524433653501239296-899'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1524433653501239296&theme=dark" }

Porque Visual Studio 2022 tampoco para, ya se ha lanzado la versión 17.2, incluyendo las siguientes features:

Mejoras para el debugging de colecciones
Live preview de webs para ASP.NET
Mejoras para el desarrollo con Azure
Mejoras de experiencia con Git dentro del IDE

Taller de .NET MAUI

Javier Suárez está publicando, vídeo a vídeo, un taller introductorio a .NET MAUI en su canal de YouTube. Si estás deseando crear tus próximas futuras aplicaciones multiplataforma con una nueva herramienta, aquí tienes la solución:

Al momento de escribir esto, tenemos 7 episodios, pero puedes ver todo el temario planificado en el repositorio de GitHub, junto con todas las diapositivas y demos.

Novedades de .NET 7 Preview 4

En el artículo original de esta noticia podéis ver todos las novedades relacionadas con ASP.NET Core, entre las que se encuentran:

Mejoras para OpenAPI en minimal APIs
Client results en SignalR
Mejoras de performance en HTTP/2
Devolver múltiples tipos de resultados en minimal APIs
Route groups

Entre otras cositas, como las novedades para Entity Framework 7 preview 4 y las que también anuncian de la última preview de .NET 7 en general.

#MSBuild 2022

Y esto no acaba aquí, porque se acerca el Microsoft Build.

Este evento es en el que Microsoft saca toda su artillería para mostrar todos los productos que están por venir, mejorar y sorprendernos. Más juguetes y herramientas con las que seguir creando y aprendiendo.

// Detect dark theme var iframe = document.getElementById('tweet-1518985549591289856-743'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1518985549591289856&theme=dark" }

¡Nos veremos en #MSBuild, del 24 al 26 de mayo!

Junior devs, ¿qué espero encontrar?

elena — Mon, 25 Oct 2021 07:47:18 +0000

Al momento de escribir este artículo, voy en camino a los cuatro años dentro del mundo del desarrollo de forma profesional. He vivido cambios de empresas, muchas personas, diversas tecnologías…

Es un recorrido en el que creo que puedo decir que ya no soy junior, pero tampoco me considero senior o experta en las materias con las que trabajo diariamente. Así que me lancé a preguntar en Twitter si os gustaría leer sobre cosas que espero o me gustaría encontrar en alguien junior que entra a desarrollar y trabajar conmigo. Es cuestión de mirar atrás, tomar perspectiva y empatizar con quien está empezando.

La respuesta a la encuesta fue tremendamente positiva, así que me pregunto: ¿qué me gustaría encontrar en junior devs cuando trabajan conmigo? ¡Comencemos!

Podría ponerme a listar tecnologías o a hablaros de lo mucho que me gusta .NET y todo el ecosistema Microsoft, pero no se trata de eso. Haré una pequeña categorización para dejar claro cada punto a tratar.

En soft skills

Curiosidad

El mundo del desarrollo es enorme, y parece que crece cada día más. Nuevas tecnologías, frameworks, herramientas. Hay tanto que resulta abrumador, y es normal, especialmente cuando estáis empezando.

Pero por eso estáis en un equipo con muchas personas con diferentes backgrounds, experiencias y áreas de conocimiento. No os cortéis en preguntar qué áreas podéis investigar, qué tecnologías resultan más útiles en una determinada tarea…

Paso a paso, vais conectando piezas y encontrando el camino. Siempre habrá cosas que mejorar y cambios de direcciones en el aprendizaje, pero creo que es lo mejor.

Recordad que trabajáis en un equipo y podéis apoyaros en él para satisfacer vuestra curiosidad.

Comunicación

Esta es quizás una de las más difíciles, pero a la vez que considero muy importante.

Saber expresarte por escrito o bien hablando es realmente valioso. ¿Por qué? Porque expresándote de forma adecuada, puedo:

Ayudarte más rápido
Resolver tus dudas con mayor precisión
Detectar posibles malentendidos o errores de concepto a la hora de abordar una tarea
Reconducirte si es necesario hacia un camino más sencillo

Ya sea a viva voz o por escrito, valoro mucho cuando me expresan una necesidad de forma clara, concisa y concreta. Por resumirlo de alguna forma, cuando necesitéis ayuda es fantástico leer la siguiente información:

¿Con qué tarea estás o qué estás haciendo?
¿Cuál es el problema o duda?
¿Qué has intentado?

Porque al estar enfrascada en mis propias tareas, necesito todo el contexto posible de tu problema o situación para poder entenderte y ayudarte.

Proactividad

Es normal otorgar tareas pequeñas y/o cortas a juniors, especialmente cuando estáis empezando. Así, poco a poco, se puede ir midiendo vuestra velocidad y autonomía, e ir escalando gradualmente en dificultad o complejidad.

Con el tiempo iréis cogiendo velocidad, y acabarán tareas más rápido, con menos errores y con menos ayuda. Lo que aprecio muchísimo es, si te ves sin tarea, has acabado antes de tiempo o no hay nada que hacer de forma activa, encontrar alguna de las siguientes preguntas:

¿Qué más puedo hacer?
¿Qué puedo investigar?
¿Puedo ayudar con algo?
¿Hay alguna tarea con la que pueda empezar?

No quiero decir con esto que no despegues la mirada del monitor, descansar es necesario y más que recomendable, pero creo necesario el percibir las ganas de crecer y evolucionar.

En tech skills

Git y buenas prácticas de control de versiones

Git es una herramienta que considero indispensable si trabajas con otras personas en cualquier tipo de solución, independientemente de la tecnología y el lenguaje. No pido que tengas un perfil de GitHub con +8000 repositorios y un tablero de contribuciones lleno. Pero sí un manejo fluido de repositorios y ramas.

¿Cuales son las buenas prácticas que aprecio?

Commits descriptivos
Higiene y buen mantenimiento de ramas
Resolución de conflictos entre ramas
Pull requests bien documentados

Comprensión del código

La mayor parte de los lenguajes, por no decir todos, tienen estructuras similares si no iguales. Entender cómo usar variables, estructuras condicionales, bucles, refactorización… son nociones básicas.

No me importa tanto la tecnología o el lenguaje como el dominio que tengas de la programación en general. Poco a poco, los detalles específicos de cada tecnología irán llegando en forma de documentación, y se irán perfeccionando a base de práctica.

Otros conocimientos como infraestructura, entornos, despliegues, automatización… ya llegarán, con el tiempo a medida que evoluciones y sigas progresando en proyectos. Pero, de forma totalmente intencionada, en primer lugar y en mayor número se encuentran las soft skills.

Después de leer todo esto:

¿Añadirías alguna otra?
¿Crees que sobra alguna?

Si eres junior o llevas poco tiempo desarrollando, ¿cuál es la habilidad o el conocimiento que te hubiera gustado aprender o desarrollar antes?

Espero que os sea útil, y cualquier feedback a que queráis compartir es más que bienvenido en comentarios o en Twitter.

seeU!

Empatía y código ajeno

elena — Mon, 20 Sep 2021 08:48:56 +0000

Todo el mundo ha empezado cometiendo errores, creando mal código (o al menos, altamente refactorizable) y con mucho margen de mejora. Y cometeríamos un error si olvidamos esta realidad para hacer daño a quienes están empezando o mejorando.

A veces me da miedito subir capturas de mi código porque siento que aquí esperan ver puro código senior level, la vdd no me molesta recibir recomendaciones y/o críticas constructivas pero hay gente que sí se pasa (hay maneras de aportar). Pero csm de todos modos lo subo 😜😹 - Miranda, en Twitter

Quiero escribir sobre la exposición en redes, lo complicado de hacerlo de forma voluntaria... y lo erróneo que es hacerlo sin consentimiento o contra los deseos de la persona autora.

Hace unos días veía cómo una persona reconocida, valorada y bien considerada en el mundo del desarrollo tomaba una captura del código de alguien anónimo y exponía todos los errores que ese código contenía. Y como este ejemplo habrá otros muchos, desde luego, pero este es el más cercano que tengo y el más reciente que conozco.

Encuentro muchos problemas con todo este asunto, que voy a desarrollar todo este asunto para intentar crear conciencia.

"Lo que mejora las cosas es la conexión", Brené Brown sobre la empatía y vulnerabilidad

¿Qué hay que tener en cuenta? ¿Cuales son los problemas que encuentro con todo esto?

Empatía

La empatía es sentir con las personas, conectar con ellas. No podemos dejar conectar con las personas, para poder entender su posición, buscar la mejor forma de crecer en compañía y acompañarlas en el camino a ser mejores.

Recordar nuestra historia

Como decía al principio, no hay quien no haya pasado por los primeros pasos, los errores comunes, código no refactorizado, escrito a la carrera y con alto margen de mejora. Y precisamente hay que dar un paso atrás y ponernos en la piel de la otra persona... y pensar cómo nos podría sentar algo así si volviesemos a esa posición, o nos encontremos en un momento vulnerable o difícil.

Pensando en el futuro

Minar la moral de una persona aunque sea de forma anónima tiene muchas consecuencias en las que quizás no hayamos pensado. El temor a este tipo de exposición puede desembocar en que alguien que esté empezando no muestre su código, no busque ayuda... y por lo tanto no mejore tan rápido como podría o en el mejor ambiente. Esto, pensando a gran escala, afecta a nuestro sector.

Crear una cultura de la vergüenza en el desarrollo creará más *developers *con miedo a mostrarse vulnerables en su aprendizaje, algo que es clave para mejorar. ¿Necesitamos eso realmente? Estoy bastante segura de que no.

El alcance de nuestras acciones

Con este punto no quiero decir que una acción sea mejor o peor dependiendo de la visibilidad que tengamos en foros, redes sociales o dinámicas de grupo. Pero sin duda, la onda expansiva de una acción tendrá mucho más peso, y atraer reacciones dañinas, si tienes alcance a mucha gente.

Ser un ejemplo para mucha gente

Hay personas que, por decisiones de una entidad, el trabajo realizado o simplemente por carisma natural, son más visibles y son tomadas como un ejemplo a seguir. Esto es una gran responsabilidad, porque la gente busca en ti un apoyo, una fuente de conocimiento... y en ocasiones acciones a seguir. Esto ocurre en redes sociales y fuera de ellas, y muchas veces ocurre de forma natural, sin que la persona en particular lo busque. Pero, lo hayamos buscado o no, es así y debemos tener cuidado con lo que decimos y hacemos.

Si hay algo que debatir sobre este tema, quisiera que fuera un debate sano, un debate que aporte, que nos haga reflexionar sobre si hemos caído en esta falta de empatía y si debemos dar un toque a las personas que lo hacen a nuestro alrededor.

La comunidad se crea entre todas las personas que la conforman, y todas las prácticas, positivas o negativas, pueden crear tendencias y patrones.

¿Que patrones queremos repetir? ¿Cuales son las prácticas que queremos ver a lo largo del tiempo? ¿Cuál es el legado que podemos dejar en la comunidad y las personas?

Pensemos a futuro, en las consecuencias que pueden tener nuestras acciones, tanto en las dinámicas de grupo en los que participamos y las personas que hay a nuestro alrededor. Cuidemos, o al menos no dañemos, a las personas en la medida que esté a nuestro alcance, estén cerca o lejos.

seeU!

Buenas prácticas en Azure DevOps

elena — Mon, 29 Mar 2021 06:52:22 +0000

Si no conoces Azure DevOps, es un servicio de Microsoft que nos permite implementar de forma más sencilla la cultura DevOps en nuestros proyectos de desarrollo.

Puedes crear una organización y hasta 300 proyectos de forma gratuita, por lo que puedes dividir todo tu trabajo en diferentes proyectos.

No existen reglas estrictas sobre buenas prácticas, pues cada proyecto es un mundo y tiene sus propias necesidades, pero sí que voy a escribir lo que considero algunos consejos útiles después de bastante tiempo trabajando con esta herramienta.

¡Comenzamos!

Metodología de equipo

Lo primero y más importante es definir reglas, convenciones, para trabajar en equipo.

Mientras tu equipo y tú tengáis una metodología común y clara a seguir, todo debería estar bien. Pero Azure DevOps te ofrece plantillas de metodologías orientadas a la gestión de tareas como Agile, SCRUM... para que te sirvan de apoyo en tus procesos de trabajo.

Tienes la documentación de Microsoft para saber todos los procesos entre los que puedes elegir. Aunque, si tienes dudas o no tienes claro cuál deberías elegir, siempre puedes elegir el proceso Basic.

Despeja la vista

Azure DevOps te ofrece, por defecto, los siguientes servicios: Dashboards, Repos, Boards, Pipelines, Artifacts y Test Plans.

Como cada proyecto es un mundo, puede que solo necesites cuatro, dos o solo uno de los servicios que acabo de listar. Así que, en ese caso, puedes desactivar aquellos servicios que no uses. ¿Cómo puedo hacerlo? Aquí tienes una guía, en la documentación oficial de Microsoft, donde muestra lo sencillo que resulta.

Usa la Wiki

Documenta todo lo que necesites. La documentación de proyectos es considerada una de las partes más pesadas del mundo del desarrollo. Es una de las partes más olvidadas a la vez que más valiosas de un producto.

Ya sea para hacer el *onboarding *a alguien que recién entra en el proyecto de forma más sencilla, para tener bien detallada la infraestructura o los diferentes entornos, la estrategia o arquitectura elegida en las diferentes soluciones... es algo que olvidamos con frecuencia pero que resulta muy útil de cara al futuro.

Al estar dentro de Azure DevOps, puedes crear diferentes páginas y secciones dentro de la Wiki, además de enlazar con sencillez elementos como Tasks, pipelines... y reunir toda la información en un mismo lugar.

Establece tus Teams

Establece bien los equipos de trabajo y su visibilidad de los diferentes elementos del proyecto. Dentro de cada proyecto, no todas las personas que forman parte del mismo tendrán la misma responsabilidad o visibilidad de las diferentes partes de la solución.

No todo el mundo podrá validar pull requests, no todo el mundo podrá hacer despliegues... y en lugar de gestionar esos permisos a cada persona de forma individual, podrás dar permisos a los *Teams *que consideres oportunos y agregar a personas a estos, para recibir esos permisos que se hayan asignado al Team.

Dashboards y widgets

Uno de los servicios que tiene Azure Devops es Dashboards. Su función es darte un entorno que personalizar por completo a través de widgets para tener un vistazo general del proyecto.

Puedes tener un Dashboard, totalmente independientes entre sí, por Team, para que cada uno tenga su propia visión de tareas, burndowns en los sprints, gráficos de pipelines, porcentajes de éxito en el testing...

Al final, tu proyecto puede visualizarse como la siguiente imagen, o de forma totalmente diferente según tus necesidades:

No dudes en consultar la documentación de Microsoft para conocer más sobre este servicio.

Usa las pipelines

Las pipelines, que son el nombre que reciben los procesos automatizados para integración continua o CI, son realmente potentes. Hay tareas para múltiples tecnologías, no solo las que pertenecen a Microsoft.

¿Quieres saber todo lo que puedes hacer en una pipeline? Echa un vistazo a la lista de todas las Tasks que hay disponibles en el catálogo: tareas de utilidad, compilación en Android, invocación a Azure, llamadas a Jenkins...

Queries sobre tus Tasks

Cuando un proyecto se alarga en el tiempo y tiene mucha actividad, es normal tener muchas, muchísimas tareas, que se han generado a lo largo del tiempo de vida de la solución.

Para evitar tener que navegar entre sprints, tareas asignadas o casi adivinar dónde estaba qué tarea, Azure DevOps ofrece un servicio poco conocido pero realmente potente: las Task Queries.

A través de un editor SQL-like de forma gráfica, puedes hacer consultas sobre todas las tareas que se encuentren en un proyecto, parametrizando para buscar por personas asignadas a esas tareas, estados en los que se encuentran, *sprints *en los que se localizan...

Estas queries no son volátiles: puedes guardarlas para seguir trabajando sobre ellas o ejecutar la consulta tantas veces como necesites. Además, están integrados con algunos de los *widgets *de Dashboards, por lo que puedes ver los resultados de una *query *en Dashboard de tu Team... ¡y tener toda la información a tu alcance!

Una organización, múltiples proyectos

Como mencionaba al inicio de este post, una misma organización puede contener hasta 300 proyectos de forma totalmente gratuita. Teniendo esa posibilidad, y para evitar el caos, crea siempre tus proyectos en la misma organización si pertenecen a un mismo equipo, empresa o grupo.

Crear múltiples organizaciones es tentador y sencillo, pero después es difícil mantener control de qué proyecto se encuentra en qué otra organización... cuando sería más fácil tenerlo todo reunido en un mismo sitio. ¡Usa las herramientas que tienes a tu alcance!

Buenos nombres de proyecto, por David Gonzalo

Otra buena práctica, esta vez aportación de David Gonzalo, es sobre nombres de proyectos. A la hora de crear un proyecto, puedes darle un nombre en el que puedes incluir espacios en blanco.

// Detect dark theme var iframe = document.getElementById('tweet-1330799020537749508-540'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1330799020537749508&theme=dark" }

Esto es algo que os invitamos a evitar, pues este nombre con espacios se convertirá al final en parte de las URLS para, por ejemplo, tus repositorios. Al final, si incluyes una URL con espacios, tu cadena de conexión para clonar, pushear o pullear repositorios puede ser así:

http://dev.azure.com/WikkaLab/My%20Project/_git/MainAPI

No es la URL más intuitiva, puede inducir a errores difíciles de detectar a primera vista... por lo que, recomendamos mantener nombres de proyecto con camelCase, PascalCase, snake_case o kebab-case, o cualquier otro sabor que más te guste, mientras evites los espacios en blanco.

¡Gracias por tu aporte, David!

¡Y esto es todo por ahora!

¿Usas Azure DevOps para proyectos profesionales o personales? ¿Tendrías más consejos que ofrecer desde tu experiencia? No dudéis en escribirlos en comentarios, para añadirlos al post enlazando a vuestras redes sociales.

Este contenido tiene su origen en el post de reddit "Azure DevOps Best Practices", donde puedes seguir leyendo sobre la cuestión, ver más comentarios respondiendo a la consulta o aportar tus propias experiencias.

seeU!

Non-binary developer here!

elena — Thu, 18 Jun 2020 20:35:04 +0000

Hi! My name is Elena, and I'm a .NET developer located in Spain. I'm a non-binary person, so you can use she or they pronouns to talk with me.

I'm proud of my identity as a non-binary person. Also, my appearance is very androgynous, which is why people have long wanted to place me in a binary world that doesn't really exist.

For a long time, it was a problem and a reason to feel ashamed, wrong with myself. But not anymore.

I am who I am, I am as I am, and there is nothing wrong with it.

This does not boil down to the phrase "love is love". Relationships between LGTBQIA+ people are not just love. The LGTBQIA+ movement is about people who have the right to be, exist, live, work and develop like everyone else.

I find support on people like me, who express themselves on social networks and in communities around me. And I look with hope to those people who are discovering their identity in this spectrum of identity and sexuality. Also in people who, although they do not belong to the movement, look, understand and support.

I am a non-binary programmer who finds another piece of happiness in movements like this, in dev.to, opening their space for all of us.

Thanks, community, and thanks for reading.

And yeah, this is politics. But life is, because it's all about people.

And never forget:

Trans rights are human rights. Black live matters. Trans black live matters

Refactorizando vidas con AngularMalaga

elena — Mon, 06 Apr 2020 09:03:39 +0000

El día 25 de marzo era un día muy especial. Era el día en que la comunidad de AngularMálaga me había invitado como ponente para compartir mi conocimiento y mis intereses sobre programación. Con la noticia que está sacudiendo el planeta parecía que no sería posible llevarlo a cabo.

Pero conseguimos salvar los obstáculos encontrados, ¡pues nos reunimos de forma digital a través de YouTube!

¿Qué es AngularMálaga?

AngularMálaga es la comunidad de personas interesadas en Angular, que usan este framework de forma ya sea profesional o bien por afición. Hay muchas comunidades de Angular a lo largo del mundo, pero esta se concentra en Málaga.

Puedes encontrar más información en su grupo de Meetup o bien en su web, pero en estos tiempos de confinamiento y cuarentena, su contenido se concentrará en el canal de YouTube.

De forma local, son más de 800 personas, ¡y espero que sigan creciendo!

¿De qué trató el evento?

La calidad del código es muy importante, y para conseguirla es vital usar la empatía. Detrás y al final del software, lo que hay son personas, y necesitamos tratar con ellas para realizar múltiples tareas: determinar especificaciones de un producto, escribir código legible y claro para el equipo de desarrollo, explicar al cliente lo que necesita saber...

Todo empieza por código limpio, refactorizando el código que escribimos para mejorarlo dentro de lo posible.

Así que, desde nuestras variables hasta la Programación Orientada a Objetos, ¿cómo podemos mejorar nuestro código? ¿Cómo aplicamos la empatía en nuestro equipo de desarrollo? Esto es lo que abordamos en el meetup.

¿Habrá más en el futuro?

¡Puedes apostar por ello! La comunidad de AngularMálaga agenda un evento al mes, y han demostrado que esta situación no es un impedimento para llegar a las personas que la componen.

No perdáis de vista su actividad en redes, os podéis suscribir a su canal de YouTube para futuros eventos, ¡porque habrá mucho contenido por disfrutar!

seeU!

Enseñando programación en C# con @yeswetech_org

elena — Wed, 12 Feb 2020 09:41:56 +0000

YesWeTech es una asociación que conozco desde hace unos años y que siempre ha estado ahí. De hecho, mi primera participación en un evento fue gracias a ellas y también a GDG Málaga. Guardo un especial cariño por este grupo, y quise iniciar con ellas estas actividades.

Un taller de introducción a la programación, ¿por qué no? Con C#, el lenguaje con el que aprendí a programar y con el que trabajo cada día. Esta es mi experiencia.

Reunidas en el Centro de Espacios Participativos, gracias a la Plataforma de Voluntariado de Málaga, aprendimos lo que es la programación y por qué la practicamos.

Hay un pensamiento bastante generalizado de que la programación solo sirve “para programar”… cuando en realidad ¡sirve para todo! La programación es un conocimiento que se puede aplicar a cualquier campo. Para cualquier área de conocimiento hay tareas que se pueden automatizar o simplificar gracias al desarrollo de aplicaciones.

Conceptos básicos como las variables, condicionales y también bucles… dejando claro que son las herramientas a las que podemos recurrir para crear nuestras aplicaciones. Empezamos por aplicaciones de consola en C#. Puede parecer poco, ¡pero está vivo!

Paso a paso, puedes seguir aumentando el código que vas generando hasta crear soluciones a problemas sencillos. Una aplicación que te saluda de forma personalizada, otra que te calcula la edad, otra que te recoge datos personales, otra que te gestiona tareas pendientes…

Utilizamos dotnetFiddle para programar sin necesidad de instalar software en nuestro equipo, pero si quieres dar el paso a instalar un IDE y programar desde tu equipo:

Cómo crear una aplicación en consola con Visual Studio Code, un IDE limpio y sencillo con el que programar aplicaciones de forma sencilla.
Tutoriales oficiales de Microsoft para C#, por si tienes dudas sobre cómo se escribe el lenguaje y sus palabras clave.
Aventuras .NET, una serie de artículos que estoy escribiendo donde explico con detalle algunas de las lecciones que aprendimos en el taller.

La idea original es una serie de talleres que introduzcan a diversas tecnologías y conocimientos en este sector… como introducción al desarrollo web, diseño de base de datos… ¡aún no sabemos dónde acabaremos!

Porque creo que es realmente importante compartir el conocimiento que tenemos, propagar aquello que nos apasiona… haciendolo accesible a aquellas personas que no tienen la oportunidad o simplemente no han visto un camino posible en este mundillo.

Puedes seguir leyendo sobre otro taller de introducción a la programación que tuve la oportunidad de impartir en TalentWoman Summit, en diciembre de 2019, con CodeHouse Academy.

Volveré pronto, y espero que con experiencias de futuros talleres.

seeU!

Aventuras .NET, tomando decisiones

elena — Fri, 31 Jan 2020 20:09:13 +0000

Te damos la bienvenida a la tercera entrega de Aventuras .NET, para aprender los fundamentos de la programación con C#.

En esta aventura, vamos a conocer los condicionales, porque en la programación es fundamental tomar decisiones.

Los condicionales se basan en el tipo booleano. Ya conocemos algunos tipos de texto: las cadenas de texto se conocen como strings, los números enteros se conocen como integers… pero hay un tipo especial de datos llamados booleans.

Los tipos booleans o booleanos solo contemplan dos opciones: verdadero o falso. Vamos a declarar dos variables que almacenarán valores booleanos para dos situaciones diferentes. En mi caso, resulta que me gusta programar y me encanta el cine, por lo tanto:

bool meGustaProgramar = true;
bool noMeGustaElCine = false;

¿Para qué usamos estas variables? Para tomar decisiones en base a esos valores.

if (meGustaProgramar == true)
{
    Console.WriteLine("Me gusta programar");
}

La sintaxis es muy literal. Lo podemos leer “si me gusta programar, escribo por pantalla diciendo que me gusta”.

Podemos incluso simplificar la expresión. La sentencia de if comprueba si el valor de la variable meGustaProgramar es cierta, es true. Por lo que podemos escribirlo de la siguiente forma:

if (meGustaProgramar)
{
    Console.WriteLine("Me gusta programar");
}

También podemos contemplar, reaccionar con código si la condición no se cumple, si no me gustase programar. La sintaxis vuelve a ser muy literal: “si me gusta programar, lo diré con alegría; si no, diré que no me gusta”.

if (meGustaProgramar)
{
    Console.WriteLine("Me gusta programar");
}
else
{
    Console.WriteLine("No me gusta programar");
}

Las decisiones no siempre serán así de sencillas. A veces necesitamos contemplar más variables, y para eso existen operadores condicionales.

El primer operador ejecuta el código dentro del condicional solo si las dos condiciones se cumplen, solo si las dos variables son true. El siguiente código podemos leerlo como “si me gusta programar y me gusta C#”, escribiré el mensaje en pantalla”.

if (meGustaProgramar && meGustaCsharp)
{
    Console.WriteLine("Me gusta programar en C#");
}

Este operador se conoce como AND, literalmente describe una condición como: “si se cumple esta condición Y la segunda”…

El otro operador ejecuta el código en su interior si al menos una de las variables es cierta. ¡Puede ser una de ellas o todas! Se puede leer como “si me gusta la pizza o el sushi, diré que me encanta alguna de las opciones”.

if (meGustaLaPizza || meGustaElSushi)
{
    Console.WriteLine("Me gusta la pizza o el sushi... ¡o tal vez los dos!");
}

Este operador se conoce como OR, literalmente describe una condición de la siguiente forma: “si se cumple esta condición O la segunda”…

Y estos son los condicionales, con los que podemos tomar decisiones y ejecutar código de diferentes formas dependiendo de los valores con los que estemos operando.

Esto es todo por ahora, ¡y en el siguiente post hablaremos de listas y bucles!

Aventuras .NET, ¡descubre los métodos!

elena — Tue, 28 Jan 2020 12:29:46 +0000

Las aventuras .NET continúan, ¡y esta vez para aprender qué son los métodos e implementarlos en nuestra aplicación!

Sigamos desarrollando la aplicación de consola que creamos en el primer post, donde arrancamos la aplicación y saludamos al mundo.

Hasta ahora nuestro código era así, una aplicación sencilla que saluda, da unas breves instrucciones, espera a recibir tu nombre y saludarte de una forma personalizada:

static void Main(string[] args)
{
    Console.WriteLine("¡Hola! Dime tu nombre");
    Console.WriteLine("Después pulsa ENTER");

    string tuNombre = "";

    tuNombre = Console.ReadLine();

    Console.WriteLine("Bienvenid@, " + tuNombre);

    Console.ReadLine();
}

Este código es sencillo, pero a medida que las necesidades cambian y el código crece, puede que no queramos apilar y apilar líneas y líneas de código dentro de esta sección llamada Main… ¿pero qué es exactamente?

Main es lo que conocemos como un método. Es una porción de código que se ejecuta, desde la primera línea hasta la última, tal y como vemos que funcionan los programas.

Los métodos agrupan código bajo un nombre concreto, para llamar a ese código a través del nombre que le hemos dado. Son “invocados”, ejecutan su código y después regresan al lugar desde donde han sido invocados para seguir ejecutando el código que reste. ¿Podemos escribir nuestros propios métodos? ¡La respuesta es sí!

Bajo el código que encierra Main, después de las llaves que encierran su código (los símbolos { y }), empezamos a escribir más código, como el que puedes ver aquí:

static string ObtenerNombre()
{
    string nombre = "";
    nombre = Console.ReadLine();
    return nombre;
}

Hemos creado un fragmento de código que con un nombre concreto, ObtenerNombre, que tiene tres sencillas líneas.

Declara una variable, espera a que escribas su contenido y, literalmente, la devuelve a quien ha llamado al método, gracias a la palabra return. La variable que hemos creado dentro de este método, llamada nombre solo tiene la función de recoger el nombre y lanzarlo hacia el método que lo llama. Después de que el método sea ejecutado, ¡la variable deja de existir! Solo existe dentro de su método.

Si quieres comprobarlo, prueba a escribir el contenido de esa variable dentro del método Main, donde puedes ver que no existe:

static void Main(string[] args)
{
    Console.WriteLine("¡Hola! Dime tu nombre");
    Console.WriteLine("Después pulsa ENTER");

    string tuNombre = "";

    tuNombre = Console.ReadLine();

    // La siguiente línea mostraría un fallo
    // porque fuera del method no existe
    //Console.WriteLine(nombre);

    Console.WriteLine("Bienvenid@, " + tuNombre);

    Console.ReadLine();
}

static string ObtenerNombre()
{
    string nombre = "";
    nombre = Console.ReadLine();
    return nombre; 
}

Una vez hemos comprobado que las variables de un método solo existen dentro de los límites del método, es decir el código que está dentro de sus { }, podemos avanzar.

Ahora podemos sustituir las líneas dentro del método Main que pedían nuestro nombre, lo escribían en una variable… por el método que acabamos de crear. Finalmente, el código quedaría de la siguiente forma:

static void Main(string[] args)
{
    Console.WriteLine("¡Hola! Dime tu nombre");
    Console.WriteLine("Después pulsa ENTER");

    // Hemos sustituido las líneas que pedían nuestro nombre
    // por la llamada al method que hemos creado
    string tuNombre = ObtenerNombre();

    Console.WriteLine("Bienvenid@, " + tuNombre);

    Console.ReadLine();
}

static string ObtenerNombre()
{
    string nombre = "";
    nombre = Console.ReadLine();
    return nombre; 
}

¡Pulsa ▶️ y ejecuta la aplicación, tal y como hicimos en el capítulo anterior! Comprobarás que el funcionamiento es exactamente el mismo, pero hemos mejorado la forma en la que lo escribimos.

Las ventajas de los métodos es que podemos llamarlos tantas veces queramos, ahí reside su potencia. ¡Podemos ejecutar el código múltiples veces sin necesidad de repetir código! Así que podemos modificar el contenido de Main para pedir y almacenar dos nombres diferentes, a los que saludaremos:

static void Main(string[] args)
{
    Console.WriteLine("¡Hola! ¿Cuales son vuestros nombres?");

    Console.WriteLine("Primer nombre: ");
    string tuNombre = ObtenerNombre();
    Console.WriteLine("Segundo nombre: ");
    string otroNombre = ObtenerNombre();

    Console.WriteLine("Bienvenid@, " + tuNombre);
    Console.WriteLine("Bienvenid@ también, " + otroNombre);

    Console.ReadLine();
}

En el próximo post, exploraremos los bucles y su gran utilidad.

seeU!

Tu primera aplicación en .NET

elena — Tue, 31 Dec 2019 13:20:33 +0000

¿Quieres empezar a programar en .NET? Tras haber instalado Visual Studio en tu equipo, tienes las herramientas y las ganas de crear. ¿Cómo hacerlo entonces?

Vamos a crear nuestra primera aplicación en consola en esta aventura .NET.

Puedes crear tu primero proyecto a través de Visual Studio, pero también desde la terminal o consola. Escribiendo el siguiente comando, se creará un proyecto y todos los directorios y ficheros necesarios.

dotnet new console --output MiPrimeraApp

Se creará en la localización desde donde hayas ejecutado este comando, así que puedes abrir el directorio con Visual Studio.

Escribiendo nuestras primeras líneas

Lo principal es explorar el fichero Program.cs, que es la Clase donde se encuentra el primer (y único en este caso) código que se va a ejecutar:

using System;

namespace MiPrimeraApp
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello World!");
        }
    }
}

Prueba a ejecutar la aplicación, ¡y verás el resultado!

Es posible que, al ejecutar, se muestre una pantalla negra que se cierre rápidamente. En este caso, el código que estás ejecutando necesita una nueva línea que espere que pulses la tecla ENTER para continuar, o cerrarse.

Edita el código siguiendo el siguiente fragmento de código y prueba a ejecutar de nuevo.

using System;

namespace MiPrimeraApp
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello World!");

            // Añade esta nueva línea:
            Console.ReadLine();
        }
    }
}

Hasta ahora, lo único que esta aplicación hace es saludar por pantalla, con un mensaje genérico. Lo primero que hacemos como developers es saludar al mundo, ¡es una curiosa tradición que aún perdura!

Pero podemos mejorar nuestro código, haciendo que no solo mostremos mensajes por pantalla si no que también reaccionar a los datos que introduzcamos.

Vamos a seguir modificando el código de forma que nos pida un nombre por el que saludarnos, almacenarlo en una variable y utilizar esta para saludarnos.

using System;

namespace MiPrimeraApp
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("¡Hola! Dime tu nombre");
            Console.WriteLine("Después pulsa ENTER");

            string tuNombre = "";

            tuNombre = Console.ReadLine();

            Console.WriteLine("Bienvenid@, " + tuNombre);

            Console.ReadLine();
        }
    }
}

Entendiendo el código

Escribimos código para dar soluciones a situaciones concretas, y para eso es fundamental entender el código. Lo primero que hace es saludar por pantalla, después declararemos una variable, de tipo string, o texto, para guardar nuestro nombre.

Las variables pueden almacenar datos de diferentes tipos: texto, números, números decimales, listas… Todo depende de lo que necesites en un determinado caso.

Esa variable está vacía en inicio, pero después le indicamos que almacene cualquier cosa que escribas hasta pulsar ENTER.

Es momento de ejecutar la aplicación. En la barra superior de Visual Studio, pulsa el botón ▶ para iniciar la aplicación que acabas de crear. Así, el programa se ejecuta, te pide un nombre y con lo que sea que hayas escrito, el programa te saludará y te dará la bienvenida a la aplicación.

¡Ya estás programando!

¡Felicidades, has empezado el camino! Este es el primer paso para crear aplicaciones. Ahora puede ser una aplicación de consola que parece muy simple, pero estos primeros pasos son los que pueden llevarte a hacer una aplicación de escritorio, web o muchas otras tecnologías increíbles.

Sígueme en esta aventura .NET para seguir creando aplicaciones.

seeU!