hjertnes.blog

#

26.11.2017 01:00

My favourite thing about emacs is how easy it is to make a simple function that solves something that don’t work like you want it to, or something that takes too many steps

#

26.11.2017 01:00

Sanity is highly overrated.

#

24.11.2017 01:00

Template literals

24.11.2017 01:00

There exists like a billion templating libraries for Javascript, and I guess many of them exist mostly to get around the problem of: How to generate html without doing that weird "<h1>"+title+"</h1>" problem. It works fine for short stuff, but it doesn’t take a lot before it becomes too cumbersome for anyone to enjoy.

Template Literals to the rescue.

All good programming languages have a way to do something like for example this in C#

This is where one of my favourite features in ES6 comes in, that I always forget to use, because the plus hack is to ingrained in my brain that I always forget to use it:

They are great, and could be used as a mini templating languages, if you needs are too simple to include something like Pug or Handlebars; they do exactly what they say they are, and work great. But I’m not the worlds biggest fan of the use of ticks: `. Mainly because it is kind of weird how they are inserted into text files. Other than that, great.

I get why they didn’t, but I kind of just wish they had broken the String type and let us use ${} inside regular strings.

#

23.11.2017 01:00

Every time I introduce someone to pingdom they “complain” about it being expensive. I think it is cheap, if you take into consideration that it discovers issues in 910 times before our customers does.

#

23.11.2017 01:00

I’m not a fan of Turkey; neither the country or the dinner.

Webpack

23.11.2017 01:00

There have existed build tools for Javascript as long as I have been coding with it. I can without doubt say that they are better and easier to understand today than they have ever been. But there are also much more you “need” to know before you get started.

The problem tools like Webpack, Browserify and Grunt try to solve is that on one side you got how developers want to have their code organised to make it as easy as possible to have control over this ungodly mess we have chosen to do, and how a browser prefer to consume it. While you probably prefer to have your code neatly organised in different folders with as small, but not too small, files that only have methods that do “one” thing. This is not how your browser prefer to consume it. And a browser is not the only way to use Javascript these days.

A browser prefer a few larger files over many small files. What I mean by “prefer” is that it is faster if you do it this way. There is of course a limit to how large those files should be, webpack starts to warn you if you pass a few hundred KB. If you have too many small files, then your browser spend more time opening connections to your web server than it does on downloading them, but if they are too big your bandwidth are not used efficiently enough; if the total is a megabyte, then it would probably be faster to download it as 10 100kb files, instead of one 1014kb files or 1024 1kb files.

There are also many other benifits. You can do all your css processing in the same build precedure, for example compiling from LESS or SASS to css. But the biggest advantage is to use it with Babel to enable the use of Javascript language features that aren’t available in all browser yet, or css features that are behind prefixes and let babel and css plugins convert everything to something that is safe for what ever browser requirement you define.

You can also use webpack to solve one of the most annoying problems with web development, after the browsers started to become very aggressive in caching resources. That is: you updated index.js, but you can’t see the changes it your browser. Or you have updated the server, but you need to get a customer to clear their caches. That’s not going to happen, right?

So. What you can do with webpack is to get it to generate a HTML, either an empty one or one based on something you define that links all the javascript resources for you, and get it to give the javascript files a unique name; so instead of bundle.js you can call them bundle-[sha1].js. And that means that there will be a new file with a new file name every time you update. No more “have you cleared your caches?” e-mails, slack messages or phone calls.

I think every one should use something like webpack for their web development, at least if you move beyond a humdred lines or Javascript code. There are alternatives to webpack, but I would go for it, because it seems like most of the community have adopted it as the standard.

No code or samples in this one, but I’m probably going to show how I’m doing stuff with webpack in the near future.

#

22.11.2017 01:00

It snowed tonight, the big question at hand: when will it rain and turn it into a living hell?

Intro to Express.

22.11.2017 01:00

This is a super short, and super simple introduction to both Express and RESTful services. There will be details about both I won’t touch on. It is only intended as a starting point, and I recommend taking a deep dive into each topic on their own.

RESTful web services are a way to build web services. It is probably the most popular one today, and have been so for a quite a while. A web service is a collection of endpoints or URL’s you use to do stuff with your backend from either some kind of native app or even web apps. The reason we use web services is that it is a interface most developers are familiar with, and know how to do well and port 80 and 443 (http and https) are almost always open without restriction; this makes it a good option to make sure your users always can use your app or web app no matter where they are.

The core idea behind RESTful web services is that you have four different methods: GET, POST, PUT and DELETE. There are others but we’ll cover the basics with the four. But they should also be stateless. This means that except for saving stuff to URL and keeping track of who is logged in where, the server takes the input and returns the same data (based on what is in the database). There are no “you need to do this before you do this or the nature of one endpoints is completely different because of something you did before.

The four methods: GET, POST, PUT and DELETE are used for four different things. You use GET to retrieve information, POST to add information, PUT to modify information and DELETE to remove information. It is fairly easy to understand as long as you get those four principles. And you should also always use the most appropriate STANDARD HTTP Status code.

Let’s move on to Express.

My favourite thing about Express is how simple and how little extra stuff you need to deal with to get it up and working. It is the only REST API thing I have used and ejoyed where I don’t spend ages removing stuff before I can start.

The first thing we need to do in ordet to get express up and running is to initialize npm and install a few packages.

And then we’ll add some bare minimum boilerplate, so that we at least have what we need to retrieve post data.

What we are going to do now is to first look at how you define routes to deal with GET, POST etc and then look at the different ways you can send data to express, before we look at how to send data back. And a little bit about the method you use to do stuff in express.

If you want to add a method that goes something at a given URL in express (based on the code above) you can do something like this

You pick the URL endpoint your want, for examle /api/hello/world, and you give it a function, either a named or a anonymous one, that will do something at that endpoint. It takes two parameters, it doesn’t matter what you call it, but the standard is req and res. The first one is the REQUEST you recieve and the send is the RESPONSE you send.

There are three typical ways your endpoints will retrieve data (you also have headers and cookies, they are typical, but often very specific and not general). Url parameters, query parameters and body data. Body data are typically only used on POST and PUT requests, while the rest are available everywhere.

A url paramter looks like this ‘api/hello/world/1, where the ‘1’ is the paramters. They are required and mapped in the url like this:

app.get('/api/hello/world/:id/', function(req, res){})

A typical use case for this is when you want to fetch, delete or edit a specific element. Compared to if you want to fetch all. Url parameters are available in the req.params object.

Query parameters on the other hand are often used for optional paramters (because it is a pain in the ass to add a billion different routes for url params). They also look different: ‘api/hello/world?key=value&key1=value’. Everything after a ? is considered a query paramters; they are divided by a & and the key value pairs are divided by a =. Remember: they should be URI encoded. Ugly but useful. You find them in the req.query object.

And body data are available in req.body. Most of the boilerplate code above is code required to deal with posting data. Because you can post more than one kind of data as the body text. We used to post uriencoded data for a very long time. But these days we usually post JSON because it is way more powerful and easier to deal with.

The last thing you need to know is how you send data back to the requester. There are two methods I typically use when I send data back to the user res.send and res.status; the way I often do it these days is res.status(200).send(myListOrObject). You use .status to give it a appropriate HTTP Status Code, and .send to send some data. I usually use it to send JSON responses, but there are others to send other kinds of data.

I’ll probably come back and go deeper on Express in the future.

#

21.11.2017 01:00

I’m really enjoying the audiobook of Joe Biden’s book.