DEV Community: Johannes

Docker - Introduction

Johannes — Thu, 06 Dec 2018 07:41:50 +0000

What is docker?

Docker themselves say that docker is

the world’s leading software container platform.

Now, by reading the information that docker provides about their platform I'm sure that someone with knowledge in
containers would get a good grasp on the subject, but people who have never before used anything like this, it might be a bit hard to understand.

Docker is a software which runs containers. A container is a "isolated package" including a piece of software.

A container does not include a full OS, but rather just the parts that it needs to run the software itself.

This makes a container a whole lot smaller than a traditional virtual machine and a whole lot less resource hungry.

Easiest way to "explain" docker is to say that its much like a virtual machine.

It's not entirely true, but we go with it anyways, because that way anyone whom are used to VM's will feel safe!

Now, the best thing with a container, is that its exactly the same on all computers that runs it, regardless OS! That means that it will run the same on a linux computer as on windows or mac!

To use docker

First off, you will need to install docker. I'm not going to explain this step though, I think you can manage that yourself!

Every container you run will be using a docker image. A image is a pre-built package on which the container will be based. Images can be built locally or by using a hosted alternative like docker hub.

Building your own images will let you customize the containers a whole lot more than using pre built images, but in this first part we will just use
images from docker hub rather than jump in to writing docker files right away!

Note: I will cover the Dockerfile and the docker build command in a later post of this series.

Retrieving pre-built images

On docker hub one can find images for most things that one could want. In our first example,
we will use the official docker tutorial image called hello-world.
The first thing we have to do is to fetch the image to the computer and your local docker service.

No! this is not done by using curl, it's already built in to the docker engine!

Fetching the image is done by using the docker pull command:

docker pull hello-world

Note: its also possible to just run the image, docker will fetch it, but pull is a good thing to start with.

It can take some time to pull a docker image over the net, but this image should be one of the faster (its under a kb in size).

When we got the image we can start a container based on the image.

Running the image

Starting a container for the first time is done by using the docker run command, and there are a few important arguments that one can or even should apply.

docker run --rm --name hello hello-world

When running the command like this, we will start a container which we have named hello, when the container is stopped for some reason, it will be removed
we have ensured this by the --rm argument. If you want the container to keep on existing after it has stopped (so that it can be started again), just omit the --rm argument!

Further down the rabbit hole

Running a hello-world application like this might not be very fun, so we could go on with something a bit more useful.

How about installing dependencies in a composer project? That could be useful I bet!

You do not have to install composer or anything locally for this, all that is done in the container.

First off we need a composer file, cause that is the project "base".

Example:

{
  "name": "my/project",
  "description": "Just testing docker!",
  "require": {
    "jitesoft/exceptions": "2.2.0"
  }
}

Put the file in a empty directory and open the terminal there.

After creating a composer file we will need to find a composer image that we like. I personally always use one I made myself which can be fetched with docker pull jitesoft/composer.

When we got the composer image we will want to run the image... but we need to add the files to the image someway...

Docker and volumes (filesystem) is kind of a special thing and there is a whole lot of stuff to learn about it but in this case we will go the easy way and just share a volume!

Sharing a volume with a container is done when its started and the command looks something like this:

docker run --rm -v $(pwd):/app jitesoft/composer install --no-interaction

This will start a container which is based on the jitesoft/composer image, the image will have the current directory ($(pwd) will put that into the command) to the /app directory in the container,
it will run composer install --no-interaction and install the dependencies that is required, then it will stop and clean up itself (remove due to --rm).

More run arguments!

There are a few more arguments in the docker run command that I find very useful to know about:

Detached:

-d

The -d argument tells the docker container that you want to be detached from it. This can be useful when running containers that are supposed to be long lived.

Port:

-p <local-port>:<container-port>
--port=<local-port>:<container-port>

With the -p argument you can map a port from the container to the local computer. Say for example that you want to open the containers port 80 (standard http port) to your local machines port 8080 you would write something like:

docker run -p 8080:80  nginx

Memory:

--memory=<size>

With this argument you can limit the amount of memory that the container is allowed to use. I always try to set this argument to make sure that the computer don't run out of memory if I made something very wrong! (yes it has happened, on a live server!).

You can find all the arguments at the official documentation.

This post is cross-posted from my blog and can be found here: https://jite.eu/2017/9/1/docker-intro/ (including a bunch of other posts!).

Wtf is git?

Johannes — Mon, 26 Nov 2018 10:58:38 +0000

Introduction

Version control... One of the corner stones of the development process.

There are a lot of Version Control Systems, but the one mainly used in my field of work is Git. I work a lot with git and I work a lot with people who use git. But now and then a person who has not used git earlier comes along. This post is intended to give some basic information on how to work with Git and a general idea of what it is. It's mainly written for people with some basic knowledge of some type of version control system but should hopefully give something useful to people whom have never used any too.

As always, if you find any oddities, let me know in comments and I'll take a look as soon as possible!

What is Git

Git is a version control system, a program which saves differences between files - sort of like a checkpoint - it even creates a history of file changes.

It's not just useful for creating a history of changes though, it's also one of the core parts of a development project.

Each developer in the project run their own git client, each time they have made a change they commit the change to their local git repository. Whenever they feel the need or feel that it's time to do so, they push their local changes up to a server, a remote.
When a developer have pushed their changes, the other developers can pull the changes down from said remote to their own code base and then push their own! The remote repository will always contain all developers (pushed) file changes!

Most developers have an idea of what Git is, I bet that even most developers nowadays use it in one or another way. But a lot of developers have only had the chance to learn the basics of it, and even more have no idea how to use the git Command Line Interface (CLI) in a good way. Now, that's okay, if you dont want to use the CLI then dont, using a git GUI is not a bad thing! But the point of this post is to give some info on how to use the git CLI and how to commit, merge, push and pull with it.

The repository

Initializing and cloning a remote repository

When a project is first started someone should set up the remote git repository.
The remote server in the following examples will be github, (which is a free-for-public-projects type of git remote server), there are a lot of sites to sign up for free hosting of git repositories, and one could host their own git server, but github is one of the most well known, so to make it easy, github is used in the examples.

The easiest way is to just set it up by clicking "new repository" in the menu and choose a repository name (the description, readme and license is quite self explanatory, so I'll leave that to you to try out).

When the repository has been created on the remote, it's possible to clone the repository. This can be done either by using the http protocol (https even) or ssh.
If the repository is public, you don't have to log in locally, but if it is git will tell you how!

Cloning is done quite easily by the following command (in a directory where the project should be):

git clone git@github.com:some_user/some_repository.git

After a wait (which depends on how large the repository is) the repository will have been downloaded locally to your folder.

Any changes to the local repository will not be on the remote repository if no push is made.

Initializing with init

Another way to start of a project is to not have it on the remote from start. This can be useful if you have not yet decided where to put the repository, or just want to create and start of before you even bother sharing it with others.

To initialize a local git repository, you use the following command:

git init

Now, this creates the files that git requires (placed in a .git directory in the project dir) and you can now make changes and commit them to the local repository.

At any time you can add a remote server.

git remote add origin git@github.com:some_user/some_repository.git

note: origin is the name of the default remote.

Now the remote is the same as the one in the clone example!

Committing

Committing is a word that - for me - was a bit confusing as I came from a SVN (which is another version control system) background. In SVN, commit means that you commit your changes to the server. It does not mean that in git. In git, commit means that you "save" the currently added file changes to the local repository.

Before you can commit, you will have to add the files you wish to commit.

Adding files is done with git add <file>, thats all. Although before committing, I would recommend that you check the difference between your file and the changes last committed, so you can be sure that you didn't make some changes that you didn't intend to do (git diff <file>).

After adding the changes that you wish to "save", the commit command is used. When you use the commit command you should always leave a message. The message you leave will be stored locally and whenever you push, on the remote and will make it easier for both you and any possible collaborator to see what the meaning of a given commit is.

The commit message should describe the changes you made, not in depth, but at least so that you or anyone looking in the logs can understand what you where thinking.

Always leave a message!

Committing is done with the git commit -m "Message" command, and after that is done, you will have a "checkpoint" in the code!

If you feel that the message is too long, that you did too many changes, you have done wrong! Don't fret though, most people who start with git does this - to be honest, I still do from time to time - but best practice is to commit often!

So, in conclusion:

# Edit file a.txt and b.txt
git add a.txt b.txt
git commit -m "Updated a.txt with something and changed b.txt with something else!"

Pulling and Pushing

Push is the word that is used for sending your code to the server. This is often done when you have made enough changes to complete a specific task, or in some cases, at the end of the day or at a specific time, depending on the project and team (I'll describe my personal flavour of git-flow in a later post, but for now, lets leave it at this).

Pull is the word that is used for fetching the data from the server and add it to your own codebase.

Push without pull?

A good rule of thumb is to never push your changes without first checking if there are other changes on the server first.

When you push data to the repository, all the changes that you made locally will be tried against the server codebase. Luckily, git does some checks before merging, that means, you can't actually push code to the server that will interflict and it will let you know instead, nevertheless don't do that.

So before pushing, you should do a pull...

Is it safe to pull?!

No, it's not always safe to pull.

That might sound like pulling will kill you, but it's not that bad!

If you pull and there are changes on the server that interflict with your changes, there will be merge conflicts. Merge conflicts are okay, it's something that you will have to deal with every now and then, but there are ways to avoid it as much as possible.

Tip number 1: Use branches!

Small disclaimer: This part is mainly personal preferences, other people might disagree, but this is the way that I feel have been working best, especially while we have had junior developers in the team!

Always work in branches.

When you have a task, create a branch. There is always a remote branch that the team will merge all their changes into, that branch is usually the best one to start of from, to use as base for your branch.

Checkout the branch with the git checkout <branch name> command and make sure it is up to date with the remote (by pulling). If you have not changed anything yourself in the branch, it should be totally fine to pull, no merge conflicts should be possible. Then, when it's up to date, create a branch from it with the git branch <your new branch name>. When the branch is created, check it out with the git checkout <your new branch name> command, and you will have your own branch, ready to develop in!

Whenever you are done with your task, you commit all your changes. When committed, you make sure that there are no conflicts between your and the other branches code, and then you can merge!

It's possible to merge on the remote server, in some cases it's easier, as it will give you a lot of info about merge conflicts and such, but I prefer to do it locally and in this post I will describe how to do that.

In conclusion:

git checkout develop    # Checkout the develop branch which will be used as base.
git pull origin develop # Make the develop branch up to date with remote.
git branch my-branch
git checkout my-branch  # Now the current branch will be 'my-branch'.
# Edit file a.txt and b.txt
git add a.txt b.txt
git commit -m "Updated a.txt with something and changed b.txt with something else!"
# At this point, the local repository have your changes in the my-branch branch!

Diff

The git diff command is not only used to show the difference between your current changes and your last commit, it can also be used to show differences between two branches.
When you do this, you will get detailed information about what changes has been done that conflicts. With this info it's possible for you to fix the potential merge conflicts even before they are merge conflicts!

To check the diff, you use the git diff <your new branch name>..<the other branch> (note the two dots), this will show you the difference between your branch and the other branch at their current state.

When you check the diff, you can see where both you and the other branch has changes in the code at the same place, those places are where the merge conflicts might happen. Fix those, and you won't have to see a conflict ever!

And then we pull..?

No...

After we have diffed the branch, we merge the other branch into ours, we make sure that our code and the remote code are at the same point + the changes made in the new branch!

I always recommend people to use the --ff-only argument. The --ff part means "fast forward" (add all your commits onto the other branches commits without merging the commits together). The only part makes the whole thing a slight bit safer. If git can't fast forward (because of a conflict) it will say that it cant, and the code will stay as when you first typed the command. I use it like sort of a dry-run. If it does complete successfully, I'm happy, if it does not, I know so and prepare to fix the conflicts!
If there are conflicts, I usually remove the only and fix the merge conflicts.

git merge <other branch> --ff-only

Oh no! Conflicts!

Conflicts happen, and it's okay! Whenever you encounter a conflict, you should deal with it. Don't panic, it might be a pain, but it's fixable!

So what is done when a conflict happens? Well, you should manually merge by starting a merge-tool.

A merge tool is a tool which helps you with the merge (the name kind of hints on that). While the merge-tool is running a few files will be created. The files created will be named filename.orig, and are backup files. If they are still in the folder when you are done merging, it's okay to remove them, they should never be added to the source control.
Remember, it's all quite safe, you will still have your changes saved in the repository, so without doing something really wrong, you won't loose your (or anyone elses) code. I personally prefer the graphical tools that come with my IDE, but not everyone have an IDE, there are free ones online and there is a cli one included in git by default. So whenever you get a conflict, you can start the default tool by typing git mergetool.

The merge-tool will show you the differences and where there are merge conflicts. The conflict is, as stated earlier, a part of the code which has been changed both by you and someone else.

There is usually an option to select either your or the other persons parts of the code, but you could also use both, or change it to something completely different!

When the merge conflicts are fixed, you commit the files and resume the merge.

At the end, you will have a branch which contains both your code and the other branches code. And that's when you can push (or rather (imho) create a pull-request).

The push command

When you are done with your merge it's always a good idea to make sure that none in the team have had the audacity to push while you where merging! Hehe... Do the above routine again to make sure, and when you see that there is nothing left to merge, you can push to the remote.

If you use your own branch and will be creating a pull-request, just push the branch with the git push origin <my branch name>, but if its a shared branch, use that as name instead.

When you have finally pushed the code to the server, the whole cycle starts once again!

Last words

Hopefully the information above have given you an idea how to git. It's not that hard, and it's really not that scary!

There are a lot of commands and a lot of different ways to do stuff with git, but this is the absolute basics, the parts that you need to know to use git in a decent way.
But remember, the most important thing of all when it comes to using git (or any other type of development tool), is to try to use it the same way as your team does. And never be afraid to ask! It's better to ask and get an answer than to do it wrong and have to fix stuff!

This post is cross-posted from my blog and can be found here: https://jite.eu/2017/12/19/git-intro/ (including a bunch of other posts!).

I'm a developer who hit a brick wall, Ask Me Anything!

Johannes — Fri, 23 Nov 2018 08:48:14 +0000

Hi there! Thought I'd give you a "short story" about my life as a dev and what made me hit a brick wall...

I'm not really sure that this is a good AMA, but I thought I'd write it, both to give me some type of closure and if possible, being able to answer some questions, maybe even in the long run answer questions that I haven't yet figured out myself!

My story:

I've always (since I was 5 and we got our first computer) been interested in development, my big dream was to work with games, building games, something that I actually achieved!
I started studying programming after highschool, my educational life is quite boring, but I initially studied webdevelopment/webdesign, and moved on to C# programming at a school which gave me nothing more than a further interest in development. When I was ~20 or so, I applied to a school which was specialized in game development and I got in.

After the education I got a job at the place where I had my internship, the company was not a rich company in monetary resources, but it was really fun to work there, I really loved it, even though I didn't make much cash. Around this time, my wife gave birth to our first child.

I have always (since the age of 9 or so) had issues with stress, normal load is not that bad, but crunch and bad structures makes me stressed, so stressed that I have been at the ER multiple times with gastritis and have had cronical headache and migraines since waay back.
Having a small family and a job which gave me just enough cash to keep pay the rent and food was stressful, not so bad that I wanted to quit, but due to unfortunate events, the company
went bankrupt when I had worked there for about two years.

As a dev, it's not very hard to get a new job in Sweden, it took me a few weeks of slow-paced searching till I found a new one. This was not within game development,
something that made me a bit sad, but I figured that due to my current life, I had to make some cash.

During my first months of the new work, my wife gave birth to our second child.

Working with web and application development was something I actually enjoyed quite a lot. But the big issue with this company was that there where
very few, next to no, structures. We (the people working there) didn't really know what we where expected to work with, the boss was away a lot and we could be
alerted that it was deadline the evening before instead of letting us know ahead of time so that we could work in normal pace.
As you probably can guess, this was quite stressful and it took its toll.

After a couple of years, I chose to quit that job, move to another town and take up a new one.
The new one promised a lot of great things, a higher salary, a lot of perks and so on. Well, as it was a startup, it was mostly promises, and due to one of the other people working there - who disliked me for reasons I have no idea of - who had a more senior role than me (being able to punish and behave badly) I became quite depressed. After about a year or so in a culture that was quite bad to me, I started having panic attacks.

I, as most other people in this type of situation, thought I'd be able to cope with it, that I was "strong", but after a while it became too much, I had panic attacks multiple times a day,
something that made it impossible for me to work (could be pretty much a zombie for a couple of hours after), something that happened pretty much as soon as I had any type
of social interaction. The whole thing was bad and during this time, my wife gave birth to our third child.

I decided to contact the health services and they called me in on a emergency meeting.

I was on sick-leave for over a year... During the first few months I couldn't touch a computer, I couldn't have people over (not even my parents or siblings)
and most of my social interaction with my wife and kids was me being irritated and angry. Something that put a strain on my marriage, something that I can still (almost 4 years later) notice.

If I could go back in time today, I would have done a whole lot different, but yeah... that's not possible, so I hope that my experiences could at least give someone a hint of when to stop, when to ponder on life and consider changing it before hitting a wall and being forced into a state that in many ways are irreversible. A state which I still have a lot of both physical and physiological issues from.

Being strong is not to endure it, being strong is being able to say stop and to accept that you cant keep going this way.

It's okay to not being able to do everything and it's okay to ask for help.

Observe: I have only my personal experience from this type of things, any recommendations I give should NOT be seen as professional opinions (when it comes to anything but development that is),
Any advice I give should be treated as a layman advice or just as an advice from a fellow peer, nothing more than that.

Also worth noting: I live in Sweden, and Sweden have free healthcare, which made it possible for me to get help without having it destroy my economy.