Many developers hesitate to use CSS Grid in their project. A typical argument is that Grid is not supported in all browsers. But that's not true!

If you're not familiar with CSS Grid, check out this short article"Oops! I Grid it again".

Grid is fully supported by all browsers except Internet Explorer. Well, at least partially. 🤷🏻 Partially because what IE10 and IE11 does support is the older specification of CSS Grid syntax.

Thus , some Grid syntax will work fine while newer Grid properties will fail. There are some tools to help you with this!

Autoprefixer can fix! 👩🏻‍🔧

Autoprefixer is a PostCSS plugin to parse CSS and what it does is that it adds necessary CSS and prefixes to your CSS rules so that it will work even in IE. So what are you waiting for? Add it to your project with:

Or if you have used create-react-app to create your app, then all you have to do is enable it. By default, Autoprefixer is disabled for Grid. To switch it on, add this comment /* autoprefixer grid: autoplace */ at the top of your CSS file.

To see it in action, test your code with their online tool.

Awesome, right? 💁🏻✨ \ Check out their docs for details.

Limitations

Autoprefixer do have its limitations, thus there are properties even Autoprefixer can not fix. So here's a short list of things you should be aware of:

IE does not support autoplacement. Thus, grid autoplacement properties like grid-auto-rows or grid-auto-columns does not really work even with Autoprefixer. Read more about Grid Autoplacement support in IE here.

Defining your grid with grid tracks and grid-template-areas? Make sure each grid element have unique area names.

In the new version of Autoprefixer, grid-gapkinda is supported. However, make sure to defined both grid-template-areas and grid-template-columns. Daniel Tonon has a pretty good article about IE and the new Autoprefixer.

Avoid shorthands! Shorthands such as grid or grid-column/ grid-row. grid-column and grid-row are both shorthands for placing grid items using grid lines, which means that you will have to go from two code lines back to four.

grid-template-areas and grid tracks is your friend! It's quite the hassle to write four codelines for each grid item when you use grid lines and have to support IE. So try to use grid-template-areas and grid-area as much as you can.

Still gotta use grid lines? Always make sure to define both columns and rows for your grid items. Thus, you gotta write four codelines for your grid item. 🙄

Always check your grid fix in IE! ****You have probably used grid a lot of places in your code even though it can be a hassle, make sure you check if your site behaves like you would expect it do. If you're like me and do not have IE on your laptop, you can either download a Virtual Machine (VM) to use Windows on your laptop such as Parallels or test your website through a web solution such as SauceLabs or Browserstack. Because you know, safiety first 😆!

@supports

If you would still love to have some autoplacement properties, such as grid-auto-rows or auto-fill, then another option could be using the feature query, @supports. You can then use some CSS features, such as grid, depending on whether the browser supports it or not. So you basically put the grid code you would like to use IF the browser supports grid inside of the @support (display: grid) {...} and keep the fallback code outside of it. So in the example below, the flexbox code will be used as a default and if the browser do support grid? Well, then the grid code is used instead ✨

This is because @supports is not supported in IE, thus it would not helpfull to use the other way around. 🤷🏻

Have you tried not supporting IE?

Even Microsoft writes Internet Explorer off as a browser and describes it more as a “compatibility solution” for enterprise customers to deal with legacy sites that should be updated for modern browsers, and also have plans to stop supporting IE11 themselves. Read more about it here.

A solution could be to show the users an informative banner that is shown if IE is used. Bowser can be used to detect your users browser and version. Then show them a nice banner to enlighten them how much at risk they are from using an outdated browser, and that the application will not work properly in IE. If you want to be extra kind, then consider adding download links to other browsers. ✨

Internet Explorer is not all bad though 🤷🏻

You will rarely meet a web developer that has not had a fateful encounter with Internet Explorer. Most feel strong emotions when it comes to making a site that actually supports IE, thus it can always be a fun subject to rant over when you meet someone new in the same field 😄.

Hope you enjoyed the article!

See you later, alligator! 🐊

Don't suffer like I Grid - SafIEty first

After an eventful, or not, weekend, nothing beats listening to some fine entertainment while taking a walk, going skiing in the woods or while cranking out some code on your hobby research project. Today we are happy to share some of our favorite podcasts this year.

Security Now!

When we started gathering pod cast for this post, Security Now! was one of the first that was listed. Since its start way back in '05 it has been a weekly listen for many in and outside the security business. Computer legend Steve Gibson and podcast pioneer Leo Laporte summarizes, in understandable terms, the latest security news. In addition, there is usually a deep dive into a current topic. As a bonus the hosts share their opinions on sci-fi literature, tv-show and movies. Note that Gibson also provide transcriptions of the shows, making is a valuable research tool. https://twit.tv/shows/security-now

Darknet Diaries

True stories from the dark side of the Internet

Host security veteran Jack Rhysider presents mesmerizing stories about incredible people doing stuff you never thought was possible outside the movies or tv-shows. Each episode typically tells the story of a security incident, usually with interviews with the (for good reason) anonymized people involved. The well-presented stories are filled with interesting facts and background information. Episode 6: The Beirut bank job is an incredible story about a penetration test gone bad, in a totally unexpected way. Jack Rhysider also maintains a webpage on https://www.tunnelsup.com which is well worth keeping up with. https://darknetdiaries.com

Malicious Life

The Malicious Life podcast is a great supplement to the earlier mentioned Darknet Diaries. Malicious life provide insight into the life of hackers and security professionals. We get to hear first-hand reports and background from fascinating people. The podcast is underwritten by Cyberreason. https://malicious.life

Hackable

Listening to an episode of Hackable is like hearing a good friend tell a great story. You may know the facts and have a basic understanding of it, but the way it is being told makes it worth the time. Each episode of Hackable the host Geoff Siskind and security expert Bruce Snell cover a popular topic which should resonate for anyone even outside the security industry. The formula is as simple as it is entertaining, host Geoff is the (volunteer) victim of a hack, ranging from hostile telefax take over to circumventing car key-fob security. The podcast is presented by McAffe. https://hackablepodcast.com

The Secure Developer

In The Secure Developer podcast you can hear experiences from developers and other people in the industry. There are great tips and interviews with people that have hands on experience and know what they are talking about. This is mostly relevant for developers, but anyone working with development can get great insight to valuable topics. The podcast is predented by Heavybit. https://www.heavybit.com/library/podcasts/the-secure-developer/

SANS Internet Storm Center

The daily podcast from SANS gives you a heads up on the new attacks and incidents that may be relevant to you or your team. The episodes usually don't go too deep into each topic, but is a great 5-minute listen on the commute to the office. The podcast is a must for anyone in the operations part of security. https://isc.sans.edu

BEKK Open

When mentioning podcast, we must not forget our own podcast, BEKK Open. The podcast is not a security podcast, but still enjoy the topics presented. Watch out for the next episodes. The podcast if, of course, presented by Bekk. https://soundcloud.com/bekkopen

Stuff we listen to

How can we use methods from machine learning, along with traditional principles from service design, to get a better understanding of our customers and their needs?

As customers and users, we are expecting an ever-increasing level of personalization from the products and services that we use. Providing a personalized offering is a recognition that all customers have different needs but catering to these individually is often too costly and time-consuming to be applicable in practice. We are usually forced to segment our customers into smaller or lager groups with similar needs.

The simplest way to segment customers is to use demographic characteristics as a predictor of the needs for those individual groups. Age and gender are typical examples of such characteristics that are frequently used. Similarly, the number of employees and the sector of operation are often used to segment business customers. This common approach is fine but presents a few problems. Firstly, the demographical characteristics are easy to observe but they are not necessarily perfect predictors of customer needs. And secondly, we are only able to include two, three or perhaps four different characteristics with this approach so we have no guarantee of including the ones that creates distinct and relevant customer segments.

Service design theories recognizes these shortcomings and offers an improved alternative. The common approach to creating customer segments is to identify customer needs through thorough interviewing or observations, studying a wide variety of variables, and creating distinct segments based on these needs. However, interviewing or observing a large number of customers is time consuming and presents a challenge when it comes to finding a representative selection of a perhaps large customer base. How many customers can you interview in depth and fully understand? Ten customers? A hundred customers? Imagine if you could interview them all…

Perhaps data science can provide us with the answer we are looking for? We suggest combining the ideas from service design with quantitative data and machine learning by creating new customer segments through a cluster analysis. This means feeding tons of data to a clustering algorithm and allowing the algorithm to find patterns in the data and combining observations of similar characteristics. Clustering algorithms allows us to examine a large number of customers and variables for each customer, thus avoiding the problem of deciding what data to include in advance. The whole process includes five steps where the first three consists of preparing the data, before we do the actual clustering and finally describe the customers segments.

The key to succeeding with this approach lies, of course, in the data. In order to predict customer needs, we need to look at behavioral and preference data rather than simple demographical data. These sorts of data are available to us today as more and more of our actions leave digital traces, but it often requires qusite a bit of processing and combining data from several different sources. Describing and understanding the segments is also crucial and can require extensive knowledge of the specific field in question.

Succeeding in using a cluster analysis in customer segmentation provides us with a few key benefits:

Firstly, the approach is objective. We are able to find hard facts about our customer base, their behavior and their preference, meaning there is no need to speculate and make assumptions based on subjective experience. And the best part is that we get to quantify the size of different customer segments we have, thus allowing us to make more informed decisions on for example what segments to target.

Secondly, the method is robust with respect to choosing the right variables to cluster customer with, because we are able in theory to use all of them! Traditionally we would only be able to use a few variables (sex, age and geography), which has a huge risk of missing out on important aspects.

And finally, as always with machine learning: If you start with data, you might discover the answer to the questions you did not even think to ask!

Merry Christmas!

Customer segmentation

During an application's lifespan you've probably added quite a few dependencies. But are all of them necessary? And are you using some libraries you're not even aware of? Today I'd like to talk a little bit about a maven plugin I'm a big fan of: maven-dependency-plugin.

This plugin has a fair amount of goals. I'll highlight a couple of my favorites, but first, let's get the boring part out of the way:

To start using this plugin, simply add the following to your <pluginManagement> section:

Version 3.1.1 is the most recent at the time of writing, check The Central Repository to see if there has been a new version released.

Now, let's look at the more interesting bits!

analyze

This goal analyzes the project’s dependencies and figures out if any of the declared dependencies are unused and vice versa – which dependencies you’re using which are not declared (i.e. transitive dependencies that you actually depend upon).

Let's say I run mvn dependency:analyze and get the following output:

See those four lines starting with [WARNING]? This indicates I've got some issues in my project.

I've got a dependency on com.foo:baz, but I'm never using it. I should be able to safely remove it.

com.foo:bar is not a dependency declared in my POM, but I'm still using it. This must mean one of my dependencies are depending on com.foo:bar. Since I'm actually using it in my project, I should declare it in my POM for two reasons: 1. If I upgrade the dependency that contains com.foo:bar and they have removed said dependency, I’ll get a build failure. 1. The POM should serve as documentation for my project, describing which third party libraries I'm using.

But wait a minute – what if I don’t even know how com.foo:bar snuck into my code?

Allow me to introduce you to:

tree

This goal displays the entire dependency tree of the project.

For small to medium sized projects this gives a great overview of all dependencies, even transitive ones I don't use. For large projects, this list will probably be very long and hardly usable for any purpose.

So, in this example it's fairly easy to see how com.foo:bar is a transitive dependency because of com.foo:qux. For large projects, simply use the includes parameter to filter the dependency tree:

💡 You can even use wildcards, such as *:bar for the includes parameter.

Include it in your build lifecycle

Remembering to run dependency:analyze every now and again is probably unrealistic – I know I'd forget to do it. I'd highly recommend including it in your build, so it's always executed.

Add the following to your <build> section:

The plugin will execute upon running e. g. mvn verify and report any violations.

There are two things worth noting in the code above:

The goal I'm using is analyze-only. This pretty much does the same as analyze, except it assumes the test-compile phase is already executed. analyze-only is intended for use in the build lifecycle, analyze is intended to run standalone.

The failOnWarning property is set to true. This means your build will fail if you have any violations. It's probably going to be an issue turning this property on for a big project where you might have a lot of violations, but I'd suggest enabling it once you've regained control over your dependencies to prevent unknown transitive dependencies to sneak into your project once again.

Now that you've hopefully removed a lot of unnecessary dependencies and declared all the ones you actually use, have another look at the list of goals to see if there are any other sweet features you can make use of!

Manage your dependencies

Today's interview is with @christianalfoni. Christian is a developer and creator of overmindjs.org and cerebraljs.com, and works at @codesandbox.

The questions below came from a simple question we asked ourselves:

if you had the chance, what would you ask an Open source maintainer/person/community member.

Here we go!

What are your biggest challenges in working with Open source today and how do you handle them?

As an open source maintainer, the biggest challenge is managing time and emotions. Since the open source work is typically done beyond working hours that actually gives income, you have to balance that time with everything else going on in your life. Things like family, friends and other things that is way healthier for you than crunching code.

Emotions plays a big role on this as well. Maintaining open source work becomes very personal. You put more pressure on yourself and take feedback more personally. How you feel about your open source work bleeds into your time outside open source work. Again, family, friends etc.

Handling this has taken me a long time, and still there are times I do not handle it very well. In my experience it is important to set a small scope and have some clear core principles for your project. The scope determines the amount of time needed to write code, but also it reduces the discussions around API surface... as there is less of it.

With core principles you can minimize the discussions around the API choices as well. This is very useful in issues and other channels where questions about decisions and new suggestions pop up. "This is not within the scope", or "A prioritized principle was to have lower level APIs and allow people to build on it". Stuff like that. Also getting to the point of "there is really no rush" is very important. Developers are smart. They hack around solutions, forks the project etc. if some bug blocks them or similar. You do not have to fix things right away.

Are there any useful tools you use to make your GitHub-life easier to manage, and if so, could you share a few of them with us?

Hm, good question. Personally I just use Git in the terminal, though the Github desktop app is really good now. If you contribute to open source I would suggest looking into "rebasing" and "interactive rebasing". These are necessary tools to keep your PRs clean and up to date with master. Different projects has different preferences on how to merge your PR, but keeping your commits clean requires wielding some rebasing.

As a maintainer you can get help on structuring the commits. A project called Commitizen runs a script that asks you questions on the type of change etc. This can be used to create release notes and bump the project with the correct version number (breaking etc.). You also have Husky which can add git hooks. It can for example run linting, prettier, typechecking etc. to make sure that the commit is valid, before even creating the commit.

I also find it beneficial to test PRs effectively and help contributors on their own branch. This is a script we use at Codesandbox to quickly test a PR. It allows us to write "yarn test:pr 1234" and it sets up a branch updated with current master, ready for testing. On this branch you can create new commits. This allows you to set up a pull request to the contributors original PR. Now the contributor becomes a maintainer and stays in control of the PR. It gives a feeling of collaboration instead of you overriding the contributor.

How can repository-owners facilitate contributions from newcomers in Open source?

You know, I think there is far too much focus on code contributions in open source projects. There are so many other things that open source needs in terms of contributions. Here are some examples:



Say "thank you": When you use a project that solves a problem for you, go on twitter and say thank you to the maintainer. Recognition and the feeling of producing value for others is "the fuel" of open source. You do not have to donate money... just say thank you



Give support: If a project you know well has a community, join that community. It being slack, discord or just Github issues. Help answer questions and help create a culture of understanding, patience with beginners and handling "bad players"... cause there are some of them, who just does not understand what open source is all about



Documentation: Documentation is the biggest challenge for a maintainer. And I am not talking about typos here. A maintainer should ideally not write any documentation because they typically have too many assumptions. So adding paragraphs to improve the flow, create better examples or maybe maintain some Codesandboxes that helps beginners get going is incredibly valuable



Write an article: Most projects are never recognized because the maintainer does not have time or a wish to "put themselves out there". An article is very often the one and only reason a project even gets noticed. If you find a project that you think is amazing, write an article about how you used it and what it solved for you

So basically I would highlight these points in the documentation of the project. It is way more helpful than actual code PRs, as those typically has very little code... code you could easily write yourself with a good reproducible example of an issue. All these other points is way harder for a maintainer to manage. I am not saying code PRs and bug fixes are worthless..On the contrary, they are very welcome, but the points here are way more pressing :-)

If you could time-travel to when you first started, what advice would you give yourself as an Open source rookie?

To becoming a maintainer I would say: "Stop! Do not go down this path". It is way more valuable to help other projects than wielding your own. I just can not help myself because I am constantly popping with ideas and I always think they are really good, even if they are not. It is a curse :-D Then I would argue that I would be way better off focusing on the points in the previous question. Keep writing articles, make videos, educate and help people use existing libraries. What libraries to choose. Compare them. Etc. Way more valuable.

Can you describe how you see the future of Open source, what new directions or paths do you think it will take?

You know, I am super hopeful. I think "the open source way" is how most of us will work. Many fields are moving into async global collaboration. With national borders diminishing and remote work becoming more and more common, the "open source way" is a set of principles and processes that fits very well with that world... it appeared in that world.

Also more companies are realizing that open source is actually why they are in business at all. If the company uses open source, especially for profit, it also has a responsibility to move open source forward. Making "open source" a part of the company strategy and branding is basically a way to say: "Our profit is based on open source. We use some of that profit to give back. It is the right thing to do". We will see a lot more of that I think.

Thanks for taking the time to talk with us Christian! 💪

Interview with Christian Alfoni

Av og til trenger man en skikkelig kickstart på en workshop. Hensikten kan være å fremme kreativ tenkning, eller bli bedre kjent og løse opp i stemningen. Det er ikke alltid lett å gå fra 0 til 10 på kort tid. Derfor kan oppvarmingsøvelser være en ypperlig måte å sparke i gang en workshop, eller unngå den velkjente «etter lunsj-dippen».

Det finnes en rekke ulike oppvarmingsøvelser der ute som kan benyttes i workshops, avhengig av hva som er hensikten. Men det er ikke alltid like lett å velge. Jeg vil gjerne dele noen av øvelsene vi har testet ut i faggruppen “Kreativ problemløsning”, og som jeg har prøvd ut på prosjekter. Kanskje det kan hjelpe deg å velge den øvelsen som passer best til din neste workshop?

1. Tegne i blinde

Type: Ice breaker, bli kjent, team building

Tidsbruk: ca. 5-10 min

Du trenger: Ark til alle deltakerne, noe å tegne med

Antall deltagere: Bør gå opp i par, men ellers ingen begrensning på antall.

Hva

Denne øvelsen går ut på at man går to og to sammen, og lager portretter av hverandre. Utfordringen er at du ikke skal se på arket når du tegner, og bruke feil hånd (ikke den du vanligvis tegner med). Om man skulle ha lyst til å legge til enda en tvist, kan personen som tegner samtidig intervjue den andre for å bli bedre kjent, f.eks. "Hvor studerte du?", "Hvor vokste du opp?" osv.

Hvorfor

Hensikten med denne øvelsen er å lage god stemning. Den skaper rom for å dumme seg ut, og poengterer at man ikke alltid trenger å prestere. Målet er å ha det gøy, ikke å lage det beste portrettet. Da jeg prøvde den ut i et prosjekt med teamet mitt, satt latteren løst og vi fikk en god start på team building-workshop'en vår. Øvelsen kan også fungere bra som team building ved at man setter navn på portrettene, og henger de opp i team-området som en artig presentasjon av alle i etterkant.

2. Historiestafett

Type: Energi, ice breaker

Tidsbruk: ca. 10 min

Du trenger: X antall store plakater/ark som kan skrives på, tusjer, musikk

Antall deltagere: Gjerne 2 eller flere lag, men fungerer også med bare en gruppe.

Hva

Øvelsen går ut på at gruppen/stafettlaget skriver en historie sammen ord for ord, ved at deltaker skriver et ord hver. Dette resulterer ofte i nokså morsomme og særegne historier.

Hvorfor

Målet med denne øvelsen er å få opp energinivået, og leke seg litt. Av og til er det akkurat det man trenger før man setter i gang med selve workshop'en. Dette har blitt en av mine favoritter, da den er enkel å forberede, og alltid leverer. Øvelsen kan bidra til å løse opp stemningen i grupper som ikke kjenner hverandre så godt, eller fungere som en underholdende "energizer" med teamet ditt eller en annen gruppe. Det har ikke vært fokus på å kåre en vinner de gangene jeg har vært med på den, men hvis man ønsker trigge konkurranseinstinktet i gruppen, kan man fint inkludere det også.

Hvordan

Hvert av "stafettlagene" stiller seg på rekke med en plakat/noe å skrive på foran seg. Førstemann har en penn i hånden, klar til å starte historien.

Fasilitator setter på en sang, gjerne en med litt tempo, og historiestafetten er i gang!

Førstemann løper opp til plakaten for å skrive det første ordet. Deretter løper hen tilbake og gir stafettpinnen(pennen) videre til nestemann på laget som skriver ord nummer to i historien. Og slik fortsetter det til sangen er ferdig.

Til slutt deler lagene de unike historiene med de andre i workshopen.

3. Tegne et dyr - fort!

Type: Tegning, kreativitet

Tidsbruk: ca. 5 - 10 min

Du trenger: Tusjer, ark å tegne på

Antall deltagere: Ingen begrensning

Hva

Dette er en tegneøvelse som utfordrer deltagerne til å tegne et dyr på 10 sekunder. Hvis du ikke ønsker å tegne dyr, kan du bytte ut dyr med et annet tema. Her er det bare fantasien som setter grenser.

Hvorfor

Målet med denne øvelsen er å presse seg selv til å tegne noe som gir mening raskt. Det resulterer i mange morsomme tegninger.

Hvordan

En person på gruppen bestemmer hvilket dyr gruppen skal tegne først. F.eks. en sau.

Samme person setter klokken på 10 sekunder. Nå kan alle tegne.

Etter 10 sekunder er gått skal alle vise sin tegning av en sau.

Personen som valgte første dyret skal nå kåre en vinner. Det vil si, hvem hen synes tegnet den beste sauen. Denne personen får velge neste dyr som skal tegnes.

Slik fortsetter det så lenge gruppen ønsker å holde på.

4. Sirkler

Type: Tegning, kreativitet

Tidsbruk: ca.10 min

Du trenger: Tusjer, ark med mange sirkler (20 stk)

Antall deltagere: Bør gå opp i par, men ingen begrensing på antall.

Hva

Dette er en enkel tegneøvelse for å fremme kreativ tenkning (kilde: Digital Norway)

Hvorfor

Målet med denne øvelsen er å presse seg selv til å være kreativ ved å finne flest mulig måter å omskape en sirkel til noe forståelig. Det er en superenkel og veldig artig øvelse. Den kan for eksempel brukes før en skal i gang med brainstorming eller før en sprint- workshop hvor deltakerne skal tegne en del.

Hvordan

Alle får et ark med mange sirkler på foran seg og klokken settes på 5 minutter. I løpet av denne tiden skal du gjøre flest mulig sirkler om til noen annet enn sirkler

Når 5 minutter har gått går man sammen i par og bytter ark.

Se på hverandres ark og skriv hva du tror den andre har tegnet.

5. Zombie Cats

Type: Bli kjent

Tidsbruk: ca.10 min

Du trenger: Ingenting!

Antall deltagere: Passer for gruppearbeid, gjerne med ikke altfor store grupper

Hvorfor

Målet med øvelsen er å bli bedre kjent med hverandre ved å finne noe man har til felles i gruppen. Øvelsen er laget av Smashing Ideas.

Hvordan

Først skal gruppemedlemmene sammen finne to ting de har til felles med hverandre.

Deretter får gruppen vite at de to tingene de har til felles nå er deres nye gruppenavn. Da jeg var med som deltaker på denne øvelsen en gang, fant vi ut at alle hadde hatt Java-programmering på studiene, og at alle i grunn var ganske glad i Baileys i kaffen. Dermed ble vårt gruppenavn "Java Baileys". Navnet på selve øvelsen kommer fra at en gruppe fant ut at det de hadde til felles var at alle likte Zombie-filmer og katter, derav navnet Zombie Cats.

Alternativt kan gruppen også få i oppgave å mime navnet sitt for alle de andre gruppene, slik at de kan prøve å gjette seg fram til hva navnet er.

6. To sannheter, en løgn

Type: Bli kjent, team building

Tidsbruk: ca. 20 - 40 min

Du trenger: Post its

Antall deltagere: Jo flere deltagere, desto lenger tid tar det.

Hva og hvordan

En øvelse hvor hver person i gruppen skal skrive 2 sannheter og en løgn om seg selv. En og en leser opp alle 3 påstandene. Så skal resten av gruppen diskutere, og til slutt gjette hvilken av de tre påstandene de tror er en løgn. Når riktig svar er avslørt fortsetter neste person i gruppen. Dette er en øvelse som kan ta litt tid avhengig av hvor mange man er, og hvor snakkesalig gruppen er. Derfor passer den gjerne best som del av en litt lenger workshop.

Hvorfor

Målet med denne oppgaven er å bli bedre kjent. Jeg synes den passer spesielt bra som en team building øvelse, men den trenger ikke brukes bare i den sammenheng. Uansett, så er det en veldig morsom måte å generere samtaletemaer for neste lunsj!

Lykke til med din neste workshop!

6 oppvarmingsøvelser for å kickstarte din workshop

Dette er del 5 av 6 kaffeprater om Smidig organisering. Hvordan samhandler teamet med resten av organisasjonen? Er horistonal samhandling konsensus eller koordinering, eller noe annet? Er det viktig å vite hva andre jobber med i organisasjonen? Hilde Marie Flesland, Pia Solheim og Moquan Chen drikker kaffe og prater.

Smidig organisering, del 5: Horisontal og vertikal samhandling, og kan vaskemaskinstol-teamet lære av andre?

What is lazy loading, and why should you do it?

Or, to put it more accusingly: Why are you making your users wait for your entire app to be loaded, when they are only going to use a tiny portion of it?

Fact #1: Aspects of a website cater to different needs in different situations. One single user probably does not need your entire site to be loaded at once.

Fact #2: Smaller JavaScript bundles load quicker than large ones.

Conclusion: We should not load more JavaScript than needed at a given time.

Lazy loading is a technique to help you achieve that in your website. Cool, huh? So how do we do this?

How to do it

Let us look at a small example website. We have two tabs on our site: “Home” and “Contact us”. Originally, we have a simple router that does the job for us:

When the user enters our website, the JavaScript bundle(s) containing both the ContactUs and Homepage components are loaded at once. When the users goes to a new route, no additional JavaScript is loaded.

However, introducing React.lazy and Suspence, we can choose to only load the relevant JavaScript. The changes are simple:

If we import our components using React.lazy, and then wrap them in a Suspense tag, the components wrapped will only be loaded when needed. In our case, when the user switches their route.

What is the effect?

On very small projects, the benefits of doing lazy loading are negligible, if any. To test lazy loading in a genuine setting, I tried implementing the same type of logic in a much larger project that I have worked on, where there are many more routes with more content.

Before we start code splitting, let us look at our original JavaScript chunks on a single page load.

In this app, I did the exact same thing as in the example above - wrapped the Router in a Suspense-tag and lazy loaded the components for each route. The project in question uses Create React App and a new version of React, so I did not need to do any extra configuration to get it working.

After introducing lazy loading we get the following chunks on a single page load.

When loading this application after the introduction of lazy loading, the first thing to note was the JavaScript chunks. As expected, the number of chunks had increased, and the size of each chunk is reduced.

But more importantly: The DOMContentLoaded-metric was on average reduced with about 200ms with a regular internett speed, and upon throttling the network in Chrome DevTools with a Fast 3G connection the average difference was 4 seconds. That is a huge gain with very little effort. It should be mentioned that this test was done in a very informal setting, but the difference is still significant.

When to use and when not to use

Of course, lazy loading also works wonders with components that aren't the target of a Route. A menu hidden behind a dropdown-menu would be a great candidate for lazy loading. The same holds for any component that is hidden until the user performs a certain action.

Not all components are eligible for lazy loading, though. There is a slight amount of overhead on it, so components that would be loaded anyway for all users, or almost all users, should be loaded straight away. The perceived loading time for the user might end up being longer if not!

In addition, it does not look good, and is not a good user experience if many components load and pop up at an unsynchronized pace. Therefore, make sure you think through which components should be lazy loaded, and which should not.

Still, there are many cases where lazy loading is an obvious benefit that will help optimizing and improve user experience. It is easy, simple, and will help out with performance.

Optimize your app by being Lazy

JSON is probably the most common way of representing data that is being sent between a server and a browser. JSON stands for JavaScript Object Notation, and, as the name implies, dealing with JSON in JavaScript is pretty straight forward. When you get JSON from the server in a web app written in JavaScript, you can just run JSON.parse() on the string containing the JSON to get a proper JavaScript value out. Or the library you use for HTTP requests might even do it for you.

Things aren't as straight forward in Elm, where we have to decode our JSON to get Elm values out of it, but hopefully this article will give you some advice, which will make JSON decoding a bit easier.

Decoder a

The Decoder type is the fundamental building block of all JSON decoders in Elm. It is what we define to tell Elm how to get an Elm value from some JSON. Unlike JSON.parse() in JavaScript, a decoder is not a function, it is just a value. The way I like to think of it, is that a decoder is a recipe. And the recipe is for Elm to know how to turn a string containing JSON into an Elm value.

The proper type definition of the Decoder type isn't actually Decoder, it is Decoder a. The a in the type definition is a type variable, which means that it can be any type. The a is what the decoder decodes. It is the result of following the recipe, if the decoding is successful. In other words a Decoder String is a recipe to decode a String from a JSON value, a Decoder Int is the same for an Int. And if we want to turn a JSON value into a type we have made ourselves, for instance type Christmas, we would write a Christmas decoder, with the type signature Decoder Christmas.

The Json.Decode package defines the basic decoders we use to decode JSON, like string, int and list, along with the other data types that can be represented in JSON.

Decode Backend Data

JSON decoding can often be quite difficult to reason about, especially if the JSON value you are decoding doesn't map neatly onto the Elm value you are decoding into. I have often found myself lost in huge decoders that I don't understand anything of, even though I wrote them myself only a couple of weeks earlier. The best strategy I have found to make my JSON decoders more simple to both read and understand, is to write them in two steps. First, deocde the JSON as simply as possible to an intermediate Elm value, and then, convert that intermediate Elm value to the value you actually want.

Let's look at an example. Let's say we have an endpoint on our server, that returns JSON that looks like this:

In this contrived Christmas example, we have three fields in an object. The first field has the key "type-of-christmas", and the value is a string. The string should only be one of three variants: "WHITE", "LAST", and "ITS_BEGINNING_TO_LOOK_A_LOT_LIKE". The second field has the key "first-snow", and it holds the year and month of the first snow for one Christmas, represented as a string. The last field also has the year and month represented as a string, but this time of the season's last snowfall, and the field has the key "last-snow". The "type-of-christmas" and "first-snow" fields are not nullable fields, meaning that they should always contain strings, not null, while the field "last-snow"can contain null.

Let's say we want our Christmas type in Elm to be an opaque type. Then it could look something like this:[^1]

Decoding the JSON directly into this might be a little difficult. It would at least be difficult to read the code afterwards. So instead we start by decoding the JSON to a temporary type, I usually just call this type BackendData:

Decoding this type, on the other hand, is quite easy, so let's do that! I usually always use NoRedInk's json-decode-pipeline package, but you can also use the map3 and field functions in the Json.Decode package, to decode BackendData. Using json-decode-pipeline, the decoder for BackendData would look like this:

That's pretty straight forward, but we don't actually want a BackendData value, we want a Christmas value. To get that we need to use to use some other functions in the Json.Decode package.

map and andThen

map and andThen are two functions we can use to transform our BackendData decoder into a Christmas decoder. We can start by looking at their type definitions, to get a sense of what we can use the functions for.

The following is the type definition for map:

This type signature looks suspiciously like every other type signature of functions called map (see my article from last Christmas on map functions here). We see from the type signature that map takes two arguments, a function from a to value, and a Decoder a, and that it returns a Decoder value.

What the map function actually does is that it applies a function to the value that has been decoded, if the decoding succeeded. This makes it so that the result of the decoding is the result applying the function to the decoded value, instead of the decoded value. We will go into more detail on this, but first, let's look at the type signature of andThen:[^2]

We can see that the type signature of andThen is quite similar to map, with one notable exception. The difference is that instead of the first argument being a function (a -> value), it is a function (a -> Decoder value).

So what does this difference mean? It means that the two functions (map and andThen), can be used in slightly different situations. We can use map when we want to transform a value that is being decoded, while andThen can be used when we want to make a transformation than might fail. That is the main distinction between when we want to use each function.

So, going back to our Christmas example, we have now created a decoder for BackendData, and we want to use that decoder to create a decoder for Christmas. To do that we will have to use either map or andThen or both. So, which one is it?

To find out, we don't really have to think about decoders, we only have to think about our two types, and answer the question: Can all values of type BackendData be turned into a value of type Christmas? To answer that question, we can look at the fields in Christmas. The typeOfChristmas field is of type TypeOfChristmas, which is a custom type, but the type we have in BackendData is a String. Since not all strings can be mapped to one of the three variations of TypeOfChristmas, we know that we have a transformation that isn't always successful. We therefore need to use andThen.

This is what our actual Christmas decoder will look like:

In our case, BackendData is the a, and Christmas is the value, from the type signature of andThen. The last thing we have to do now is to write the function backendDataToChristmas, which takes BackendData as an argument, and returns a Decoder Christmas.

To write backendDataToChristmas we have to have decoders for TypeOfChristmas and YearMonth. We will only show the implementation of the decoder for TypeOfChristmas, but the two are quite similar. To create a decoder, we can use succeed and fail from the Json.Decode package. succeed takes an argument of a certain type, and returns a Deocder for that type (which always succeeds). While fail takes a string explaining why the decoder failed, and returns a decoder of any type (which always fails). In the case of TypeOfChristmas, we will write a function that takes a string as an argument, and returns a Decoder TypeOfChristmas. This is what it looks like:

In this function, we just have an if-expression, and we check whether the string being decoded matches the values we expect in that field. In the cases where the value matches our expectation, we return a successful decoder that contains a TypeOfChristmas. And in the else-branch, we return a failing decoder with an explanation of why we had to fail.

Putting it all together

To wrap things up, we can pretend that we have made two more functions, decodeYearMonth and decodeMaybeYearMonth, with the following type signatures:

In that case, we now have all the building blocks to implement the backendDataToChristmas function from before. And it goes like this:

We use Json.Decode.map3, which is like map except that it takes three decoders as arguments instead of one. And the function we use as the first argument to map3, returns a Christmas, meaning that backendDataToChristmas returns a Decoder Christmas, and we have completed our task.

Don't be afraid to fail

When creating more complex decoders, where the JSON representation of our data doesn't line up perfectly with the type we want in Elm, we often have to use the succeed and fail functions, like we did above. It might be tempting to avoid succeed and fail entirely, and just use a default value instead of failing. But I would suggest that you do not do that.

Writing decoders that can fail, might seem a bit scary. But failing decoders have helped me discover bugs in the backend code, which I never noticed in the JavaScript apps using those endpoints, specifically because the decoders I wrote failed whenever the data from the server didn't line up with my expectations.

As long as you take care to write the decoding failures to a log somewhere, you should feel confident that your decoders aren't the source of bugs, but actually help uncover them.

Conclusion

So, in conclusion, to more easily write good and maintainable decoders, simply follow these guidelines:

Decode your BackendData first

Transform that BackendData with map or andThen

Don't be afraid to fail

Happy decoding, and happy holidays!

[^1]: We won't actually define YearMonth, but you can imagine what the definition looks like.

[^2]: I changed the name of the type variable from b to value to match maps type signature in the package.

JSON Decoding in Elm

By now, you have probably heard about serverless applications. You know, the applications where you focus on the code and let some third-party cloud provider manage the infrastructure and deployment process. With serverless functions offered by these cloud providers, it is surprisingly easy to create modular and serverless APIs that can easily be deployed with one command. Let's dig into how.

ZEIT Now is a cloud platform that allows you to deploy static sites from the command line with the single command now. With Now 2.0, the platform also offers deployment and execution of serverless functions. These functions work by responding to HTTP requests and can be written in Go, Python or JavaScript.

In this article, we will explore how Santa Claus can use serverless functions to create a simple 🎁-list API for all his elves to use.

Note: To follow the steps in this tutorial, use a unix-compatible shell.

Setting up the project

Before we start, we need to prepare some stuff.

Sign up at https://zeit.co/signup.

Install now-cli with npm i -g now (or with Yarn if you prefer).

Login with now login.

Initilize the folder structure with mkdir gifts && cd gifts.

Next, initlize the project with npm init to create a package.json.

Constructing the API

Ok, we are now ready to create Santa's simple gift lists API. First, we create a new directory named api at the project's root. Any file, as long as the extension is supported, we put in this folder will be automatically executed when someone visits the route /api/file-name. This works since filesystem routing is used by default, but it's also possible to define your own routes. If you want a file to live inside the api folder, but not be served as a serverless function, you can simply prefix the filename with an underscore, like _utils.js. If you prefix a folder with an underscore, none of the files inside it will be executed by Now.

The first endpoint will provide all the gift lists. Let's make the api directory with mkdir api && cd api, create the first endpoint with touch gifts.js and write these lines of code:

This is a serverless function and will run whenever the /api/gifts endpoint is visited. The two objects, req and res, are passed to each serverless function and can look like standard HTTP request and response objects. However, they include some additional helper functions provided by Now, including the res.json(obj) used above to send all the gift lists as a JSON object.

We can also create a dynamic route to retrieve a gift list by a persons name. If we wrap the filename in square brackets, Now will pass the value in the route to the function. So let's create a [name].js file in the directory /api/gifts. Inside this file, write this simple function:

To retrieve Albert's gift list, the elves can simply go to the route /api/gifts/albert. Neat, right?

So, how do I deploy this?

Well, I promised you that the API could be deployed with one single command. And that's true, from your project's root in the terminal, run the command now. Now will spin up a server and provide free automatic SSL with zero configuration. After some seconds, you will receive a live URL like this https://gifts.username.now.sh/ and Santa's API is ready to go.

Made some changes or added more endpoints? Just run now again and the URL point to the latest changes.

What about local development?

Also one command. In your project's root, run now dev to get a local environment.

Let's sum it up

This article only scratches the surface of what's possible with Now and there is still a lot to learn. I recommend you to explore the Now cloud platform from simple static site deployments to serverless functions. The workflow is truly amazing.

See the related links below to learn more. Happy holidays🎅

Modular and Serverless API with ZEIT Now

In this article we will look into promises in Javascript. The concept of a real life promise is simple, as may also be the case when we first start using promises. However, as we gain more experience with Javascript, it becomes important to really understand promises.

When working with promises today we usually focus on the handling, and a promise is often linked with asynchronous operations like API calls, DB operations or IO calls. There are two important parts of a promise we need to understand: Creating and handling. Lets start by looking into the creation of a promise:

When creating a promise we pass a function that takes two paremeters, which are in turn two functions. When a promise is complete, either resolve or reject is called, each representing two key parts of a promise. The success of a promise, depending on the point of view, is often associated with resolve, and the faulting state is often associated with reject.

Resolve and Reject

Lets have a look at a real life example, and consider a scenario where a friend has made us a promise:

In this case the promise would be resolved right away to 'My friend keeps his word'. Simple right?

Additionally, a promise can have two other states. The pending state for this promise would look like this:

While the rejected state would look like this:

Prototypes

After a promise has been resolved or rejected, we often want to update something. This is where the prototype methods come in. One or two of the prototype methods will almost always execute depending on the implementation. When a promise is in the pending state, three of these prototype methods are really handy:

Promise.prototype.then()

Let's add a setTimeout() to our code to use then():

Promise.prototype.catch()

If the promise is rejected with an error:

Promise.prototype.finally()

If .finally() is implemented, it will call whenever a Promise is settled, regardless if the promise is rejected or fulfilled. Let's use it by adding a waitingOnFriend:

This image shows the flow of .catch() and .then():

Here we see that .catch() and .then() also return a Promise, meaning they can be chained.

Rule of thumb when using Promises

Use Promise when handling asynchronous code

Always implement .then() and .catch()

Remember that you can have multiple handlers of a promise

If you want code executing in both .then() and .catch(), use .finally()

Check out Promise.all and Promise.race if you need to handle multiple Promises.

The Promise of Christmas

How the code is formatted can be a hot topic, but it's a solved problem - just use a linter and/or formatter! In this article, I'll introduce you to a linter and formatter for your Kotlin codebase.

When you have two or more people working on the same codebase there is bound to be disagreements. It might be about larger things such as the architecture or what framework to use. It might be about smaller things, like the number of spaces used for indentation or the order of modifiers.

Meet ktlint, ''an anti-bikeshedding Kotlin linter with built-in formatter'', which is here to help you with the small things!

Wait, bikeshedding? 🙋

What, you haven't heard of this term before? What about Parkinson's law of triviality? No? I hadn't neither!

In short, the term bikeshedding stems from the aforementioned 'law' which argument that ''members of an organization give disproportionate weight to trivial issues''. Here, an example.

While planning to build a nuclear power plant, there is an allocation meeting. In this meeting, large issues such as the size of the workforce and the budget for the containment vessels are passed without much hassel as there are just a few experts fronting each issues. However, when the small issue of a bikeshed is raised, everyone has an opinion, so the issue drags on and ends up claiming a larger part of the meeting then the large issues combined.

For a full version, I recommend the blog post Bikeshedding. Just remember the gist; we tend to spend too much time on trivial things, especially compared to time spent on larger things.

So in other words, an ''anti-bikeshedding'' tool is a tool which aims to tackle the small and trivial issues, so that you won't have to!

So ktlint is for the small issues? 🤔

Yes it is! More specific, it's an opinionated tool that performs linting and formatting of your Kotlin source code, based on the official style guide. Other similar tools are ESlint(javascript), Prettier(javascript), gofmt(Go) and Black(python).

ktlint can perform two actions; it can check kotlin source files, and it can format the source files. When checking the source files it will report any errors it encounters in the files, and the developer will have to fix it. Performing the formating action however, will fix any identified flaw in place in the file, leaving nicely formatted source files in place.

Getting started in two simple steps

It's quick and easy to get started!

Download ktlint from their github releases page

Run it as a jar file with java -jar ktlint.

Alternatively, if you're on Linux or macOS, make the downloaded file executable(chmod +x ktlint) and call it directly with ./ktlint. You can also install ktlint with Linuxbrew and Homebrew.

By default, calling ktlint without arguments will perform the check action on all kotlin files in the current folder and subfolders. To specify directories, simply pass one or more ant-style paths(e.g. "src/*/.kt"). To make ktlint format the source files, pass the -F/--format flag.

There's also several other flags and triggers, such as what style to print the reports in or to configure Intellij to use ktlint-compatible style(ktlint applyToIDEAProject). Call ktlint --help to learn more!

Usage in build automation tools

Calling ktlint works, but will you always remember to do it? I won't, so let's look into how to integrate it into our build tools.

Maven

To keep the configuration somewhat short, the example below will use the dedicated plugin mentioned in the ktlint github documentation. This will give you the self-explanatory commands mvn ktlint:check and mvn ktlint:format, as well as mvn ktlint:ktlint to generate a report containg the result of the check.

Note also that we hook it into the verify phase of the build, but one could be even stricter and run it in the validate phase if one so wishes. If you want to configure ktlint manually, just follow the example listed in their github repository.

Gradle

There's two Gradle plugins mentioned in the github documentation for ktlint. For this example, we have elected to use org.jlleitschuh.gradle.ktlint, but the other seems just as good. By adding it to the plugins block, we get access to the gradle ktlintCheck and gradle ktlintFormat tasks. The former task is also made as a dependency to the general check task of gradle, so that it becomes a natural part of the verification process.

And that's how we got rid of bikeshedding

Armed with ktlint, you can now put an end to style and format discussion. You'll also have one less thing to worry about when looking over pull requests, leaving you with more time to take on the larger and more important things happening in your codebase or at your workplace.

8-Dec

Today's posts