When I first came to work on the React team at Facebook, I wasn’t sure what to expect. From the outside, the React Core team seemed huge! But it turned out that folks like Eli White and Sebastian McKenzie were on React Native. And most of the famous trainers whose names spring to mind when you think of React have never been anywhere near Facebook or the Core Team. Throw in the maintainers of all of the open source libraries that enable the React community like Chakra UI and Framer Motion, and suddenly “React Core” looks like it could fill a stadium! But the reality is quite the opposite.

The React Core team is small—Sebastian Markbage, Luna Ruan, Dan Abramov, Andrew Clark, Brian Vaughn, Rick Hanlon, Seth Webster, Christine Abernathy, and myself. While Dan is the person who springs to most folks’ minds when they think of React, Sebastian is one of the last remaining “founding” team members. Though Sebastian didn’t invent React, he remains the team’s compass pointing the way forward—meticulously considering how each feature fits into the greater React story. Dan and Andrew built Redux together. Brian builds React DevTools. Rick is an advanced maths evangelist. Luna works on our data story with Relay—and is the only person on the team who majored in computer science! Christine has worked with universities to bring React Native education to the underrepresented. Seth supports us as the team’s manager. And, I work on our docs and educational materials.

But if you get to know the team, you might be surprised to learn that Andrew slays at karaoke, Seth used to be a performing musician and Brian actively records music (bonus points—his cat is also the unofficial team mascot), Rick is an active participant in social justice campaigns, Dan can dance the night away, Christine has seen every film in the Marvel Cinematic Universe, Luna shares my love of good puerh tea, and Sebastian has spent lockdown learning carpentry!

Internally at Facebook, React is a part of an ecosystem of many amazing projects that constantly influence each other, some open source, some not. Facebook’s engineering culture is like a solutions reactor. React itself was one of several libraries created internally to solve the same UI challenges. React stood out from the pack and soon burst into opensource! Now, even though React inspires other UI frameworks, libraries, and solutions at the company, the React Core team functions like an independent, lean R&D lab. While a it’s not quite the same as working with a standards body, working with React Core reminds me of working with the W3C. It is almost like a working group dedicated to making it easier for developers to write consistent, responsive, reusable UI.

When standards bodies think about introducing new specifications to the browser space, specification authors work cautiously before finalizing the API. Every API is a huge commitment for multiple browser developers to support—possibly in perpetuity. Similarly, the engineers on React Core impact many codebases with their work and must be cautious. Feature development starts with deep discussion and healthy debate. Once fleshed out, ideas get tested across Facebook’s “living lab” of a codebase. This way, every feature that makes it into an RFC (Request for Comments) has been road tested before it ever reaches the community, weeding out dead ends and bad ideas into a React junkyard few ever see. Of course, while a new spec could “break the Internet” (see also the ill-fated XHTML 2), upgrading to new React versions is entirely voluntary for maintainers. The emphasis is on ease of migration and compatibility with existing libraries.

Even though an idea may “fail” behind the scenes, it can still bear fruit in the long run. In 2015, the team tried moving React into a Worker to boost performance. It didn’t work out—passing the data back and forth had more overhead than anticipated. Although the experiment ultimately failed, it inspired something more. If components could be divided into ones that execute on the main thread and the ones that execute in a Worker, why couldn’t they split execution between the server and the browser, too? Five years later, this idea formed the basis of the Server Components proposal that the React team has announced a few days ago.

Similarly, in 2018, the React team was collaborating with the Prepack team. The hope was to automatically optimize React components by removing any calculations that can happen at the build time. This collaboration took months of effort from both teams! In the end, the tradeoff wasn’t right, and the experiment has “failed”. However, the learnings from that experiment have informed the design of Hooks later that year. It also showed that compilation alone is not enough to optimize performance. Much of the code you’d want to optimize depends on dynamic conditions that a compiler can’t possibly know — but the server can! This was another insight leading to Server Components two years later.

That’s something people don’t realize when they see Dan on stage or read Luna’s release notes about the new JSX transform: for every polished feature like Hooks that makes it into a release, there are so many that don’t even reach the RFC stage. Things are held back until they’re ready. Others are left on the cutting room floor after ruthless prioritization. Some don’t emerge until everything else has been removed.

In an industry that places so much emphasis on shipping, and shipping at ever increasing velocity, it can feel demoralizing when you can’t deliver the things you promised to yourself, to others. But a lack of motion doesn’t mean a lack of progress. There’s a time for thinking and for planning; a time for experimenting and learning. Even dead ends are worth ruling out, and attempts that aren't successful aren't failures. They are signposts, pointing to the solution.

Even if you haven’t accomplished the things you expected to at the start of this year, trust that setbacks and disruption are the norm rather than the exception, good times or bad, even on React. The React Core team places importance on doing the right thing in the right way. And sometimes, that means being patient with each other when pushing through a dip, be it emotional or technical. It means asking for assistance and second opinions rather than trying to do everything alone. It means having faith that just because you aren’t shipping, doing, releasing doesn’t mean you aren’t providing value.

Inside the React Core team

Jeg skal trene hver dag.

Jeg skal gå ned 10 kg.

Jeg skal få kjæreste.

Jeg skal bli rik.

...

Ok, det er ikke nyttår riktig enda, men siden dette er siste luke i kalenderen vår tar vi det likevel opp: Nyttårsforsetter!

Vi har alle hørt dem, hatt dem og kanskje til og med mislyktes i å nå dem. Hva kjennetegner egentlig de som lykkes med å trene hver dag, som faktisk går ned 10 kg, får kjæreste OG blir rik? Personlig har jeg en følelse av at OKR kan være en del av forklaringen. Eller i hvert fall at teknikker eller prinsipper som OKR bygger på som målstyringsverktøy, kan hjelpe oss i riktig retning.

Nyttårsaften markerer en ny tid, med blanke ark

Et nyttårsforsett er et mål man setter seg, og som er ment å gjelde fra årsskiftet. Årsskiftet kan gjerne oppfattes som en spesielt god anledning til å foreta endringer i livet. Mennesker fungerer generelt litt på den måten. Vi trenger gjerne en større endring, et tidspunkt av betydning eller andre eksterne sjokk for at vi skal endre livsstilen vår. Litt slik som korona har endret måten vi jobber på, trener på og sosialiserer oss på. Disse koronatider (som for øvrig er et begrep som ikke skal benyttes flere ganger i dette innlegget) har for mange vært det perfekte tidspunktet for å lære nye ting, utforske ukjente områder og leve på en måte som det tidligere ikke var behov for.

Korona skaper isolasjon --> Isolasjon skaper behov for luft og frihet --> Folk tilbringer mer tid i marka og ute på løpetur = Korona (sjokket) har påvirket enkeltes livsstil til å bli mer aktiv.

Litt på samme måte opplever vi kanskje årsskiftet:

Ny kalender og blanke ark --> Økt motivasjon og søkelys på endring = Endring.

Men er det bare en god anledning som skal til for at vi skal nå målene våre? I en undersøkelse gjort av den britiske psykologiprofessoren Richard Wisemen (New Year’s Resolution Project), kommer det frem at hele 88% av de som setter seg nyttårsforsett mislykkes i å nå dem! 1. januar er rundt halvparten helt sikre på at de skal nå målene sine, mens kun 12% faktisk når dem.

Hvor feiler vi?

En utfordring kan være at vi ofte tenker på nyttårsforsett som ett eller flere hårete mål. Vi snøvler ut noen målsettinger i det fyrverkeriet farger himmelen på nyttårsaften, men vi glemmer kanskje at mål sjeldent kommer alene. I tillegg til mål trenger vi gjerne også en strategi og en form for målstyring.

For hva er egentlig et hårete mål uten en definert tanke om hvordan vi skal nå det (strategien)? Og hva skal du med en strategi dersom du ikke har tenkt over hvilke verktøy du trenger for å forsikre deg om at strategien følges, at tidslinjen holdes og at vi er rute med å nå målene (målstyringen)?

Det er her jeg tror de 12% som lykkes i å nå nyttårsforsettene sine har skjønt noe som ikke alle andre tenker over. Når de snakker om nyttårsforsett så snakker de ikke bare om målene i seg selv. De snakker om en treenighet. De snakker om et mål, som støttes av en strategi samt et sett teknikker eller aktiviteter for å holde kontroll på om de er i rute til å nå målet eller ikke. Disse individene har ikke bare et mål. De har en plan for hvordan de skal nå det, og de er motiverte for å følge planen!

Dette høres kanskje ut som ufattelig mye arbeid. Det er i hvert fall slik det kan føles dersom målsettingen er stor, året er langt eller organisasjonen du jobber i er stor og kompleks. Men hvis vi bryter ned problemstillingen så er det egentlig ikke så veldig vanskelig; men det krever litt mer planlegging på forhånd. Og tro meg! Denne planleggingen sparer deg på sikt for en del tid, og til syvende og sist kan det være den avgjørende faktoren for om du når målet ditt eller ikke. Hvis du når målet er du basically «top 12%». I mine ører høres dette ut som en driver for litt herlig mestringsfølelse.

Og her kommer OKR inn i bildet

Hold on there! Hvor kommer egentlig OKR inn i bildet, og hva er egentlig denne OKR?

Les gjerne litt grundig om OKR her, i et blogginnlegg jeg skrev for en tid tilbake. Kort sagt er det et rammeverk innenfor målstyring med røtter tilbake til 60-tallets Silicon Valley. I dag er det et populært målstyringsrammevek i alt fra små start-ups til store internasjonale konsern. Rammeverket består av:

Objectives: Overordnede mål som skal sette en tydelig retning

Key results: Målbare og kvantitative måltall som indikerer om vi beveger oss i riktig retning av objectivet eller ikke.

Initiatives: Prioriterte og konkrete oppgaver som er avgjørende for å ta oss i riktig retning av objectivet.

Rammeverket legger opp til at man skal lære og iterere hyppig på hvordan det går med progresjonen mot målene våre. Det handler om å fokusere på de riktige og viktige tingene, fremfor at man skal prioritere ressursene i alle mulige retninger. I bedrifter skal det være transparent og forankret horisontalt og vertikalt, slik at alle deler av organisasjonen føler eierskap. Eierskap skaper til syvende og sist motivasjon. Motivasjon skaper handlekraft og resultater. Fokus, prioriteringer og motivasjon skal sikre at vi lykkes!

OKR + Nyttårsforsetter = Sant?

Så da er vel konklusjonen at du skal bruke OKR for å oppnå nyttårsforsettene (målene for det nye året)? Svaret er både ja og nei.

Det er jo ikke sånn at du som enkeltindivid må forankre målene dine i alle retninger. Hovedfokuset er å forankre med deg selv, noe som for så vidt kan være vanskelig nok. Det er heller ikke slik at du trenger å formulere mål, strategi og OKR i lange rapporter, investere i OKR-systemer og diskutere med kone, familie, kjæreste eller venner hver gang du «faller bakpå». La oss heller analysere OKR fra et litt mer folkelig perspektiv.

Objectives

La oss starte med objectivet. Her tror jeg mange gjør den første feilen. Du tenker at nyttårsforsettet = Målet = Objectivet. Jeg er ikke helt enig i det. Dersom man setter mål uten helt å hvite hvorfor man har dette målet, svikter gjerne den indre motivasjonen fordi innsatsen i det lange løp kan oppleves som en for stor kostnad.

Hvorfor vil du trene hver dag? Hvorfor vil du gå ned 10 kg? Hvorfor vil du få en kjæreste? Hvorfor vil du bli rik? Tenk igjennom hva som er den faktiske driveren bak de tingene du ønsker å oppnå. Jeg ønsker å trene hver dag, fordi jeg ønsker å oppleve mestringsfølelsen av å løpe maraton under 3 timer. Jeg ønsker å gå ned 10 kg, fordi jeg ønsker et lenger og bedre liv med barna mine. Jeg ønsker å få kjæreste, fordi jeg er lei av å være ensom. Jeg vil bli rik, fordi jeg vil føle meg vellykket.

Ta deg litt ekstra tid til å forstå motivasjonen din. Dersom du innser at du vil oppnå noe som du egentlig ikke bryr deg så mye om, kan du heller fokusere tiden din på noe bedre!

Key results

La oss fortsette med key results. Kall det gjerne for motiverende delmål som stykker opp store langsiktige mål i mindre biter. Dette er allerede noe du kanskje bruker til en viss grad allerede? Toppidrettsutøvere er kjent for måltall som maksimalt oksygenopptak, tid brukt på 3000 meter testløp osv. For oss normale folk er det kanskje heller snakk om at du tror du burde være på én date i måneden for å møte den rette. Kanskje gå ned 1kg i måneden, slik at du har litt slingring for å nå det årlige 10 kg målet. Eller kanskje det handler om å spise fisk 3 ganger i uken for å nå kalorimålet. Uavhengig av hvordan du gjør det, er det i hvert fall «dokumentert effekt» å dele opp store mål i mindre biter. Det føles litt mer overkommelig, og kan til syvende og sist skape mer motivasjon.

Initiatives

Til slutt må vi tenke på initiatives. Dette er jo egentlig den enkle biten. Dette handler jo bare om de konkrete og prioriterte tingene vi vet vi må gjøre for å bevege oss i retning av målet. Men her ligger kanskje også den største utfordringen. Er det ikke lav grad av gjennomføringsevne som ofte gjør at vi ikke klarer å nå målene våre? Forhåpentligvis har objectives og key results allerede gitt deg en form for indre motivasjon, men det er ikke sikkert det er nok.

Prioriteringer utheves som et viktig nøkkelord. På samme måte som store organisasjoner har vi alle begrensede ressurser. Dersom vi skal nå målene våre har vi rett og slett ikke kapasitet til å strekke til på alle arenaer. Har vi tydelige mål, ja da må vi rett og slett prioritere hverdagen slik at vi gjør de tingene som gir positiv energi mot målsettingen. Her gjelder det å legge inn støtet der det virkelig gjelder!

Målstyring er kult, både for bedrifter og for enkeltpersoner

Støtte og motivasjon fra de rundt oss kan også være avgjørende. Skap transparens ved å dele målene dine med andre. Skap forankring ved å sørge for at målene dine også kan gagne andre enn deg selv. Vær fleksibel gjennom året ditt! Blir du syk må du kanskje redusere treningen én periode og øke en annen. Blir det bryllups-helg må du kanskje tillate vektøkning én måned, mot en større vektreduksjon den neste.

Målstyring er kult, både for bedrifter og for enkeltpersoner. Man ser ofte bedrifter og enkeltpersoner med gode mål, og med en veldig tydelig uttalt strategi. Men hva er egentlig et hårete mål og en svevende strategi uten målstyringen? Prinsippene bak OKR kan være fine å ha med seg inn i 2021!

I år har jeg planer om å oppnå nyttårsforsettene mine! Bli med du også!

Lykke til! Og ikke minst, god jul og godt nyttårsforsett!

Nytt år, nye meg…med OKR?

Finally Christmas Eve! Hopefully, this calendar has made the Christmas advent a little more interesting. This year with both harde og myke pakker which Kjersti Bjelkarøy has written about. That you might have learned something new from the calendar or got some tips and tricks for yourself or your team. Maybe it has contributed to Ease the wait for Christmas Eve?

I’m not going to write a long article today, but instead, take a look back at some of the articles written. If you haven’t read it already, this might inspire you to read some in the calm days before the new year arrives (Romjulen as we call it in Norwegian).



This year’s calendar had a lot to offer!

Maybe you have used the last weeks to become a master of Figma after taking the Figma 101 that Herman Slyngstadli wrote about in So you’ve opened Figma, now what?. Or maybe you have tried one of Thea Sommersletta’s 17 activities to get to know your team remotely, to get some Christmas fun in between meetings and work.



My todo for the new year:

First of all, I’m going to take the digital Christmas clean up inspired by Anne-Berits experiences testing the email service Hey.

Then I’m going to set up a new column with UX debt so we won’t forget to fix the small, but important design-improvements often not prioritized or forgotten. This was a genius tip from Kjersti Barstad Strand in the article Et bittelite tips på bittelille julaften.

Finally, I’m going to focus a bit more on everyday inspiration after getting inspired by Espen Stavern’s article Inspirasjon: En date med et fabeldyr.

Besides that, I’m going to focus on my team and the importance of the psychology behind confidence and feeling safe with the people you work with. These are important aspects that I have learned about from Martin Skarbø Sangolt and Valentina Sørlie’s articles:\ Kan et produktteam sammenlignes med et parforhold?

Å designe en kultur med psykologisk trygghet

And I think 2021 is going to be the year where the carbon footprint of the internet will (hopefully) get more attention. Reading Håkon L'orange’s article This article emits 0.28g of CO2 every time it’s viewed… got me to understand that this also is a part of being a designer.

Huge applause to all the brilliant people that have contributed to the calendar this year and happy Christmas!

👏🎅👏🎅👏🎅👏🎅👏🎅👏🎅👏🎅👏🎅👏🎅👏🎅👏🎅👏🎅



I also want to use this opportunity to guide you into some of the other calendars that I think are relevant for designers.

First of all, innovation.christmas. This is the calendar of the Drypp podcast. You can, amongst many topics, listen to Oslo vs Silicon Valley - what's the difference? And Hva er en inkubator?

In strategy.christmas you can read about Kan gode kundeopplevelser true lønnsomheten din? Or maby get some good reading tips from Hvordan lese seg gjennom 2020 med strategibrillene på?

If you like to get better at talking in front of others you can take a look at talks.christmas. There you can find articles about How to cope with stage fright and The building blocks of compelling arguments

A Christmas Eve of Design 🎅

Thank you for joining our calendar this December. We truly hope you have gotten inspired by our reflections, ideas and learnings. Now, it's Christmas Eve, and the story of Cinderella will soon reveal itself once again. Relax.

During December, we hope to have given you a tiny spark in the back of your head. Share more with others, try presenting more, in the year to come. We promise you that it will be worth it!

And if you are afraid of presenting, know that almost every man or woman is! If you're not sure, rewind and take a stroll down memory lane and look back at our own experiences and reflections on stage fright and how you can cope with it in any of these hatches\ \ Hein in: "How to cope with stage fright"

Hein in: "How I stopped worrying and started to love holding presentations."

Jens Andreas in: "Hack your paleolithic mind to overcome stage fright "

Julia in: "Tips & tricks staying calm on stage"

Jøran in: "Fear, loathing and uneasy love: how experimentation taught me to enjoy public speaking"

Hong Nhung in: "Visualization to cope with stage fright (part 1)"

Hong Nhung in: "Visualization to cope with stage fright (part 2)"

Or just enjoy the laughs from the old classic from Don McMillan "Life After Death by PowerPoint";

Happy holidays, everyone!

Time for a New Year's resolution?

There's no doubt that we're leaving behind a challenging year, but we're alsoleavingbehindnineothergreat adventcalendars, and a podcast!

I encourage you to spend some time reading those, as they are bustling with great content.

As we wrap up our advent calendar and this year is coming to an end, it's time to have 20/20 vision on 2021.

On behalf of all of the authors behind cloud.christmas, I wish you a happy holiday and a happy new year.

Clear skies

In the first article of this year's calendar, we gave a few tips to help making your applications a bit more secure. Now, as the countdown has come to an end, and we are ready to start the Christmas holidays, we want to give you a few more.

1. Logging and monitoring

Sufficient logging and monitoring is essential to gain insight into how your app is doing out there in production. Without it, you may be under attack without even knowing it. In your logs, pay special attention to login-errors and failed validation of input. Repeated errors of this kind may indicate that someone is trying to attack you.

To be able to aggregate the information and search your logs in a useable way, you should use a centralized logging tool. An alternative is to use the so-called "ELK-stack", i.e. Elastic Search, Logstach and Kibana. You should not need to continuously read your logs manually, to detect suspicious or unexpected situations. You should instead set up some triggers for alerts. If there are many log entries of a certain kind, unusual amount of errors, and so on, an alert should be fired in a channel you have an eye on.

The amount of logging needed, and what information you should log, does not have a definitive answer. As usual, it depends... However, it is important to continuously improve and gradually learn over time. Do not log so much information that you are overwhelmed with data, but, on the other hand, you should also have enough information to properly debug and detect abnormal situations. Be careful with sensitive data!

2. Take control of your data

Often, the data you have is what makes your application an attractive target to attack. The less you know, the less tempting it will be to attack you. Take a step back and consider, is this data something I really need? And, even if you need it now you probably not need to keep it forever. Do an analysis of what data you actually have, where it is stored, and where it flows. Then, it may be easier to identify vulnerabilities and take qualified decisions.

3. Never trust input

This might seem obvious and a bit repetetive, but you should never trust input. Neither from users or external systems. Always escape request-data that you cannot trust. In frontend, use a framework or tool designed to prevent XSS. If you are talking with a relational database, you might want to use a light-weight ORM-tool. That will help you prevent SQL-injections. And, as we halve also mentioned before, know your HTTP-headers and use them correctly.

4. Don't expose unnecessary information

Your users does normally not care that you use version X of webserver Y. Nor that you have a table-column named Z in your database. So, why not keep that information for yourself? We see lot of examples where such information is exposed in error messages or stack-traces in the browser, thus presented to the users, when something goes wrong. This information does not belong there. The more information you reveal about your platform and application, the more attack vectors you introduce. Instead, keep such information in your logs and serve you users with a more decent and understandable error-message.

5. Know your platform

Whatever technology or platform you are using to build and run your application, you should invest some time to get to know it. Learn how you configure it in a proper manner, to suit your own needs. Be wary of default configuration, and remove or turn off functionality you neither need nor use.

With these words we wish you a happy and secure Christmas celebration. We hope you have enjoyed following our calendar just a much as we enjoyed creating it. From the security practice group at Bekk - Merry Christmas!

Merry Christmas!

A more hands on approach to functional programming.

This last article won’t teach you something new by itself (hey, what a selling point), but rather point you in the right direction if you want to continue your functional journey. Because, at least to me, that’s what this feels like. A journey from the imperative kingdom to the functional Nirvana! Ugh, what a cliché.. I’m really sorry, and I won’t do it again. Promise. But still, the thing is, the more I learn, the better things feel.

Which is the exact reason why we write these articles. We truly believe that by attacking problems in a declarative manner, our clients ends up with a better product. More readable code, and less time spent fixing bugs. What else can you ask for? I guess a good user experience is one thing you can ask for, but let’s stick to programming for now.

Thinking declaratively requires experience. It does not come by itself. And without going down this rabbit whole one more time, computer science classes still does not seem to teach anything other than imperative coding. At least not where I come from.

Luckily, there are great resources out there to help you up your functional game. Reading is great and all, but nothing beats practicing on real problems. The first site to visit is exercism.io. Find your favourite functional language, complete realistic coding challenges, and have it reviewed by professionals. Code reviews are a great way of getting exact feedback on how you can improve!

Another resource is HackerRank. Mainly touted as a system for matching developers with companies, they also have a great deal of coding challenges as well. The functional ones are especially interesting for us, ranging from easy to hard, so there should be something for everyone here.

No matter how you end up spending your christmas – on the couch, in front of your computer, or doing something completely different, I hope you have a great time. Ohh, and also that 2021 works a bit better than this year has done!

Merry christmas!

Practice Makes Perfect

Gjennom 20 år med store endringer har Bekk tilsynelatende forandret seg ganske lite. Hvordan har vi klart å fornye Bekk gjennom alle endringene?\ \ Vi tok en prat med Olav Folkestad, Harald Krogh og Anders Christensen.

God jul!

20 år uten å endre forretningsmodellen - hvordan har Bekk overlevd?

One article a day for twenty-four days from nine authors! Merry christmas and happy holidays from all of us.

It’s been a weird year, but something never changes, and this year Vegard kicked off the calendar with Immutability. Some things do change though and Nicklas took us through the Kotlin changelog.

This year we’ve looked at many of the Kotlin features and resources for learning Kotlin. Matias taught us how to delegate and destruct, Jobi knitted an article of strings templates and demystified the magic behind the Kotlin collections. Eivind explained Operator Overloading and how we can add new operators to our code.

We’ve taken a look at some of the nice and naughty libraries we can use with Kotlin. Tia took a look at the naughty Gson library and the nice Spek Framework. Kristoffer taught us how we can use MockK for figuring out if something is nice or naughty and Nicklas showed us how we can make Kotlin write the code for us with Kotlinpoet.

We’ve had some good discussions. We’ve written about when and why to use let, apply, run and also and Eirik explained the difference between companion objects and top level vals.

Sondre has given us two fantastic introductions to the Kotlin tooling integrated with Intellij. How to use the Kotlin REPL and how to better understand the Christmas mysteries using the bytecode viewer and decompiler.

Kotlin has introduced a lot of new things over the last few years and we’ve taken a closer look at some of these. Contracts to help the compiler better understand our intent, functional Interfaces as a better alternative to typealiases. It's (Christmas) Time for Kotlin when Jobi explains the new Kotlin time API and Nicklas explains the new serialization library.

We’ve also deep dived in some of the more magical parts of Kotlin. Matias gave us insight into type classes, Sondre about the reified keyword and Nicklas on how to write your own domain specific languages.

All that's left now is to wish you all happy holidays. Happy holidays!

Happy holidays 

Wow! It's Christmas Eve, and elm.christmas is drawing to a close. We've published 24 articles, and I want to thank you for visiting our advent calendar, regardless of whether you've read all 24 articles, or if this is the first one you've read. This last article won't be long, as I just want to highlight a neat tool that you might not have used for your Elm project.

I remember being really inspired by Richard Feldman's keynote talk at Elm Europe 2018, and on the plane from Paris I just had to start rewriting my side project using some of the techniques from that talk. During the flight I needed to check the documentation of a package at package.elm-lang.org. The only problem was that I was 30 000 feet above France, with no Internet access.

What I didn't know at the time, was that I actually had all of the documentation locally for Elm packages I was using already. So I could have just checked the source files to read the documentation I was looking for.

Another, even better, solution would have been to use the command line tool elm-doc-preview to view the documentation I wanted. Elm Doc Preview shows a webpage displaying the documentation of the packages you have installed, and makes them look exactly like the documentation does on package.elm-lang.org.

You can install the command line tool using npm:

And to view the documentation, you simply run the following command:

The command line tool starts up a web page showing all the dependencies you have installed in your app.

Select a dependency and you see that the documentation page looks exactly like it does on package.elm-lang.org.

The tool is a really nice convenience for those times where you don't have an internet connection. And even when you do, it's nice to have an easy way to view the documentation for every dependency in your app in one spot.

Lastly...

Lastly I want to thank everyone who contributed to this years elm.christmas. 10 authors wrote 24 articles in total, in addition to reading and giving feedback to articles written by others. Thank you all for taking the time in a busy holiday season to give back to the Elm community. ❤️

Log Off and Read Some Docs

From all of us behind javascript.christmas, to all of you: Merry Christmas! We really hope you've enjoyed our advent calendar. For our very last article in this advent calendar, we need your help saving christmas.

Oh no! The Grinch has come and kidnapped Rudolph! Hopefully you can make his heart grow and he will come to love JavaScript by solving the puzzles he left behind.

24-Dec

Today's posts