Hjertnes.blog

#

March 05, 2018

How to get into programming.

March 05, 2018

The “How do I get into programming?” questions is one of the hardest things to answer. Or I do at least think it is. This is because being good at programming is about having experience doing it and having the drive to always looking for better ways of doing everything. Including those things you didn’t know was a problem, and of course the things you think are annoying.

The way I got into programming, and the way everyone I know who know how to code got into it was by doing. They had something they wanted to make, and they figured out how to do it. I started with web development. First I wanted to add a visit counter to my web sites, then I figured out how to make it only count unique visitors within a timeframe. Before I moved on to implementing a full CMS driven by PHP and MySQL.

The best way to learn how to code is to start learning about the technology you would like to make it in. If you want it to be a iOS app you should start with Swift and Xcode and if web devvelopment is your thing I would start with HTML and CSS, before moving over to JavaScript and server side technology. I would start with either Django or Ruby On Rails because they are very easy to get started with and almost everything you want is included. And React or Vue are good places to start for when you want to do Web App Development.

How you learn the basics are up to you. Some people like to watch video lessons, while others like a more interactive approach and I prefer books and blog posts. How you do it is up to you, but I would encourage you to try different methods and stick with what works for you.

And the final step to get started is to find a project. If you are doing a web development, making a custom CMS is a good place to start. Not because you’ll get the most amazing thing every. But just because you will learn a lot from doing it. Everything from server side rendering on what people will see and more advanced Web App development on the admin side of it.

A todo app is a good place to start, if you are doing an native app; but also works if you are doing a web app.

Then I would encourage you to make what every you are making as good as you have the time for. And always improve everything as you learn new stuff. A solid project that shows how you work and what you can do is always useful when you are going to apply for a job.

There will be a lot of “abstractions” no matter what kind of software development you get into. They are a way to make more complicated or time consuming tasks easier to work with. The good thing about them is that you don’t need to know all the details when you start out. The bad thing is that you need to learn more things. But I would still take the time to learn to theory behind them as you get more experience.

If you decide that you would like to make a living as a developer then I would start by looking at what kind of languages, frameworks and technology are popular in your area. And the best way to do that is by looking a job listings. And then start learning that. The next step is to have some code you can share with potential employers when you apply for a job. The closer the code is to what they use the better it is. It is just a way to show them that you actually know how to do the job. Because the biggest nightmare when we hire is to get someone who don’t know how to code.

Testing your web app

March 05, 2018

To implement tests in a Web App requires your to test three different things: the backend, the front end and cross browser testing.

Assuming your backend is a series of REST API’s, the tests should make sure that your API’s are always doing what you expect even when you get input you don’t expect. And it is always a good idea to implement tests that re-produce bugs that are reported to make sure they don’t are re-introduced.

Then you also need to test your front end code. This means that you test all of your components or views and make sure that they always do what you expect, even with input you don’t expect. This is especially important when you are dealing with forms.

And last you should also use something like Browser Stack to do cross browser testing. Just to make sure there aren’t any problems with either your backend or frontend code in any of the browsers you support.

The reason you want all of this is to make sure that a) everything works right now b) test if some changes you made broke something c) see if performance improvements actually improved things.

Using a higher order function to deal with exceptions

March 05, 2018

I have a longer and complicated relationship with exceptions, and I do in general think that they are the right solution, but I’m not a fan of the syntax. And I also think that they are not always the best solution. For example I personally think that to throw an exception when you are trying to fetch something(as in one exact row) from a database and don’t get anything back, I would prefer null instead of an exception because it ends up being a lot of code to deal with something very trivial. But when there are actual problems (like you try to get one of something and there are many, then you should get one). Long story short.

You have many different approaches when it comes to dealing with Exceptions. There are problems you can recover from and then you have those you either can’t recover from or those you don’t know about. I say use a specific solution to fix the former. But I often use generic ones when it comes to dealing with “the rest”.

I have written many versions of the higher order function below over the years. It is a simple HOF to wrap a function that will or might trigger an exception in a try catch and deal with it. For me it almost always means sending some feedback to the user and reporting the error.

Web Development in 2018

March 05, 2018

Web Development is in a weird place for me at the moment. The choices for front end development are pretty solid. Frameworks or libraries like React, Vue, Ember and Angular are pretty solid; I personally prefer React, but all of them are good. Backend development on the other hand is in a weird place for me. I have used both Django and .NET a lot in the past. But neither of them are what I want in 2018 or 2017 for that matter.

The good thing about Django is that everything is easy to do and you get all the tools you need to build a database driven, fully tested RESTful JSON API out of the box. And you get the same with .NET Core. What I don’t like about both of them is that there are a little bit too much “magic” in other words stuff that the frameworks just does. The thing I don’t like about Django or Python is the lack of a solid type system, which makes the tests more verbose than needed and too much validation code. And C# and .NET have gone a long way, but there are still too many places where you need to define full classes to do simple things.

I spent a lot of time last year to see if Node + Express was what I wanted. And the answer is not quite. The reason is that I could come up with a setup that is almost there, but the type system is still too far away from what I want.

The next thing I started to check out was F#, Chicken Scheme and Guile. But none of them had all the stuff I wanted.

What I want is either a framework or a set of libraries I can configure to Database Migrations, define database tables in code (ORM), write RESTful API’s, manage authentication etc. And I want the language to have a good type system, support functional programming well and most important be fun to use.

The thing I mean when I say “good type system” is to define what kind of parameters to I expect to get of what type over URL parameters, GET Parameters and BODY data. Ideally those who are required and not required.

What I have decided to use for now is Clojure. It is a LISP, which I love. And I think everything is just a question of setting everything up to work like I want to. My “starter” project is on GitHub but it is far from done.

#

March 04, 2018

I’ve been looking for a good replacement for Django for a while. What I like about Django is that you get everything you need to build a database backed backend out of the box. What I don’t like is how bad of a fit Python is for functional programming, and because the type system isn’t that great.

Clojure seems like the best option I’ve tested out this far.

#

March 02, 2018

I have been trying to get into meditation for a very long time. I think some of my first attempts where back in 2009. It have been difficult to identify what is important and not. And I gave up after reading countless books. The “breathing” app on my Apple Watch got me back into it, and I used the Oak app for a while. Before I started to use Headspace a few days ago. It is awesome. And I would encourage anyone that want to get into it to check it out.

#

March 02, 2018

Decided to pretend like I’m a designer and write some styling for my micro blog last night.

A single Apple OS

March 02, 2018

There was a lot of talk about the merging of iOS and Mac OS at the end of last year. And I never wrote anything about it, because I never made up my mind what to say about it.

When people start to talk about a single Apple OS, I assume they are talking about making them more similar under the hood. Because I know I don’t want OS X on my iPhone, and I certainly don’t want iOS on my MacBook.

I’m certain that there is a “Core” that is maintained separately from OS X, iOS, TV OS, Watch OS etc. And that is the “Apple OS” everything Apple makes with Apps shares. And I think that Apple will, and I also think that it is in their interest to limit the differences between the platform as much as possible. One of them is to make sure that the API’s on their platforms are the same, except for where there are really good reasons for doing so.

If expanding from iOS to OS X would be more like adding an extra Storyboard to the Xcode project, I assume that it would be more of an option to add OS X to the supported platforms. This would solve many problems that both Apple and third party developers have. It is hard to maintain many different projects at once. And by limiting the number of them, and making them as similar as possible, without turning Y into X or X into Y, you could end up with more Mac Apps. And more Mac Apps adding support for iOS. For example the app I’m writing this blog post into (MarsEdit).

I think the biggest issue with maintaining both iOS and Mac OS at this point is that even the most trivial stuff like a fucking colour is not the same across the different platforms. Making Apple’s development platforms more modern is a story for another day.

Optimising your Web app

March 02, 2018

Let’s say you are building a new web app. When should you start to optimise it?

I personally think that starting to make sure something is as fast as possible is the last thing you should do. Because there are a number of things you should think about and test out before you start on that.

First, you need to make sure that what you made are doing what you want it do to.

Second, make sure that what you made are needed and add value to your product.

Third, make sure all the user experience is how you want it to be, so that your target users will actually use it.

Then I would start to make sure everything is as fast as possible. This means everything from how fast your code is to how large the code the browser have to load is. My approach to optimising have always been to find the way to do something that requires the least work. For example by limiting how often you commit queries to the database(saving data), using the fastest possible queries to fetch data and, if you are looping over data: always continue to the next row as fast as possible when there is no point in running a lot of extra code.

If you’re still not happy with the performance I would start to debug and identify the parts of your code that is slow and try to find better ways to do that.

In the backend it’s often about optimising how you deal with the database and to cache slow stuff in memory (redid) and on the front end is it often about using many smaller methods instead of large ones and to limit how often stuff are re-rendered.