Who doesn’t love flashy fun things! LibGDX is a framework that makes it easy and fun to work with graphics in Java. LibGDX makes it possible to use the same code base for multiple platforms such as mobile, html and desktop. It comes with OpenGL bindings, a high level graphics API, audio, input handling and much more.

Introducing LibKTX

Using LibGDX with Kotlin can feel a little bit dated and clunky, it's a Java framework that's been around for quite some time, and not a framework tailored for Kotlin. To make LibGDX feel more idiomatic to Kotlin we have the perfect library for that; ktx is a library aimed to make LibGDX feel like native Kotlin framework.

Project setup

While LibGDX supports multiple platforms in this article we will focus on making a small game for a desktop environment. To get started we need an empty Gradle Kotlin project. Fire up your favourite editor and create a new empty Gradle Kotlin project.

We are going to use LibGDX and LibKTX, so lets add those to our dependency list. The build.gradle file should look something like this:

From LibGDX we need the core gdx package, the lwjgl for opengl bindings and platform for our desired platform, which is desktop (native) in our case. We also want to include ktx-app and ktx-graphic for idiomatic Kotlin syntax supplied by the LibKTX library.

Let there be darkness

Lets create the simplest application we can. A black screen!

There is not much to the example above. We've created a Kotlin file named `MyGame.kt` and have put some code in to it. We use LwjglApplicationConfiguration to configure our games resolution. It has a lot of options to play around with, like capping FPS and other performance tweaks, but for now we'll keep it simple. The second thing we do is to create a LwjglApplication and pass our game adapter and config to that.

The last thing we need to do is to create a game adapter that will contain our game. To make one we simply extend the KtxApplicationAdapter and override the methods we want to use. For our black screen application doing nothing is enough. And that's it. We can now start our application by running the main method.

Let there be light

A black screen isn't very interesting. To make it more exciting we need game objects, keyboard controls, some simple logic and graphics.

The application adapter comes with two important methods we can override: create and render. The create method is run before the application starts and this is where we do all our LibGDX related setup. The render method acts as the main game loop. We know we need to handle user input, have some game play and we need to draw the game. So lets make functions for those and put them in the render method.

With our game application structure outlined lets add some game objects and what's more fitting than Santa and gifts.

We use Kotlin data classes to represent Santa and ChristmasGifts. For the gifts we give them a random horizontal position and put them at the top of the game screen. The create method is run after LibGDX is loaded and ensures that we can safely access LibGDX-specific stuff inside it. We don't need that for our data objects so we just place them as private variables and ignore create for now.

The next part is to make our game interactive. Luckily input-handling with LibGDX is easy.

LibGDX has already mapped all keybindings to reasonable names for us and Gdx.input contains methods for checking input state. In this Christmas themed game we just want to check if a keyboard button is pressed and move Santa based on that.

Every game needs some good core game play. This game won't have much of that, but lets add some randomness and "gravity"!

That's the game. We add a new gift every now and then and then move all the gifts down one pixel on the screen. I gotta admit that this is maybe not the most exciting game to date, but hey, it at least does something.

With input, game play and data objects out of the way let us draw our amazing game!

There are two main ways of drawing stuff with LibGDX: Sprites and Shapes. We'll be drawing shapes (rectangles) and that require us to set up a LibGDX renderer. Since the renderer is a LibGDX component we need to load it in the create step of our game adapter. With that out of the way lets draw some stuff!

First things first though. We need to clear the screen (cleanScreen) so we don't get multiple frames drawn at the same time. If we forget to clear the screen we'll just draw stuff on top of other things and it will become a huge mess, you can remove cleanScreen to see how messy it can get, but I will for sure clear the screen. To draw shapes in our game we use ShapeRenderer from LibGDX combined with the use extension function from LibKTX.

LibKTX has countless of extension functions and this is where some of the magic comes from. Using only LibGDX we would have to use start a drawing by renderer.begin(), do some drawing, and finishing it up by calling renderer.end(). LibKTX simplify this and it comes with a huge range of improvements over LibGDX when using Kotlin. Check out the official site for more examples.

With our renderer set up we can now draw stuff on to the screen, renderer.color sets the color and renderer.rect draws a rectangle.

Putting it all together

Full source code

The game might be simple, and we can almost argue that it's not a game at all, it has no real game play and no end goal, but it does highlights some of the features of LibGDX and LibKTX. And with enough imagination you can almost see Santa running around trying to pick up the green gifts, saving Christmas.

Going further

If you want to see how to structure a proper LibKTX project that includes assets, sounds and multiple platforms you should take a look at SimpleKtxGame. I can also highly recommend Beat the High-Score, a talk from last years KotlinConf by David Wursteisen.

You can make pretty cool stuff using Kotlin, LibGDX and LibKTX. As a side project over the last year I've been making a game and I can wholeheartedly recommend you to do the same. Check out the video below to see an example of what you can make using Kotlin! Peace out and happy holidays.

Making games with Kotlin!

Java 11 was released in September 2018, and it is the new long term support (LTS) version of Java. "Long term support" means that this version will receive public updates for five years, as opposed to the regular Java releases, which will only be supported for six months. This makes Java 11 a good choice if you don't want to migrate to a new Java version every six months, but you still want to get updates (and you do want those updates, of course!). Java 10 was the last free Java release from Oracle, so if you want Java 11 without having to pay for it, you must make sure to download an OpenJDK version of Java 11, for instance from AdoptOpenJDK.

There are plenty of good articles describing what is new in Java 11, but here are a few highlights.

New String utility methods

Have you ever tried to use trim() on a String containing a whitespace without being able to remove the whitespace? And after some frustration, you realize that the whitespace you are trying to remove is some Unicode whitespace that trim() does not recognize as a whitespace? Java 11 to the rescue! The new String utility method strip() is a Unicode aware version of trim(). We also have stripLeading() and stripTrailing() to remove whitespace from the beginning and end of the String. Java 11 also provides a few other new String utility methods that are worth noticing, like lines() for splitting a String based on line terminators (\n).

New garbage collectors

A less visible, but still important new feature in Java 11 is the two new garbage collectors: Epsilon and ZGC. Both of them are considered experimental. The Epsilon GC is called a No-Op garbage collector because it does memory allocation, but it never reclaims memory. When no memory is reclaimed, you will probably get an OutOfMemoryException, so Epsilon should in most cases not be used in production. The Epsilon GC is meant for performance testing, memory allocation analysis, and for creating a baseline to compare future GCs to. ZGC is a more traditional garbage collector. Being a low-latency garbage collector, one of its main goals is to reduce the length of GC pausing.

So long, Java EE and CORBA!

If you are migrating straight from Java 8 to Java 11 and use a lot of SOAP based webservices, then you are in for a surprise (or maybe more of a cold shower)... The following packages has been removed, after having been deprecated since Java 9:

java.xml.ws (JAX-WS, plus the related technologies SAAJ and Web Services Metadata)

java.xml.bind (JAXB)

java.activation (JAF)

java.xml.ws.annotation (Common Annotations)

java.corba (CORBA)

java.transaction (JTA)

However, this only means that these packages have been removed from Java SE, most of the functionality will be available as Maven artifacts if you still need it.

More details about what's new in Java 11:

https://dzone.com/articles/90-new-features-and-apis-in-jdk-11

https://dzone.com/articles/90-new-features-and-apis-in-jdk-11-part-2

https://www.journaldev.com/24601/java-11-features

https://openjdk.java.net/projects/jdk/11/

What's new in Java 11

Xamarin is a well-known framework from Microsoft allowing you to use C# to write cross-platform apps for iOS, Android, Tizen and more. With Xamarin Forms, a cross-platform native UI-layer built on top of Xamarin itself, even the views and logic can be shared.

This is great for the object-oriented guys and gals, but what about functionally oriented people? Good news! Xamarin supports F#, Microsoft's functional language, as a first-class citizen on the platform. And just like C#, F# can utilize the entire .Net ecosystem and gives us some exciting choices in regards to app architecture. MVC and MVVM are great for what they are, but haphazardly mutation of state easily leads to bugs and more complicated testing harnesses.

Luckily, with the power of F#, a better way exists.

Fabulous Architecture

Fabulous is a fabulous framework for crafting apps with the ultra-simple Model-View-Update architecture, know from Elm and Flutter, using F# and Xamarin Forms.

The Model-View-Update architecture is easy to reason about. It structures applications into three parts and it defines how these interact with each other. There is only this one determined way to handle interactions and manage state – and it provides a good foundation for modularity, code reuse and testing by default.

Using Fabulous, this is an app in its purest form:

Fabulous Model

The Model is the core data from which the whole state of the app can be resurrected. The init function returns your initial model. The update function updates the model as messages are received.

Fabulous view function

The view function computes the GUI using the given model. The GUI consists of an immutable object graph of the Xamarin Forms views and controls to be used.

Fabulous update function

Each model has an update function for message processing. The messages are either messages from the view or from external events. From these, a new model can be computed.

Fabulous example

The following is a complete example of an app, the source is available on github.

Fabulous advantages

Using immutable models, this architecture has a couple of advantages:

The init, update and view functions can be easily tested in isolation

Models can be easily saved and restored

The update function is the only place where your model gets transformed, this structure makes it very easy to reason about state changes and where they are coming from.

And off course, Fabulous supports Live Update, enabling you to make and see the effect of these changes in the simulator without redeploying the app.

Xamarin Forms can truly be fabulous.

Fabulous Xamarin Forms

The people behind JavaScript is a series of interviews with the members of TC39. The committee consists of JavaScript enthusiasts and language experts who get together to define how new versions of JavaScript should work.

:point_right: Make sure to follow Dan on Twitter

Who are you and what do you do?

I'm Daniel Ehrenberg, a TC39 delegate and a partner at Igalia, a free software consultancy.

How did you get into programming?

I used to program little games on my TI-83 calculator when I was 12 or so. From there, I wanted to learn "real programming" on the computer, but didn't know where to start. So I ended up reading about a lot of different programming languages, trying to figure out which was the best to learn.

What do you like about JavaScript?

I like how JavaScript is generally both free-form and uniform, when it comes to how you use objects, how lexical scoping and closures work, etc. Its base is both minimal and free of arbitrary restrictions.

And I like how JavaScript is everywhere, adding an layer of programmability accessible to a wide range of people.

How did you get involved in the development of ECMAScript?

When I was working at Google on various Linux kernel/firmware teams, I saw an internal job opening for the V8 sub-team working on new language features. At the time, this was implementing ES6. I jumped at the chance, and quickly found myself on TC39, pushing forward SIMD.js and working out the unfinished bits of ES6.

What's a contribution you are proud of?

I'm really proud of the JavaScript BigInt feature. It was the work of a lot of people, but I helped by pushing it through the TC39 process and editing the proposed specification. This feature lets you work with integers of any size, without arbitrary restrictions like BigInt has.

:video_camera: Watch Dan's JSConf talk from 2018 about BigInts In JavaScript.

What's an upcoming proposal you are excited about, and why?

I'm excited about the BigDecimal proposal. This would be a new numeric type that can represent numbers like people write them: with base-10 decimals of unlimited size represented precisely, without rounding errors. You can find more information at https://github.com/littledan/proposal-bigdecimal .

What is the most fun about being a part of the development of ECMAScript?

It's really fun to dream about new language features and think through the details and the design space. I really like how I get to learn about all sorts of different problems in a somewhat deep way, in terms of how they interact with the JavaScript language.

What is the hardest part about developing a programming language?

Working with a large group of people and understanding their problems and concerns, and resolving conflicts between these.

What do you wish you knew before you started contributing to the development

I wish I knew how important and complicated it was to both listen and to reach out and seek feedback. Initially, I thought that we could get "correct" answers could be reached through first-principles reasoning and just negotiating with people who assert themselves. I don't think that that sort of development process will actually meet people's needs; it's not inclusive enough to actually understand the real problems.

How do you hope JavaScript will evolve in the future?

I hope the language will evolve in a gradual, open, community-based way, and that TC39 will remain a good place to solve problems that exist at the language level. I can't give a single answer here: The needs of JavaScript programmers will change over time as the community grows and evolves. I hope TC39 will be ready to meet these needs, in a thoughtful, stable, dependable way.

The people behind JavaScript: Daniel Ehrenberg

At Digipost we are in the progress of building up our new infrastructure on Azure. We are already enthusiastic users of Terraform and have chosen to continue down that path, towards infrastructure-as-code (IaC) bliss, where the totality of your infrastructure can be created by a single command. But what happens when that totality is a bit big for a single Terraform state-file?

As we were building the new infrastructure and adding more and more components to our Terraform state, some operational pains started to surface. Operations were slower and recreating the stateless compute parts (Kubernetes) sometimes led to seemingly unrelated resources being affected, in part because the effective dependency graph was slightly accidental. As a response to these pains, we did some research to learn a bit more about best practices when structuring Terraform projects.

Splitting by environment

It turns out that especially in the early days of Terraform, bugs where Terraform crashed and messed up your state was not uncommon. This led to early adopters being concerned about the blast radius when running Terraform, in other words, if something explodes, how many resources will at maximum be affected. In the words of Charity Majors:

It is still as green as the motherfucking Shire and you should assume that every change you make could destroy the world. So your job as a responsible engineer is to add guard rails, build a clear promotion path for validating changesets into production, and limit the scope of the world it is capable of destroying. This means separate state files.



https://charity.wtf/2016/03/30/terraform-vpc-and-why-you-want-a-tfstate-file-per-env/

Though this was written back in March 2016 and Terraform has matured a lot since then, the point she makes is still valid and touch upon the scary thing about IaC: As easy as it is to create all your infra in one command, it is just as easy to tear it all down again. Which is why you need to think about what "guard rails" you have in place to make sure that never happens. One such guard rail, Charity suggests, is separate state-files per environment, enabling you to safely test out infrastructure changes in test environments as well as reducing the total number of resources in the state-file.

Splitting by component

Yevgeniy Brikman, creator of Terragrunt and another infra-veteran, goes further in the theme of blast radius reduction and "guard rails", and suggests to also separate state by component, so that resources that are changed frequently are not grouped together with stateful resources such as databases. In a blogpost he says:

If you manage the infrastructure for both the VPC component and the web server component in the same set of Terraform configurations, you are unnecessarily putting your entire network topology at risk of breakage (e.g., from a simple typo in the code or someone accidentally running the wrong command) multiple times per day.

He suggests the following structure as a template for a Terraform project:

Notice the additional directories under for example prod/. This will in addition to environments, isolate VPC, data stores, web-servers etc from each other. The drawback of such a layout is the increased complexity of operations when using many state-files (as Terraform need to be run in all the different subdirectories), and also the increased duplication of config. At this point, most seem to prefer using a wrapper like terragrunt or astro to ease the pain, while some prefer the wrapper-less approach.

Another benefit of splitting by components, or at least layers of similar components, is that it forces you to think more of what the interfaces between layers are, since you cannot reach back through the dependency graph and extract data from resources that now live in other state-files. And thus it will also be harder to accidentally introduce unwanted dependencies, for example from a database to a Kubernetes cluster.

So there seems to be a general consensus that you should both separate by environment and by groups of components. But how you keep the Terraform source DRY and how you rollout changes is where things get much more opinionated and dependent on things like team-size. The good thing though is that those things are easier to change as you go along, whereas moving resources between modules and state-files is a bit harder and better to get “as right as you can” from the start.

For those interested in a deeper dive into the topic, OpenCredo have written a great article about the different stages in their journey from a single state-file to a split-by-component setup. They loosely compare splitting by component to a monolith being broken into smaller micro-services.

So what did we do?

So what did we end up doing? We already had one state-file per environment, and decided to further separate it into layers of components to really isolate the stateful resources from frequent changes. It was a really useful exercise which made it clearer what resources belonged together and which did not. Below is a somewhat simplified illustration of our current state split.

We are particularly happy with having isolated the storage components into small stable state-files.

Hopefully this will make operations faster and safer and be a better foundation to evolve from.

Splitting the Terraform monolith

I denne kaffepraten samles tre konsulenter, med ulik faglig bakgrunn og senioritet, for en uforpliktende prat om OKR (Objectives & Key Results). Vi forsøker å få klarhet i hva som egentlig er greia med det sagnomsuste OKR-rammeverket. Du får innsikt i komponentene rammeverket består av og hvordan OKR skiller seg fra andre målstyringsrammeverk. I tillegg deler vi noen gode råd til deg som vil prøve OKR i egen virksomhet.

Hva er greia med OKR?

This December 1st, Helen kicked off our Christmas calendar with a bit of a rant, concerning titles.

“It’s natural for us to want to keep to our own camp and focus on problems that can be solved with our own discipline. But this tunnel vision can severely limit our creative thinking and force us to fall back on obvious solutions.”

I couldn’t agree more.

And this year, I came across a challenge that really put this in perspective for me:

The APIs we were delivering, weren’t doing their job.

Well, that’s not exactly true. We were making APIs that worked – others could use them to build their own digital solutions. But it was difficult for them to figure out just how they could make use of them, and develop stuff with them.

And it occurred to me then, as I started looking into that problem, that APIs are as much of a service as running an airport express train and needs just as much design attention if they’re to be great services. And it’s not just about touchpoint-design – like the documentation website – but the design of the APIs in themselves, the communication channels surrounding them, the onboarding process of new developers, security and access levels.

I hadn’t really given APIs much thought as a designer before, I must confess.

I am an interaction design, with 12 years of experience. And my UX playground has certainly grown over the years; from doing strictly user interface interaction specifications and information structures way back in 2007, I now deal with the attractiveness of our digital products, with how our cross-functional teams deliver and collaborate, the viability of our ideas, the organizational intricacies of setting clear goals for digital services and how we work to reach them, the completeness of the customer journey our products are part of and underpin – along with the usability and desirability and doability of it all.

And yet – paying attention to our APIs as a designer and product developer hadn’t really occurred to me as part of responsibility.

I thought of APIs – like most of the organization around me did – as the developers’ responsibility. Alone. It was their delivery – not mine. I don’t handle code. I’m a designer.

Big mistake!

Because fairly soon, we experienced exactly what you would expect when you don’t pay attention to the user experience of your product or service: our users found our APIs difficult to use. And delightfulness? Forget about it. We were – as I believe many are – focused on delivering functional APIs. As long as they worked, we’d met the requirements. I mean – delightful APIs? Come on.

But it is a thing, as I came to learn. Once I started interviewing developers – as good old fashioned user insight – I found different sets of needs, of motivational factors, barriers – and examples and stories of how APIs can delight them, frustrate them, confuse them, and make them want to build more with them.

And it opened up a whole new way of thinking – both for me as a designer, but also for our organization.

And seeing that it is already December 11th, and Christmas is almost around the corner, and that we all have a lot of stuff to do, I’d like to end this article with a few concrete examples of how our new mindset manifested itself. I hope what I have written so far, in a small way, might inspire you a bit, to broaden your perspective as a designer – and that the few points that follow might help you improve your organization’s APIs if that is part of your company’s offering.

We recognized that our API’s are products and the provision of them to others is a service. So we organized ourselves accordingly: set up a cross functional product team with

a product owner to manage the development of the APIs as service - across all the API-delivering teams

a UX designer to bring the user’s perspective into the process (and design touchpoints)

two developers to assess the design of the APIs in themselves and develop the touchpoints needed for communication with our users

We set up ambitions for our APIs like we had on our other digital services and products. I have included them at the bottom of the article. We set them up specifically for our work with our APIs, but they’re quite general, and even if they reflect our specific challenges with our APIs, I believe they will resonate with many API-providers out there.

Just like we set up ambitions, we also decided on a few metrics to watch, to see that we were succeeding with our work.

We started doing user interviews with developers whom were using our APIs. This was a tough one – it felt like being a completely fresh off the farm UX designer again. It’s been a long time since I have been so unsure and unfamiliar with the subject matter at hand. Understanding developers talking about how they experienced our APIs? Hello, darkness, my old friend. Half of the time I just wrote down the sounds I heard, trusting I could ask a developer colleague later what it meant, and reminding myself that it’s not really what they’ve done but how they experienced it that matters right now. It was rough – but felt kind of good, too. I couldn’t rely so much on my own experience and assumptions anymore, and that felt…well, healthy.

We did other insight activities as well, just like we would for any other service or product we’d design and develop.

We drew up a service framework for our APIs, with the different stages of the customer journey (onboarding being our prioritized stage), different user segments (professional developers in bigger organizations – in different sectors and markets, individual developers – we have a few open APIs, students, etc.) with different needs and offers, and: most important touchpoints. The APIs in themselves being number one, of course, then change logs/change notifications, our documentation website and direct communication channels.

The key take-away for me, from the user interviews, was how important a user centric view was even when developing APIs. We had developed APIs based on functional specs – API this shall make that possible. And when it was possible – we were done. But when we interviewed the developers using our APIs it became clear that what would have been helpful for them, would have been developing our APIs based on what they would most likely want to build on top of them. Separating the different APIs after feature areas relevant for our prioritized users, designing objects in a way that most likely would answer to their specific need.

In the end, designing the actual API and develop them falls on the developers: I am simply too far removed from API as a material to efficiently and effectively design for it. But what I was able to do, once I had taken off my tunnel vision goggles, and look outside my regular design box, was to make that part of our delivery, which up until now had not been recognized as a service or product, and put it in a user centric perspective – and thereby adding value to that delivery as well.

(I have, however, included a few links to articles on designing APIs that I found very useful in understanding what good UX for APIs is or can be all about. If you're curious and fancy broaden your designer horizon a bit, check them out)

To quote Helen again:

“What if the whole team, no matter their background, was more curious about each other's work?”

And for us, that would have meant that we probably would have caught on a lot faster on the importance of designing APIs as a real service. If I had been more curious about that part of the developers’ job, and they had been more curious about my bringings to the table – I think we could have saved us and our users a whole lot of trouble and delivered a more powerful service sooner.

UX is everywhere – and you can live long and prosper a lot more if you take a look around and not let titles and old assumptions bog you down.

The UX of APIs

Do you really know how your users are interacting with your application? Have they tried out the latest feature you just deployed to production? Examining your user’s behaviour and interaction can be tremendously useful - figuring out where they incur problems or halt a purchase, where in the onboarding process most people fall off, how long time they spend on certain pages, or even just where on the site they’re located, are all valuable information for the further improvement and development of your website.

There are many products and services offered relating to measuring and tracking a user’s behaviour on websites. This article is an introduction to using Azure’s Application Insights in your React project, focusing more on how it’s used than setup and implementation.

For our React project, we’re using Microsoft’s npm packages created for integrating your project tracking in Application Insights. @microsoft/applicationinsights-web is the Javascript SDK and works well if you’re mostly interested in tracking actions and events. @microsoft/applicationinsights-react-js is a React plugin for the Javascript SDK, which enables instrumenting various react component usage tracking and utilizing higher-order component function. It permits for more calibrated tracking, for instance measuring time from the ComponentDidMount event through the ComponentWillUnmount event. There's a useful React demo project by Microsoft available here, all you need to get started is the instrumentation key from an Application Insights resource in your Azure Portal. If you're just getting started with Application Insights tracking, try running the demo locally and experiment with the different forms of tracking showcased. So what can you do with all of this? Let's get trackin'

The most basic form of tracking is arguably event tracking. For example, say you want to track what users search for on your site

Pretty straight forward. Use the trackEvent() method by passing an object as argument. Use the name key to keep track of the different events in Application Insights and pass along other useful data. With multiple event trackings, this proves beneficial for observing various stages of a process.

Now this is just to showcase a possible use case and could be better placed elsewhere. Here's how that could look in Azure Portal:

As with all examples it might be a bit primitive, but it gets the point across. Here we've create a funnel using two events - it lets us track events in sequence, measuring the changes between each step. For instance, in a multi-step onboarding process, this proves very beneficial for investigating where most users fall off.

Getting back to our event tracking, we also have these tracking methods:

Here we’ve also introduced severity level, which can be used to filter tracking in Application Insights to display what requires our immediate attention and what deserves to be logged at all.

Instead of doing all of this manually, you can also automatically track a number of events without explicitly telling it to do so. A convenient feature is auto collecting errors and API methods:

Another very useful feature is automatically tracking page views and user navigation behaviour. This lets us follow the users path from start to end, by looking at the visited pages and the navigation route. For instance, a purchase process could look something like this:

Now, these trackings can be made smarter, of course. For more useful tracking, you might want to include more data which is relevant for monitoring page views, events and errors. From there on, it’s easier to look for common denominators on potential improvements and errors. For instance, you can create a helper for tracking events and including all the relevant data:

Using this approach, you can predetermine desired data for passing along particular types of data used in different types of tracking. Additionally, instead of typing the tracking name in manually, it could prove wise to create a file to maintain tracking constant for use across the project.

Templates to get you started

Application Insights has a number of templates available which allows you to explore the metrics from your webapp, without much need for prerequisite knowledge or experience.

There's still a ton of functionality which isn't mentioned here, but hopefully this article served as an interesting introduction to using Azure Application Insights in your React project and the potential benefits, whether it's a small hobby project or a large client one.

Working with Azure Application Insights in your React app

Version control software is an essential part of modern-day software developer practices, and Git is by far the most used system. However, the amount of commits, pull requests and activity in general may be huge, and reduce the value of the git history. The Open Source project Gitmoji is a standardized emoji guide for your commit messages which enables you to assign an emoji at the beginning of commits. It even comes with an interactive client that lets you access the emojis through your command line. Although emojis are always fun, the question arises; is it just a gimmick or does it add any value?

Overview of Gitmojis: https://gitmoji.carloscuesta.me

A picture says more than words

Gitmoji was born to make it easier for developers to identify the purpose of others commits. With gitmoji others or your future self can simply look at the associated emoji and straightaway catch the intention. That in itself is a powerful feature for a developer analyzing line by line with text and code. And not to mention, the colors and joy it brings to the commit history.



A small set of gitmojis make commits easy to identify

However, some emojis are more recognizable than others and the Gitmoji guide currently consists of 66 different emojis describing different intentions, some more useful than others. The 🐛 emoji is easily recognized as a bug by most people, but will 🔥 immediately signalize that code is removed?

The learning process is an important factor with successful use of gitmoji. By selecting a small set of emojis, you and the contributors can rapidly recognize the emojis and their meanings, which is the whole idea with gitmoji in the first place. Some of the emojis are more general than others. I would recommend using those more general rather than the more detailed ones unless their usage is frequently and should be highlighted. What emojis that are selected should vary depending on technology and which stack you are working in. Frontend repositories would for example use 💄for UI changes, an emoji less relevant for backend development.

Forces you to make smaller and more specific commits

A positive outcome of using gitmoji is the fact that it forces you to think through the content and message of your commits to a larger extent. It might reduce the urge to combine completely different changes in the same commits, or even writing diffuse commit messages like small fixes. The purpose of commit messages is to communicate context about a change to other developers working on that project, and indeed, to your future self. Gitmojis may contribute to making this history more understandable a long time after the changes were committed.



May also be used for pull request titles

Originally, gitmoji is meant for assigning emojis to the commit messages. This may be suitable for large pull requests with many commits of different nature. However, a small pull request with a defined objective may have fewer commits of similar nature. In this case, assigning gitmojis to the pull request title may be more relevant. From experience, doing both adds value.



Summary

Gitmoji will add value to your development project by simplifying code collaboration. Using a small set of emojis, suitable for your project, will make it easy for the contributors to recognize the intention of the commit. It may also contribute to better and more precise commits, and last but not least it definitely adds joy and excitement ✨💥🚑🤖.

Gitmoji - Yay or Nay?

Usually we let neural networks adapt their parameters to data, for instance images. Ever wondered what happens if we instead adapt images to match the network? Style transfer applies the style of one image onto another, and it's a crowd-pleaser.

To grasp style transfer, we must first understand what neurons inside the network represent. Let's focus on networks trained on images; those are easier to appreciate visually. Efforts have been made to understand what different neurons “looks for” in the input image. In other words; what patterns or objects must be present in the image for a given neuron to activate?

As it turns out, neurons close to the input look for lines, contrasts and gradients. The next layer of neurons will then look for patterns across these simple lines and contrasts. This makes the patterns increasingly complex as we get deeper into the network. Zeiler, Matthew D., and Rob Fergus. “Visualizing and understanding convolutional networks” illustrates what the different layers might look for, shown below.

 Each square illustrates the kind of pattern a certain neuron will recognize in an image. The nine patterns seen here are simple shapes like lines and contrasts, implying this is an early layer in the network.

 Deeper in the network neurons are triggered by the presence of complex features like human or animal faces.

Another way to think about difference in layers, is that deep layer patterns make up the content of an image; objects that make up the scene. Shallow features on the other hand resemble texture, but they seldom contain enough information to reveal what object they are part of. The concept of texture vs. content is explored in style transfer, where the goal is to apply the style of one image onto another.

Transferring style is done in two steps. Start by feeding the image containing the wanted style, for instance “The Starry Night”, to the network. This will cause some of the neurons to activate, depending on what patterns are found in the image. Next we feed the network our destination image, for instance a regular photograph. Now a different set of neurons will light up. In order to transfer the style, we simply make small, iterative changes to the photograph such that neurons fire more similarly to the first stylized image. After doing this for a while, the photograph will start to adapt features from the initial image! We can further tune this by adapting more to neurons representing texture than content. This way we preserve the content in the photograph, but replace textures.

 The style of Vincent van Gogh’s “The Starry Night” is transferred to a photograph. Taken from Leon A. Gatys and Alexander S. Ecker and Matthias Bethge. "A Neural Algorithm of Artistic Style"

Google's gaming service Stadia aside, neural style transfer is somewhat limited in terms of practical applications. As a tool for researchers and hobbyists to broaden their understanding of neural networks however, it's certainly a topic worth looking into.

Style Transfer

There is a display property that goes hand-in-hand with CSS grid: display: contents. With this property you can keep good HTML semantics when using CSS grid. Let's see how.

Let's say you're writing a blog, and want an overview page of all the posts you've written. You might choose the following markup:

If you want to present this in e.g. a two-column layout, a good choice would be to set display: grid on the section tag:

However, you might stumble into a challenge if you also want both the title and the ingress of each article to align nicely with each other. In that case it might be tempting to remove the <article> tag from the markup, but instead you may simply add display: contents on this tag, along with some extra CSS to specify the flow of the elements in the grid:

See how Ingress #1 is now vertically aligned with Ingress #2? 🤩

When the display property display: contents is added to the <article> tag, the h2 and p elements act as if they were direct children of the grid.

So next time you're working with CSS grid, see if you can utilize its companion display: contents to get the grid just the way you want it - while keeping the HTML semantics in tip-top shape.

PS: display: contents also enables you to use CSS grid with tables, which potentially gives you superpowers over the common table-layout: fixed approach (see the link "Flexible data tables" for an in-depth blog post). Here is a simple example:

CSS Grid's Best Friend

Most authentication solutions end users are exposed to on the web these days are password based. Unfortunately, there are a number of reasons why we shouldn’t use passwords to protect access to web accounts:

The passwords have to be shared with the sites we register with. We have no control over how the passwords are stored or who has access to them. The result is that passwords end up being exposed all the time, through data breaches or even system logs. Currently there are over 9 billion leaked accounts on haveibeenpwned.com.

It is the user’s responsibility to generate and remember passwords. Therefore they often end up being easy to guess and reused across multiple sites.

Users are easily tricked to give away their passwords. Verizon's Data Breach Investigations Report for 2019 showed that 3% of phishing attempts were successful.

Knowing all this, why do we still use password based authentication methods? For the most part it’s due to the lack of good alternatives. Different attempts have been made to rectify the issues mentioned above. Two factor authentication protects you if your password is leaked, while password managers help you generate strong passwords that are unique across your accounts. Unfortunately most people don't use them, indicating that they aren’t user friendly enough for your average Jane or Joe.

The FIDO (Fast Identity Online) Alliance has set out to solve the world’s password problem by creating an authentication method that is both secure and user friendly. The alliance consists of some of the most influential companies on the web, like Google, Amazon and Microsoft, and have created an open authentication standard called FIDO2. In simple terms FIDO2 replaces the need of a shared secret, i.e. the password, with public key cryptography. The standard consists of a W3C approved API called WebAuthn and a client to authenticator protocol called CTAP. Before diving into the details, let’s walk through how this will work in practice (use cases taken from the WebAuthn specification):

Registration (using a phone)

The user navigates to example.com in a browser and clicks a button to create an account

The phone prompts, “Do you want to register with example.com?”

To accept, the user provides some previously configured authentication mechanism such as a PIN code or fingerprint

Once authenticated, the registration is complete

Authentication (using a laptop)

The user navigates to example.com in a browser and clicks a button to sign in

The browser displays a message saying, “Please complete this action on your phone”

The phone receives a notification saying, “Sign in to example.com”

The user taps on the notification and authenticates using their preferred authentication mechanism

The sign in completes

Let’s take a closer look at what’s happening under the hood. The central component in FIDO2 is a cryptographic entity called the authenticator. In the examples above, the authenticator is running on the user’s phone. The authenticator’s job is to generate public key credentials for relying parties, authenticate the user and cryptographically sign challenges presented to it by relying parties. When the user clicks the button to create an account, the website (referred to as the relying party) uses the WebAuthn API in the browser to initiate the registration process illustrated in Figure 1. First the authenticator prompts the user to authenticate. Then public key credentials are generated, given that the authentication was successful. The private key is stored on the device together with information about the relying party. The public key is sent back to the relying party which associates the public key with the newly created account.

Figure 1 (source: https://fidoalliance.org/how-fido-works)

When signing in, the website uses WebAuthn to send a randomly generated string of characters called a challenge to the authenticator. The authenticator verifies the origin of the request, unlocks access to the private key by prompting the user for authentication, signs the challenge with the private key and returns the signed challenge back to the relying party. The website, knowing the original value of the challenge, verifies the signature by using the public key associated with the account. If the signature is verified, the sign in is complete. The process is illustrated in Figure 2.

Figure 2 (source: https://fidoalliance.org/how-fido-works)

In the authentication scenario the authenticator is not running on the same device as the browser. These authenticators are referred to as roaming authenticators and communicate with the client platform through the CTAP protocol. We won’t go into details about the protocol here, but it describes how external devices running authenticators communicate with client platforms through underlying transport protocols like USB, NFC and Bluetooth.

So what exactly makes FIDO2 better than using passwords? First of all, the secret, which in this case is the private key, never leaves the device. It is also locked behind some authentication mechanism on the device itself. This makes it a lot less likely that someone will be able to steal your secret. If some website is breached, only the public key, which can not be used to impersonate a legitimate user, will be available to the attacker. Additionally, FIDO2 has built-in phishing protection. The private key is scoped to a specific domain, meaning it can only be used to authenticate on the same domain for which the key was generated. FIDO2 also protects against replay attacks. The challenge that has to be signed is randomly generated each time a login is initiated and can only be used once. If someone attempts to reuse a signed challenge, no access will be granted.

FIDO2 support is increasing. Most major web browsers already support WebAuthn, whilst devices running Android 7+ or Windows 10 can be used as FIDO2 authenticators. Now it’s mostly up to websites to start offering FIDO2 authentication to end users. Companies like Google and Github currently allow you to use your FIDO2 security key as a second factor of authentication, whilst Microsoft has gone all the way allowing you to use is it as a single factor of authentication, providing a true passwordless experience. If you’re using a WebAuthn compatible browser on one of the devices mentioned earlier, you can try out FIDO2 yourself at webauthn.io.

This is all good, but what happens if you lose the device holding all the security keys? Perhaps the biggest obstacle to reaching widespread FIDO2 adoption at the moment is coming up with a recovery mechanism that is both secure and user friendly. The current recommendation is to register a second authenticator with each relying party. If you lose one of your devices, you can still get access to your account with the other authenticator. Having to set up multiple security keys for all your web accounts is definitely not very user friendly and is hopefully something that will be solved in the future.

If you're interested in reading about an alternative to FIDO2 that is also based on public key cryptography, check out this post about SQRL. Or if you want to learn more about WebAuthn, click here (available from December 16).

11-Dec

Today's posts