uccser / cs-unplugged Goto Github PK

Possible option:
https://github.com/django-compressor/django-compressor

Each language should have a learning outcome list, with a slug or ID number as the unique identifier for each LO.

According to discussion on #6

The load scripts are currently hardcoded for the en language, and models are expected to be English. Every model will require a local attribute, which is set when loaddata is run.
Each view should retrieve the model for the language currently being viewed.

Useful links:

• https://docs.djangoproject.com/en/1.9/topics/i18n/translation/#localized-names-of-languages

This will make the Age model irrelevant, as the two values can be stored as integers.

All resources should have branded header with logo and link to resource page.

Add the Resource application in the Django project.

Currently there are two main commands within loadtopics.py:

1. Loading learning outcome
2. Loading topic content

Plus there are support functions used by both.

This management command file could be split in multiple files for ease of understanding/editing.

When a Kordac conversion takes place, the load script should:

• Check images found are within static folder.
• Check glossary entries are defined in the database.
• Generate any required images (scratch images to be added in future Kordac release).

Check for hidden CPU load or complex implied queries in templates (see Chapter 13 in Two Scoops of Django 1.8 book).

Related: #23

Possible options:

• Redis Queue: http://python-rq.org/
• Celery: http://www.celeryproject.org/

Add documentation of project structure and basic django commands.

Each resource should have:

• Number as primary key (used as unique ID)
• Slug (must be unique)

Related #7

Currently the loadtopics and loadresources commands require the database to delete (flush) all entries and then recreate them. It should instead update existing entries, create new ones, and delete old ones. This is required when users want to create a permanent connection to a resource, topic, etc.

Each resource should have a webpage associated with it.

There should be a link on each programming exercise linking to the solution (with description above on why to view, either finished or need assistance).

Scratch solution is image.
Python solution should be text wrapped in non-selectable div.

Page also states this is one of many possible solutions.

Rather than hard code each programming exercise with Scratch and Python, it should be tied to objects for a particular language, and these can hold the hints and solutions.

Investigate possible hosting options, including:

• Google Cloud Platform
• Microsoft Azure
• Webfaction
• etc

Need to check for:

• Ease of use
• Ease of scaling
• Price
• Performance

For the three tiers of programming exercises, use RGB to define each tier.

R = Beginner Exercises
G = Intermediate Exercises
B = Challenging Exercises

Age brackets should have:

• Text label
• Slug

Some resources should be created by Python logic that write to a PDF file.

Currently the create image function for a resource return a single image. Instead it should return a list of images, which would allow multiple page resources.

For example, for 4 pages of a single page resource the content would be:

Image output: [A]
Final document: A, A, A, A

For 4 pages of a three page resource the content would be:

Image output: [A, B, C], [A, B, C], [A, B, C], [A, B, C] 
Final document: A, B, C, A, B, C, A, B, C, A, B, C

See chapter 5 of Two Scoops of Django 1.8.

Using front-end tools can allow us to do the following:

• Compile Sass into CSS, including autoprefixer support.
• Compile JavaScript with Browserify.
• Add sourcemaps for our compiled JavaScript and CSS.
• Minify images with imagemin.
• Reload the browser automatically on JavaScript (and/or template) changes.
• Refresh the CSS without reloading the browser on CSS changes.
• Trigger system notifications when Sass or JavaScript has errors.
• Minify JavaScript and CSS for production deploy.

and finally:

• Generate a build folder where all the generated files are stored.

From: https://lincolnloop.com/blog/integrating-front-end-tools-your-django-project/

These tasks are extremely useful, especially the compiling of SASS into CSS. Using SASS for this project is essentially a requirement for easier web development (especially as we plan to use the SASS files from Bootstrap 4 Alpha 6).

There are many options that I'm discovering on how to solve this issue (for both development and production), I've compile a list of links (which I'll keep adding to) of useful resources to read. Quotes are copied from product websites.

This issue replaces #27 #28, but may be effected by the choice in #38.

Django Packages

Django Compressor

Django Compressor processes, combines and minifies linked and inline Javascript or CSS in a Django template into cacheable static files. It supports compilers such as coffeescript, LESS and SASS and is extensible by custom processing steps.

• https://github.com/django-compressor/django-compressor

Django Pipeline

Pipeline is an asset packaging library for Django, providing both CSS and JavaScript concatenation and compression, built-in JavaScript template support, and optional data-URI image and font embedding.

• https://github.com/jazzband/django-pipeline

Comparison

• https://www.reddit.com/r/django/comments/2f97e7/django_compressor_or_pipeline/ (Sept 2014)
• https://www.reddit.com/r/django/comments/3wq43j/djangopipeline_or_djangocompressor/ (Dec 2015)

Task Runners

Grunt

Why use a task runner?
In one word: automation. The less work you have to do when performing repetitive tasks like minification, compilation, unit testing, linting, etc, the easier your job becomes. After you've configured it through a Gruntfile, a task runner can do most of that mundane work for you—and your team—with basically zero effort.

• http://gruntjs.com/
• https://lincolnloop.com/blog/simplifying-your-django-frontend-tasks-grunt/ (Jan 2014 - Switch to Gulp in later post, see link below)

Gulp

gulp is a toolkit for automating painful or time-consuming tasks in your development workflow, so you can stop messing around and build something. By preferring code over configuration, node best practices, and a minimal API surface - gulp makes things simple like never before.

• https://lincolnloop.com/blog/integrating-front-end-tools-your-django-project/

Comparison

• http://www.hongkiat.com/blog/gulp-vs-grunt/ (2017?)
• https://medium.com/@preslavrachev/gulp-vs-grunt-why-one-why-the-other-f5d3b398edc4 (Jan 2015)
• https://www.keithcirkel.co.uk/why-we-should-stop-using-grunt/ (Oct 2014)

Webpack

webpack is a tool to build JavaScript modules in your application. To start using webpack from its cli or api, follow the Installation instructions. webpack simplifies your workflow by quickly constructing a dependency graph of your application and bundling them in the right order. webpack can be configured to customise optimisations to your code, to split vendor/css/js code for production, run a development server that hot-reloads your code without page refresh and many such cool features.

• https://webpack.js.org/
• http://blog.andrewray.me/webpack-when-to-use-and-why/
• https://egghead.io/lessons/javascript-intro-to-webpack (haven't watched yet)
• http://owaislone.org/blog/webpack-plus-reactjs-and-django/
• https://github.com/owais/django-webpack-loader/
• https://github.com/owais/webpack-bundle-tracker

Comparison

• http://stackoverflow.com/questions/35062852/npm-vs-bower-vs-browserify-vs-gulp-vs-grunt-vs-webpack
• http://owaislone.org/blog/modern-frontends-with-django/ (compares everything above)
• Consider django-pipeline over webpack: pinax/pinax#95

Related Reading

• https://12factor.net/

Process should be as follow:

1. Detect if resource has generation available (if not, send 404 response).
2. Add creation of PDF as job to job queue (Celery or Redis Queue)
3. Setup base PDF resources
4. Add resources generate image function to job queue
5. Compress images to page size
6. Render image data into PDF template
7. Send response to user

With Kordac 0.1 the title is removed for custom formatting.

HTML for the title needs to be added.

Currently the Python logic, HTML files, CSS files, static files, and structure data is all stored in different locations. These should be grouped together.

We have included a package.json file to easily install required packages for the gulp file.

However we have no Node/NPM experience so someone should check it's purpose, contents, and usage.

Add flake8 checker as basic style check.

See: https://docs.djangoproject.com/en/1.8/internals/contributing/writing-code/coding-style/