kn0ckn0ck

Выбор базы данных - это архитектурное решение, которое повлияет на все в вашем проекте. Относиться к выбору нужно ответственно, а не поверхностно - как сейчас.

Все данные всегда как-то связаны, поэтому это не может быть критерием для выбора технологии их хранения/извлечения.

Если вы на проекте принимаете архитектурные решения, то рассмотрите множество потенциально возможных сценариев использования данных, видов данных и т.п. Прям вот садитесь и выписывайте: а) нужно это, б) нужно то, в) а потом еще так, г) ...

Составив таблицу вариантов использования (требований по сути) проработайте сильные и слабые стороны для каждой из технологий, которая вам кажется здесь применимой.

Сформируйте системное и взвешенное решение.

Раньше ругали за то, что языки/библиотеки расточительно относятся к памяти - не экономят ее. Сейчас ругают за то, что расточительно относятся к сервисам/технологиям - шлеп sql, шлеп nosql и готово.

Описанная задача не является архитектурно значимой, это к вопросу дизайна вашего кода. Почему бы не хранить дату/время в линейном формате, например, аналогично UNIX_TIMESTAMP? На этом пространстве легко решаются описанные задачи даже на обычном калькуляторе, не говоря об elasticsearch...

Вопрос о том, как управлять разработкой нескольких подсистем, в одном спринте или в нескольких (у каждой подсистемы свой) не имеет единственно верного ответа, так что это не про корректность. Тем более это не имеет отношения к JIRA, либо к любому другому трекеру.

Ключевыми понятиями Scrum (где используются спринты) являются: одна команда, общие цели на спринт, один владелец продукта.

Так, двум разным командам (со своими целями каждая) будет невозможно эффективно провести планирование спринта, участвовать в стендапах и демо.

Для начала определитесь с конфигурацией управления проектом (какое вам нужно соотношение спринт-подсистема). Из этого будет понятно какую конфигурацию настроить в JIRA, а потом станут понятны ограничения и воркэраунды.

Лучше бы возникла идея ограничить использование смартфонов детьми, поскольку это плохо отражается на взаимодействии с реальностью, психике и зрении.

Если есть уверенность в том, что это кому-то вообще нужно, то сделай это:

• четко пойми каким образом эту проблему решают сейчас, это хороший маркер наличия проблемы и потребности в платном ее решении.
  
• начни с поиска и анализа конкурентов (SWOT-анализ). Если конкурентов нет, то высока вероятность, что и потребность искуственная. Если конкуренты есть, нужно убедиться, что у тебя хватит всего, чтобы с ними потягаться.
  
• оцени порог входа в этот бизнес, прикинь возможные затраты и пойми где ты возьмешь на это деньги. Не каждый продукт можно бутстрапить. Да и за время пути продукт может протухнуть.
  
• набросай небольшой бизнес-план, чтобы понять экономику будущего продукта (еще и размер ЦА нужно оценить). Отсюда должна выйти бизнес-модель и понимание масштаба/сложности мероприятия. Эта вещь пригодится, когда захочется инвесторов поискать.
  
• сразу подумай над своим конкурентным преимуществом. Если это легко повторить, то это либо уже делают, либо сделают быстро и выжмут с рынка. Серьезное конкурентное преимущество очень нравится инвестору.
  
• сразу подумай о каналах привлечения лидов, есть ли они и доступны ли они тебе. B2B-решение - это та еще заморочка.
  

И да, зачастую эти моменты начинают проясняться только в процессе, то есть таки после MVP.

Может быть это? ГОСТ 34.602-89 Информационная технология (ИТ). Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.

Вообще-то, работать нужно стоя, как это делают в Facebook и Google

Ответ зависит от того, насколько существенный у вас деплой. Например, в phpStorm можно автоматизировать загрузку измененных файлов на сервер (это тоже ведь деплой), подробнее.
Если перед фактическим деплоем нужно "собрать" приложение, то есть всякие препроцессоры прогнать, упаковать, растащить по каталогам и т.п., то от фактической процедуры деплоя вами никуда не деться даже в случае изменения одного символа.
Чтобы деплой не был долгим, нужно делать два деплоя:
1. на окружение разработчика (у вас же есть докер) по коммиту, но без серьезного тестирования
2. на окружение UAT/боевое с уже серьезным тестированием и может быть с ожиданием в минут 10 после коммита (чтобы больше коммитов собрать в деплой).
Так вот, клиент будет смотреть на окружение 1, задержка между изменением кода разработчиком и появлением его в приложении на этом окружении будет вряд ли больше 1 минуты, а быстрее и вряд ли нужно.

scrumboard.ru

gitlab devprom

В исходном вопросе чувствуется противоречие: "система назначения заданий не нужда" vs "чтобы все упорядочить"
Видимо хочется разнести задачи по нескольким инструментам:
1. назначать задачи через мессенджер
2. работать с упорядоченной информацией в системе
Следовательно вопрос решается интеграцией одного с другим, что часто решается ботами.

А можно уточнить название курса, к которому курсач нужно сделать? Просто тут такое дело - зачем тратить время на разработку чего-то, что никому и никогда не будет полезно и не пригодится? Таких тулов бесчисленное колличество - open-source в том числе. Тут либо помогать их развивать, либо другую тему искать.

Нет ничего хуже в образовании, чем бесполезные курсачи и дипломные работы. Встраиваться нужно в индустрию с молоду. Всегда найдется место где приложить не очень квалифицированные усилия. Нужно только правильный вопрос задать народу.

Выспаться, чтобы прийти на работу вовремя и не допустить выпуска сломанной версии продукта. На ретро договориться о шагах, чтобы такого не повторилось, а также четко поставить вопрос о недопустимости тестирования на выходных - все нужно успеть сделать до окончания рабочего дня в пятницу! На выходных нужно отдыхать.

Про бесплатные не слышал, потому что хранение больших объемов логов/ошибок бесплатно не обходится. Но из недорогих есть: Sentry и DevOpsBoard

Отделу разработки грех не стремиться к самодокументируемости. У вас так быстро растет отдел, что нет времени объяснить новчику в теч. пары часов как все устроено? Или у вас процесс разработки/деплоя вылит из гранита, что за устаревание/обновление докуметации вы не паритесь?

1. Jenkins Pipeline (или Gitlab) - пример самодокументируемого деплоя
2. аналогично п. 1
3. Есть уже куча готовых, просто дать ссылку
4. Показать и объяснить устно, чтобы снять сразу возможные вопросы/критику/непонятки
5. Единственное что имеет смысл задокументировать (что редко меняется) - архитектурные особенности. Внутри каждого скрипта должны быть либо комментарии, либо код должен быть самодокументируем. Если нужно описать "клей", то почему бы не использовать Ansible/Chef для этих целей?
6. "Никогда не нажимай эту красную кнопку..." - ну вы знаете, что затем последовало.

Продукт не развивается, есть более качественные бесплатные аналоги.

Спрашиваешь... так делают процентов 90. Другое дело - правильно ли они поступают при этом? Часто документацию путают с проектированием. Это разные вещи и у них разные цели.

Проектировать нужно обязательно, это существенно удешевляет разработку. При этом можно использовать UML или банальные блок-схемы, не имеет значение. Иногда это может поместиться в голове, но чаще это лучше где-то записать. И тут мы плавно приходим к документации.

Плюсы документации в том, что проектное решение можно подготовить сейчас, а реализацию перенести на потом (и ничего важного не забудится по дороге), либо можно обсудить решение с кем-то, выявить риски, передать на реализацию кому-то.

Минусы документации в том, что она быстро устаревает и ее поддерживать довольно дорого и затратно по времени.
Таким образом, ключевым является вопрос о целях документации. Из этого будут ответы и по указанным пунктам.

1. Зависит от сложности/объема задачи. Если все помещается в голове, то для чего тогда документация? Любая, UML или текст, не важно. Если что-то нужно продумать, то можно записать на доске/бумаге, сфоткать, потом выбросить.

2. Без требований мы не знаем что должно было получиться. Для начальной стадии продукта это вполне приемлемо. Основной риск - в регрессе функциональности. Смотрим код и не понимаем для чего он тут нужен и как оно должно работать, меняем как-то и в итоге ломаем ранее реализованную функциональность. Такие риски необязательно решаются документированием требований в форме ТЗ, можно обходиться и автоматизированным тестированием.

3. Уважительной причиной чего-то не делать будет четкое понимание того, как связанные с этим риски минимизируются. Долой догмы. Если в среднесрочной перспективе мы четко осознаем, что фиксация/документирование требований не принесет пользы, то зачем тратить на это время/ресурсы?

Да их полно или что-то конкретно интересует?