How to build a great MVP, fast

Corentin H. ⚡ — Wed, 05 Apr 2017 22:00:00 +0000

One of the first things a startuper has to do to get started is building a basic version of their app/website/product to show it to investors. This MVP often needs to be done fast, without sacrificing quality.

After working on a few MVPs, we have picked up a few tricks that might help you get your product up and running quickly.

Summary

Don’t try to reinvent the wheel
Pick the right tools
Choose the right people
- Look at their past projects
- Socialize

Don’t try to reinvent the wheel

One of the common pitfalls when building a new software product is to build it from scratch. We get it, your app/website is different than the others. That’s why it’s better.

Except it’s not that different. Whether you’re building a social network, a mobile app or something else, chances are similar products already exist. They might not be exactly the same (which is probably why you’re building your own), but they do pretty much the same thing.

So why build your product entirely from scratch when others have already done most of the job for you? Look online: there are probably many solutions (open source or otherwise) that could help you save a lot of time.

Use those tools! You’ll be faster and you can even use some of that free time to do other things, like:

Work on the other sides of your projects (business, marketing, contents…)
Build more functionalities, make your product even better
Improve the design, polish up the code
Give back to the open-source community by sharing some of your code
Help others learn by publishing what you discovered
Rest (if you’re an entrepreneur, you probably need some) and go be with your loved ones

Pick the right tools

Don’t be afraid to spend a few days, or even a couple of weeks, seeking and trying out a bunch of tools that might suit your needs.

If they save you a month’s worth of work, you can see why it’s a good idea to spend a few days testing them. If so many people use WordPress or Express nowadays, it’s for a (very good) reason: it saves (a lot of) time.

So don’t hesitate: test them, push them to their limits!

Study them
Read some of the code
Look at the documentation
Speak to other users
Read others’ opinions
Break them, don’t be shy

Choose the right people

If your project isn’t tiny, chances are you will need to recruit people to help you build it. But you probably don’t want to take the risk to hire someone who doesn’t suit your needs. And you’re right, you should be careful enough to make sure your beloved project becomes successful!

I won’t give you a Recruiting 101 lecture in this article, but there are a few key points that might help you a bit.

Look at their past projects

If you want to make sure someone is capable enough, you should take a look at what they have already built.

Did they write clean code?
Did they cover edge cases?
Did they use appropriate tools?

Socialize

If you’re gonna be working with someone, you should make sure you can work together. See if their personality suits you, if you can talk to them easily. You don’t have to be BFFs, but you should at least be able to chat.

How to set up your own GitLab server

Corentin H. ⚡ — Tue, 14 Feb 2017 23:00:00 +0000

One thing developers can’t ignore nowadays is Git. So why not use your own server?

Note : This is the first post of this serie, aimed at helping you set up a full dev environment with GitLab, Docker and some other tools.

Summary

But wait… Why should I use my own Git server?
OK, I’m sold. What do I need?
All checks are green. How do I install that?
Great. So how do I use nginx as a proxy?
- Configure the socket to use the GitLab Workhorse
- Configure the site in nginx
- Configure GitLab to work behind nginx
What’s next?

But wait… Why should I use my own Git server?

This may have been the first question that came to your mind when you saw this title. And you’re completely right to ask yourself that.

There are many reasons why having your own Git server is useful, but keep in mind that it all depends on you: if you don’t feel like you need one after reading a few lines of this post, then you might not need it. And that’s okay!

Anyway, here are some of the reasons why I installed my very own private Git server, that I now share with Éric:

It’s (almost) free. You just need to pay for the server itself
It’s private. Nobody else can access your repos and data
It’s self-managed. You don’t depend on an external provider (except, maybe, your hosting company)
It’s easy. There is almost nothing to manage on a regular basis, and the setup process is fairly accessible
It’s complete. There are already a bunch of options on GitLab that you can find on other providers like GitHub or Bitbucket, like:
- Issue tracking
- Webhooks
- Teams & User access
- Continuous development

OK, I’m sold. What do I need?

Well, first you need to have your own server to host GitLab.

You should also make sure that it is powerful enough to make GitLab CE work. Check out this page to know all about the requirements.

In this case, I have been using a Ubuntu 16.04 system, with 4 cores and 4 GB of RAM and a bunch of storage. The CPU capacity is enough, though the RAM is a little short if you want to use the same server for other things (CI, Docker deployment, regular hosting, etc).

The same server is already used for other projects, served by nginx, so I will reuse it.

All checks are green. How do I install that?

Well, no better way to do it than by following the docs:

sudo apt install curl openssh-server ca-certificates postfix
curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash
sudo apt install gitlab-ce

You now have a shiny GitLab server, ready to be started and used. But if you already have a web server on the same machine, you might need to configure it to redirect to the GitLab Workhorse.

You can stop here if you only have GitLab of your machine, as il will listen on port 80 by default. Just execute the sudo gitlab-ctl reconfigure command and you’ll be good to go.

Great. So how do I use nginx as a proxy?

First, check that you have Passenger installed. If not, you should install it alongside nginx, it’s really helpful.

Then, you may create a file for your site in the nginx directory. Let’s call it gitlab.helyo.world.

sudo nano /etc/nginx/sites-availables/gitlab.helyo.world

Yes, I use nano. Not vim. Not emacs. Good ol’ nano. Deal with it.

Configure the socket to use the GitLab Workhorse

upstream gitlab-workhorse {
    server unix://var/opt/gitlab/gitlab-workhorse/socket fail_timeout=0;
}

Configure the site in nginx

server {
    listen 80;
    # listen [::]:80; # Uncomment if you use IPv6

    server_name gitlab.helyo.world;

    root /opt/gitlab/embedded/service/gitlab-rails/public;

    access_log /var/log/nginx/gitlab.helyo.world.access.log;
    error_log /var/log/nginx/gitlab.helyo.world.error.log;

    client_max_body_size 500m;

    passenger_ruby /opt/gitlab/embedded/bin/ruby;
    passenger_env_var PATH "/opt/gitlab/bin:/opt/gitlab/embedded/bin:/usr/local/bin:/usr/bin:/bin";

    passenger_user git;
    passenger_group git;

    passenger_enabled on;
    passenger_min_instances 1;

    location ~ ^/[\w\.-]+/[\w\.-]+/(info/refs|git-upload-pack|git-receive-pack)$ {
        # 'Error' 418 is a hack to re-use the @gitlab-workhorse block
        error_page 418 = @gitlab-workhorse;
        return 418;
    }

    location ~ ^/[\w\.-]+/[\w\.-]+/repository/archive {
        # 'Error' 418 is a hack to re-use the @gitlab-workhorse block
        error_page 418 = @gitlab-workhorse;
        return 418;
    }

    location ~ ^/api/v3/projects/.*/repository/archive {
        # 'Error' 418 is a hack to re-use the @gitlab-workhorse block
        error_page 418 = @gitlab-workhorse;
        return 418;
    }

    # Build artifacts should be submitted to this location
    location ~ ^/[\w\.-]+/[\w\.-]+/builds/download {
        client_max_body_size 0;
        # 'Error' 418 is a hack to re-use the @gitlab-workhorse block
        error_page 418 = @gitlab-workhorse;
        return 418;
    }

    location @gitlab-workhorse {
        ## https://github.com/gitlabhq/gitlabhq/issues/694
        ## Some requests take more than 30 seconds.
        proxy_read_timeout 3600;
        proxy_connect_timeout   300;
        proxy_redirect off;

        # Do not buffer Git HTTP responses
        proxy_buffering off;

        proxy_set_header    Host $http_host;
        proxy_set_header    X-Real-IP $remote_addr;
        proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header    X-Forwarded-Proto $scheme;

        proxy_pass http://gitlab-workhorse;

        ## The following settings only work with NGINX 1.7.11 or newer
        #
        ## Pass chunked request bodies to gitlab-workhorse as-is
        # proxy_request_buffering off;
        # proxy_http_version 1.1;
    }

    ## Enable gzip compression as per rails guide:
    ## http://guides.rubyonrails.org/asset_pipeline.html#gzip-compression
    ## WARNING: If you are using relative urls remove the block below
    ## See config/application.rb under "Relative url support" for the list of
    ## other files that need to be changed for relative url support
    location ~ ^/(assets)/ {
        root /opt/gitlab/embedded/service/gitlab-rails/public;
        gzip_static on; # to serve pre-gzipped version
        expires max;
        add_header Cache-Control public;
    }

    error_page 404 /404.html;
    error_page 422 /422.html;
    error_page 500 /500.html;
    error_page 502 /502.html;
    error_page 503 /503.html;

    location ~ ^/(404|422|500|502|503)\.html$ {
        root /opt/gitlab/embedded/service/gitlab-rails/public;
        internal;
    }
}

Configure GitLab to work behind nginx

You will need to open the /etc/gitlab/gitlab.rb file to change a few lines:

external_url 'http://gitlab.helyo.world'
gitlab_rails['internal_api_url'] = 'http://gitlab.helyo.world/'

unicorn['enable'] = true;

web_server['external_users'] = ['www-data']

nginx['enable'] = false

Then tell GitLab to apply these changes:

sudo gitlab-ctl reconfigure

And you should be good to go! You can now visit your domain and get started. You will be asked to configure the root account’s password before you can log in.

What’s next?

Well, if you want to have a secure environment, you should consider switching to HTTPS. So we’ll see how to do that very soon!

DEV Community: Helyo World

How to build a great MVP, fast

Summary

Don’t try to reinvent the wheel

Pick the right tools

Choose the right people

Look at their past projects

Socialize

How to set up your own GitLab server

Summary

But wait… Why should I use my own Git server?

OK, I’m sold. What do I need?

All checks are green. How do I install that?

Great. So how do I use nginx as a proxy?

Configure the socket to use the GitLab Workhorse

Configure the site in nginx

Configure GitLab to work behind nginx

What’s next?