Да потому что Project это и есть Excel с пресетами таблиц и полей :) По крайней мере другого объяснения я не смог найти, при работе ощущение что ты как бы в экселе, но вроде бы и нет.
Да ладно, в любой команде/компании всегда бывают жесткие запары. Необязательно из-за того что сотрудники некомпетентны. Сервера падают, случаются атаки на приложения или инфраструктуру в целом, клиенты внезапно осознают проблемы с требованиями — триггеров «аппокалипсиса» очень много может быть. И вот в таких, в идеале редких, ситуациях умение оперативно мобилизировать все свои скиллы очень важно.
Это смотря с какой стороны посмотреть. Одна из целей абстрагирования в разработке ПО как раз и заключается в том, что бы особо не думать о том, что находится на нижних уровнях и как именно работает.
Что значит на 2-3 уровнях?
А насчет джойнов, то тут наверняка проблема в организации структуры данных. Джойны нужны в реляционных СУБД. В Монго денормализация является вполне нормальной практикой. Так что если нужны джойны, то стоит подумать над архитектурой БД.
А почему бы демо-версии не выкладывать на тестовом сервере, который будет доступен клиенту откуда угодно без всяких установок софта на свой компьютер? Заодно и ездить меньше может быть придется ;)
Читаю я все эти новости про то, как АНБ то, АНБ сё и думаю — крутые чуваки эти АНБшники, такие системы замутить. И работать там технарями и аналитиками должно быть крайне интересно. Им в пору лекции на курсере по проектированию систем слежения выкладывать =)
Бизнес-аналитик это не предельный фен-шуй мечты. Просто он не всегда нужен, например если компания небольшая. То его роль выполнять все же лучше менеджеру проекта, а не тимлиду.
Так то понятно, что из-за недостатка специалистов в большинстве случаев один человек занят в 2-3 направлениях.
Это вот уж точно не зона ответственности тимлида. Преобразовывать требования клиента в понятный список требований — это, как правило, задача либо бизнес-аналитика, либо менеджера проекта. А планирование релизов это вообще стратегическая задача. Тимлид отвечает чаще всего за тактику: разбить список требований на итерации, выделить задачи, проводить ревью кода, и держать в тонусе команду не давая ей прокрастинировать и еще не мало всяких вещей. Однако нужно понимать, что основная область работы тимлида — это его команда, он отвечает за общую эффективность.
А то, что вы поместили в обязанности некоего менеджера. То это административные задачи в широком смысле, которые зачастую вообще имеют мало отношения к разработке проекта. И занимаются ими менеджеры по другим вопросам.
Самым неприятным для реализации сейчас представляется модуль обновления и структура хранилища. Мне хочется, чтобы платформа сама позволяла хранить различные именованные сущности, причём с поддержкой версий.
Ну с обновлениями не так страшно, просто по расписанию ставить задачи для повторного сбора. Тут конечно подумать над вариантами обновлений, просто страницу обновлять или же писать историю полную. А для хранения данных могу посоветовать MongoDB использовать.
Во-первых как минимум на этапе сбора страниц оно удобно, потому что вы просто пихаете контент и заголовки в виде json-документа в коллекцию. То есть получается веб-страница = документ в монге.
Во-вторых свободная структура будет удобна для множества ситуаций с парсингом, потому что наверняка структура данных для страниц форумов будет отличаться от новостных сайтов. Таким образом у вас на каждом этапе, где нужно сохранять данные, будет абстракция «хранилище» о которой особо заботиться не нужно в этом контексте — просто помещаем туда документы.
Конечно есть обратная сторона. Нужно описывать структуру документов отдельно, потому что со временем хаос начинается. Хотя можно строго изолирвать код, который работает с конкретным «типом» документов, тогда знание о конкретной структуре будет в одном месте.
У вас скорее всего возникнут проблемы с мониторингом на этапе реализации. На схеме он никак не связан с главными процессами, хотя может это проблема схемы)
Разделение этапов загрузки и проверки не имеет особого смысла, и уж тем более такая их последовательность. Судя по описанному в статье, вы сначала пытаетесь загрузить данные, а потом узнать можно ли это сделать (например проверка на 404 ответ сервера). Думаю можно вынести обработку случаев, отличных от успешного получения данных. Но сами проверки совместить с модулем загрузки.
Что касается нестандартных ситуаций, то их очень много. Но при этом получение страницы для установки куков принципиально не отличается от получения любой другой страницы.
Поэтому я бы посоветовал придумать миханизм, который позволит управлять логикой поведения модуля загрузки. Обычно ситуации с капчами и куками выглядят как зависимость одной страницы от другой. И когда будет происходить загрузка, то система должна знать об этой зависимости и выполнять дополнительный запрос. Это немного портит идею того, что загружать за раз можно только одну сущность(страницу, файл, и тд). Но это упростит архитектуру и реализацию. Меньше точек нужно будет мониторить.
Интересно как вы подойдете к реализации. Я подобную систему разрабатывал в одном из проектов,. там у меня схожие принципы применялись. Как раз вот готовлю статью на эту тему.
В том и дело, что это дело каждого, кому что продавать и кому что покупать. Рынок как бы.
Так не покупайте.
А насчет джойнов, то тут наверняка проблема в организации структуры данных. Джойны нужны в реляционных СУБД. В Монго денормализация является вполне нормальной практикой. Так что если нужны джойны, то стоит подумать над архитектурой БД.
Так то понятно, что из-за недостатка специалистов в большинстве случаев один человек занят в 2-3 направлениях.
Это вот уж точно не зона ответственности тимлида. Преобразовывать требования клиента в понятный список требований — это, как правило, задача либо бизнес-аналитика, либо менеджера проекта. А планирование релизов это вообще стратегическая задача. Тимлид отвечает чаще всего за тактику: разбить список требований на итерации, выделить задачи, проводить ревью кода, и держать в тонусе команду не давая ей прокрастинировать и еще не мало всяких вещей. Однако нужно понимать, что основная область работы тимлида — это его команда, он отвечает за общую эффективность.
А то, что вы поместили в обязанности некоего менеджера. То это административные задачи в широком смысле, которые зачастую вообще имеют мало отношения к разработке проекта. И занимаются ими менеджеры по другим вопросам.
Ну с обновлениями не так страшно, просто по расписанию ставить задачи для повторного сбора. Тут конечно подумать над вариантами обновлений, просто страницу обновлять или же писать историю полную. А для хранения данных могу посоветовать MongoDB использовать.
Во-первых как минимум на этапе сбора страниц оно удобно, потому что вы просто пихаете контент и заголовки в виде json-документа в коллекцию. То есть получается веб-страница = документ в монге.
Во-вторых свободная структура будет удобна для множества ситуаций с парсингом, потому что наверняка структура данных для страниц форумов будет отличаться от новостных сайтов. Таким образом у вас на каждом этапе, где нужно сохранять данные, будет абстракция «хранилище» о которой особо заботиться не нужно в этом контексте — просто помещаем туда документы.
Конечно есть обратная сторона. Нужно описывать структуру документов отдельно, потому что со временем хаос начинается. Хотя можно строго изолирвать код, который работает с конкретным «типом» документов, тогда знание о конкретной структуре будет в одном месте.
Разделение этапов загрузки и проверки не имеет особого смысла, и уж тем более такая их последовательность. Судя по описанному в статье, вы сначала пытаетесь загрузить данные, а потом узнать можно ли это сделать (например проверка на 404 ответ сервера). Думаю можно вынести обработку случаев, отличных от успешного получения данных. Но сами проверки совместить с модулем загрузки.
Что касается нестандартных ситуаций, то их очень много. Но при этом получение страницы для установки куков принципиально не отличается от получения любой другой страницы.
Поэтому я бы посоветовал придумать миханизм, который позволит управлять логикой поведения модуля загрузки. Обычно ситуации с капчами и куками выглядят как зависимость одной страницы от другой. И когда будет происходить загрузка, то система должна знать об этой зависимости и выполнять дополнительный запрос. Это немного портит идею того, что загружать за раз можно только одну сущность(страницу, файл, и тд). Но это упростит архитектуру и реализацию. Меньше точек нужно будет мониторить.
Интересно как вы подойдете к реализации. Я подобную систему разрабатывал в одном из проектов,. там у меня схожие принципы применялись. Как раз вот готовлю статью на эту тему.