One of the most common complaints I see from hack days is how much boilerplate work there is just to get a project set up. Many hours can be wasted on just getting a Webpack application up and running and it tends to be a lot of the same basic setup code that projects need.
This is where Takeoff aims to step in, by reducing the time-to-development for developers and small teams, and can be used for not only hack days but proof-of-concepts and prototypes.
When I first developed Takeoff, I started with some opinionated defaults, itself the result of a small side project I had been working on at the time.
I realised that I had built a nice layout that could be made into a template for future projects and soon after I found myself writing some scripts to make initialising and working with the environment and from
The idea was to get developers up and running quickly with a database, API and front end that had basic authentication and JWT tokens. Alongside that all the configuration to make this work, and have hot reloading on the client and sever, was done for them.
This worked pretty well, but having a look at the code (and two weeks away from programming while on honeymoon) I realised I could decouple the whole application part as a separate repository and clone this into a local folder to achieve the same goals.
This development came earlier than I expected in the project, but I’m happy to say this had lead to Takeoff now having two blueprints that it ships with out of the box:
- The Basic Blueprint that is always installed by default in the envs/takeoff directory. You can view it’s documentation here which provides information on its API, front end application and how to configure it
- The Wordpress Blueprint provides a local Wordpress install that reads files from your system, so you can develop features and content while serving it within the local docker system. Instructions on how to install this are in the docs.
With this there is updated documentation to support this (The weak spot is still the quality of the default application, but I’m hoping now there are two blueprints out we might start to see more).
Getting started with Takeoff
Currently Takeoff is distributed via a git repository. In version 1.2 it will ship with it’s own CLI tool, but in the meantime the setup instructions are reasonably simple. To start you need git, docker and docker-compose installed on your environment.
> git clone https://github.com/takeoff-env/takeoff.git
> cd takeoff
> npm install
> npm start
At the moment, npm install will not only install the required dependencies it will also clone the default blueprint and use docker-compose to build the environment. Then npm start will bring up the environment available via http://localhost
You can start editing code directly on your local machine within the env/takeoff folder under where you installed Takeoff.
Creating new environments
As mentioned there is a default environments envs/takeoff . The envs folder is not included in source control so it is recommended you set up your own in your folder. If you wanted to set up a new default environment in a different name, you could type:
npm run takeoff:new -- --env=my-new-app
This will create env/my-new-app which you can then start with npm start -- --env=my-new-app . Yes the -- is very important because Takeoff still uses npm scripts to power these commands.
Trying out the new Wordpress blueprint
The new Wordpress blueprint gives a PHP environment using nginx and reads files from you local system, so you can do live changes — again ensure you have your own source control set up.
npm run takeoff:new -- --env=wordpress --blueprintName=wordpress --submodule
npm start -- --env=wordpress
You will then be asked to set up database variables and to write the config file. It is up to you to set your own permissions on folders.
So with both these commands you can be up and running in just a few minutes with your MVP for your next hack day, and spend those precious hours developing instead of being stuck in configuration hell.