Cool string methods

20.02.2018 01:00

I was looking at new stuff coming in ES7 and ES8; you know, stuff that weirdos like me do. And I came over a very cool pair: padStart and padEnd. You can run it on any string and it will pad the end or the start with a string x times. It works like this:

Looks like a great option when you just want to add X of something either before or after a string.


19.02.2018 01:00

The latest in hospital fashion


19.02.2018 01:00

There are some obvious advantages to using immutable data types. I personally think it is much easier to understand immutable code, and much easier to understand. The reason is that you replace data, and you omit the problem of two methods in a class trying to mutate the same thing. For example by incrementing a int twice or changing a boolean to the opposite twice.

The reason you can avoid this problem with a immutable data type is that you would instead of changing the data, send the initial data set to the function, make a copy and then return the mutated copy, that you replace the original data with.

Knowing that the result is always input + the code, and know that something else can’t be doing something weird in the background makes many thing a lot easier.

Immutable.js is one way to do Immutable data structures in JavaScript. You need a third party library because JavaScript don’t have real immutable data structures as a part of the language. I’m not using Immutable.js at the moment, but I have tested it out to a great extent in the past. And there are many great things about it. For example to test if two objects are the same by doing obj1 = obj2 is awesome.

But I have decided to not use it in any of my projects. Not because it’s bad or anything like that, but because I think it requires a little bit too much work. You have to use the Immutable Map and List objects instead of the native JavaScript ones. And you need to convert stuff between the native and immutable types all the time.

I agree on the basic premise. But I would have preferred something like a babel plugin, that let me use Immutable data structures without having to use a separate API.

Lightroom and previews

19.02.2018 01:00

I guess most beginners start out with the assumption that a “raw” file is just a fancy image file. But learn as they move on that it isn’t really a image or a picture file like a jpeg, but rather a huge collection of data that one can use to generate a image.

RAW files are big and powerful. Especially big.

Most people probably start out with a single lightroom library and then they shoot, import, remove the pictures you don’t want to keep and continue like that until their laptop drive is full. And then I assume many people do like me, move it to an external drive and start a new one. And continue that process for way too long. A better way to go about it is to add your external drive to a library on your internal one. One library is easier to navigate, and there aren’t really any good reasons to keep multiple ones.

If you import some raw files into lightroom as they are. And don’t do anything but adding the files. Then the experience isn’t the best, because then lighroom have to generate a JPEG preview every single time you open a new file. A better way to do this is to generate previews. Lightroom has three different previews, standard, 1:1 and smart. The standard sized preview is used when you look at a grid of photos and when you look at a single image (before you zoom in) and the 1:1 are used when you zoom in. While a smart preview is a small, lossy raw file that you can use to edit your photos (when the external drive is offline or if you want better performance).

I personally generate standard sized preivews for everything; they don’t take up much space; and makes everything a million times more enjoyable. And I also generate smart previews for everything because they don’t that up that much space and makes it more enjoyable to use Lightroom.

Then I also generate 1:1 Previews that I keep for a limited time, when I process images, and I re-generate them for selections of images when I work on them. Be aware: they take up a shit load of disk space, but makes it much faster when you zoom in and compare a lot of images. My workflow is that I discard them as soon as I don’t need them anymore.

Removing one notebook.

19.02.2018 01:00

The notebooks I have been carrying as of late – I don’t remember exactly when I re-added the pocket sized notebook to what I carry – but it has remained the same since then.

I carry one pocket sized notebook, one Leuchtturm1917 Bullet Journal, one Leuchtturm1917 Lined A5 and a regular sized Traveler’s Notebook filled with lined refills.

The reason I carry two different lined notebooks is that one of them contains drafts for various long form stuff I am writing, while the other is just journal entries.

I have decided to do something about this. What I’m going to do short term is to use up the last lined refill for my Travelers Notebook, before I move over to just using the Leuchtturm1917 and then I’m going to move back to using the Travelers Notebook.

As always, I might go back, if that makes sense. But at the moment it feels light to slim things down a little bit. And only carry one notebook for each thing, instead of two for long form writing. x


17.02.2018 01:00

[@helgeg]1 where would I start if I was going to get into fancy keyboards?


17.02.2018 01:00

Cleaning my office, and found my iPhone 4s. Still my favourite.


16.02.2018 01:00

[@jack]1 what’s your favourite 35mm films?

ESNext Proposal

16.02.2018 01:00

I can’t wait until I get the chance of using this one. In functional programming languages like F# it is common to do things like “64 |> sqrt” instead of “sqrt(64)”. The value of it might not be as clear with the simple example I gave above.

But it can make more complicated chains of function calls much easier to understand and maintain because of how composable the syntax is. And not more silly syntax errors because you forgot to add or remove some opening or closing parentheses.

My Terminal Setup

16.02.2018 01:00

I have been what one might call a terminal power user for at least 15 years by now.

Here is the thing, from the moment I realised you could start any app from the terminal instead of looking for the application in some list, until now the terminal have been my preferred way to use a computer. There are of course some tasks that works better with a proper GUI app. This doesn’t mean that I use a text based app all the time. It just means that I always start stuff either from a terminal or using a launcher like Alfred on OS X. Instead of clicking in some menu.

I have used three different shells. First I used BASH as my main shell, until I switched to ZSH and I also used FISH for a majority of this year, before I moved back to ZSH. BASH is a very good shell, and it is a huge improvement over the old SH or CMD.exe on Windows. The big advantage with going for ZSH over BASH is mainly about being able to configure more or less anything, including much better support for custom prompts. And much more powerful and polished features in general. I’m of the opinion that all bash users should at least check out ZSH.

FISH is a very modern shell. And I think it will take over from ZSH at some point. I did love using it. But I decided to move back to ZSH for one reason. ZSH plays much nicer with “everything” than what fish does at the moment. The biggest problem with using fish for me, at this moment was that it didn’t work that well in the integrated shells in Emacs and VSCode.

I use a pretty standard Oh-my-zsh setup at the moment. 90% of my config is the default one, with a few aliases and a few variable changes. One of them is to add ~/bin to the path; one of my favourite hacks to have an easy way to add stuff to the path.

My editor of choice at the moment is Spacemacs, and I do more or less everything that involves typing characters into a text field in it. But I also use VIM from time to time. The difference between the two is that Spacemacs is where I sit all day and type, while VIM is what I use when I’m just going in and out fast.

On Mac OS X I use iTerm 2, together with Amethyst and Alfred App. The built in terminal app is fine, but I prefer iTerm because it supports splitting the window both horizontally and vertically. And Hyper is way too slow as far as I’m concerned. Amethyst is just a tiling window manager for OS X that makes it kind of work like XMonad. It’s awesome for weirdoes like me that don’t want to deal with windows.

On my Arch Linux box, I use XMonad, with dmenu and xmobar, and urxvt as my terminal.