Picking the right language for your project.


Languages like Python are very easy to develop in. That means that you can do a lot more in it, in a shorter period than with something like C# or Java. There are a lot of reasons for this. The awesome thing about Python is how productive you are while using it. But there are a reason many of us use them at home, and pick other languages for our work projects. At work I use C#.

The reason I pick languages like C# for large work projects even though the productivity coding in it is way worse is simple: Types.

All languages have types, some of them give you more control over them than others. When you deal with compiled languages things can either fail in the run time or in build time. This is one of the bigger differences between Swift and Objective C. Obj-C is a very dynamic language, this means that more stuff happens I the run time while Swift is less dynamic, which means more validation and type conversion have to be done before you get it to compile. There are good and bad sides to both; dynamic are easier and more flexible, while the other side crash less often but takes longer time. ยจ

The way it works is that every value has a type, and if you try to pass a value to somewhere that can't deal with that type it won't build. And there are also standard checks and error handling anywhere you might get data that don't match. What I enjoy about working with languages like C# above everything else is that when I run "dotnet build" and it succeeds I know that all of it will run. If it does what I think it will is another case. But I do at least know that there are no syntax mistakes or someone using the wrong values.

It takes more time than it would take. But the result is that we write a lot less "make sure this really is a number" code. And often we write something once and don't touch it in a very long time. That almost never happens with Python or PHP.


#


Who Uses EMacs to read mail? - emacs


Making Code Faster


The basic idea behind optimising code is to make what it does today by doing "less". When you do less, it takes shorter time. That doesn't mean less code however.

  1. Figure out what takes the most time.
  2. Start at the top and find ways to make it go faster.
  3. Change one thing and test.
  4. Repeat.

Things like writing to disk, output (like printing) or committing write queries to databases are slow. When I write code I often first focus on getting it to work, and then I try to make it fast later. One of the first things I always do is to limit how often I commit transactions to the database. With complicated background jobs, you can take it from hours (with large data sets) to minutes if you limit how often you write to the database. By using transactions. The ideal is once.


Everything on GitHub


If you are a software developer, you probably have a lot of code laying around. Because you needed something or wanted to learn something. But having something that you can use and having something other people can use are two different things. Because you have to make sure it is at least kind of easy to install it, run it, configure it etc.

One thing I have focused on doing since the start of 2017 is to put as much as possible on GitHub. I've had a rule: either I start making money on it, or it goes up on GitHub. If it is something I coded on my spare time.

There are many reasons for it, but the two most important ones are: if I put it up on GitHub, I make sure that it is easy "enough" to install and get started with it, that means that I don't have to study the source code to figure out how it works between each time I use it. And it is awesome if someone else finds it either useful or can learn something from it.


#


The keybase logo is too cute


#


I'd love it if micro.blog sent out some follow recommendation once a week, based on who those I follow follow that I don't follow


#


Seems like Spacemacs is much less of a dumpster fire since the last time I checked it out.


Optimise for the problems you have.


It is important to know what kind of problems you will get in the future. But remember: don't spend a lot of time optimising for problems that you might get. But rather design your software in a way where it is as easy as possible to deal with those problems as you can see the signs of them becoming a problem.

Seeing how your users use your software is important to understand how you should optimise your database and code. For example, if you have a CMS with tags. There is no point in optimising it for a shit load of tags, if none of your users use more than five per post. Or have more than 50 different ones on their site.


My custom Emacs.d


I started to use Emacs with Spacemacs, and loved it, and then I moved over to Doom Emacs when it started to feel slow. And then I moved over to having my own thing when I realised that the kind of changes I wanted to make would be much easier if I went 100% custom. This is not the first time I tried this however. But nothing went anywhere the first time I tried it.

The reason I wanted to write my own was that I wanted to make sure my editor had less moving parts, and only had what I used. Instead of having a huge system for managing configuration and a lot of stuff I didn't use. I'm very happy with it this far. It starts faster than Doom Emacs with a little, and faster than Spacemacs by a lot. And I can set stuff up in a way that makes the most sense for me.

The hardest thing about it was to identify the various packages or combination of packages that provide a certain functionality in Spacemacs and Doom. But everything worked like a charm after a few days.


#


Edit for iOS is better than I hoped.


#


Not to confuse my earlier advice about meditation apps, I still consider Headspace to be the best place to start, but I have enjoyed the built in breathe app on the watch a lot lately.


1Password X


1Password X is awesome. If you use Linux, or some other platform like Chrome OS, where 1Password don't have a native app, you can use their "Chrome App" called 1Password. The difference between this and the regular extension is that the extension requires you to have the native 1Password app installed, while X does not.

It is awesome. But the user experience of using it is not as great as the regular extension yet (like copying OTP codes on fill in doesn't work yet).


Apple Watch


I'm still on my first Apple Watch: the series 1.

It's slow, but still great.

My plan is to upgrade when the next version comes out, if it survives that long. And to get a Series 3 if not. The reason I say survive is that my current one have a crack in the screen.

I do not recommend people to buy an Apple Watch unless you are the kind of person where Achievements and Push Notifications about moving more helps to motivate you. And the push notification stuff is okay. But health related stuff is the only real reason to get an Apple Watch.


The Apple Sportsband


I have used the Apple Sports band a lot with my Series 1 watch. And I think it is great, for a rubber / plastic watch band. But I'm not a huge fan of it, even though it is the band I have used the most. My problem with it is that it is not the worlds most comfortable to wear like 22 hours a day. It kind of feels like your arm can't breathe. And unless you tuck the end in the hole, it is very easy to unbuckle it. I don't tuck it in there because harm hair.

The band I use most of the time is my Clockwork Synergy NATO band. It is awesome. A standard buckle. Never unbuckles, comfortable to wear no matter where and how. But it has one problem that the sports band doesn't: it gets dirty.


#


I'm not a fan of the App Store pre-order


Apple custom CPU's?


Apple have already moved all their non OS X hardware over to custom chips. And I think the future will bring custom Apple CPU's or systems on a chip for the rest of their hardware lineup. But that does not mean that they are moving all of it over to ARM. What I think Apple will do, if they start moving away from intel is to make the best possible chip for each of their computers. For example it makes sense with ARM for their MacBook, but the rest should probably remain on some kind of x86 style system. At the same time I think Apple could go for a tailored chip for each of their products. Because what is the "perfect" chip for a MacBook Pro is different from a MacBook; and the best chip for an iMac is different from a iMac Pro or Mac Pro.


Twitter.


Okay. I get it, third party apps doesn't make them any money because they don't show ads.

But I don't get why twitter didn't do a real effort to get an agreement with third party clients to require them to show ads and report some data back.

I guess them just don't want them.


#


Liked: GitHub - Lokeh/reagent-context: Easy access to React context in ClojureScript & Reagent

Getting started with ClojureScript.


I have been playing around with ClojureScript a lot the last few months. A lot of it together with React. No matter what you do, use the "official" fighwheel lein template. I used a reagent specific one for a while, and it caused me a lot of grief. Pick either Reagent or Om(the two most popular ClojureScript wrappers for React. I personally prefer Reagent because it feels the closes to regular React.

The official figwheel template works great, no issues with it at all. I just picked another one because I didn't know what I was doing. It compiles down to a single JS file. And you can run it through webpack or other build tools if you want to.


Reason React


I obviously think that React is awesome. But I have been looking for a strongly typed language to use together with React for a while now.

The best option I have found is Reason. When you use a language like JavaScript, that isn't strongly typed. You are either hoping for the best or you end up writing a lot of code making sure that what is passed to this function really is a number and not a object or a string. Or that a object have the expected elements and so on. This is something you can avoid with a strongly typed language. Because all of the checks are done when you build it, and then there are much fewer things that can go wrong in run time.

You probably don't want a strongly typed language for smaller projects, because it takes more time to work with them. The idea is that you do a lot of "convert this string to a JSX element" etc.

Reason React is pretty awesome. You can use it almost like you would use React with some differences. One of them are that you only can have one component per file. And you do have something like Redux, but it is more like a combination of the default react state management and Redux; which unfortunately means that you don't get something like the Connect HOC.

I'm going to use Reason for some of my side projects for now. And I think I would use it for work projects if I started them today.

Check it out if you like React, but would like something strongly typed.

The introduction of a type system makes it less elegant though. So stick with React if you want the tool that lets you build stuff as fast as possible. But it is excellent if you want something that limits the number of places with runtime errors.


#


Let's test out Safari Technology Preview for a while.


#


The only thing I'm excited about after the WWDC keynote is the dark mode and the anti tracking stuff in Safari.


Chrome vs Firefox


So, I have changed all my daily browsing activities over from Chrome to Firefox, because I think it is just much faster. But I still use Chrome for some stuff: 1Password X on Linux and web development. The reason I still use Chrome for web development is not because the dev tools are better, but because I like them better. Part of it is probably because I have used them since 2009, and know them in and out. And because I prefer having them on the right side of the screen instead of the bottom, the Chrome dev tools are much more adaptive to how wide they are than the Firefox are. It will probably be better and the future. But I'm going to stick to Chrome for web development.

This is very important actually. If web developers are using browser X for development, because they think the tools are better, then that app will probably work better there, because the developers spend more time using their web app there.


#


WWDC Keynote iOS Wishlist:


Autojump


I just installed autojump, and I have no idea why I haven't done this before. The pitch is that it looks at your history of commands using "cd" and tries to guess where you want to do when you hit "j foobar". Just install it, configure it, and leave it for a few days or weeks and then try to use it. It is awesome.