DEV Community: Mirjam Aulbach

Do we need safe spaces for minoritised people in tech?

Mirjam Aulbach — Sun, 17 Jul 2022 16:30:28 +0000

And why my answer is still a big YES.

This article is originally from Aug 29, 2019. I'm moving my content from medium to dev.to

In 2019, I’ve spent a weekend at the SoCraTes Conference, an un-conference organized by members of the Softwerkskammer, a community of Software Craftspeople whose members are mostly located in Europe.

One of the values SoCraTes is listing on its website is:

We are committed to providing a friendly, safe and welcoming environment for all, regardless of gender, sexual orientation, programming language, ability, ethnicity, socioeconomic status, and religion (or lack thereof).

-> https://www.socrates-conference.de/values

I had four awesome days, met great people, found like-minded and different-minded folks to have respectful discussions with, made connections and friends. There were many lessons I took from this Open Space, I can’t even wrap my head around all of them now.

But there’s one thing that stood out, is still very present in my mind, still bothering me. One thing I want to share with y’all.

Nail polish session

In spirit of Open Space conferences, the topics at SoCraTes covered a wide spectrum. So we had one session about nail polish. Some people brought equipment, some just their curiosity — and nails, obviously. We sat together, did our nails and talked about nail polishing tricks, wearing nail polish while presenting as male and all in between.

The session was visited by people who identified as women, as men, non-binary folks. It was a really nice and diverse bunch, I had lots of fun. And pretty nails afterwards! Later someone put a lot of the equipment up in one of the lounge areas and gradually the amount of people wearing colorful nail polish grew 🌈

Results of our nail polish session at SoCraTes 2019. Picture credits (and thanks!): Koen Metsu. And yes, there's still work to be done for more diversity in different aspects.

Safe Space

This un-conference was what I consider a Safe Space in our technology community: A place were people, especially from minoritised groups, can feel safe and free of judgment or even harm.

Coincidentally, we had a discussion about the pros and cons, the need or even harm, of having such Safe Spaces in tech events. The opinions differed, but it was a meaningful and respectful debate. I’m very happy that I had the opportunity for an exchange with other opinions than mine.

One of the most expressed critics about Safe Spaces (in tech at least) is that they are forcing further separation of different groups instead of supporting inclusivity. It’s a valid argument.

In my opinion, providing Safe Spaces can be an important step to enable people of underrepresented groups gaining the confidence to join our community.

Shirt worn at the SoCraTes 2019, reminding us to use inclusive language. Original pics: https://twitter.com/coderbyheart/status/1164957001438433280

Leaving this place

For days, I saw people of all kind of genders with colorful nails and nobody seemed to see this as something unusual. White cis-male with glittering nails? So what.

Then we left the un-conference.

We took a regional train and were controlled by the train conductor, a middle-aged women, seconds in. The train station is only a few meters from the hotel, so we could still see the Safe Space we just left. My seat neighbor wore blue and yellow nail polish. When the conductor saw this, she commented immediately on it. Telling him that “your nails are ugly”, people would think he were “into men” and that he was a good looking guy so it would be “a shame” that the nails would make him “look gay”.

“This is not really happening right now”

…was all I could think in this moment.

He reacted great, telling her that he thought his nails looked good. She actually asked about his sexual orientation a few times — like she had any right to do so — but he didn’t answer this questions and just said it didn’t matter if he was into men or women or both. And that his nail didn’t have to do anything with it anyways.

Honestly, none of us by-sitters knew how to react in that moment and I’m still not sure what would have been a good way to handle this. The women sure noticed that her comment felt inappropriate for us, but I don’t think that’s quite enough.

Now there’s a lesson here

This interaction stayed with me for a while. And with Lucas — you know, the guy with the nice nails — too. He wrote down his own thoughts on that encounter and I highly recommend to read it, because it gives you another view.

In this situation, no real harm was done because my seat neighbor wasn’t fazed and the rest of us was not addressed in that way. But not everybody has — and can have — that kind of confidence. Not for everyone are this kind of things the exceptions but the norm.

But “Safe Space” sounds like the rest of the world is unsafe!

I say it is.

Sometimes the rest of the world is unsafe

What if that comment had been directed at someone who didn’t had that kind of confidence in this moment? I for sure wouldn’t have it! That person could have felt rightfully hurt because another human being just felt the need to tell them something about them was “ugly”.

What if that comment has been directed at someone who was homosexual? That person could have felt rightfully hurt because someone just used the “looking like you are gay” as an insult. As if the sexual orientation of this person was something that they should be ashamed of.

I don’t know if other people had similar experiences on their way home. I suspect so. Every day there are people out there who experience this.

So my stance on still needing Safe Spaces in the tech community was reinforced this weekend and especially through that train ride.

We need safe places to let people be. To let them breathe freely.

Let people safely wear nail polish because they want to, not because they have a certain sex. Wear what the heck they want, that is! Love who they want, be sexual attracted to whom they want or not be sexual attracted at all.

We need to provide places for people to calm down, recharge energy and to heal. To be empowered to deal with the world out there, were people may call you ugly just because you don’t fit their narrow-minded picture of the world.

Results from our Session about fostering diversity in tech (events). Original from Twitter: https://twitter.com/coderbyheart/status/1165251497476743173

My favored SCSS setup with Bootstrap 4

Mirjam Aulbach — Fri, 20 Mar 2020 18:02:13 +0000

This article is originally from Aug 25, 2017. I'm moving my content from medium to dev.to

You can find this setup as an example on github: https://github.com/programmiri/brunch-setup-bootstrap4

Please note that I used this repo also as an example for an article of mine about Setting up Brunch with Bootstrap 4, so that's the only reason it's based on Brunch.

First things first

I already worked with Bootstrap a few times in private projects (e.g. hundetrainer-barcamp.de) and I really, really like it! It's comprehensible and easy to get started with, even for a beginner. It's been love at the first site!

https://twitter.com/mirjam_diala/status/591253430464811008

My requirements and how I use Bootstrap

I'm using a specific setup and structure for my Bootstrap and SCSS in general. I want to:

use only selected components of Bootstrap instead of having the whole Bootstrap CSS in production
customize Bootstrap easily without touching the Bootstrap core files or overwriting styles over and over again
getting a neat and clean CSS in the end :)

My folder and file structure

How my setup looks in the end and how I like to work with it:

├── app/
│   ├── assets/
│   ├──  js/
│   ├──  scss/
│        └── bootstrap/
│            └── _config.scss
│            └── _pre_defaults.scss
│        ├──  bootstrap_ext/
│            └── _button.scss
│        ├──  _variables.scss
│   ├──  index.scss
│   ├──  index.js/
│   ├── file22.ext
│   ├──  file23.ext

Directory "scss"

There shouldn't be SCSS files directly in this directory other than the _variables.scss. I prefer to use the variables which are provided by Bootstrap. Only in cases there's nothing to be used from the Bootstrap core, I declare a custom variable in _variables.scss.

Directory in "scss": Bootstrap

config.scss

Bootstrap can be used very modular. I don't import the complete Bootstrap CSS. Instead I use import in the _config.scss to only get the components I want to use. In the end my CSS files only contains what I really need and use. Neat and clean - that's how I like it!

// READ MORE
// https://github.com/twbs/bootstrap
// https://get.getbootstrap.com

@import "pre_default";

// Core variables and mixins
// state in March 2018

// *** Core with grid
@import "functions";
@import "variables";
@import "mixins";
@import "root";
@import "reboot";
@import "type";
@import "images";
@import "code";
@import "grid";

// *** Standards
// @import "tables";
// @import "forms";
@import "buttons";

// *** Components
// @import "transitions";
// @import "dropdown";
// @import "button-group";
// @import "input-group";
// @import "custom-forms";
@import "nav";
@import "navbar";
// @import "card";
// @import "breadcrumb";
// @import "pagination";
// @import "badge";
// @import "jumbotron";
// @import "alert";
// @import "progress";
// @import "media";
// @import "list-group";
// @import "close";

// *** Components w/ JavaScript
// @import "modal";
// @import "tooltip";
// @import "popover";
// @import "carousel";

// *** Utility classes
@import "utilities/align";
@import "utilities/background";
@import "utilities/borders";
// @import "utilities/clearfix";
@import "utilities/display";
// @import "utilities/embed";
@import "utilities/flex";
// @import "utilities/float";
@import "utilities/position";
@import "utilities/screenreaders";
@import "utilities/spacing";
@import "utilities/text";
@import "utilities/visibility";

// *** Print classes
@import "print";


// *** READ MORE
// https://github.com/twbs/bootstrap
// Based on Bootstrap v4.0.0

@import "pre_default";

pre_default.scss

Bootstrap uses !default on each variable, which makes customizing very easy. It's the opposite of the notorious !important: While !important is like "Oh, there's a rule for this? I don't care, use this!", a variable with !default will only get defined by SASS if it isn't already set.

Take the variable $enable-rounded: true !default; as example: It's set in Bootstrap and rounds all the corners. And if I don't want rounded corners?

Simple: I write $enable-rounded: false; in the pre_default file. So when SASS is compiling the Bootstrap variables, $enable-rounded is already set and won't be touched. I didn't have to overwrite anything! Neat, huh?

// Example for the use of pre_default

$enable-rounded: true;

Directory in SCSS

bootstrap_ext

I customize and extend styles in Bootstrap in separate files, which are stored in a special folder. The file is named like the Bootstrap component I'm changing or extending.

Suppose I want to change the border width for all buttons and add a class for dark buttons: I create a file _button.scss - that's the name of the respective Bootstrap component - in the "bootstrap_ext" directory and adapt the style like this:

// Example for overwriting and extending bootstrap components

.btn {
  $button-border-width: 2px;

  border-width: $button-border-width;

  &.btn-dark {
    background-color: $black;
    border-color: $black;
    color: $white;

    &:hover {
      background-color: $white;
      color: $black;
    }
  }
}

With this structure it's easy to keep a clear overview where a style comes from and what Bootstrap component it extends or is based on.
From here it's up to you how to create your structure. As example, in a pet project I worked on, I used this structure:

├── css/
│   ├── bootstrap/
│   ├── bootstrap_ext/
│   ├── components/
│   ├── vendor/
│   ├── views/
│   ├── _variables.scss
│   ├── app.scss

Directory "vendor"

All vendor files are stored here.

Directory "components"

"components" contains custom SCSS components for this project, like "_calendar.scss".

Directory "views"

In "views" I place styles which are not reusable and specific for a single view. I prefer to work in components, so there shouldn't be much in here.

Tada.
That's it! My basic SCSS setup with Bootstrap 4. :)

How frontend unit testing turned from a fling to a real thing for me

Mirjam Aulbach — Fri, 28 Jun 2019 12:13:15 +0000

This article is originally from Sep 21, 2017. I'm moving my content from medium to dev.to

It’s hard to get around the word "testing" if you’re on your way to become a professional programmer. Of course I read about it and even spend a few hours writing tests and solving artificial problems with test driven development. But I didn’t have the opportunity to apply my acquired knowledge in my day to day coding life. It just isn’t a thing at my job. We don’t write tests (yet, I want to change that) and so for a long time, all I knew about testing was more on an academic level.

How the fling started

Pet projects to the rescue!

I’m lucky to work on a few pet projects with experienced programmers. The most important thing I learn from my these projects are new or different workflows, best practices and patterns. In a project I’m currently working on I finally wrote real tests in a real environment. Hell, I had a lot of fun!

By all means, I’m still a bloody beginner when it comes to unit testing. But now I finally saw and felt all the benefits I only read about before. And yeah, I fell in love a bit!

Since a few days I’m working on a text about testing in the frontend with an example from said pet project. It helps me learn more about testing. At the same time I try to build a simple workflow to test my code for an non-testing environment, so I’ll be able to deliver more stable solutions. My new found feelings for testing are there, but I’m not really sure if and how they will work in my job.

Real world catching up — TIFU

Today, I received a bug ticket. For a simple Javascript feature I wrote a few months ago. I saw the description of the ticket, took one look into the code and I was furious at myself. I could see my error right away and it was a stupid one.

Background: The script should take an integer and give back a number formatted in the € currency format — a dot as thousands separator if needed and “Euro” at the end.

That’s what my script looked like:

function formatSum(sum) {
  var sumNum = sum.toString().split('');
  var sumFormatted = [];

  for (var i = 0; i < sumNum.length; i++) {
    var currNum = sumNum[i];

    if (i != 0 && i % 3 == 0) {
      sumFormatted.push('.');
    }

    sumFormatted.push(currNum);
  }

  if (sumFormatted.length > 0) {
    sumFormatted.push(' Euro');
  }

  return sumFormatted.join('');
}

I wrote this almost 4 months ago and really, I’m not proud. Nobody noticed the error for quite a time, because the function was used to format integers delivered by an API and — coincidentally — they all had six digits for a while.

My first thought: Damn, you’re stupid.
My second thought: Damn, you’re so f*** stupid, you only checked your script on the live site. You didn’t test your damn code properly!
My third thought: Huh. You’re smarter now than back then.

Me and testing: Getting serious

Here’s what I did to fix the bug: I wrote tests. I didn’t touch the script, I didn’t changed a single thing. I opened my editor and I. Wrote. The. F. Tests.*

function assertEqual(actual, expected) {
  if (expected === actual) {
    console.info('[SUCCESS] Is ' + expected);
  } else {
    console.error('[ERROR] Expected ' + actual + ' to be ' + expected);
  }
}

function tests() {
  console.log('Test results');

  assertEqual(formatSum(1), '1 Euro');
  assertEqual(formatSum(12), '12 Euro');
  assertEqual(formatSum(123), '123 Euro');
  assertEqual(formatSum(1234), '1.234 Euro');
  assertEqual(formatSum(12345), '12.345 Euro');
  assertEqual(formatSum(123456), '123.456 Euro');
  assertEqual(formatSum(1234567), '1.234.567 Euro');
}

I ran the tests.


I used an old grunt setup I did a while ago to practice TDD.

The bug ticket reported a false format with a 5 digit number and the test reproduced this — 123.45 Euro instead of 12.345 Euro.

I corrected my script.

function formatSum(sum) {
  var sumNum = sum.toString().split('').reverse();
  var sumFormatted = [];

 for (var i = 0; i < sumNum.length; i++) {
    var currNum = sumNum[i];

if (i != 0 && i % 3 == 0) {
        sumFormatted.push('.');
    }

sumFormatted.push(currNum);
  }

if (sumFormatted.length > 0) {
    sumFormatted.reverse();
    sumFormatted.push(' Euro');
  }

return sumFormatted.join('');
}

Note: I didn’t touch it otherwise. I didn’t refactor it, I didn’t make it better, I didn’t make it prettier — I just fixed my error.

I ran my test again.


Now that's a view I like!

All done. I could push that change. It cost me about 10 minutes to curse me for a bit, write my tests and correct my script. That’s it! Now, there are tests for my function. I could refactor ist, write a new one — anything. While testing it.

What I learned today

I really like testing. We are, like, serious now!
There are so damn many things I have to learn about testing and I’m really looking forward to it.
I don’t have to wait for anyone or anything to write tests. Yeah, it would be best to work with a 100% code coverage and test allllll the things — but even one little test can improve my code and make me a better programer in the long run. And hey, I’m a perfectionist, I strive for improvement ;)
Testing doesn’t have to be time consuming and therefor expensive! On the contrary: If I had written proper tests in the first place, the second bug ticket would never have happened.
I write better code today than three months ago.
Committing (sometimes even writing) code without tests feels a bit like driving without seatbelt now.

Cover Image: Photo by Cerys Lowe on Unsplash