I need a Python Django developer and webmaster
- or -
Post a project like this2750
$$
- Posted:
- Proposals: 8
- Remote
- #1283330
- Awarded
Python and Django expert, IT strategy consultant, and internal cloud for SMEs
Royal Leamington Spa
1586044456945115456336165103890255811356341348985
Description
Experience Level: Intermediate
Estimated project duration: Ongoing
Allows UK parents to find a UK based tutor
Kind of development: Customization of existing website
Description of every page/module: The Django application runs on Python 2.7 in a virtualenv
- There are two static folders (normal ‘static’ and user uploaded ‘media’) served by Nginx
- The database is Postgresql with PostGis extension for spatial lookups
- We use Supervisor to monitor the Django application and restart it if it ever fails
- The site uses Memcached
- There are a few cronjobs used to run management commands each night e.g. reminder emails
Webfaction also currently hosts three email addresses, the one used by Lee (team@approvedtutors.co.uk), the one used to send automated emails from the site (admin@approvedtutors.co.uk) and a webmaster one (webmaster@approvedtutors.co.uk), which is where the site sends logging messages to.
A copy of the code can be viewed on bitbucket by invitation.
General
• The backend code is organised into Django apps in the usual way. Some external, open source apps are used (see requirements folder). A few needed tweaking and so they install from forks on github.
• All general Django settings for the site are contained within the global settings file 'approvedtutors/settings.py'.
• Any settings which are specific to the running environment are contained in a 'settings_local.py' located next to the global settings file and imported by it at the end. This is stuff like database settings and also contains all sensitive stuff (passwords etc.) and is therefore not committed to version control. A completely different settings_local is generated from a template for deployment to the server (see deployment).
• Most of the templates for the site are contained in the global templates directory. Some which are contained within the scope of one app are placed inside the app folder.
Front end
• I have been managing front end code using gulp. The gulp file can be found in the root directory. The source code for all the front end is contained in static/src. gulp build-css bundles up site wide, minimised files for css and js respectively and sticks them in static/dist which is where Django expects to find them. The settings file for the server is setup to use ManifestStaticFilesStorage which appends a hash on the end of the name every time they change so that you don't need to worry about browsers caching old versions of the front end code.
Javascript
• The javascript code for the site can be found in the static/src/js directory.
• The javascript code used on the site is now mostly packaged up using browserify to try and make things more modular. As I migrated it, I tried to write tests for anything non trivial that can be executed with Karma. Anything that hasn't been migrated is in the legacy folder.
• To use external js resources (e.g. google maps api) or files loaded from a cdn (e.g. jquery) it is necessary to use browserify-shim. The configuration for this is a bit fiddly but is dealt with in the 'config' directory.
CSS
• The style sheets for the site are all written in Sass.
• lint-sass was recently added to the gulp file to try and enforce some consistency in how the sass is written and have been trying to correct lint warnings when changing a file. It still comes up with a scary amount at the moment but they are mainly complaining about ordering of parameters which is not a big issue.
Testing
• The site has a reasonable amount of automated testing of key features now.
• Tests can be run within the virtualenv using python manage.py test. Often running in development against an SQLite database (you need spatiallite) or using the --keepdb flag with postgresql helps, as running all the tests can be quite long.
• Javascript test coverage is pretty low at the moment but the infrastructure is now there to write and run tests using jasmine and karma. Just run karma start from command line.
Deployment
• Development work has normally been done in git branches off of a 'develop' branch. When stuff is ready to go, its merged into master and then pushed to a remote repository from where the site is deployed.
• There is a fabfile in the root of the application. There are functions to install all necessary packages on the server (except swig - never successfully automated that for some reason - that will need to be done manually), and to deploy the site code to the server. Most of the commands require a prefix of either production or staging to allow for every deploy to be first tested on a staging server before being put up on the production server.
• In short, the deploy routine creates a backup of the database and of the static and media files, does a git fetch on the source code from the remote repository, uploads templates if they've changed, then runs collectstatic and does a database migration before restarting gunicorn.
Kind of development: Customization of existing website
Description of every page/module: The Django application runs on Python 2.7 in a virtualenv
- There are two static folders (normal ‘static’ and user uploaded ‘media’) served by Nginx
- The database is Postgresql with PostGis extension for spatial lookups
- We use Supervisor to monitor the Django application and restart it if it ever fails
- The site uses Memcached
- There are a few cronjobs used to run management commands each night e.g. reminder emails
Webfaction also currently hosts three email addresses, the one used by Lee (team@approvedtutors.co.uk), the one used to send automated emails from the site (admin@approvedtutors.co.uk) and a webmaster one (webmaster@approvedtutors.co.uk), which is where the site sends logging messages to.
A copy of the code can be viewed on bitbucket by invitation.
General
• The backend code is organised into Django apps in the usual way. Some external, open source apps are used (see requirements folder). A few needed tweaking and so they install from forks on github.
• All general Django settings for the site are contained within the global settings file 'approvedtutors/settings.py'.
• Any settings which are specific to the running environment are contained in a 'settings_local.py' located next to the global settings file and imported by it at the end. This is stuff like database settings and also contains all sensitive stuff (passwords etc.) and is therefore not committed to version control. A completely different settings_local is generated from a template for deployment to the server (see deployment).
• Most of the templates for the site are contained in the global templates directory. Some which are contained within the scope of one app are placed inside the app folder.
Front end
• I have been managing front end code using gulp. The gulp file can be found in the root directory. The source code for all the front end is contained in static/src. gulp build-css bundles up site wide, minimised files for css and js respectively and sticks them in static/dist which is where Django expects to find them. The settings file for the server is setup to use ManifestStaticFilesStorage which appends a hash on the end of the name every time they change so that you don't need to worry about browsers caching old versions of the front end code.
Javascript
• The javascript code for the site can be found in the static/src/js directory.
• The javascript code used on the site is now mostly packaged up using browserify to try and make things more modular. As I migrated it, I tried to write tests for anything non trivial that can be executed with Karma. Anything that hasn't been migrated is in the legacy folder.
• To use external js resources (e.g. google maps api) or files loaded from a cdn (e.g. jquery) it is necessary to use browserify-shim. The configuration for this is a bit fiddly but is dealt with in the 'config' directory.
CSS
• The style sheets for the site are all written in Sass.
• lint-sass was recently added to the gulp file to try and enforce some consistency in how the sass is written and have been trying to correct lint warnings when changing a file. It still comes up with a scary amount at the moment but they are mainly complaining about ordering of parameters which is not a big issue.
Testing
• The site has a reasonable amount of automated testing of key features now.
• Tests can be run within the virtualenv using python manage.py test. Often running in development against an SQLite database (you need spatiallite) or using the --keepdb flag with postgresql helps, as running all the tests can be quite long.
• Javascript test coverage is pretty low at the moment but the infrastructure is now there to write and run tests using jasmine and karma. Just run karma start from command line.
Deployment
• Development work has normally been done in git branches off of a 'develop' branch. When stuff is ready to go, its merged into master and then pushed to a remote repository from where the site is deployed.
• There is a fabfile in the root of the application. There are functions to install all necessary packages on the server (except swig - never successfully automated that for some reason - that will need to be done manually), and to deploy the site code to the server. Most of the commands require a prefix of either production or staging to allow for every deploy to be first tested on a staging server before being put up on the production server.
• In short, the deploy routine creates a backup of the database and of the static and media files, does a git fetch on the source code from the remote repository, uploads templates if they've changed, then runs collectstatic and does a database migration before restarting gunicorn.
Lee F.
100% (1)Projects Completed
2
Freelancers worked with
2
Projects awarded
100%
Last project
19 Sep 2016
United Kingdom
New Proposal
Login to your account and send a proposal now to get this project.
Log inClarification Board Ask a Question
-
Dear Lee
Having looked at your site, I see that your browse function is
(a) limited (e.g., no browse by geographical area or tutor name) and
(b) in the site-wide footer. Google downgrades links from these page areas, e.g.:
https://www.seroundtable.com/google-footer-sitewide-links-weight-21540.html
Can these two design decisions be questioned as part of the project?
Thanks
Ivan
147015
We collect cookies to enable the proper functioning and security of our website, and to enhance your experience. By clicking on 'Accept All Cookies', you consent to the use of these cookies. You can change your 'Cookies Settings' at any time. For more information, please read ourCookie Policy
Cookie Settings
Accept All Cookies