Here at Vinta we believe that programmers, not processes, nor code, are the most important assets on software engineering. Due to that, we believe in using every tool available in order to facilitate our programmers' lives. One of our favorites is our boilerplate. If you are unfamiliar with the concept, a boilerplate is "any code block that is reusable in new contexts with minimal alteration". In this post, we will show you guys some examples of famous boilerplates, why we did our own, and how it looks so far, so you feel comfortable with using it or editing it to fit what you need.

Famous boilerplates around and why to use them

You probably have already seen some boilerplates around, it can be the simplest bits of code or even a default project template for Django. They are all templates, and it's easy to see their advantages. On this lower level of complexity, they are good to guarantee coding standards across projects. But you can check more complex ones like the HTML5 boilerplate, the Cookiecutter Django, the Django Hackathon Starter or even Vinta's boilerplate (which comes with a whole set of facilities we will discuss in a moment). These bring even more advantages to the table such as a speed-up on the initial project.

How about building your own?

We believe that the best solution still is to create your own boilerplate, besides increasing the benefits already listed here, you'd also get:

• a Full-stack solution custom-fit to your environment
• an easy way to create and maintain guidelines for your projects company-wide
• reduced errors
• keep the project template updated

the idea behind making your own boilerplate is simple: no one knows the needs of your company better than you. So the first thing you should do in order to build your own, first write down and discuss around the company "what should all of our projects have in common?". This list can go from email sending to VR integration but it's really important to get a list of what are common needs among the projects in your company.

Here is a list of what we thought necessary here at Vinta and the technologies we chose for those needs:

• Backend Framework (Django 1.10 and Django.js)
• Email Sending (Sendgrid)
• Responsive Styling (Bootstrap Alpha 4.2)*
• Periodic Jobs (Redis and Celery)
• Interactive UI (React)
• Continuous Integration (CircleCI)
• Handling Static Assets (Webpack)
• Static Files Serving (WhiteNoise)
• Database (PostgreSQL)
• Easy Deployments (Heroku Button)
• Logging (Papertrail)
• Performance Monitoring (Opbeat)

As you can notice, we use the Alpha version of Bootstrap 4, we strongly encourage you to use it instead of Bootstrap 3, there is a huge list of improvements, for us the best thing is that it got way easier to customize elements and that opened a lot of design options. You can check other advantages here.

Vinta Boilerplate

To show you how easy it gets with your own boilerplate, here is the actual structure of a project using Vinta's boilerplate:

To start coding is easy. Most people don't know that the django-admin startproject command can receive arguments to open on a specific boilerplate, so just use the command django-admin startproject theprojectname --extension py, yml, json --nameProcfile --template=https://github.com/vintasoftware/boilerplate/archive/master.zip then check for dependencies using these lines:

>>> pip install -r requirements-to-freeze.txt
>>> pip freeze > requirements.txt
>>> npm update --save
>>> npm outdated

Update everything that was flagged as outdated, change the first line of README to the name of the project.

The last step would be to set up the migrations, as follows:

• Create a copy of {{project_name}}/settings/local.py.example in {{project_name}}/settings/local.py
• Create a .env file in the root of the project and add DJANGO_SETTINGS-MODULE="{{project_name}}.settings.local" to it
• Create the migrations for users app: python manage.py makemigrations
• Run the migrations: python manage.py migrate

After you start coding, one of the biggest perks is using CircleCI. As said above, we use it for continuous integration, for those who don't remember, continuous integration is: "The practice of merging all developer working copies to a shared mainline several times a day." and that requires a high level of automation with tools, as well as a internal habits to deploy minimal amounts of code. Down here is how a deploy looks like with CircleCI for us. You can check more about the subject here.

if you have any doubts be sure to comment down below and check out the other posts on our blog!