So, you've heard talk of a so-called :has() selector, but don't really know what it is. Or maybe you just clicked the article hoping to learn something new. Well, this article is for you! Now that :has() is supported by almost all major browsers (except Firefox where you need a feature flag …), it is time to learn what it is, why you should care and how you use it.

What is it and why should I care?

:has() is a so-called pseudo-class—this makes it different from normal selection in CSS. Take a look at the example in figure 1. A pseudo-class works by styling the anchor (the thing before the colon) when the state behind the colon (the pseudo-class) is true. In figure 1, this means styling the div when it is hovered.

The same is true for :has(), it styles the element before  : when the has() part is true. But when is has() true? When the relative selectors* in the parentheses are found**. This lets us style our anchor (e.g. the div in figure 1) based on other relative elements—like children.

* e.g. In div span, span is a relative selector to div
** pseudo-elements and :has() inside :has() is not supported

“I don’t need a new pseudo-class for relative selection”, you might say, “div:hover p for example lets me style my paragraph element when my parent div is hovered.” This is true, but what if you want to style your parent div when the paragraph  is hovered? div p:hover would just style your paragraph, not your div. With :has(), however, this is now possible! div:has(p:hover) will style the div element when it contains a p element being hovered! Let’s look at a few simple examples:

A parent selector

The most obvious use for :has() is as a parent selector. In the following example (see embedded CodeSandbox below) we have an .image-container div. This div contains an image and a .caption paragraph. The goal is to style our image-container background when it has a caption. 

Without using :has() we might try the following:

This has the right idea, we check when an .image-container has a .caption within it and apply a background colour. Unfortunately, the background colour is applied to the .caption, not the .image-container. Let’s try with :has():

Now the style is applied to the .image-container instead of the .caption—just as we wanted! The styling is also removed when no .caption is present!

More than a parent selector!

Another usage for :has() is to style your element based on a sibling traits. A good usage for this is to change the spacing between adjacent headings. 

With :has() we can remove this space for all adjacent headings like this:

The :is() makes it work for all elements inside the parentheses and the + targets adjecent elements. The result is that h1, h2 and h3 elements followed by a h2, h3 or h4 element have a margin-bottom of -1rem. 

Now use it!

And there you go. Now you know the :has() selector exist and you know how it works. The only thing left then is to go out and use it—good luck!

:has() is here and you probably need it in your CSS

The data engineering toolbox is growing as the industry adapts to increasing data. We need tools to process data to unlock its value efficiently. One such tool is Apache Beam. This article aims to introduce key Apache Beam concepts and provide an example of implementing a data pipeline.

🚀 Introduction

We have all heard about the fuzz arising from the world of data: AI, data is the new oil, big data, or being data-driven. To latch on to all the hype, we have to begin somewhere. That somewhere is finding ways to extract and enrich your data. Building data pipelines can feel overwhelming, and it is often tough to figure out where to begin. In a possibly futile attempt to demystify and concretize data pipelines, I will introduce Apache Beam.

Apache Beam is a framework to define batch and stream data pipelines. It aims to simplify and enable large-scale parallel data processing. By utilizing Beam, you get multiple benefits, including portability. With different Beam-runners, you can run your pipelines on various platforms using the same code. For instance, you can develop and test locally using the DirectRunner, and then use DataflowRunner to run the pipeline on the Google Cloud Platform (GCP). Another benefit of Apache Beam is that it offers different Beam SDKs, which allows you to develop pipelines using Python, JVM-based languages (such as Java, Scala, and Kotlin), or Go.

⚙️ Requirements

To run the code in this article, you need to install Python version 3.6 or higher. Then, you need to install Apache Beam and PyArrow. You can use the following commands to install these packages using pip:


If you want to test out the JDBC or SQLTransform modules that are mentioned later in the article, you need to install Java(Version 17) and Docker.

🌐 The Beam API 

Apache Beam consists of several functions to load, filter, manipulate and write data to and from different sources. The following sections briefly introduce some of the essential parts of the Apache Beam API. This article focuses on batch pipelines using the Python SDK; however, you can write almost exactly the same code for streaming pipelines. For more details, check the documentation.

As a side note, I recommend you combine and play with the different Beam-functionalities we will discuss. Also, add a print step between steps to see how the data is manipulated, as this can be a helpful way to understand how Apache Beam truly works.

Defining the pipeline

When defining a pipeline, we must start by importing Apache Beam and creating a pipeline object. Using the pipeline object, we can define different steps in the pipeline:



Pipeline input with beam.Create and apache_beam.io.*

The primary way to start a pipeline is by reading data from a source. Apache Beam ships with standard I/O connectors that you can use to read data from various sources. For example, you can read from a SQL server using JDBC like this:

If you want to initialize a pipeline without loading directly from a data source, you can load data programmatically using beam.Create:

After loading data from a source or via beam.Create, the data is loaded into a PCollection. A PCollection is when Beam has loaded your data into a parallel collection. Data in PCollections is immutable and can be distributed over different threads and/or machines. 

beam.ParDo

The ParDo function in Apache Beam takes a regular Python function and applies it to each element in a PCollection. This is known as a PTransform in the Beam world. A ParDo outputs one or more elements from a single input. The syntax for using ParDo is straightforward: you call it using the beam.ParDo method:


beam.Map

Map is a special case of ParDo in Apache Beam. Like ParDo, Map applies a function to each element in a PCollection, but it always outputs a single element for each input element rather than a one-to-many mapping. The syntax for using Map is the same as ParDo. You simply need to swap out the ParDo method with Map:




Map vs ParDo

To further demonstrate the difference between Map and ParDo, imagine some function in a pipeline step that takes in a word and returns the char array of the word. Let's compare:

PCollection("hello", "world") -(ParDo)-> PCollection("h", "e", "l", "l", "o", "w", "o", "r", "l", "d")

PCollection("hello", "world") -(Map)-> PCollection(["h", "e", "l", "l", "o"], ["w", "o", "r", "l", "d"])


As we see, ParDo yields ten elements that will be passed to the next step of the pipeline, and Map yields two. Sometimes we need to maintain the relationship between the elements, and sometimes we don't. This is important to keep in mind when developing a pipeline. For instance, if the pipeline's goal is to count each letter's occurrences, then a ParDo will be a much better choice. This is because ten elements will be distributed across threads and machines, compared to two.

beam.Filter

If we need to filter out some rows in the dataset, we can use the filter function in the following way:



SQL and beam.coders

By utilizing Python type-hints, we can define transformation steps using SQL. To do this, we need to register the type that the SQL query is based on using beam.coders. Next, by annotating a function in a Map or a ParDo step with the registered type, we can follow up with a SQL transformation:

beam.GroupBy

If we need to do operations on the PCollection that requires data to be grouped, we can utilize the beam.GroupBy function. GroupBy takes in the column name to be grouped. Note that this requires the type to be registered similarly to the SqlTransform. GroupBy will return a tuple containing the key and all items belonging to that group in a list. The syntax is straightforward:



Writing to a sink

Beam offers several ways to write data to various sinks. One popular option is the Parquet file format, which is well-suited for storing large amounts of data efficiently, thanks to its columnar storage. By supplying the storage path and the parquet schema, we can define the write-to-sink step:

Using WriteToParquet, Beam automatically handles how to partition and write the data efficiently to the sink. Super convenient!

🧑‍🔬 Tying it all together

Now, we're going to make an end-to-end pipeline by using the components we have learned about:

To run the code above, navigate to some folder and save it in a file called first_name_count.py. Run the pipeline by opening a terminal in the same folder and then run python first_name_count.py. We see that the pipeline outputs a dataset with two columns: first_name and first_name_count.

Data lineage

Imagine that another person or team wants to use our dataset to find the least common names. When looking at the data that our pipeline produced, they would see a list of names and their respective counts. But as we know, our pipeline filters out all first names that occur once, which renders the data unusable for that use case. This demonstrates a common problem about using datasets that are not ours: how can we trust the data?

This is something data lineage aims to solve. Data lineage describes the processing steps of the data from source to sink. With Apache Beam, we can extract the automatically generated execution graph:

Where the last line will output a dot graph that can be visualized using a GraphViz-visualizer. 

The graph should be stored near the data, for instance, in a data catalog. This way, we can establish trust between the ones that produce and consume data. In the example above, by looking at the data lineage graph, the data consumers would instantly find this dataset unsuitable for their use case.



🪄 Final remarks

Apache Beam is a powerful tool for starting to process your data. It has an active community with new features constantly being under development. Beam helps you speed up the process of making your data available for analysis in a way that promotes trust between the producers and the consumers of the data.

Hopefully, you feel like it is a little bit easier to start building pipelines. Thank you for reading my simple introduction to Apache Beam! 🌞



Sources

Apache Beam documentation

https://beam.apache.org/documentation/

IBM, data catalog

https://www.ibm.com/topics/data-catalog/



Demystifying data pipelines with Apache Beam

Ragnhild thinks we should put detailed prototypes to rest, and rather get our designs out to the public faster.



Hi there! Did I catch you in the act of making an ultra-complex, clickable prototype in Figma? If that’s the case, it’s time to stop right now and think anew!

The intention is good

While studying design at university, we learned that a traditional design process usually starts with some preliminary research which – after some analysis – leads to a concept phase where we can think of solutions. Often, this concept phase culminates in the creation of a prototype and accompanying user test. The goal is to check whether our ideas are understandable and usable for our future users.

At first glance it’s easy to applaud this approach because we are working to limit risk by testing our ideas before we spend resources developing them. I’ll admit that the intention is good – but one doesn’t get very far with good intentions when they end up wasting our time and giving us unreliable insight.


A time thief

Because yes, we open Figma, switch over to prototyping mode, and start the hairsplitting process of creating micro animations and hover effects. After a long while, we unravel the ultra-complex flow charts necessary to make sure all buttons are clickable wherever and whenever. And when the job is done, we’re left with a false product which in all likelihood – despite all the hours spent – doesn’t work exactly as it should. The weeks have flown by.

This is where all the alarms go off… We’ve got to stop spending several weeks sitting alone and nitpicking on something that soon will gather dust in a digital drawer.

Our mission as designers is to create value – for the end user, the organization we work for, and society. Creating a false version of a service in Figma with just a small new feature isn’t value creation. If your team is organized well and you have an agile approach, you’re hopefully only testing out a small part of a bigger totality. If so, it’s a waste of time making a half-good pretend variant of the service in Figma just to test a small piece. Get it out in the real world at once! Learn from real interaction. Collect insight from real behavior to understand how the service is actually used.


Insight we can’t trust

Talking about insight. User tests, which is usually the end goal of prototyping, gives us a potentially false understanding of the usability of said prototypes. Here’s what we’re doing: We’re testing a fictional service – which doesn’t work as it should – in a fictional environment. Furthermore, we’re asking questions which are unavoidably biased by the pride and ownership we’ve grown for the masterpiece we’ve spent so many hours creating. And this affects us, whether we like it or not.

So let’s just bury the complex Figma prototype today and instead do our testing out in the actual service. Test where people interact in their natural environment without the disturbance from weaknesses in the prototype, bias, or the pressure of feeling observed. Today, we’ve got amazing opportunities to collect and analyze behavioral data from every interaction people have with the stuff we make.



Is it necessary?

Before I round off, I'd like you to reflect on the following: Is your design really so complex, groundbreaking, different, and revolutionary that you have to test it before people out there get to try it out? With all likelihood, the answer is “no”. Plenty of smart people have walked this path before you. And I’m pretty sure your design intuition is good enough to test ideas live. The “worst” that could happen is that you’ll need to iterate if the design didn’t work 100 % the first time around. And that’s a valuable lesson too!

So please: Don’t waste valuable time sitting alone and creating beautiful, complex prototypes in Figma. Work with your team, be agile, and test things live. Let’s kill the prototype.

🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥

What did you feel while reading? Did it spark something in you? Do you agree or disagree? Join the discussion on UX Norge's slack (Norwegian) or share this article with your colleagues and start a debate! Remember that the goal of Brannfakler is to start discussion!

Let's kill the prototype

En god sikkerhetskultur er verdt en bunke med policies og litt til.

Kultur som fremmer sikkerhet i alle ledd fra konseptutviklingen av produkter helt til ledelse av ansatte er å anse som god sikkerhetskultur. En kultur der spørsmål og nysgjerrighet står sentralt, og hvor det er helt greit og lov å gjøre feil. Gjennom denne artikkelen skal vi prøve å forklare hvorfor man bør strebe etter, og hvordan man kan bygge god sikkerhetskultur i en organisasjon.

Men, hvorfor trenger man sikkerhetskultur, når man heller kan fokusere på å bygge sikre systemer?

Først og fremst er det viktig å innse at mennesker er feilbare. Vi ønsker selvfølgelig ikke feil, men det er utopisk å tro at vi kan eliminere menneskelige feil. Derfor må mennesker være en del av en trusselmodell.

For å enkelt og effektivt beskrive hva god sikkerhetskultur er, og hvordan man kan jobbe for det, prøver vi i denne posten å ta dere gjennom et par scenarioer for de fleste utviklingsteam. Det er vanskelig å uttrykke kultur gjennom ren tekst og vi tror at scenarioene kan hjelpe å forstå bedre.

Scenario 1: Features først, sikkerhet til slutt

Du er tech lead på et prosjekt hvor det ikke er tid eller ressurser til å prioritere sikkerhet. Features er det eneste som betyr noe, og ledelsen tror at sikkerhet er noe man kan gjøre til slutt.

Hvordan får man sikkerhet inn som en del av utviklingsprosessen, og inn på dagsorden?

Først og fremst vil vi oppfordre deg til å løfte problemstillingen med teamet ditt. Opplever alle situasjonen lik som deg? Er løsningen egentlig tilstrekkelig sikret? Det kan være greit å snakke med flere før man går hardere til verks. Får man ikke løst det internt i teamet, anbefaler vi å starte en prosess hvor man har fokus på bevisstgjøring av hvordan sikkerhet bør implementeres som en del av den daglige prosessen.

Kontinuerlige leveranser — en feature er ikke ferdig før sikkerheten også er på plass. Altså inngår det i pakken av “en feature” i det å jobbe kontinuerlig. For eksempel kan man ikke prodsette et nytt API kontinuerlig uten at hvert endepunkt er tilstrekkelig sikret.

Allier deg — prat med de rundt deg, sammen er dere sterkere!

Å utsette er dyr “sikkerhetsgjeld” — kostnaden ved å legge fra seg en feature og ta den opp igjen er høy i seg selv. Det er også sannsynlig å anta at løsningen man implementerer i ettertid ikke vil være like god som når man utvikler selve featuren siden man ikke husker context og omfang like godt.

Opprett rutiner — for å teste systemene jevnlig, både av egne utviklere for eksempel med hack-yourself-first prinsippet eller ved ekstern pentesting. Ved en hendelse vil det også være nødvendig å koordinere med flere personer, og beste måten for å forberede seg på det er ved å ha gode beredskapsplaner og rutiner.

Security Champion —å ha en sikkerhetsutvikler eller Security Champion på teamet gir teamet en god forutsetning for å jobbe tverrfaglig og smidig med sikkerhet.

Scenario 2: Soveputer og falsk trygghet

Sikkerhet er høyt prioritert i organisasjonen. Det er en egen sikkerhetsavdeling som setter meget strenge retningslinjer. Spesielt for for eksempel klientmaskiner. Faktisk så streng at den føles som et hinder for utviklerne. Samtidig vet du at applikasjoner sender data ukryptert, man har fellesbrukere og man er ganske langt fra en zero-trust modell. Likevel har organisasjonen troen på at sikkerheten er ivaretatt.

Hvordan overkommer man slike soveputer, og falske tryggheter?

I første omgang bør hvert utviklingsteam iverksette en kartlegging av sikkerheten. Rent teknisk kan det være “sikkerhetsgjeld” som beskrevet over, og noen ganger kan det være utfordringer som er unikt for domene. Områdene med svakheter bør underbygges av resultater og objektiv informasjon. På applikasjonsnivå er det fint å gjennomføre penetrasjonstester som vanligvis vil avdekke en del av de vanligste feilene, og man sitter gjerne igjen med en fin oversikt over test og resultat.

“Hvor ønsker teamet å være om 3, 6, 12 måneder?” er en fin øvelse for å prioritere hvilket sikkerhetsarbeid som må gjøres for å nå målene man setter seg. For å komme dit må man også snakke om hvilke utfordringer dere har. Det at data går ukryptert i nettverket eller at passordet til databasen ikke har vært rotert på flere år burde ikke være en hemmelighet innad i teamet.

Etter denne kartleggingen kan det vært fint å ta med resultatene høyere opp i organisasjonen for å sikre at risikobildet matcher teamenes. Dere vil sannsynligvis raskt merke at ledelsen og teamene har ulik virkelighetsforståelse av sikkerheten. Det er helt ok — poenget er at nå begynner dere å prate sammen, og samarbeide!

Videre i det daglige anbefaler vi å fokusere på de lavthengende fruktene — kultur tar generelt lang tid å bygge.

Dra i gang lavterskel sikkerhetsforum, hold foredrag, inviter eksterne — men husk å ha fokus på objektiv kunnskapsdeling slik at ledelsen i mindre grad kan argumentere mot det som legges frem.

Scenario 3: Sikkerhet uten kompetanse

Ingen på teamet har noe særlig kompetanse på sikkerhet, og ledelsen har uttrykt ønske om å løfte sikkerheten i organisasjonen.

Hvordan motiverer man og skaper en kultur i teamet for å øke bevisstgjøring av sikkerhet?

Dette er en gylden anledning til å utfordre seg selv. Det er mange som unngår sikkerhetsoppgaver — det er ofte komplisert og feil kan få store konsekvenser. Ansvaret for å lage tilstrekkelig sikrede løsninger ligger i teamet og det er derfor fint at ledelsen ønsker å løfte sikkerheten. Så fremover bør dere som team sette av tid til kompetanseheving. Dette kan man gjøre gjennom felles workshops, forberede foredrag, eller ved å hente inn sikkerhetskompetanse for å komme i gang.

Et alternativ er å anbefale ledelsen å opprette et kompetanseteam. Det kan være et eget team som jobber aktivt med sikkerhet i organisasjonen, eller et team basert på security champions i ulike teams. Autonome team vil sjeldent ha all kompetanse som trengs for å løse alle oppgaver, så å bringe inn ekspertise ved behov blir en kunst å få til.

Allikevel er det gjennom praktisk erfaring man lærer mest, og best! Derfor er vår sterkeste oppfordring å høre med andre i selskapet hvilke sikkerhetstiltak dere kan iverksette og bruke mye tid på dette fremover. Det kan også være fin trening å la flere i teamet løse samme oppgave for å diskutere beste løsning, samt å lære av hverandre!

God kultur bygges ikke ovenifra og ned. Bygg sikkerhetskultur nedenfra opp, og se verdien i å utøve sikkerhet som en del av utviklingsløpet.

Sikkerhetskultur spiser policy til frokost!

From Neopets to hypothesis-driven development, the challenges of working with data to the power of humor – Sonja talks about her work as a UX designer with SpareBank 1.

Who am I?

If you were a middle-school girl in the midwest United States during the marvelous 2000s there was only one thing that really mattered: Neopets. With each of these digital pets you got a ✨webpage✨ that you could customize with HTML, CSS and the illustrations you mashed together in Gimp (or a bootleg version of Photoshop if you were lucky). Hour after hour of customizing these pixel-perfect masterpieces finally convinced my mother that I would not, in fact, go into actuarial science – but instead pursue my true calling: DESIGN.

A decade or so plus five years of university later, I dropped the CSS and instead focused on understanding users, defining functionality and continuously developing digital products and services as a UX Designer.

What do I do?

This past year and a half I have been working with SpareBank 1, most recently on a team that aims to create a better digital onboarding experience for new banking customers.

The fun
I almost don’t dare to say it, but this is one of the best teams I’ve been on... and I’ve done some thinking recently as to why. First and foremost: we have a very clear mission and mandate. Our team was created specifically to address one of the main points of the organization's strategy – meaning we don’t have to fight for time to focus on that goal. Our core outcomes are already a priority in the organization making it very thankful work. In addition we have two product-minded UX designers plus a dedicated Product Owner on the team, giving us enough capacity and community to have the important conversations about what our goals are, what that means for our team’s backlog, and the real, time consuming work that is weaving that goal and identity into our team’s culture.

Another thing that makes this team a joy to work on is the whole team's enthusiasm for hypothesis/learning driven product development. There is a real drive to measure and document our progress, which is very motivating.

The challenge
Not to say that we don’t have our challenges. SpareBank 1 is a large organization with many passionate and talented people which, while mostly positive, also demands that many hours of the day go towards synchronizing our efforts and getting people on board. In addition, though many product teams at SpareBank 1 love to measure their progress, many of the key results we need to see weekly are not continuously available to us. Yet 😉. Also, working with data and quantitative measurements is hard. While we are having fun and doing our best setting up measurements and analyzing the results, we could definitely use a person closer to the team who could run larger analyses and spot a statistical significance when they saw it…

What tip would you give yourself when you started at this client?

Sometimes, humor can be the key to addressing conflict and actually push to change behavior without escalating the situation. See the miming traffic cops of Bogota.

8-Dec

Today's posts

:has() is here and you probably need it in your CSS

Demystifying data pipelines with Apache Beam

Let's kill the prototype

Sikkerhetskultur spiser policy til frokost!

Design tip of the day