I eventually got to work on a large scale ui component library for a customer, and I have to say, developing atomic components just made me a far better developer. Storybook together with react helped me realize important things.


Obviously we all want to create a accessible website. It's our one goal, to create every single atomic pixel accessible. When the designer gives the handover if the new Facebook, you probably have a goal, to create a nice replication of the initial design (even pixel perfect or what not). 


What one usually forget is to ask the critical questions, such as "what should the focus implementation of this button be, if the button is not disabled?".

As a senior front end developer you would ask questions like:

"How does the element look when it's hovered"

"How does the element look when it's disabled"

"How does the element look when it's focused"

"How does the element look when the element is given input"

Those are all questions of creating accessible components!

Storybook has made me a better developer because:

add react and react-dom as peer dependencies

Keep your UI in a separate repo to avoid mixing business logic

At first it might seem overly complex. But in the end the result will have a huge outcome. All your  atomic components matters.

Building Your app with storybook

There are a few ways we could generate a sitemap.xml using next.js.

Use a custom npm script that generates a sitemap.xml inside the public/ folder. This could work if you build your project on every content change in the CMS.

Utilize the pages folder (dynamic routes), creating a sitemap.xml.tsx file. The benefits is that we can generate sitemap without building our next app. We can cache the generated sitemap, if you have a statically generated next app.

We will look at how we can utlize the dynamic routes and use sanity as our CMS.


Lets create our sitemap file (typescript):

First of all, Next.js expects a component to be returned as a default export. Here we will export a component that says that this page can not be navigated via client side routing. This is because if we use the <Link> component this should never be generated on client side, and thus displaying this errror.

In this variable we store the generated sitemap, we only query the CMS the first time sitemap.xml is loaded from the URL /sitemap.xml. And then we store the result inside this sitemap variable. Note that this requires a new build in production, if you want to update the sitemap. For my case, i actually want this to happen because all my content is statically generated! If your content is not statically generated, you could omit this, and create some kind of TTL cache, so e.g. only generate a new sitemap every hour or so.

So whats up with these return statements? Next.js expects props to be returned from getServerSideProps, but above each return we use res.end(), which will actually send the request as is before rendering the component. Which we want to do because we generate XML and not HTML from the component.

Lets look at one way to generate a sitemap from dynamic content, in this blog post we will look at getServerSideProps + sitemap package.

Next.js 9.3 - generating a sitemap from dynamic content

Lets build a simple blog, index page will list all the blog posts in our cms. There will also be its own url for each blog post.

No server side calls to any database, which means saving resources.

You can still have dynamic content, which we will look at in this blog post. But the web page is generated once. 

 and create a free account. Sanity is a great headless CMS platform!

And lets add this to export, so sanity knows about it.

This just lets you run e.g. npm run dev to start the development server.

Lets add our index page, which will list out all our blog posts.

So this is a very simple blog listing page.

The important part here is that we are exporting getStaticProps. Also the index page does not have any query parameters, so we dont need any context to render all our posts.

Npm run build will statically build this page, and take care of running a query to sanity api, and then build a static page.

Congrats! You now have your first statically generated page, with dynamic content!

Now for the next page we are going to build, we need to use another export that nextjs has availble getStaticPaths.

This is because we are going to dynamically respond to existing blog posts from the URL parameters.

 should should find the correct blogpost in sanity and display it.

First find all our blog posts that are published ( getStaticPaths() ). Get the slugs, so we can send this in paths to the real Post page. Here we QUERY sanity, and ask for all the posts that has a slug defined (and is published).

For each slug, we query sanity per post and fetch all content based on that slug.

Behind the scenes Nextjs. will build static pages for all your blog posts. so if you have two posts with slug hello-world and my-first-post. Two pages will be generated and http://localhost:3000/hello-world and http://localhost:3000/my-first-postw will be accessable as a static generated page.

Congrats! You have a fully statically generated site.

You will notice that NO api request to sanity is made if you go into e.g. http://localhost.3000/my-first-post

Currently, you will have to build the codebase everytime you edit something in sanity! Next up we will look at how we can build our codebase once we edit something in sanity. That can be done with webhooks, and a service such as now.sh. 

In the next episodes we will look at how we can 

Next 9.3 introduced getStaticProps, getStaticPaths and getServerSideProps. Using getStaticProps and getStaticPaths, you can generate any page fully statically rendered from any CMS. Today we are going to have a look at how can create a blog statically generated with Sanity as our CMS.

Next.js 9.3 - statically generated pages

I have been interested in "home automation" for years. In fact, it started with writing a 

 in 2012. I bought some x10 modules after writing that library, but x10 was very unreliable and slow. This made me look for other solutions

After dealing with x10, i noticed z-wave. I bought a Raspberry Pi and a razberry board. I bought some power plugs to test it. That was when i wrote my own 

. I worked, it could turn on and off my few lights based on dynamic conditions. But a great GUI was  missing and this solution required a server running php. 

But that fact that i only owned a small appartment i felt no use for automations. I had like 4 lights, that was all i was able to control.

This is a picture of my technical "room". It consists of several devices and most of them are connected into one single system. Im not proud of the cable management BTW 

IoT is starting to really catch up. There are now tons of devices that can be controlled via either some custom made http api, z-wave, zigbee and so fourth.

Currently these are the devices that I can control via some kind of communication:

My new kitchen appliances (Siemens with home connect)

Temperature in the floors (heatit zwave) 

how do I control all of these devices using a single automation library when they use several forms of communications?

Home assistant is what I have been looking for since the early days. The beauty of home assistant is that you can control tons of devices, and it has lots of plugins that you can install to control your IoT devices.

You write generic automation scripts based on the state of all the devices you have connected to Home assistant. 

My current and only automation is that I turn off the lights in the bedroom when i turn on my LG TV.

But more automations will be written once i find some suitable automations.

Describing the "boxes" in my technical room. The server, patch panel, switches, hubs and so fourth. This is my home automation solution

My home automation setup

These are linux commands that I use every day at work and home as a web developer.

History is useful, especially when dealing with deployments and other setups on projects that you are not very familiar with. If the standard go-to guy for deploying the app is on vacation, and you need to deploy emergency fix - history is your friend. 

I normally use sudo su - www-data and change directory to the web app i'm dealing with. As deployments in terms of a php app is normally done via the www-data user / web server user.

If the project is a php project you can assume that it uses composer (at least now in 2019). Then, to find out how the app was deployed you can simply use history together with grep.

Using this command you should probably get some results of how to use the composer install command. 

"pwd" shows the current working directory. Useful when you're lost.

"top" is useful to check for abnormal resource usage. A list of the processes will display live in the terminal. Important statistics are e.g. memory usage and CPU usage.

To sort the results by memory usage press "SHIFT+M".

"clear" clears the terminal in the viewport. Very useful when you need a clean sheets for some heavy command use. I normally use clear 

I use grep every day for searching a tree of files for some keyword. 

To do a recursive lookup you can use the following command:

This command searches the src/ folder and its sub folders of a file that contains the word "cash" or even "CaSH". 

l: Means it prints only the names of the files that matches.

And then to some one-off commands for dealing with web related tech.

This is especially useful when testing caching strategies and deployment. You want to remove all the data in memcache.

This command uses netcat, connects to the memcache instance and runs the "flush_all" command which clears the memcache data.

Useful linux commands that I use every day as a web developer.

Useful linux commands for web developers

Today we will take a look at how we can implement simple global state using useContext and useReducer hooks. 

We don't need redux to implement global state. That said, redux has some nice features that we wont have using the method i am about to show.

 is supposed to be called once, and preferably on the top component. 

 is a hook that we can use anywhere on all of our components. 

This is the magic of hooks! Here we have created two functions

A HoC: withGlobalContext
Which we will use on the App component.

A hook: useGlobalState
Which is just a wrapper around useContext.

Lets create an App component and also 3 components that uses global state.

We will be using these actions through the test components we will create.

The counter component uses our custom hook "useGlobalState". This hook returns the globalState object and a dispatch method so that we can send actions to change the global state.

MyNameComponent also uses global state. This component has the ability to update the name and clear the name of the global state.

AsyncComponent uses the global state. It fetches some values from a API then dispatches actions.

How to do global state without any library, just using react hooks!

Global state with standard react hooks

PHP is probably amongst the most hated programming languages around the world. Some people love it, some people say its a toy language, some people hate it with a passion.

PHP has grown a lot within the last couple of years. PHP now supports proper OOP, and have concepts like Classes, Interfaces, Traits, Closures / lamdas,  Generators, Strict types, and more.

This article will be a list of what I think is good, and what I dont like about PHP.

PHP is really easy to get started with. Put a script on a web server and run it. This can also be bad.

You dont have to learn basic concepts like how the http protocol works, just create a script and start echoing stuff out. This can also be bad.

PHP 7+ is really fast, it beats the contenders such as 

PHP has composer which can be compared to gem, pip and npm. Composer was probably the best thing that happened with PHP.

PHP has plenty of well tested blogging systems and cms systems. E.g. Wordpress, Drupal, Joomla and eZ Publish. This alone is huge, and might be a big reason that PHP is still alive.

PHP has great libraries for doing advanced integrations and large legacy systems.

Creating complex libraries is great because PHP supports almost full type safety in classes.

Well tested frameworks used in production for years: Symfony and Laravel.

PHP Documentation is readable and indexed greatly by google. Just google that function and you are good.

PSR. PHP Standards Recommendation. This project is great, it means that libraries written can work with each other. Also PSR consist of a coding standards guide, which leads to better code.

PHP's mess around global functions can be frustrating.

Dollar sign in front of variables shouldn't be necessary. I would rather use literals to concatenate.

Because PHP is so simple by default, it doesn't have good defaults for security such as XSS injections.

I mean it. Its way too easy. PHP is so easy to learn, which leads to really bad code written by junior developers which just started learning to code. 

I dont like Java. Actually I dont like Java at all. PHP is starting to feel more like Java. This can be great, but often leads to overly complex code. E.g. use a simple array instead of creating 10 value object classes that implements each of its own interface?

When working with PHP projects you would often work with legacy code. This legacy code was e.g. written by really bad programmers or was written for PHP 4 with no OOP at all. Working with such code makes you feel like a sad -sad Panda. Often these systems are also full of bugs.

Legacy code can be true for other programming languages as well. But I solely think PHP has the worst legacy code. PHP 4 was really bad and the eco system was not there.

PHP, the good and the bad

. Typed properties would be really good for PHP, as PHP has already gone on the way to be a strict types language. 

The RFC has been accepted, and PHP 7.4 will now include typed properties.

The benefits of the new typed properties:

Relying on dockblocks for code completion in IDE's.

Future performance improvements can be done internally in PHP.

Less type checking code, meaning cleaner code.

This is an example of how you can define typed properties, in reference to the RFC:

First of, the obvious. There are no longer needs for types in dockblocks and getters / setters to ensure type safety. This alone is a huge deal. Today, per property there are at least 21 lines of code that can be removed. This given the PSR coding standards.

Which can be converted to 3 lines of code.

Sometimes you would need a getter / setter in cases where the contents of the variable mutates to something else. Still the dockblock would not be needed.

Building Your app with storybook

Next.js 9.3 - generating a sitemap from dynamic content

Next.js 9.3 - statically generated pages

My home automation setup

Useful linux commands for web developers

Global state with standard react hooks

PHP, the good and the bad

PHP 7.4, typed properties RFC

Hello

Get in touch

Weather in Bergen