Following the release of Deno v1.0 I got excited to try my hands at it. These are my first experiences writing a simple tool in Deno.
A super fast introduction to Deno: Deno is the spiritual successor of Node trying to fix design mistakes that were made early on but recognized only late into the project. Deno supports TypeScript out of the box and relies on web-standards. In Deno you can import ES modules from any URL and use fetch like you would in the browser. To help unify the community on processes and workflows Deno provides a wide array of stdLibs and has build in solutions for bundling, testing and code formatting. You can read more in the Deno v1 release post.
To try my hands at Deno and collect some experience on how ready it is I decided to implement a simple cli. The goal: read all markdown files in the current directory, parse them to HTML, add a navigation and output them into a new folder. I also decided to use new.css as a class-less CSS library to style the pages.
Once you get a centralized logging solution like Elasticsearch setup you open up an incredible amount of possibilities. That is if you actually send logs to your central place. On a recent project, we wanted to “just log our deploys from the Jenkins Server”. Thus we set out to find the “easiest” way to log to our Elasticsearch. We finally reached curl as our solution and today I will walk you through how to do that.
Testing is one of the essential steps in software development. Yet, testing and especially manual testing that clicks through the application is a tedious job that we often shy away from. But it doesn’t have to be. With great tooling coming out over the past couple of years we now have what it takes to automate click-through testing in our build process. In this post, we will look at why manual or click-through tests are important and how to turn this tedious and bothersome task into a fun one that drives our development forward.
Most websites these days are Single Page Applications (SPA for short) where a single entry file handles all routes that a user might visit. Swept up in the ongoing trend of hosting in the cloud you might find yourself needing to “dockerize” your SPA. That is to say wrap it inside a Docker image and run it as a container.
In this post we will explore how we can get that done. We are going to build a simple SPA that just tells the user which route of our website they are currently visiting. That means you should be able to visit not only / but also any route you might think of, such as /unicorn or /rainbow. This SPA will be a super simple and hand made one but you can see it as representative for any complex React, Angular or Vue app you might want to deploy. Finally we are going to build our SPA into a Docker image and deploy that as a container.
We will run through all the basics of what we are doing. So whether you are seasoned with Docker and just can’t get that SPA to run on your cluster or you are a great web developer tasked to do this Docker thing, this post is for you.
We will walk through an example of such a scenario and implement a solution using RxJS. On our way we will learn some basic operators for RxJS, and a few techniques as well as how to avoid a pitfall or two. At the end I will present a real-world example to show you how to implement what we learned in a specific scenario.
The CMS (Content Management System) was one of the first building blocks of the content driven web. The CMS marked the move away from hardcoded HTML pages, and towards our modern web in which everyone has become a content creator. They are great for businesses because the competence of building websites and managing content could not only be split in theory, but also in practice. With a CMS, we can update our website on the fly — so there is really no justification for not using a CMS.
In the world of CMSs, we as developers are tasked to create a flexible, extensible and usable systems that not only conveys meaning to readers, but also helps content managers getting their job done. In practice, a big part of this work is displaying the content that is managed through the CMS on a multitude of platforms — from desktops and phones to TVs.
After my recent undertaking to migrate a blog from Wordpress to Contentful I was also faced with the challenge to import content to a Space that had a different locale than the Space it was exported from. This came about after we setup a “base” space for our Product that is supposed to be rolled out in multiple countries.
Once again I wanted to use the Contentful-import tool to get this job done. However soon I kept seeing:
✖ Checking if destination space already has any content and retrieving it → Default locale for destination space: es-ES
Contentful is one of the most prominent headless CMSs at the moment. As such it provides you all the content management capabilities of traditional tools like WordPress while decoupling the delivery of this content via an API that can be used to retrieve content.
Headless CMS are quickly turning from the new kid on the block intro everyone’s favourite. And I totally understand why: it makes thinking about building a frontend so much easier, for once you actually know what is happening and we have great separation of concerns. For me as a webdev this is great stuff!
But it is also work, after all these old and dusty WordPress sites need to be migrated to those new an shiny, Contentful powered React based single page applications ✨ I have been building for clients. Luckily Contentful provides a range of tools to make this easier for. While the contentful-export and contentful-import can help you migrate Content Models and Entries from space to space the Content Management API helps you to manage your content. Thus today, let us take a look at how you can utilize it to migrate a blog from Wordpress to Contentful.