Альтернативный метод загрузки для Django FileField
Обычно, оценка должна быть сделана на 2 уровнях в начале каждого спринта: уровень истории и уровень задачи. Для лучших результатов владелец продукта и команда должны сделать обоих вместе, каждый раз, хотя иногда это приемлемо для оценки команды на уровне задачи без присутствующего владельца продукта.
Оценка Проекта / Конструкция Дорожной карты (Уровень Истории)
На Вашем первом спринте, необходимо оценить по крайней мере 80% неудовлетворенных объектов (я предполагаю, что Владельцу продукта уже расположили по приоритетам его) создавать разумную дорожную карту проекта, которая будет состоять из историй, сгруппированных в спринтах, и начальная буква оценила проекцию длины проекта.
В данный момент, оценка каждой истории сделана с помощью, не часы, дни или неделя, но относительная единица для размера (которые охватывают усилие, сложность и рискуют всеми одновременно), такие как точки истории. Мы используем масштаб Fibonnaci и Покер Планирования для этой фазы. Важно, чтобы целые команды активно участвовали в этом процессе.
После этого, команда должна предположить, сколько историй они могут завершиться в 1-м спринте, который будет оцененной скоростью их начальной буквы (точки/повторение). Обычно, лучше не использовать 1-месячные спринты, а скорее 2-недельную или 1-недельную длину спринта для улучшения точности оценки. 1-е планирование будет обычно занимать целый день или даже 2 дня, в зависимости от неудовлетворенного размера, размера команды и длины спринтов.
После того, как это, которое 1-й раунд оценки истории, мог бы хотеть владелец продукта вместе с командой, повторно присваивает приоритет отставанию для оптимизации отношения стоимости/преимущества, таким образом, сила быть некоторыми назад и вперед, пока нет соглашение.
необходимо закончить с чем-то вроде этого:
PROJECT ACME ROADMAP
SPRINT 1 (38 points) <= estimated velocity
--------
Story 1 (21 points)
Story 2 (13 points)
Story 3 (4 points)
SPRINT 2 (40 points)
--------
Story 4 (13 points)
Story 5 (13 points)
Story 6 (8 points)
Story 7 (5 points)
SPRINT 3 (39 points)
--------
...
На следующих спринтах, эта дорожная карта будет пересмотрена много раз, в начале каждого спринта, корректируя скорость к фактической скорости, что команда получает и повторно вычисляет длину проекта по мере необходимости. Иногда, переоценка историй необходима также, поскольку команда развивается и изменение требований. Однако время для пересмотра дорожной карты должно быть не больше, чем половиной дня.
прогресс на этом уровне должен быть видим заинтересованным сторонам, использующим диаграмму burndown, где ось X является спринтами, и ось Y точки истории.
Оценка Sprint (Уровень Задачи)
2-я часть стадии планирования для каждого спринта потрачена, ломая каждую историю в задачи. Здесь, задачи должны быть очень техническими по своей природе и оцененные часы использования. У нас есть политика что, если задача оценивается дольше, чем 8 часов, то она должна быть разломана на более подробные задачи несмотря ни на что. Результатом будет отставание спринта с задачами, сгруппированными историей и спринтом burndown диаграмма, где ось X/Y должна быть днями спринта и часы соответственно.
Это должно быть похожим на это:
Sprint 8
--------
Story 17
Task 1: 8 hours
Task 2: 6 hours
Task 3: 2 hours
Story 18
Task 1: 8 hours
Task 2: 6 hours
Story 19
Task 1: 6 hours
Task 2: 3 hours
...
Так в основном, это 2 типа оценки, которую необходимо делать в начале каждого спринта, где обычно 1-й спринт требует немного большего усилия создать первоначальную дорожную карту проекта.
3 ответа
Я не эксперт в передаче огромных файлов, но если вашим пользователям необходимо иметь возможность делать это без «заклинаний UNIX», я бы посоветовал изучить возможность создания для этого Java-апплета. Это потребует много работы, но тогда у вас может быть нормальный индикатор выполнения и т. Д.
Не уверен, понял ли я, что вы хотите добавить в админку. Вы ищете способ автоматизировать процесс загрузки файла с помощью протокола передачи, отличного от HTTP?
Если да, вы можете создать модель с базовым CharField (или, возможно, URLField), а затем выполнить rsync или scp-копию, когда объект сохранен. Например:
from django.db import models
class File(models.Model):
path = models.CharField()
def save(self):
import os
# WARNING! The path given by the user should be sanitized; this is
# example code only. This is a security vulnerability.
# Attempt to rsync the target file from a remote machine
exit_code = os.system("rsync %s /incoming/files/path/" % self.path)
# Make sure it worked before saving
if exit_code == 0:
super(File, self).save() # Call the "real" save() method
else:
# Raise exception
Это очень грубый пример, но он должен помочь вам кое-что понять. Вам нужно убедиться, что ваша процедура безопасна (например, искаженные пути могут позволить пользователю запускать все, что он хочет). Кроме того, это, скорее всего, заблокирует процедуру сохранения Django при копировании файла , поэтому вам следует рассмотреть возможность запуска предпочитаемой команды в отдельном процессе.
Удачи!
Вы упомянули, что FilePathField работает, но для просмотра новых файлов необходимо перезапустить веб-сервер. Это происходит потому, что параметры собраны FilePathField .__ init __ , который вызывается один раз при импорте модуля.
Исправление - повторный вызов поля __ init __ в форме __ init __ :
def __init__(self, **kwargs):
super(MyForm, self).__init__(**kwargs)
self.fields['file'].__init__(path)
(Таким образом, каталог сканируется каждый раз, когда создается экземпляр формы.)