The JavaScript Advent Calendar is coming to an end. For each day in December, we've written an article on a subject that matters to us. If you want to keep learning about the language and the web itself, here's four exciting web proposals you might want to play with during the holidays!

💡 A web proposal is the specification of a feature, API or any other addition to the official web standards, governed by the World Wide Web Consortium (W3C). These additions are typically developed in the open by volunteers and large browser vendors such as Apple, Google, Microsoft and Mozilla.

🛠 As a result, browsers such as Chrome and Firefox often let you try new features before they're ready to go public. In Chrome, you can enable experimental features by navigating to chrome://flags/#enable-experimental-web-platform-features and enabling the flag. Just make sure you're on the latest version!

Shape Detection

A few years ago, I helped develop an arcade machine for a large student festival in Trondheim, Norway. The machine had a camera that would scan for QR codes to identify the player. It ran on a Raspberry PI with a Chrome Web app, so the scanning would be implemented in JavaScript. Finding a suitable library was not an easy task. They were either slow, unstable, or unable to read the QR codes at all.

We had to go for the slow option. But soon, this and other, similar problems can be solved using the proposed Shape Detection API! While JavaScript solutions are typically heavy on the CPU, this proposal lets the browser access specialized hardware modules and SDKs that support both efficient scanning of both QR codes and traditional barcodes.

In addition to QR and barcodes, the Shape Detection API lets you do text recognition and even face recognition – directly in the browser! Using the API is also quite simple. Here's an example by Cassie Evans from CSSCamp 2019, showing how to retrieve faces from a webcam feed:

🎥 In the video, Evans demonstrates what you can do once the browser has discovered a face!

The Shape Detection API is openly available on GitHub. Take a look for current browser and device support, examples and more!

Progressive Web Apps

Progressive Web Apps (PWAs) erase the boundaries between apps that live in your browser, and native apps you install on your OS. PWAs are actually a combination of at least two, new web proposals; The Web App Manifest lets you define a name, icon and colors for your app, and enables the app to be installed locally on the user's device. Using Service Workers, the app can work without a stable internet connection and send push notifications using the Push API.

PWAs have been around for a while, but the API support still varies a bit across browsers and devices. Creating a PWA from scratch is also a daunting task, given the long checklist of features to keep in mind. However, frameworks such as Gatsby for React or Gridsome for Vue makes the process as easy as installing a handful of plugins.

🎥 If you want to build a PWA, I recommend watching Maximiliano Firtman's talk from JSConf EU 2019 with an updated perspective on the matter.

Native File System

This is a big one. A team from Google is working on a Native File System API for the browser. Currently, web applications are very limited in terms of reading and writing files to your local storage. When they want to read a file, the user must manually choose the file using a native file explorer. Saving works in a similar fashion. This quickly becomes tedious when dealing with frequent file operations or handling multiple files simultaneously.

Using the Native File System API, the browser can (if given permission) gain access to local files like any other, native application. This opens a lot of possibilities for the Web. Combined with features of a Progressive Web App, there may be less need for bundlers such as Electron, which powers VSCode, Slack, Discord and many other desktop apps. Certainly an opportunity for ChromeOS, which mainly relies on web applications. But only time will show if the public wants this merge of the desktop and web, or if they want the browser to remain a separate, sandboxed corner of their operating system.

🚀 See it for yourself in this interactive demo, or read a thorough introduction at web.dev.

Picture-in-Picture

I found this while watching NRK TV, a streaming platform by the Norwegian, government-owned broadcasting company. While watching a video, I discovered a button that made it pop out of the browser, appearing in a stand-alone, sleek and resizable window.

As I later discovered, this is an implementation of the Picture-in-Picture API. While the proposal is mainly available in Chrome, many other browsers support a similar, proprietary implementation. Either way, this API can often be utilized even if the streaming platform has not yet implemented it – using a little JavaScript.

Assuming the streaming site contains an HTML5 video-tag, the following one-liner should drag the feed into a picture-in-picture window:

Try it with the previousvideos – just paste the snippet into your console and press enter!

Wrapping it up

These are all relatively new web proposals, so don't assume they're available to users of your app just yet. I recommend checking the amazing caniuse.com for the current implementation status across all modern browsers. In any case, you can try experimenting locally on your own!

From all the JavaScript nerds here at Bekk, thank you for staying this far! It's been lovely to serve you articles every day this December. If you want to learn the nitty gritty of how these calendars were all made, stay tuned for a special article on bekk.christmas.

Until then – merry Christmas! 🎄🎅🏻

Four Exciting Web Proposals

Hva snakket vi om for 20 år siden? Hva fikk oss til å snakke om det og starte Bekk? Har det skjedd noe ila. de siste 20 årene og hvordan ser de neste 20 ut? Dagens kaffepratere er Olav Folkestad, Reidar Sande, Harald Krogh, Pia Solheim og Moquan Chen.

Historien om Bekk sin fødsel. Hva snakket vi om for 20 år siden?

You are now reading the last of our 24 blog posts on functional programming. We hope you have enjoyed our functional advent calendar, and maybe even learned something new. We have tried to keep a balance between introductory and slightly more advanced posts to make sure most people can find something interesting to read. Believe me – this ain’t as easy as it sounds!

This last post is a bit different from the 23 previous ones. There will not be a single theme this time. Instead, we have collected some of the presentations on functional programming that we have enjoyed the most, and remember the best. They have different themes, but are all enjoyable and enlightning. You might have seen some of them before, but hopefully you’ll find at least one you haven’t.

Happy holidays, thanks for joining us, and enjoy the talks!

Simple Made Easy – Rich Hickey

Link: infoq.com/presentations/Simple-Made-Easy

Length: 60 minutes

Rich Hickey emphasizes simplicity’s virtues over easiness’, showing that while many choose easiness they may end up with complexity, and the better way is to choose easiness along the simplicity path.

Propositions as Types – Philip Wadler

Link: youtu.be/IOiZatlZtGU

Length: 40 minutes

The principle of Propositions as Types links logic to computation. At first sight it appears to be a simple coincidence---almost a pun---but it turns out to be remarkably robust, inspiring the design of theorem provers and programming languages, and continuing to influence the forefronts of computing. Propositions as Types has many names and many origins, and is a notion with depth, breadth, and mystery. Learn why functional programming is (and is not) the universal programming language.

Functional Principles for Object Oriented developers – Jessica Kerr

Link: infoq.com/presentations/fp-principles-oop

Length: 60 minutes

How is an expert OO developer to improve on their craft? By learning from other paradigms! These six principles of the functional style also apply to OO. Some are part of good practice already; some express patterns both old and new; all give us different ways of thinking about problems. For developers without expertise in functional programming, examples in Java and C# provide new techniques for writing clear, quality code.

Parsing lexical ambiguity with Elm and expressive types – Emma Tsujimoto Cunningham

Link: youtu.be/sLh-7E-iOto

Length: 20 minutes

Parsing lexical ambiguity in natural language has always been a tricky endeavor, both from the perspective of formal linguistics as well as natural language processing. In this talk, we'll consider one of the canonical examples from linguistics, the "Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo." sentence from Dmitri Borgmann's 1967 "Beyond Language: Adventures in Word and Thought."

The Power of Composition – Scott Wlaschin

Link: vimeo.com/254635723

Length: 60 minutes

Composition is a fundamental principle of functional programming, but how is it different from an object-oriented approach, and how do you use it in practice? In this talk for beginners, we'll start by going over the basic concepts of functional programming, and then look at some different ways that composition can be used to build large things from small things. After that, we'll see how composition is used in practice, beginning with a simple FizzBuzz example, and ending with a complete (object-free!) web application.

Why Isn't Functional Programming the Norm? – Richard Feldman

Link: youtu.be/QyJZzq0v7Z4

Length: 25 minutes

Richard Feldman explores the reason why functional programming hasn’t taken over despite its advantages.

Functional Composition – Chris Ford

Link: youtu.be/jyNqHsN3pEc

Length: 40 minutes

Chris Ford demonstrates that music theory can be delightfully represented as code. He shows how to make music starting with the basic building block of sound, the sine wave, and gradually accumulates abstractions culminating in a canon by Johann Sebastian Bach. Examples will be live-coded in Clojure.

Communicating in Types – Kris Jenkins

Link: youtu.be/R2afqbzWDiU

Length: 40 minutes

Modern type systems have come a long way from the days of C and Java. Far from being nit-pickers that berate us for making mistakes, type systems like the ones found in Haskell, PureScript and Elm form a language in themselves. A language for expressing high-level ideas about our software to our colleagues and to the computer. A design language. In this talk, we'll take a look at the way the right kind of type signatures let us talk about software. We'll survey how to state our assumptions about the domain we're coding in and how each part fits together. We'll show how it can highlight problems, and surface opportunities for reuse. And most importantly, we'll see how types can help you communicate to your coworkers, and to future maintainers, with little effort. You've probably heard the phrase, "programs are meant to be read by humans and only incidentally for computers to execute." Come and see how a modern type system is about communicating ideas to humans, and only incidentally about proving correctness.

Merry Functional Christmas

Gleðileg jól! God jul! Merry Christmas! Happy holidays! Feliz navidad! Christmas eve, or julaften as we indigenous Norwegians call it, is upon us, and I have the honor of wrapping this calendar up!

The subject of today's post is typography, especially, how to implement typography in CSS how the designer wants it.

Background

In CSS, the text in a given element will sit centered within its own line-height. In the design world the line height is measured from the baseline of the text. As a result, the interfaces often deviate from the designers intentions, requiring a heap of pixel-nudging to get things to line up again.

A summary of this, and to illustrate the problem we face trying to implement designs, this video explains it clearly:

How do we solve this?

Well, facing this problem at out current client, we have a design that is really tied up to the custom font that the client is using. Nailing the typography implementation would greatly improve the design, and improve the readability.

To do this, we need to calculate some font metrics to adjust the text so it will operate on the baseline of the font itself. We need to know the "cap height", "x-height", "baseline" and "descender height".

"Cap Height" is the height of the capital letters. "Baseline" is the bottom of the letters. "X-Height" is the height of the lower case x. "Descender Height" is the height of dangling characters like y, j, p and g.

So, we needed a tool that could solve this issue for us, instead of guessing the correct margins and line-heights and other adjustments. Enter basekick. Basekick provides a mixin to handle this for us, but we needed to figure out the actual values of the font metrics to get this to work as intended. I found a codepen that halfway got us there, but the app did not provide us with everything we needed, so I improved it:

That was the first iteration. But I felt that I could do this better and more automated, so I created this codepen:

The codepen above takes screenshots, thanks to html2canvas, and then I output the screenshot to a canvas. The canvas data is then processed to find the first occurring non-white pixel, and then the last occurring non-white pixel to get the first values that is needed. And to get the last piece of the puzzle, we do the same with the lower case character "x".

The values in this file that is not in a variable, is the grid-row-span, which basically is the number of rows the font goes in the line-height. Ordinarily, the grid-row is a lesser value of 2-6pt/px, but here, we use 31px, the same as the "base" line-height.

Implementation

When all variables are found, we use the basekick mixin to make it a bit easier to apply good typography:

We then use that mixin in our stylus file:

The result

When we combine all of this, we end up with a typography as close as possible to the designer's sketches:

The result looks pretty good, and it's a bit more clear when we have line-guides to actually see the difference.

To wrap it up

In an everyday scenario, this approach might seem overkill. But this method actually bridges one of the few last gaps betwen a designer's sketch and the technical implementation of it.

It's been one hell of a ride folks. From all of us to all of you, a very merry Christmas!

Implement typography how the designer wants it

As you open the final post of this year's security.christmas, we logout of our social media accounts, shut down Slack (or mute it for a while at least) and put away our thin foil hats.

The last weeks have been hectic for everyone involved here at the Bekk Christmas Calendar Machine. The topics we have covered reflect some of the things we have been working this year and technologies we would like to spend more time learning about. We have had fun looking at alternatives to usernames and password, which there are several viable solutions to. But only time will tell which technology will, if any, be the industry standard.

Like we said last year, please spread the knowledge of security, and without sounding too touched by the holiday spirit, make it a better place. Maybe you should do like many of us in Bekk, spend the last days of the year planning how you can improve your own, and co-worker’s, awareness of the threats systems we work on face.

Gather the people that seems to care about security, and plan some company or team event. We have hosted several Capture The Flag events this year, which has been really fun, both for the organizers and the participants. But it can also be as easy as finding some videos from security conferences you can watch together and discuss if and how the topics are relevant for your team or organization.

But more importantly, use the quiet days a head of the the new year, to take a well-deserved time with your loved ones, and rest assured, the security challenges will be waiting for you on the other side of Christmas.

We hope to hear what you think about this year’s effort, if not, we look forward to presenting next year’s calendar. With hopes of a peaceful celebration, the security team at Bekk.

Merry Christmas

During my time on the React team, I’ve been lucky to see how Jordan, Sebastian, Sophie and other tenured team members approach problems. In this post, I'm distilling what I learned from them into a few high-level technical principles. These principles aren’t meant to be exhaustive. This is my personal attempt to formalize observations about how the React team operates — other team members may have different perspectives.

UI Before API

Every abstraction has its own quirks when deployed at scale. How do those quirks manifest themselves in the user interfaces? Can you tell when an app is built with a certain abstraction?

Abstractions have a direct effect on the user experiences — enabling, perpetuating, or even making some of them impossible. This is why when designing APIs, we don’t start with the abstraction itself. Instead, we start with the desired user experience, and work backwards to the abstraction.

Sometimes as we work backwards, we realize we need to change the whole approach to enable the right user experience. We can’t see that if we start with the API. So we put UI before API.

Absorb the Complexity

Making React internals simple is not a goal. We are willing to make React internals complex if that complexity lets product developers keep their code easier to understand and modify.

We want to allow the product development be decentralized and collaborative. Often, that means that we bear the brunt of centralization. React can’t be split into small simple loosely coupled modules because in order to do its job, something has to act as the coordinator. That’s what React is.

By raising the abstraction level, we make product developers more powerful. They benefit from the system as a whole having certain predictable properties. But this means that every new N+1st feature we introduce has to work well with all of the N existing features. This is why contributing new features to React is so difficult both at the design and the implementation side. This is why we don’t get many “core” open source contributions.

We absorb the complexity to stop its bleeding into the product code.

Hacks, Then Idioms

Every API creates new restrictions. Sometimes these restrictions prevent people from shipping delightful user experiences. We provide escape hatches so people can work around us where necessary.

Hacks can’t survive for long because they are fragile. Product developers then have to choose whether they prefer to take a maintenance hit by supporting the hack, or to degrade the user experience but remove the hack. Often, the user experience loses — or the hack prevents further improvements to it.

We need to allow hacks using escape hatches, and observe which hacks people put in practice. Our job is to eventually provide an idiomatic solution for hacks that exist in the name of better user experience. Sometimes, a solution might take years. We prefer a flexible hack to entrenching a poor idiom.

Enable Local Reasoning

There aren’t many things you can do in a code editor. You can add some lines or remove them. Or copy and paste something. And yet many abstractions make these basic operations difficult.

For example, MVC frameworks tend to make it unsafe to delete some part of the rendering output. This is because parents imperatively call methods on their children (which aren’t there after you removed them). By contrast, in React it’s usually safe to just delete lines of code in your render tree. This is a win.

When designing APIs, we assume the person only has local knowledge about the piece of code they’re working on. When the intended effect is local, we want to prevent surprising outcomes. For example, we usually expect adding code to be safe. We expect removing and changing code to clearly point to the whole trail of code that needs to be considered as part of this change. We can’t assume the knowledge of the whole codebase when changing a single file.

When something isn’t safe to do, we want the developer to discover the full effects of their change as early as possible. Warnings, type checks, and developer tooling can help, but they are limited by the API design. If the API is not restrictive enough, local reasoning is impossible. For example, this is why findDOMNode() is bad. It requires global knowledge.

Progressive Complexity

Some frameworks choose to have a fork in the road. They provide two ways to do something: an easy way, and a powerful way. The easy way is nice to learn, but at some point you hit a wall. When that happens, you have to undo your past work, and reimplement it differently.

We prefer that implementing a complex thing isn’t too much different in structure from implementing a simple thing. For example, we don’t offer a separate template DSL “for the simple cases” because it creates a fork in the road. We’re willing to compromise on the barrier to entry if we think you’re going to want the fully featured mechanism soon anyway.

Sometimes, the “easy way” and the “powerful way” are two different frameworks. Then you also have to rewrite. It’s nice when we can avoid that, too. For example, adding server rendering is an optimization that requires some extra effort in React but not a full-on rewrite.

Contain the Damage

Top-down tools like code budgets are important. However, over the long term, our standards will slip, features will ship under deadlines, and products will be unmaintained. When we can’t rely on everyone playing along, our role as a coordinator is to contain the damage.

If some UI code is slow or over budget, we need to do what we can to reduce its negative effects on loading time and interactions with other parts of the UI. Ideally, the developer should only “pay” for the features they use, and the user should only “pay” for the UI they interact with. Concurrent Mode features including Time Slicing and Selective Hydration are different levers to address that.

Because the library code overhead is relatively stable but the application code is unbounded, we tend to focus on containing the damage in the application code instead of the fixed cost of library code.

Trust the Theory

Sometimes, we know an approach is a dead end. Maybe it works today, but we are already aware of its limitations, and they fundamentally prevent us from achieving the desirable user experience. We pivot away from investing into such approach as soon as it’s viable to do so.

We want to avoid getting stuck in a local maxima. If another approach makes a lot more sense in theory, we’re willing to invest the effort to get there, even if it takes many years. There will be many obstacles and pragmatic compromises we might have to make to get there. But we trust that if we keep chipping away at them, eventually the theory wins.

What Are Your Team’s Principles?

These are a few fundamental principles I've observed in how we work, but I've probably missed a bunch of them. I also haven't touched on the less technical principles around how we roll out APIs, communicate changes, and so on. That could be a topic for another day.

Does your team have a set of principles? I’d love to hear about them.

This article is also published on Dan's personal blog - Overreacted.

What are the React Team Principles?

And here we are, it's Christmas! We hope you've enjoyed reading Bekk's Open source advent calendar this December.

This calendar has been part of Bekk's advent calendars, and there's 12 of them! You can find our calendars at bekk.christmas. We have a whopping 288 articles for you to enjoy during the holidays and later on 😃

Spirit of Christmas & Open source

Like the spirit of Christmas, the spirit of Open source is spending time on what you love and who you love, and giving your time to aid others in need.

I hope that this calendar and its authors has given you the inspiration and motivation to help out someone who can use your time and knowledge. Contributing might even take you to new places but you won't know until you've tried 😉

From all of us behind the Bekk Open source advent calendar to all of you, we wish you a merry Christmas and a happy new year!

Have a merry open source Christmas!

People love delightful digital experiences. It can make the dullest of tasks — an exciting experience. Like filling in forms and paying for groceries. So why aren't every digital experience delightful?

The importance of delightful UX

All good things must come to an end, and that is also true for this wonderful adventure called Bekk's Cloud Advent Calendar!

We hope you've had a good time following us here, and that you've learnt a thing or two that you didn't know already.

If you are in dire need of more reading material, wait, don't navigate away from this page, or actually, do it!N avigate away from this page right now! Weactuallydohaveelevenothercalendarsthatyoucanread! That's a total of 288 articles, including this one!

Still here? Feel inspired? Want to learn more about how you can leverage the cloud for fun and profit? Look no further!

Steal from the rich!

The three largest cloud providers, let's call them the unholy trinity, gives you credits or free tiers. Leverage that and spin up your next hobby project in a new environment!

Get your hands dirty!

Reading articles is a good way to learn, but doing things in practice is even better. Luckily there's a myriad of tutorial websites where you can tag along some instructions and do some hands-on work. My favourite is by far Qwiklabs. They have a great collection of hands-on-labs, and they spin up ephemeral accounts in the cloud so you can actually spin up stuff while learning. There's a handful of free stuff, but the real gold is of course behind the paywall. Maybe you can send a little slack message to your nearest leader, and hope that they'll approve a small learning budget in the sake of Christmas spirit?

Binge-watch some conferences!

The holidays are perfect for kicking back, grabbing a glass of hot milk (or your poison of choice) and putting on something thrilling, exciting and engaging on the television. Why not replace murder mysteries and holiday movies with some good old conference videos!

Google Cloud Next is a good one. So is AWS re:Invent. I've also heard that nothing gets you in the right holiday mood as the Azure Sessions from Microsoft Ignite.

If that feels a bit general, why not dive deep into Kubernetes and the KubeCon videos? Or why not watch something from HashiConf?

It should be enough content here to last you at least until the new year!

That sums up this advent, and on behalf of all 21 of the authors behind the Bekk Cloud Advent Calendar 2019, I wish you a happy holiday, and a fabulous new year!

Happy, Cloudy Holidays!

So, you have finally arrived at the end of our modest “tutorial” to machine learning, and may continue on the road of illumination all by yourself.

..But that doesn’t mean that you won’t have help along the way from other contributors to this vast field of knowledge, as we shall show you today: As our last act of magic, we are going to use an online, free-to-use and pre-trained model to create The 8th Christmas cookie

You may need some background information about this, as we may very well understand. The seven Christmas cookies is based upon a Norwegian Christmas tradition. Traditionally, all Norwegian households bakes these 7 different types of cakes for Christmas. These cakes therefore has a special place in the Norwegian Christmas soul. The seven Christmas cookies consists of:

Sand cake (Sandkake)

Ginger bread (Pepperkake)

Poor mans cake (Fattigmann)

Goro (Goro)

Berlin wreaths (Berlinerkranser)

Wafer biscuits (Krumkaker)

Norwegian butter cookies (Serinakaker)

Although these cakes have long traditions and has been refined for decades, we are getting tired of them and have come to the conclusion that they are rather boring (even though cookies are always yummy). We decided that as the Christmas celebration has changed a lot during the last centuries, that the cookies should follow suit: We needed a new cookie to “renew” this long tradition of Christmas cookies…And what could be more modern than using ML to create it? 😊

So, the plan is simple: based upon the existing types of Christmas cookies, let’s use machine learning to create a new one. To do this, we are going to use an open source neural network called textgenrnn.

If you want to understand the model to perfection, you should read our blog post about recurrent neural networks . Also, we are using this model to make use of transfer learning, which you can read about in this calendar (11th of December, titled "Style Transfer").\ The beauty of this model is that it is both pretrained and (even more important) it runs on Google Colab, which has more computer power than you could probably muster, which makes re-training much less time consuming.

The details surrounding this particular neural network, you are free to look up yourselves. The most important things for you to know, is that the model is pretrained on a substantial amount of text from all over the internet (generalized text) and, by transfer learning, it needs specialized text as input to alter it’s weights for our purpose. So: first of all, we need text.

Even though we have seven types of cake we could use as input. This is probably to sparse for the model to make some sense, and there are probably other types of ingredients that would fit in a Christmas cake. We (the entire team) therefore decided that everyone should contribute with the most “christmassy” cookies they knew of. The final list consisted of 25 cakes. This is probably also less data than what we ideally would like to have, but let’s see if we get some results.

The textgenrnn is quite easy to use, also for non-ml-pioneers. You can set some of the hyper-parameters for the model yourself (with some helpful advice given from the creators). And upload files with the information you want the model to train on. In our case: The 25 recipes.

Oh! One important tip from us: In this case, you would like the model to be word-level model. Instead of a character-level model. The main reason for this is that the word-level model is way easier to train, given that the predictions is based upon words in a sentence, and not the total amount of characters in the sentence. There are several other differences, but we leave it for you to discover them 😉

Setting hyper-parameters is an art, but we have done what all decent machine-learning enthusiasts usually do: We have experimented!

After some time experimenting, we set the rnn size to 256, and the number of epocs to 1000.

In the beginning, after a few number of epocs. Things look like this.

If you have used the textgenrnn yourself, you have probably noticed the temperature-schedule. This is telling us how much randomness the model adds. A low number means little randomness. If we have a small number of randomness, the model just says “2 teaspoons of cardamom” all the time – this is probably due to there being much cardamom in the cookies in our recipe-list…I guess that gives us some information at least! 😊

The recipes keep getting better, and after a whole 1000 epocs, things look promising.

The documentation for the textgenrnn clearly states that the model doesn't create perfect texts all the time, and that we may have to do some manual alteration afterwards. With that in mind, we did approximately 10 runs, and picked the cake we believed the most in. The cookie consists of





















We chose this recipe, because it has a substantial amount of dry ingredients (flour and sugar) fluid (milk, heavy cream, butter) and interesting (...yet special) taste components (raisins, cardamom, lemon and brandy). We might have to alter the amounts somewhat, but this is great base for creating a christmas cake!

We decided to see what kind of role our ingredients usually have in their recipes, and base our instructions upon that:

Flour is usually the base, and is blended with the rest of the dry ingredients, in this case sugar and cardamom, before blending with the liquids

Melted butter is typically blended with sugar before it cools. This is usually step 1.

Cream, milk and eggs are blended together with butter and sugar.

Lemon is usually added for it's peel, and the peel is added to the flour/dry ingredients

Brandy is also added together with the rest of the liquids

So, based on this information, we have decided on these instructions:

Melt butter, and blend it with the sugar. Let the mixture cool

Cream, milk, eggs and brandy is blended with the cool mixture of butter and sugar.

Peel lemons, and mix in flour, sugar, cardamom and raisins.

Without baking powder or baking soda, this is probably going to be a a non-raising cake, like gingerbread. We therefore prepare a long which we can fill with this (hopefully) amazing dough, and cook, before cutting them with a knife when is done.

So, we bought the necessary ingredients, prepared for a nice evening, and followed the recipe from above, we also cooked them on 200°C. The dough was much firmer than we thought it would be, so we took the liberty of trying out different shapes before they went in the oven.

You can see the result here:

Here you go! The 8th Christmas Cookie. We have decided to call it "Bekkstang" (A Norwegian pun on Bekk and the Norwegian translation of crowbar) and in the future, all these cookies should have an elongated shape. The taste was actually quite interesting, and we definitely consider the use of lemon peel and brandy as a stroke of genius.

You have now reached the end of our calendar, and we hope you haven't lost your appetite (no pun intended) for machine learning and it's wonders. Only your imagination sets the boundaries for what you can do with data science, as we hopefully has shown you throughout this calendar.

As a last note: There are many other elements you could have used machine learning for when creating these cookies: You could have used machine learning for the instructions, the shapes, or for the name of the cake for that matter. The problems aren't exceedingly difficult, but we wanted to show you that it doesn't take a lot amount of work to create something fun (and delicious in our case).

Godspeed on the journey ahead with machine learning and data science!

...and have a Merry, Merry Christmas from all of us at Bekk :)

The 8th Christmas cookie

The Spring @Transactional annotation and transaction management in general is perhaps one of the most misunderstood concepts of Spring and Java programming. Do you add @Transactional on every service class or API you create without putting too much thought into why you are doing it? Keep reading.

What are transactions?

A transaction is a way to wrap a number of actions that should be executed as one unit. This means that if one of the operations within your transaction fails, then all the operations, even the successful ones, must be rolled back. The most common use case for transactions is when your application is accessing a database. Transactions are very useful to prevent that any technical error may cause inconsistent data.

When adding @Transactional to a method, it does more or less the same as this piece of code:

However, @Transactional does not always work the way we think it does. First, the @Transactional annotation (along with all other Spring annotations) will only work on methods with public visibility. If you add @Transactional to a method that is package-private, the annotation will be ignored, silently. Many of us also think that the transaction will be rolled back in case of any exception. This is not true: The default behavior is that only unchecked exceptions will cause rollback.

You should also be aware that if you add @Transactional to a method that fetches an entity from the database using JPA (for instance Hibernate), and you change that entity, then the changes will be written to the database at the end of the transaction, even if you never told it to save the entity.

Distributed/global transactions

Distributed transactions means transactions that involves more than one transactional resource. The classic example is an application that reads a message from a message queue and stores it in a database. Then reading from the queue and saving the message in the database can be defined as one transaction - if writing the message to the database fails, then the message should not be considered read from the queue either. But, it's worth noting that transactions will only work with resources that are transaction-aware. Most JMS providers and datasources, and typical Java EE resources like EJBs, are transaction-aware. Changing data by using a remote REST API or a traditional webservice call, however, are not transaction-aware operations. It makes sense when we think about it: It is not possible to simply roll back a call to some remote API. Hence, adding @Transactional to a method that does webservice calls will not have any effect when it comes to rollback in case of an exception.

Recommendations

Here are a few more recommendations for using @Transactional:

@Transactional should be used on specific methods where it is actually needed, not on the entire class. This makes it easier to see which methods are meant to be executed as one transaction, and which ones are not.

You don't need @Transactional for database operations that only read from the database. If a read operation fails, there will be nothing to roll back anyway.

Avoid adding @Transactional to the top level service method or API controller method. It is better to add the @Transactional annotation to the method at the lowest possible level, usually this will be at the repository level. As the annotation will not have any effect on anything before interacting with a transaction-aware resource, it will be easier to see what is supposed to be the transaction when it is put closer to where it has an impact.

If you are using distributed transactions, pay attention to timeout values and other settings. Default values are not necessarily the right choice for your use case.

Learn more about @Transactional:

https://codete.com/blog/5-common-spring-transactional-pitfalls/

https://www.baeldung.com/jee-jta

https://www.marcobehler.com/guides/spring-transaction-management-unconventional-guide

https://docs.spring.io/spring-framework/docs/current/spring-framework-reference/data-access.html#transaction

https://www.baeldung.com/transaction-configuration-with-jpa-and-spring

@Transactional demystified

It's the 24th of December and a visit from Santa is right around the corner. The reindeer are eager and his sleigh is ready. He has determined who is naughty and who is nice.

We’ve covered a lot over the last twenty-four days! Twenty-four articles by thirteen authors. Yrjan kicked it of with getting started with Kotlin and after that the articles came in fast succession. It's time for a recap!

We’ve looked at some of the language features Kotlin has to offer. Einar explained null safety and how to avoid NullPointerExceptions, Herman showed us how to use data classes, and Øyvind told us when to when. We've looked at cute pictures of seals and Henrik wrote about sealed classes, and Yrjan extended our knowledge about extension functions. Sondre named some use cases for named and default arguments, and Vegard explained lambdas!

We’ve also taken an in-depth look at some of the features of Kotlin. Jørund explored the in’s and out’s of Kotlin, Øyvind explained the difference between lists and sequences. We’ve looked at receivers and Thomas explained when to use the reified and inline keywords.

Vetle, working in parallell, wrote a three part series about coroutines. An introduction, looking in to dispatchers, and exploring channels and flows.

Øyvind shared his experiences with going from Java to Kotlin. Vegard gave us an introduction on how to make games in Kotlin, Thomas talked about anti-bikeshedding and how to use Klint, and Fredrik wrote an in-depth guide on how to use typesafe error handling.

KotlinConf! What an amazing conference. Torbjørn covered some of the highlights of last years KotlinConf. We also recapped the first day and the second day of this years KotlinConf.

Phew! That's all from us this year, and thank you for reading. Happy holidays and who knows, maybe we'll see you again next year!

24-Dec

Today's posts