I have wanted to start a business for a long time now. But I’ve never done it before, so into the YouTube rabbit hole I went. Got some book recommendations and started reading them. From there, I found more books that I felt I needed to read before I deemed myself qualified to start a business. Sound familiar?

You may already know this, but deep down you probably don’t think you are unqualified. Consuming content is just so much easier than taking the steps to learn something new and inherently failing at things.

Reading self-help books gives you the illusion that you are learning and making progress in what you want to achieve.

Don’t get me wrong, I am not saying that the books are bad. What I am saying is to put the things you read into action. If you don’t do this, you will stay in your comfort zone of just reading and not truly learning.

If you wanted to learn to swim, would you pick up a book? Probably not. You would go to a local swimming pool and get lessons. What do those lessons do? They don’t put you in a school bench to tell you how to float; they give you instructions, and you immediately get in the water to practice.

See what I’m getting at here? You need to put every lesson you learn into action immediately, or you’ll learn nothing from it.

When you read a self-help book, I want you to do what you would in a swimming school, or any other learning environment. Take notes on the things that stand out to you. As we know, taking notes while learning helps you remember the material. So, take notes, highlight interesting quotes, and write yourself a summary. But we’re not stopping there.

The last important step is to get you out of that comfort zone. Since you won’t be tested or thrown into the pool by your teacher, you have to do this yourself. With every chapter or lesson you learn, create an action point for yourself. And now put it to practice. When you finish a chapter and have a few points, start putting those into action before the next time you pick up the book. You could see it as homework you need to do before the next lesson. This way, you’ll get yourself out of that warm and cozy comfort zone and start moving towards your goal.

When you follow these steps, you won’t feel the need to read another book before you can get started because you already did! Of course, at some point, you might want to learn a new skill related to your goal, and it’s perfectly fine to get another book to learn that skill, as long as you follow these steps again. Remember, Rome wasn’t built in a day, and neither will your dreams be. But by taking action, you’re already building the foundation.

So, let’s put this post into practice right now, shall we? Highlight the points in this post that bring value to you, and create some specific action points based on what you’ve learned. Since there won’t be a next lesson for this class, how about setting a deadline? Execute the action points you made before next week and start building that base! Remember, the goal is progress, not perfection — every small step counts.

Thank you for reading this, and good luck!

Got a lot of machines to connect to? It gets really annoying to memorize the ip's. Use this tip to give names to the connections and easily connect to the names instead of the ip's.

In your users home folder create or go to the /.ssh folder and create a file named config. In this file add the following lines for each connection you have.

Host my-local-address
    HostName 127.0.0.1
    User username

Cool! After you save the file you can, with this specific example, connect to the ip 127.0.0.1 by using the command `ssh my-local-address`.

As you can maybe imagine the are plenty more options to be entered here. But this being a quicktip, I am not going to explore these with you. If you want to know more, check out this article which shows a lot more: https://linuxize.com/post/using-the-ssh-config-file/#ssh-config-file-location

As developers we want our stuff running as quick and easy and cheap as possible. Why else would you keep working on that side project, am I right? So for this the best option I have found is to publish my frontend projects to Amazon's AWS S3. The first year is completely free and after that time it is still dirt cheap. So in this tutorial I will show you how you can deploy your Angular app to AWS S3 automatically with Gitlab CI!

Step 1: The build

First of all we want Gitlab CI to build the project so that it can be deployed in a later stage. For this we need to make a file called .gitlab-ci.yml in your repository. In this file we are going to make a stage to build the project:

build:
  stage: build
  image: node:lts-alpine3.11
 
  cache:
    key: build-cache
    paths:
      - node_modules/

  script: 
    - "npm install -g @angular/cli"
    - "npm ci"
    - "npm run build-prod"

  artifacts:
    paths:
      - dist/

As you can see we are using a node image to build the project. In the script section the real building magic kicks of: First we install the Angular CLI, next we run the CI-friendly npm install just like you would when you get a new project on your machine. And last but not least we run build-prod. If you've worked a lot with Angular CLI before you can tell this does not exist. Normally you would run ng build --prod. So the next thing to do is put that configuration in the package.json file under the scripts section: "build-prod": "ng build --prod",
When you commit the code with these adjustments you should see your code being build by Gitlab CI automatically!

To make the builds a bit more efficient we added a cache with a key. This means all the node modules don't have to be downloaded every time a build runs.

Step 2: Deployment stage

The next step is to add another stage to the .gitlab-ci.yml file that handles the deployment of the Angular app to AWS S3. For this we will be using the AWS CLI. Luckily, the lads and ladina's at Gitlab have provided us with a docker image on which said CLI is installed. So for the image of this stage use registry.gitlab.com/gitlab-org/cloud-deploy/aws-base:latest. From there only one action is really required, which is copying your files to the bucket. This is done with the cli command aws s3 cp ./dist/my-app/ s3://$BUCKET_NAME/ --recursive. That is it, really! To be fancy I added the bucket as a Gitlab environment, but this is optional.

deploy:
  stage: deploy
  image: registry.gitlab.com/gitlab-org/cloud-deploy/aws-base:latest
  dependencies:
    - build
  script:
    - echo "copying files to s3://$BUCKET_NAME/"
    - aws s3 cp ./dist/my-app/ s3://$BUCKET_NAME/ --recursive
    - echo "Copying files complete"

Notice the $BUCKET_NAME usage in the scripts. That is an environment variable that can be set in Gitlab's variables tab, but we'll get to that later. One other final step is to make the two stages not run simultaneously by adding the stages at the top of the file:

stages:
 - build
 - deploy

Okay, we're almost done with Gitlab. The last thing we need to do is to add the BUCKET_NAME variable, and two others for AWS authentication. You can find this in your project under Settings -> CI/CD -> Variables. Here you can add the following variables:

1. BUCKET_NAME
2. AWS_ACCESS_KEY_ID
3. AWS_SECRET_ACCESS_KEY

These values will be filled in the following steps so don't worry about them for now.

Step 3: Setting up an IAM user with permissions

To make it possible for your Gitlab pipeline to deploy your Angular app to AWS S3 we are going to create a new user that has the permission to put new files in a bucket. If you are familiar with this already feel free to skip this step.

If you haven't already, create an account on AWS. Heads up: I said it was free and it truly is. AWS will ask you for your credit card, and will reserve a small amount (can't remember or find if it was a dollar or a cent), only to verify you. This money will not be actually be written off your card.

AWS can be managed with the online console, a CLI or even an SDK. For now we will use the online console for its ease of use. So login to your account and navigate to IAM. From here you first need to head to Policies and click on Create policy. Click on the tab JSON and add the following:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "darkthemecoder-s3-ci-policy",
            "Effect": "Allow",
            "Action": "s3:PutObject",
            "Resource": "*"
        }
    ]
}

Click on Review policy and add a describing name, I went for the name ci-s3.

Now for the adding a user:

• Go to Users and click on Add user.
• Once again, give it a nice name. I chose ci-user.
• Select Programmatic access and go to the next step.
• Click on Attach existing policies directly and find your policy (You can use the Filter policies function and set it to customer managed). Select it and finish the wizard.
• After creating a user you will get a screen with the Access key ID and the Secret access key. Copy those and add them to the corresponding variables in Gitlab. (If you closed this screen on accident: Don't worry, you can generate a new key in the options)

Step 4: Getting S3 set up

Okay you're almost there. Just two more little steps before you can git push your code and see it being built and deployed automatically. These steps are to create a new S3 bucket, and get it configured to host the website. In other words, make the files in your bucket public.

First, let's create this bucket, shall we?

• Log in to your AWS account and go to https://s3.console.aws.amazon.com/s3.
• From here you can press the button Create bucket which will open a wizard.
• Select a region and enter a "DNS compliant" name, which simply excludes some characters that can mess up the domain name. When you got several words just use a - and you're golden.
• In the next step, Configure options, you can leave everything unchecked as they are optional features that can cost extra.
• In the Permissions step uncheck the Block all public access toggle, and acknowledge the warning message.
• Review your settings in the next step and click Create bucket to do exactly what the button says.

Hooray, you've got a bucket! Now, very important: Set the BUCKET_NAME variable in your gitlab settings to the bucketname that you have just created.

To make the bucket a website host follow these steps:

• Navigate into your bucket and click on the tab Properties.
• Click on the card Static website hosting to open it.
• Click on Use this bucket to host a website and make sure that Index document is set to index.html and hit Save.

Okay this is truly the last step: Navigate to Permissions and add the following json to the Bucket Policy button:

{
    "Version": "2012-10-17",
    "Id": "PublicSitePolicy",
    "Statement": [
        {
            "Sid": "WebsiteRead",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::YOUR-BUCKETNAME/*"
        }
    ]
}

You might have noticed the subtle YOUR-BUCKETNAME in there. Change that to your bucketname to make the policy work. Hit that Save button in the top right corner and it is all set! You can now start your pipeline by pushing your code and see your files appearing in the bucket.

To see your actual site, and not just the files; In your bucket go to Properties again and click on Static website hosting to see what the webaddress is of your now public bucket.

Oh oh oh.. also. You can now proudly say that your hobby projects run in the cloud. You're welcome ;)

Conclusion

I hope this tutorial helped you! If you got any feedback and/or questions or feel free to reach out to me on Twitter and of course, don't forget to follow me if you enjoyed this and want to be notified of coming tutorials.

Love, Darkthemecoder

Recently I've been looking at the potential of the serverless frameworks Quarkus and Micronaut. They look really promising, and therefore I tried to convert a Spring Boot service to a Quarkus service. In this blogpost you will find the actions that you have to take to do it yourself, and some noteable thing that I have learned in the process.

Build

First of all, Quarkus only supports Maven at this point. For Gradle a preview has been brought out, but if you're going for a production app, that's not the stable option you want to take. So if your Spring Boot app is currently built with Gradle, I'd suggest converting it to make use of Maven.

Database connection

Quarkus has hibernate to connect to a database with the needed database drivers like MySql, Postgress, H2 in-memory and so forth. The Quarkus team have provided an simplified implementation called "Panache". It works quite similar to the Spring JpaRepository works and it provides an extra way of accessing the data, called the Active Record Pattern. In a Spring to Quarkus migration you probably don't want to move to that solution.

For migrating a Spring repository to a Quarkus Panache repository you have to change a couple of things:

• Your Spring repository is an interface, in Quarkus it is a class
• Quarkus' Panache repository method names are different from Spring's repo
• All persisting methods need @Transaction to work when called

Spring repo:
public interface PersonRepository extends CrudRepository<Person, Long>

Quarkus repo:
public class PersonRepository implements PanacheRepository<Person>

Little extra note for those with an import.sql script in their SB application: The naming convention that Spring Boot has differs a bit from Quarkus' implementation when it comes to camelcase. Where the field paymentDate is converted to the sql field payment_date in Spring, it is converted to the sql field paymentDate in Quarkus. So keep in mind that you either change the fieldnames in your import.sql or add an hibernate property to change this behaviour.

Swagger

For the swagger documentation side of things, not much is needed. In Spring you've got yourself two dependencies generally: swagger and swagger UI. In Quarkus these two are combined in the package quarkus-smallrye-openapi. Besides that, no additional config is needed for basic usage. Include the dependency and access it at /swagger-ui. Note that this only works in dev mode. To use it on production you just add quarkus.swagger-ui.always-include=true in the property file.

Property files

Another notable thing is that your yaml configurations from Spring don't work out of the box; you are going to need an extra yaml-config dependency. Another big change are the property profile files. That does not exist at the moment in quarkus. If you want to have several profiles it is going to look like this:

quarkus.http.port=9090
%staging.quarkus.http.port=9999
%prod.quarkus.http.port=8080

Missing

Last but not least, Quarkus' age. The framework looks really promising and already has a good collection of extensions to make some cool stuff. However it looks like the developers aimed at quantity of extensions instead of the quality. I'm not saying they are bad, they are just far from complete or completely missing. A lot of features that you take for granted when using Spring are either in "preview", incomplete or simply missing. Therefore going to production with more complexity than simple REST endpoints is to me not a good idea yet. But I will surely be frequently playing with it and tracking its process and hoping that it will improve soon.