Процесс записи [закрытой] технической спецификации
В документации django есть два интересных сигнала, которые могут помочь вам в этой задаче: pre_save и post_save . Это зависит от ваших потребностей, но, скажем, вы хотите проверить, совпадает ли notify_on вашей модели с текущей датой после сохранения вашей модели (фактически после вызова метода save() или create()). Если это ваш случай, вы можете сделать:
from datetime import datetime
from django.contrib.auth.models import User
from django.db import models
from django.dispatch import receiver
from django.db.models.signals import post_save
class Notification(models.Model):
...
# Every notification is related to a user
# It depends on your model, but i guess you're doing something similar
user = models.ForeignKey(User, related_name='notify', on_delete=models.DO_NOTHING)
notify_on = models.DateTimeField()
...
def send_email(self, *args, **kwargs):
"""A model method to send email notification"""
...
@receiver(post_save, sender=User)
def create_notification(sender, instance, created, **kwargs):
# check if the user instance is created
if created:
obj = Notification.objects.create(user=instance, date=datetime.now().date())
if obj.notify_on == datetime.now().date():
obj.send_email()
И вы должны знать, что сигналы django не будут работать сами по себе, только если есть действие, которое их запускает. Это означает, что сигналы Django не будут зацикливаться на экземплярах вашей модели и выполнять операции, но сигналы django будут срабатывать, когда ваше приложение выполняет действие с моделью, подключенной к сигналу.
Бонус: Для выполнения цикла над вашими экземплярами и обработки регулярного действия вам может потребоваться async работник с базой данных Queue (в основном, Celery с Redis or RabbitMQ). [ 1112]
5 ответов
Интересный, я думал, что этот вопрос получит десятки хорошо обсужденных ответов, вместо этого мы получаем предположения, что кодирование стандартов решит проблему, или разрешение devs продолжить его является ответом. От вопроса я думаю, что ключ - то, что мы говорим о младших кодерах, когда Вы запускаете, там огромный переход от функциональной спецификации до законченного кода, и все мы знаем, что существует больше чем один способ сделать это.
Мой подход должен был бы принять конкретное участие системы, что осуществляет все технические слои - DB, UI, веб-сервисы вообще и документ, как это должно быть реализовано, возможно, с помощью диаграмм классов, возможно, просто предложив определенные библиотеки и подходы. Таким образом Ваша техническая спецификация не является слишком большой, поздравление и расширяет документ архитектуры (который может быть списком пункта маркированного списка, если Вы не хотите слишком много doco).
Команда может затем полностью реализовать вертикальную часть системы, которая имеет много преимуществ, можно создать и выпустить маленькую часть рано, архитектура доказана, повторение, 0 материалов (управление исходным кодом, управление версиями, сборка) все осуществлены - это - просто способ сделать это.
Две мысли:
Самым полезным путем я знаю к коммуникации о предложенном внедрении, должен использовать диаграммы классов и диаграммы последовательности.
Я думаю, что даже младшим разработчикам нужно дать ответственность создания первоначального описания. Размышление о пространстве задач, затем получение критического анализа дизайна, собираются разработать их способности намного быстрее.
Я думаю, что это сводится к определенным основам дизайна:
- Вы создаете список требований или функциональную спецификацию
- Вы смотрите на все возможные способы решить проблему
- Вы решаете, какие пути подходит лучше всего или приводит к лучшему результату
Что Вы описываете шоу, что они не сделали пользу (если таковые имеются) анализом за и против. В конце это сводится, как хорошо Юниор самостоятельно может собрать правильную информацию и затем принять корректное решение. Это могло бы включить выяснение у более главных программистов ;-)
Некоторые примеры методов разработки решить, каковы самые лучшие опции:
Вы вытащите большой пробег из увеличения Вашей функциональной спецификации со стандартом кодирования, обзорами кода и возможно инструментом статического анализа как FxCop. Код может быть основан на разумной архитектуре, но стать твердым измениться из-за плохого стиля на местном уровне.
Я собираюсь предложить читать ряд Joel, запускающийся с Безболезненных Функциональных спецификаций - Часть 1: Почему Беспокойство? У него даже есть ссылка на спецификацию Aardark Проекта (теперь Второй пилот), что можно загрузить и читать как пример того, что делает хорошую спецификацию.
Одна точка, хотя: Вы упоминаете и технические и функциональные спецификации в своем сообщении. Существует различие.
Вы затрагиваете по вопросу о кодировании стандартов, на которые оно походит (также).
Лично я одобряю основанный на Wiki подход для чисто технической проектной документации. Разработчикам jsut не нравится писать большие документы Word. Wikis позволяют Вам писать материал, сотрудничать, вставлять диаграммы классов или независимо от того, что является соответствующим.
Я нашел еще некоторую информацию об этом как этот поток о техническом по сравнению с функциональными спецификациями, где Joel пишет:
Мой образ мыслей - то, что Вы просто не пишете "технические спецификации", которые покрывают всю функциональность приложения... это - то, для чего функциональная спецификация. После того как у Вас есть полная функциональная спецификация, единственной вещью, оставленной документу, являются точки внутренней архитектуры и определенных алгоритмов, которые являются (a) совершенно невидимый (под покрытиями) и (b) не достаточно очевидный из функциональной спецификации.
Таким образом, техническая спецификация заканчивается не существующий. В он - место, Вы можете или не можете иметь нескольких технических статей о маленьких темах:
и
Помните, если что-либо, Вы говорите о влиянии пользовательский интерфейс или даже поведение вещи, которую Вы создаете, это входит в функциональную спецификацию... так все, что это уехало в техническую спецификацию, вещи, которые ТОЛЬКО представляют интересы для программистов, и, на самом деле, много того материала могло бы быть лучшим в комментариях, так самое большее, у Вас должна быть горстка коротких статей о темах как алгоритмы - и Вы пишете те статьи по требованию, когда необходимо продумать дизайн, или документировать "большое изображение" для будущих программистов, таким образом, они не должны выяснять то, что код пытается выполнить.
который описывает это намного более красноречиво, чем я.