JobsToMail is an open source web application that allows users to sign up to receive emails with jobs from one of several job boards supported by the JobApis project. Users can sign up to receive jobs for free at www.jobstomail.com or use the setup instructions below to run the application on their own server.
This application is built on Laravel 5.3 using the Jobs Multi and Jobs Common packages. The frontend uses Bootstrap v4 and Gulp.
This application is only designed to work with PHP 7.0+ and Postgres 9.5+. Some backwards compatibility may be possible, but is not officially supported at this time.
Installation requires the following:
The recommended installation method is Composer.
- Use composer to create a new project:
composer create-project jobapis/jobs-to-mail
-
Copy
.env.example
to.env
and customize it with your environmental variables. -
Run
npm install && gulp
to build the frontend. -
Run the built-in web server to serve the application:
php artisan serve
. -
Visit the local application at
localhost:8000
. -
Once at least one user has signed up, you can run the job collection and email command:
php artisan jobs:email
.
-
After it's deployed, you should be able to visit your app and see the home page.
-
Set an application key by running
heroku run "php artisan key:generate --show" --app=j2m
and adding the key that is displayed to your app's config variables. -
Add a job in Heroku Scheduler to run
php artisan jobs:email
every night. This will ensure that users receive their emails.
- A server running Linux Ubuntu 16.04+
- PHP-FPM
- NGINX
- Use composer to create a new project:
composer create-project jobapis/jobs-to-mail
-
Copy
.env.example
to.env
and customize it with your environmental variables. -
Run
npm install && gulp
to build the frontend. -
Point NGINX to serve to the
/public
directory. Your NGINX config block should look something like this:
server {
listen 80;
server_name yourdomain.com;
root /home/user/jobs-to-mail/public;
index index.html index.htm index.php;
charset utf-8;
location / {
try_files $uri $uri/ /index.php?$query_string;
}
location ~ \.php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
}
-
Ensure that PHP-FPM is running, and ensure that your site is running at your domain.
-
Create a cron job to run the job collection and notification process nightly:
php artisan jobs:email
.
After users sign up for a job search, the only thing needed to collect jobs and send them emails is the following command:
php artisan jobs:email
This command will loop through each user, collect jobs based on their search criteria, and then email them when their list has been compiled.
Because this job search can take a long time, it is best to use a queueing system and run the job in the background (via cron job). Instructions for setting this up in Heroku are above, but if you have trouble, you can post a question to the Issues tab in the Github repository.
You can also run this job for only one email address in your system when testing or debugging:
php artisan jobs:email [email protected]
Tests are run using PHPUnit. We also employ Faker to help with producing fake data and Mockery to mock dependencies in unit tests.
- Run all tests
vendor/bin/phpunit
Code coverage reports are automatically generated, and can be found in the /build
directory after running the test suite.
If you're doing local development, you may find it handy to seed the database with some test data. Using Laravel's seed commands you can do just that:
- Truncate and seed the database tables
php artisan db:seed
- Seed only
php artisan db:seed --class=TestingDatabaseSeeder
- Truncate only
php artisan db:seed --class=DatabaseTruncater
Note: Truncation is permanent, so be careful running this in your production environment.
Contributions are welcome and will be fully credited.
We accept contributions via Pull Requests on Github.
-
PSR-2 Coding Standard - The easiest way to apply the conventions is to install PHP Code Sniffer.
-
Add tests! - Your patch won't be accepted if it doesn't have tests.
-
Document any change in behaviour - Make sure the
README.md
and any other relevant documentation are kept up-to-date. -
Consider our release cycle - We try to follow SemVer v2.0.0. Randomly breaking public APIs is not an option.
-
Create feature branches - Don't ask us to pull from your master branch.
-
One pull request per feature - If you want to do more than one thing, send multiple pull requests.
-
Send coherent history - Make sure each individual commit in your pull request is meaningful. If you had to make multiple intermediate commits while developing, please squash them before submitting.
This is open source software, so share away. For more detailed information, see the license.md file.