February 20, 2018
The latest in hospital fashion
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
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.
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.
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.
[@helgeg](https://micro.blog/helgeg) where would I start if I was going to get into fancy keyboards?
Cleaning my office, and found my iPhone 4s. Still my favourite.
[@jack](https://micro.blog/jack) what’s your favourite 35mm films?
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.
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.
Jesus fucking Christ America. Get rid of that damn arcane futile hillbilly amendment now.