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 Allen on Twitter

Who are you and what do you do?

I'm a software architect and developer specializing in dynamic programming languages. In the 1980s and 90s I was deeply involved in trying to make Smalltalk an industrial strength programming language. It almost worked. I've been recognized as an ACM Distinguished Engineer and an Ecma International Fellow. I was the editor for the ES5, ES5.1, ES2015.

How did you get into programming?

I became intrigued with them in 6th grade, when small computers filled large rooms.

What do you like about JavaScript?

Its ubiquity. JavaScript is the language of the web and is likely to outlive us all.

How did you get involved in the development of ECMAScript?

In early 2007, I was working as a software architect at Microsoft. At the time, nobody at MSFT cared very much about JavaScript. I saw a need and opportunity to improve JavaScript/ECMAScript for the long term and positioned myself to lead Microsoft's reengagement with TC39.

What contribution are you most proud of?

Producing the ECMAScript 2015 Language Specification and contributing to the design of the language it defines. Part of my role as editor was making sure that all the good ideas actually fit together coherently.

Which upcoming proposal are you most excited about, and why?

The Realms API and closely-related Secure ECMAScript proposals. These are foundational proposals that enable building secure sandboxing of untested JavaScript code within JavaScript applications.

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

Impact – knowing that you are having a direct impact of the world's most widely used programming language. You are touching people everywhere.

What is the hardest part about developing a programming language?

Throwing out all the good ideas that that would make the language too complex – then trying to make sure that the features you keep play nicely with each other.

Do you think JS is a complex language now? Think what it would be like if hundreds of additional good feature ideas where incorporated into it.

What do you wish you knew before you started contributing to the development of ECMAScript?

The full history of the language and its standardization efforts. What was the reasoning behind past decisions.

That's why I've spent most of the last two years working on an in depth technical history of the evolution of JavaScript/ECMAScript from 1995 through 2015. It will be completed and available around the middle of 2020.

How do you hope JavaScript will evolve in the future?

I hope that TC39 fills in a few key fundamental holes (for example, Realms) and slows down accretion of faddish surface features.

JavaScript is unlikely to ever be the world's best programming language but its role on the web means that it is likely to be one of the world's longest-lived programming languages.

We need to make sure that in 2119 somebody who wants to get a glimpse of what software development was like in the past can open the "2019 JavaScript Advent Calendar" and it will just work!

The people behind JavaScript: Allen Wirfs-Brock

Designers usually strive to design user-friendly products fit for a diverse group of people. But how do we actually design and develop products that consider the needs of impaired users? This short article aims to introduce you to the maze of web accessibility and its related framework WCAG 2.1: How can we include people with disabilities on the web and how do we understand the numerous criteria we need to meet in order to do so?

What is web accessibility?

Web accessibility is an inclusive practice that aims to make digital content accessible to everyone, including those with disabilities. This does, for example, imply that people who are blind or deaf, as well as people impaired by socio-economic restrictions like low bandwidth or speed, should be able to operate the web without difficulty. Using design lingo, one could say that an accessible web page is universally designed.

Why consider accessibility?

Designing accessible web pages is a good and ethical practice that should be followed at all times. Furthermore, conforming to accessibility guidelines usually improves the general user experience for everyone. Universal design avoids discrimination, broadens your user base, and improves the user experience. It’s a win-win situation!

Another reason to design accessible web pages is for economic reasons. Over the past decades, many countries and regions have established laws to ensure that providers of digital content include disabled people to the best for their abilities. The European Union (EU) has, for example, developed a Web Accessibility Directive (WAD) that guides the national laws of many European countries. If a web page fails to conform to these laws, its infringing provider can face fines or lawsuits.

How can you design accessible web pages?

Enter the Web Content Accessibility Guidelines 2.1 (WCAG 2.1): a humongous set of guidelines that helps you make the web more accessible for people with visual, auditory, physical, speech, learning, neurological, and cognitive disabilities. If you’ve ever visited the official web page of these guidelines and felt overwhelmed by its extensive content - you’re not alone! To make your life a little bit easier, here is an introduction to WCAG 2.1, accompanied by four small tips for how to practice accessibility:

What is WCAG 2.1?

To directly quote the official webpage:

“WCAG 2.1 is developed through the W3C process in cooperation with individuals and organizations around the world, with a goal of providing a shared standard for Web content accessibility that meets the needs of individuals, organizations, and governments internationally.”

WCAG 2.1 consists of four main principles, which contain a total of 13 guidelines. Each guideline provides at least one success criterion:

The numerous success criteria mainly address three concerns - content (e.g. text and images), design (e.g. layout, colors and contrast), and technology (e.g. the code structure). These are concrete, testable measures of your web page’s level of accessibility. Success criterion “2.1.1 - Keyboard” says, for instance, that all content must be operable through a keyboard interface.

How to practice accessibility and use WCAG 2.1?

1. Make WCAG/accessibility a natural part of the insight and development process

Bother spending some time learning about accessibility and the WCAG success criteria. If you make yourself familiar with WCAG 2.1 and the overarching principles of accessibility, you can both consciously and unconsciously design content that is adapted to disabled users’ needs. This understanding makes it possible to consider accessibility while you develop a web page, rather than after it is finished. The following three tips are focused on how you can achieve this understanding.




2. Seek supporting sources

Some success criteria in WCAG 2.1 are written in a language that demands a Ph.D. in astrophysics to interpret. Or at least, that’s what it felt like to me - a mere designer - the first time I accessed the WCAG web page. For this reason, I highly recommend you use other materials to support your understanding. Personally, I’ve used WUHCAG and Knowability frequently to search for specific success criteria that needed some down-to-earth explanation. Google is your friend!

For Norwegian readers, I also recommend Difi’s online course in universal design and their list of WCAG success criteria in Norwegian.




3. Use supporting tools to assess your website

Numerous tools exist out there specifically (and indirectly) developed to help you discover content on your web page that does not conform to WCAG 2.1. For instance, the organization behind the guidelines - W3C - provides an extensive list of evaluation tools. I have used these a lot myself:

WAVE’s plugin for Chrome and Firefox and W3C’s validator, which helps you discover lines of HTML code that should be corrected or improved.

This color contrast checker, where you can fill in your web page's URL or color hex-codes to see whether they conform to three different success criteria.

VoiceOver - my Mac’s built-in screen reader - which helps me test content from the perspective of e.g. blind or visually impaired users.

This line-height adjuster for Chrome that specifically helps you test parts of success criterion “1.4.12 - Text Spacing”.




4. Seek to empathize with your disabled users

Empathy - the ability to understand another person's feelings and subjective experiences - is usually a crucial part of user insight. During a busy project with limited time and resources, it can be difficult to locate users who represent the diversity of disabilities you need to account for when practicing accessible design. However, you can try to put yourself in their shoes through some simple measures. To empathize with your blind or visually impaired users, you can, for instance, try to access and operate your web page while blindfolded and solely using a screen-reader and keyboard to navigate; at 200% magnification; or in black-and-white mode.

The essence of these examples is that you should try to put yourself in the position of others unlike yourself. If some content on your web page is inoperable, incomprehensible, or inaccessible when you do so, your web page is not universally designed. And if that’s the case, your newly gained empathy will make it apparent how frustrating it can be to operate a web page that is not adapted to your needs.

Some final words

Stay strong, fellow UXer. Accessibility and WCAG 2.1 may seem overwhelming, but essentially, it helps you become a better designer. You don’t need to become an expert in the field, but by understanding the main principles of web accessibility, you can advocate the inclusion of universal design in your day to day work life. Good luck and have a lovely December!





Accessibility: One web to include 'em all

Content management done the right way 🤷‍♂️

So you have an idea of an application and just started with your project. You need some content, and because you think a CMS (Content Management System) is overkill, you want to keep it simple and create some configuration with content which is imported into your app. The data is used to present some functionality in your app, for example display restaurants, blog post or whatever.

In the beginning this approach is awesome! The application is up and running in no time, so you go on to the next feature and keep adding data to your setup. The amount of content increases and before you know it, you are stuck in content management hell.

Sanity may be the tool and the backend you need to rescue your project. It is a headless CMS, which means it only cares about storing and managing your content while you can focus on the implementation of the view of your application. Sanity has very good documentation and has implemented their own query language to help grabbing the correct content for your feature.

Define your data model

Sanity is configured in a matter of minutes. First register your account here(or with the CLI) and proceed with the following command:

Run through the simple guide, once completed your «backend» is configured and the output should be somewhat similar to this:

The directory created contains configuration for your data and the complete configuration is a set of schemas defining your data fields. The basic schema contains the following properties:

The types you define will create a schema and definition of your data model. If we were to proceed with the restaurant case we would probably start of with a type something like this:

This document contains three fields - the name, address and type of restaurant. This is not so interesting so we want to add menu items to the document. Sanity comes with many predefined schema types, but a menu type is not present. However, we are able to create our own types, so we go ahead defining our menu type:

We have now defined a complex schema type with Sanity’s predefined types and this becomes very powerful when we want to modell the «world» we are describing.

Use your data model

Sanity has implemented a very nice client library that we can utilize in frontend apps. It is a promise based fetch library which enables you to grab content with their query language groq. Let's use Sanity's examples with our restaurant model in mind and create a custom hook with react's hook api.

The hook is called with the consumers query and the content is returned. A typical query can be can be:

This query fetches the last 10 restaurants created with the time of creation, an id, the name and all menu categories with their content. We have to specify what data we want from the inner data model, hence "menu_categories": *[_type == 'category']} which means, give me all fields within menu_categories with type category.

Key takeaways

Minimal setup, fast and easy to use.

The way schema is implemented lets the consumer define the level of complexity required for the use-case and offers many predefined types.

Non-technical people can easily manage content with Sanity's studio.

Managing content with Sanity

Over the years I've seen (and indeed written) quite a lot of horrible CSS, and I want to take a moment to share some of the rules and principles I try to follow when I write and teach CSS in order to keep the code as clean and maintainable as possible.

In this post, I'll go through some general tips before I'll get into some more specific tips in tomorrow's post. Let's go!

Quick disclaimer: It is generally easier to keep your CSS clean when you are writing CSS-in-JS as many of us do these days. That means that some of these tips might not apply if you have already left external style sheets behind. However, even with CSS-in-JS there are still good and bad ways to write your styling, and I am here to help you avoid a few pitfalls, at least.

Clean CSS comes from clean HTML

The times I've really struggled with CSS have been the times I've had to fight bad markup. One of the world's hardest problems, vertically centering something on a web page, is basically impossible if the HTML is a jumbled mess. This (along with the rest of this guide) might seem obvious, but I've had to repeat it a lot of times over the years, so here we go again: Elements that should be styled together, should be placed in the same component. You can, and should, think of HTML components as boxes, and vertically or horizontally aligning to elements that are in separate boxes is a surefire recipe for a bad day's work. A lot of terrible CSS – and headaches – disappear when the markup actually plays along with what you are trying to achieve. I always start any CSS task by considering the HTML and I usually don't write a single line of styling until the markup makes sense.

Use CSS for what it's good for, and nothing else

If you are intent on having a bad time, you can use CSS for almost whatever you want to these days (https://www.sitepoint.com/css3-pong-insane-things-to-do-with-css/). In general, try and use CSS for as much of the actual visual layout as possible. Period. For example, it might be tempting to write some JavaScript to count the number of elements you have in a list and add different classes or styling based on the number of existing elements. Generally, you shouldn't. Making an element look differently based on the number of elements is purely a visual decision, and that means that it should be the responsibility of the CSS. As soon as you start to use JS for styling, you make it harder to locate that styling when someone needs to find it. You should only manipulate styling directly from JS when there really is no other way to accomplish the design you want.

Read up on display and position

This might seem like a specific tip. In my experience, however, these properties are really some of the most general knowledge you can have when understanding and writing CSS. Surprisingly, quite a few developers lack a proper grasp of these concepts. Have you ever wondered why the element you are styling doesn't care about the height or width you are trying to give it? The element is probably inline. Why is that element you added with position: absolute suddenly all the way over in the corner of the screen? You probably forgot to position its ancestor. This stuff might seem daunting at first, but it's not rocket science, and it has made working with CSS that much more fun for me. I'm guessing it will for you too.

My all-time favorite site for learning a few CSS basics is this little beauty which I've shared countless times over the years: http://learnlayout.com/ It might seem a bit dated in the way it talks about supporting IE6 and presents inline-block as a new thing, but that only goes to prove the point that position and display is really something timeless that everyone who writes CSS should know. I can guarantee that the concepts are not going anywhere anytime soon, so go ahead and read it. You'll thank me later.

Write as little CSS as possible

CSS is notoriously hard to delete from big projects since you don't get any help out of the box with knowing where it is used and if it has any effect at all. In that way, it is even more important with CSS than other code to be really careful about not writing any unnecessary code. It is way easier and cheaper to remove it before you merge your PR. Before you are done with a feature, you should be ruthless about your newly written CSS and try to consider if every line you have written is really necessary. As soon as the code is merged, every developer – even you, the original author – starts thinking of it in this way: "I am not sure if I can delete this or not. It might be used somewhere by someone or have an effect I am just not understanding. Better leave it in." Say hello to bloated, horrible styling. You'll probably spend a lot of time together.

Along the same line of making something easy to delete, try to avoid creating class names in the code by manipulating strings. This makes it really hard to search for the class names to discover where, and if, it is actually used. Write the full class name whenever you use one.

A stellar example of unnecessary styling is repeating the default properties of an element. There is rarely a reason to specify that a div is display: block or scatter the code with position: static. All that tells me is that you might not know what you're doing.

Speaking of knowing what you are doing: Please don't just try adding some properties willy-nilly and seeing if it works. This shouldn't even be necessary to write, but somehow it seems that the mere act of opening up a stylesheet sometimes makes otherwise responsible developers throw all that responsibility out the window and just cram properties into the CSS until it somehow works. This is also a great way to end up with a lot of styling that really hurts the maintainability of your application. Please try to understand why the web site looks the way it does before you write anything. It will make it a lot more fun to write CSS. I pinky swear.

In conclusion

That was my general tips/ramblings about CSS. I hope you learned something. Follow along tomorrow for some more nitty-gritty tips with code examples.

Clean CSS - rambling edition

Machine learning algorithms are helping us predict the future by learning patterns from past observations. How does this effect the way we assess our models?

Go to Google Translate and type in the sentence “He is a nurse, she is a doctor”. If you translate this sentence into Hungarian and then back to English, the translation reads “She is a nurse, she is a doctor”. This would probably enrage everyone who is concerned with women’s rights and equal opportunities in the workplace. The same thing happens if you translate the sentence into Finnish or Estonian. Also, the Finnish language has the gender-neutral pronoun hän that can mean either he or she. The screenshot below exemplifies how Google Translate chooses to interpret this pronoun in two different cases.

This phenomenon is known as gender bias. Could it be that Google secretly is anti-feminist or is it simply that the translation algorithm is not good enough?

There are several ways to determine the accuracy of our machine learning models. Among the most popular is R-squared, which is a statistical measure of how close the data are to the fitted regression line. It is always a number between 0 and 1 and indicates the proportion of total variability that is explained by our model. A high number usually indicates a good fit for our model. Sometimes, however it is not enough to ensure a good model, we also need to consider the data that we feed into the model as well.

In our example from Google Translate we experienced a bias stemming from the training data. The machine learning model, or any other predictive model for that matter, is trying to tell us what will happen next based on what has already happened. This time the algorithm was trained using data or literature in which the word she occurred in relation to words like nanny and nurse more often then the word he did. Historically women have been overrepresented in these professions and this is reflected in the available literature. Therefore, when trying to predict or translate our sentence the chance of placing the feminine pronoun with these words is more likely to reflect the pattern observed in the training data. The problem can be attributed to a biased training set that is not representative for the predictions we attempt to make and we get the results observed above regardless of how good the model is by standard measures.

Biases are very hard to eliminate completely when we use historical data in our models, but there are a few simple things that we as data scientist can do to reduce them:

Be aware of the biases and thoroughly think through how your models are being used. Acknowledging the shortcomings of the historical data reduces the chances of misinterpreting the results.

Ensure the training set is as representative as possible. Our models are rarely universally applicable to datasets.

Split your data into cohorts. This ensures that your model is more likely to be unbiased for the range of data that it represents.

Have an unbiased Christmas!

How good is a model based on historical data?

Feature toggling, or feature flags, is a fairly well known concept in the world of modern system development. It provides the foundation for separating launching a feature from the physical deployment of code, enabling things like A/B testing, piloting and a faster development process. With a few clicks, you can get going with a streamlined feature toggling setup in no time using hosted cloud services.

The concept of feature toggling is pretty straightforward: Evaluating a boolean expression decides whether some (in most cases) new code should be executed or if we should go with the existing old code:

Simple as it is, this technique essentially opens the door for having code that is unused, or even still a work in progress as part of the production code. In many cases, this is an essential tool to avoid long living feature branches and go for trunk-based development - a key part of succeeding in continuous delivery. If that’s not enough, adding some smartness to the toggle evaluation helps with things like A/B testing, pilot testing / canary releases and gradual rollouts.

A dead simple toggle may be implemented as

This will hide the new stuff until ready for launch, but it will require a (really, really small) commit, build and deploy to do so. And it does not allow for configuring different setup in different environments, i.e. running the new stuff in a test environment and not in production – at least not in the same version of the code base.

This minor adjustment gives the magic touch. Now, we have the flexibility to evaluate the toggle in any way we see fit, by changing the implementation of the evaluation function. The toggle may be simply bound to some config setting, i.e. for turning on for test but off for prod - a frequently used, and in many cases sufficient, approach. But the function may also be true for specific users, a certain percent of users, certain devices or whatnot.

However, implementing rules like these at every point of evaluation in every app may quickly turn into a mess of many toggles with lots of duplicated, or slightly different, implementations – as well as being boring and cumbersome. When reaching that point, it may be time to look out for help. There are quite a few libraries or services ready to use. The organisation where I work have been using Unleash for the last year and a half, where it has rapidly become a core tool for many dev teams – so I’ll use that as an example.

Unleash allows you to define your toggles in a dedicated, central system, using a nice and simple web UI. You define your toggle with the name of your choice, and assigns it one or more evaluation strategies. These strategies define how the toggle should be evaluated, and any parameters it needs for doing so. Unleash comes with a set of pre-defined strategies, like

The simple, but handy default strategy – either on or off

userWithId - on for specific users, configured with user ids for the users in question.

gradualRolloutUserId - on for a specific percentage of users (based on hashing the user id)

gradualRolloutSessionId – as above, but based on a session cookie (handy for systems without login)

In addition to the built-in strategies, you can easily define your own, like turning on for certain environments (i.e. test), for people at a certain location or any other criteria that you’re able to evaluate. Finally, a toggle can use a combination of strategies, like “on for a certain percentage of users, plus always on for user a and b”.

There is an online demo of unleash available if you want to check it out. 

Unleash provides client libraries for various languages, to use in your app’s code. This is where the actual evaluation of the toggles will take place, according to the defined strategies. The built-in strategies comes with the library, but in many cases you’ll have to pass some contextual information for it to work (i.e. the id of the logged in user for the userWithId strategy.) For your custom strategies, you’ll have to provide the entire evaluation implementation. At the point of evaluation, your code will be quite simple, like

Communication between the client (your app) and the unleash server is asynchronous, meaning that the toggles have minimal effect on performance (unless the evaluation itself is slow), and that your app will still work if you lose connection to the unleash server. The client library caches the toggle strategies and settings. Evaluating a toggle that is not yet defined, will be false.

The client also reports metrics back to the unleash admin app, where you can see the number of times a certain toggle have been evaluated true or false within the last hour, and which apps that use each toggle.

Wrapping up, feature toggling is first and foremost an enabler for getting code into production fast, avoiding long lasting feature branches and increasing speed. Additionally, it provides lots of flexibility of how to launch and test new features, being it in the dedicated test environment or in production itself.

If you’re ready to take the step into the modern world of flexible feature toggling, Unleash is available as a hosted service at unleash-hosted.com. However, you can host it yourself for free if you’d like. Or, you might want to check out other hosted services in the feature toggle space, like LaunchDarkly, FeatureFlow or Feature Ops.

Now, go and enable the speed toggle for your team :)

Unleashing speed and flexibility from the cloud

If you have read all blog post until now, you might have come to the realization that immutability is a core concept in functional programming. In this blog post, we will take a look at a pattern that can help us update and extract data from large immutable data structures. As mentioned in a previous blog post, updating immutable data is done by creating an entirely new copy of the data structure with some part of the data with new values. For shallow structures, this is not really an issue, at least for languages that has a syntax for copying values. Take the following record as an example, written in typescript:

After creating this object, I notice I made a typo in the name, which is actually Simen. We fix this with a simple spread on the previous user object:

Now, what if the user was a part of the current login context in the application, which again is a part of the application model?

Easy! We just have to spread the model, spread the login context, and spread the user with the updated name value.

Cumbersome, right? Imagine having to do this every time we need to update a value.

Lenses

Lenses is part of a group of patterns used to abstract away the action of updating and looking through large immutable data structures. A lens – or a functional reference – is essentially a focus into a data structure, abstracting away how deep a structure is by pointing right at the requested field. Let us look at the signature of a lens:

It is a pair of two functions, a getter and a setter. The getter is a way to extract a subpart B from a larger structure A. The setter defines a way to replace the subpart B in the larger structure A.

A lens made to focus on the name field from the perspective of the model, could look something like this:

Taking the example from earlier, updating our entire model just got a whole lot simpler

We still do the exact same thing as before, only we have centralized the knowledge of how the model is constructed into the lens. This abstraction itself is nice, but is it not just a setter? Well, yes. What if we want to make setters for all the values of User, would we not have to duplicate much of the setters again and again? This is where the true value of lenses come to light. Lenses have the ability to compose with each other. This essentially means that two lenses A => B and B => C together can make up the lens A => C.

Instead of creating a lens focusing us from the model straight to the name of the user, we create a set of lenses:

For reference, we include the compose function. It is a function that takes two chaining lenses as parameters, merging them together. A key point to notice here is that the resulting set of functions are also a lens, enabling composed lenses to continue creating new lenses.

We now have lenses that together can make up to the following focus: (Model => LoginContext), (LoginContext => User) and (User => Name) Composing these together, we get (Model => LoginContext => User => Name). Since lenses compose, we can therefore create a lens Model => Name from those smaller lenses.

Why use lenses?

Lenses abstract away the operation of updating and extracting values from deep immutable data structures. This means that – in theory – consumers that solely use lenses to work on some data structure, has to know very little about how the model is actually structured. The impact of such an abstraction is greatest when returning to refactor some part of the model, where – in a dream world – only the lenses has to be changed. Without composition in such a pattern, you would find yourself duplicating the same selectors and setters again and again from different perspectives. Such qualities are often present in functional patterns, but are not exclusive to functional programming languages. Take TypeScript for example, it is not a functional programming language, but the lens pattern can be used quite effectively. There are in general many concepts that can be learned from functional to be adopted to other paradigms, which alone should inspire everyone to learn functional programming!

The Lens Pattern in TypeScript

Some grocery stores in Norway use fingerprints for verifying the users age when buying an item that has age-restrictions. The security of this solution gets a thumb up 👍

Every week we read about a new breach of personal information. Strong, unique passwords have become a necessity because the companies we trust with our information keep losing them all the time. In contrast to the way mobile devices use biometrics for faster access to a phone, some retail stores in Norway has found a refreshing new way to use fingerprints as identification.

In Norway the self-checkout option at grocery stores are favoured by the younger generation, often seen in a rush, and not buying more than a few things. But when buying items restricted by age, such as alcohol, non-prescription drugs, and tobacco there is a need for verification of the customers age.

The way to use a self-checkout system to buy age restricted items are as follows:

The customer scan all their groceries.

The user is prompted if he/she wish to store their fingerprint for convenience for the next time.

If the system detects an item that has an age restriction the customer is prompted for verification.

If the user has a fingerprint stored at that store, he or she can scan their fingerprint to verify their age.

Else a cashier will rush over to manually verify their ID.

The user is prompted if he/she wish to store their fingerprint for convenience for the next time.

The user pays the total sum to complete their purchase

In most cases I would be extremely critical to letting a grocery store collect my personal information, let alone store my biometric data. As early as in 2012 they asked the Norwegian body for digital privacy (Datatilsynet) for permission to store biometric data about their customers. The answer back then was a hard nope.

So how did they get approval? They do not store any personal information alongside the fingerprint. The fingerprint is only stored in the database if the person is over 18 years, and verified by a cashier. The fingerprint is unique to that store, and not usable in other stores, even though they are part of the same chain.

If the system storing the biometric data is hacked, and someone gets away with the database containing the digital representation of fingerprints, they can’t link that fingerprint to an individual, which is what we want from a security perspective.

One thing you should check before signing up for this service is however that the store does not connect your fingerprint to the card you payed with. Because that would defeat the whole purpose of the architecture.

Here, have my biometric data, I don´t care. 

Submit four pull requests in October, get a t-shirt. That’s the TL;DR for Hacktoberfest. It’s basically a month-long global hackathon that serves as a celebration of open source and its community. Did you get your t-shirt yet?

It sounds almost silly. You contribute to some random projects on GitHub and someone sends you a t-shirt. But this simple challenge is the root of a massive movement that closes thousands of GitHub issues around the globe. This year’s Hacktoberfest was the sixth to be held, and throughout October more than 483,000 pull requests were submitted to more than 150,000 repositories. People from 143 different countries participated! It’s the greatest Hacktoberfest ever and you can read the recap here.

If you did not participate this year, you should next year. Not only to win a piece of short-sleeved garment, but to help change the world – one pull request at a time.

Participating

It's easy to sign up for the Hacktoberfest on the primary website, which usually opens some days before October 1st. You sign up with your GitHub credentials, and after that, it’s coding time.

Finding projects to contribute to is made easy by the use of labels. Project maintainers are encouraged to label their issues with "hacktoberfest" to attract hungry hackers. There are also other useful labels like "help wanted" and "good first issue" that are commonly used to indicate good starter issues. Use GitHub’s search engine to filter on these kinds of issues, and hopefully you will soon find a fitting project you can contribute to. And here’s a pro tip for you: If you find an issue you really want to take a go at, say so in a comment. Hacktoberfest is so popular that other people might already be hacking away on "your" issue when you see it. So claiming it is not a bad idea.

But October is… 10 months away! :(

It’s quite a while until we can indulge ourselves in another Hacktoberfest. But that doesn’t mean we cannot contribute to open source today! Use the labels on GitHub, check out your favorite open source projects and see if they want help, or create something yourself. You might not get a t-shirt, but contributing to open source projects is an awarding experience nevertheless. Good luck and have fun!

Hacktoberfest

50 years ago humans managed to land on the moon using a guidance computer with no more than 4KB RAM. During these 50 years memory has become a lot cheaper, and the need for writing memory efficient code is not that critical anymore. Today, your simplest Hello World Spring Boot app will probably use at least 100MB RAM. But still, sometimes, typically when we realize that we have to provide even more memory for an application, we can not help but wonder: Why in the world should this app need so much memory?!

At least a part of the answer to that question lies within our code. Sometimes we write applications that use far more memory than necessary just because we are not aware of the hidden memory costs of our coding choices. Let us look at a few examples.

IO operations with InputStreams and OutputStreams

Let's say you need to read a file, and do something with each line. If you read the file like this:

Then the String s will contain the entire file, meaning that you now hold the entire file in memory. For smaller files that are read once this is usually not a problem, but if you are reading a large file, or if you are processing files that are received through an API, this way of reading the contents will probably result in an OutOfMemory exception, or at least excessive use of memory. A better way to read the file is like this:

Now you will read and process one line at a time, which means that you only keep that one line in memory at a time.

When writing to a file using an OutputStream you may encounter the same memory problem, so you should also process and write one line at a time.

See https://www.baeldung.com/java-read-lines-large-file for more ways to read a file efficiently.

Tightening up the code

Each object you create will require some memory, and when it is no longer used the garbage collector will have to clean it up. Make sure you don't create objects that you don't really need. This sounds obvious, but in some cases we are creating objects without really thinking about it. For instance, when using the + operation to add something to a String, we are creating a StringBuilder object under the hood. When adding to a String using + repeatedly, like in the inefficient InputStream example above, we are actually creating a new StringBuilder object for each time. When manipulating Strings it is better to use a StringBuilder object in the first place so that you can reuse it:

Lambdas are another example. When using a Lambda for the first time, what actually happens is that a new class representing the Lambda is created by the JVM. The next time the Lambda is used, this class will be reused, but if you use your Lambda only once, this is quite costly.

You should also use primitives instead of objects whenever possible, e.g. int is preferable to Integer as it requires less memory.

And, as always, clean up unnecessary method calls.

Java Streams

There has been a lot of debate concerning the performance of Java Streams, that were introduced in Java 8, compared to more traditional for and for-each loops. Several experiments have proven streams to be slower and more resource consuming than traditional loops, but they have received a lot of criticism for writing the code using streams in a poorly optimized way. The conclusion regarding streams and performance seems to be that streams are not necessarily performing worse than traditional loops, but you should pay some attention when writing the code to avoid for instance resource demanding auto-boxing and Lambdas that are used just a few times.

Hidden memory costs

Dette er del 3 av 6 kaffeprater om Smidig organisering. Trenger vi ledere når vi har myndiggjorte team som jobber kundeorientert? Hva blir rollen til lederne og hvordan utøver de ledelse nå? Hvordan bygges tillit?

Smidig organisering, del 3: Retningsgivende ledelse og trenger vi ledere fremover?

Yesterday (the non-workshop part of) the third edition of KotlinConf kicked off. This year the conference is held in Copenhagen, the capital of Denmark. While a visit to "Kongens by" is nice in any circumstance, a December visit with a taste of Kotlin is almost perfect.

The venue

This years venue is the Bella Conference Center (pictured), a quick metro ride from central Copenhagen. While perhaps not as charming as last years venue (Beurs van Berlage in Amsterdam), a larger venue may be fitting to the ever growing Kotlin community.

The registration went smoothly, and after leaving our coats in the cloakroom, we went into the huge conference hall. While at first sight it felt a little crowded around the food and drink stations, as we moved further from the entrance the crowds thinned and we could easily help ourselves to some breakfast snacks and a much needed cup of coffee.

Talks

As last year, the conference kicked off with a keynote. Andrey Breslav presented some information on the recent developments and near future of Kotlin, 1.4 is on it's way! After the keynote, a long day filled with many excellent talks started, some of which we will present here.

Putting Down the Golden Hammer

With great syntax comes great responsibility. Or, at least, with great syntax comes the temptation to use it everywhere, even places where you maybe shouldn't. In this talk Huyen Tue Dao shares with us some examples of going to far with the Kotlin syntax.

Keep using the great features of Kotlin, but always make the intention of your code as clear as possible, even though that means writing !! or dropping an apply. We can wholeheartedly recommend this talk for both experienced and new Kotlin developers.

Kotless

A fantastic talk about Kotless, a serverless framework, by Vladislav Tankov. The talk started with a short introduction to serverless and continued on about some of the issues with it. In theory serverless sounds really nice, as you don't have to deal with all the server infrastructure. In practice though it's slightly more complex. A simple serverless app often requires 500+ lines of infrastructure configuration that you as a developer have to deal with. Shouldn't it and couldn't it be done much easier?

The answer is yes, and Kotless. Kotless introspects your code, generates the configuration for you and makes serverless simple. It currently supports AWS and looks really promising.

Kotlin for science

Simulations is an important part of modern natural science, especially for disciplines where experiments are time consuming and expensive. In this talk, by particle physicist Alexander Nozik, we hear about the challenges scientists meet when programming and how Kotlin can present solutions to them.

What strengths does Kotlin have compared to the more common programming languages used in science? Kotlin is expressive and safe enough to be used by people with varying programming experience. Perhaps as opposed to certain other languages, where higher experience is needed to easily avoid errors. Extensions and scoped functions can be very helpful both in this regard and with regards to performance. As for performance, it is often good enough (both for Java and Kotlin), and much better than the well known reputation of the slow JVM. Kotlin also has the advantage of full compatibility with Java. As for so much else, coroutines is a fantastic tool for science, and kotlin/js can be great for creating visualizations.

However, there are some issues with Kotlin in science as well. There are still certain performance issues and also a lack of easy access to certain scientific tools. But if these problems can be solved, Kotlin may very well be the next big programming language used for science.

Party

As we're writing this the first day is coming to an end, and we are waiting for a new product announcement from JetBrains. Then it's time to party! Skål.kt :beers:

6-Dec

Today's posts