Говоря о проектах отдела, вот вам ещё один.
Этим я, по большей части, занимаюсь сам – сил хватает. Если только и делать, что руководить командой разработчиков – сам растеряешь навыки и постепенно потеряешь возможность давать дельные советы/замечания команде.
Данный ресурс создавался (в некотором смысле, всё ещё создаётся) для музея почвоведения ТГУ.
Данный проект (наконец-то!) подходит к концу, осталось добавить раздел с видео и «Отполировать» некоторые мелочи. В основном это касается отображения тех или иных деталей.
Данный ресурс изначально разрабатывался как мультиязычный, поэтому каждая сущность может иметь перевод на английский. И, если у сущности есть своя страница и перевод, то, сменив язык, находясь на этой странице, мы попадаем на эту же сущность, но на другом языке. Казалось бы, очевидный функционал, но на многих ресурсах об этом особо не думают и при смене языка просто кидают на главную, а переводы сущностей, по факту никак не связаны, это просто два объекта на разных языках, вот и всё.
Основным объектом на данном сайте является «почвенный объект», который может содержать несколько видов полей (описательных элементов, характеристик), например: позиция на карте, особенности почвы, расположение в рельефе и другие.
Отдельно выделяется поле «автор», указывающее на автора данного материала. На странице автора можно получить список всех почвенных объектов, которые он ведёт. Само поле автора при просмотре почвенного объекта, кстати, также является ссылкой, что обеспечивает большое количество перекрёстных ссылок на сайте, что полезно для поисковой оптимизации.
Также хочется сказать про поля, значения которых берутся из специальных словарей. К таким полям относятся разного рода теги, типы, квалификаторы (не ошибка, так и называется).
Пример отображения страницы почвенного объекта:
Сейчас на сайте не так много объектов, всего 29, база ещё активно наполняется, поэтому некоторые решения оценить немного сложнее. Например, карту. При разработке страницы с картой, я принял решение поступить следующим образом:
Во-первых, я использую Google Maps, потому это это удобно и привычно как отечественному пользователю, так и зарубежным коллегам.
Во-вторых, все маркеры (так в терминах Google Maps называются эти цветные булавки) при отображении группируются, если находятся слишком близко друг к другу на текущем уровне масштаба. То есть, чем дальше мы «отдалили» карту, тем меньше единичных маркеров мы наблюдаем, вместо многих из них выводятся группы маркеров – элементы с числом внутри (число говорит о том, сколько маркеров были кластеризованы – объединены в один объект). При клике на кластер (группу) мы автоматически приближаем карту так, чтобы увидеть все объекты, которые он вобрал в себя. Это могут быть как отдельные маркеры, так и другие кластеры (группы).
В-третьих, существует понятие InfoWindow – объекта выводимого поверх маркера при клике на него. По сути это «информационное окно» с краткой информацией об объекте, связанным с маркером. В моём случае это изображение и название почвенного объекта, обёрнутого в ссылку, ведущую на страницу объекта. Я решил провести в этом месте оптимизацию и не создавать множество информационных окон – по одному на каждый маркер. Вместо этого, при клике на маркер, к нему подрисовывается единственный объект-окно, а его содержимое берётся из данных о маркере.
И, наконец, в-четвёртых, после того, как все маркеры / кластеры выведены на карту, её содержимое центрируется и масштабируется таким образом, чтобы все маркеры были одновременно отображены, но уровень масштаба был максимальным. Это позволяет сфокусировать пользователя на нужном участке карты, где есть полезная информация.
Отдельной темой для размышления для меня была задача фильтрации почвенных объектов. Если поиск по подстроке в имени объекта и фильтрация по типу объекта явно закреплены, то все остальные элементы фильтрации не статичны и могут меняться со временем (а также не идентичны для разных языков!). Поэтому хотелось придумать какое-то элегантное решение, которое будет отличаться от простого хардкода (фиксации прямо в программном коде) двух наборов фильтров – для русского и английского языков.
В итоге я сделал следующее:
Во-первых, я сделал Mapper (инструмент сопоставления) для задания соответствия языку набора фильтров. Варианты для выбора берутся из существующих полей для почвенного объекта, которые, кстати говоря, также не зафиксированы в коде и могут обновляться силой модератора сайта, даже без знания программирования.
Во-вторых, при формировании формы фильтрации я обхожу в цикле все элементы и для каждого из них создаю элемент формы. При этом, тип поля, который послужил для создания этого элемента определяется и как именно будет происходить фильтрация. В основном, это фильтр вида «один из», вроде «типа», или выбора «почвенной зоны». Пользователю в форму фильтрации генерируются объекты, для которых пользователь может выбрать одно из значений и при активации фильтра, он получит почвенные объекты со значением поля равному его выбору. Между всеми элементами формы фильтрации действует логическая операция конъюнкции, или «логического И». То есть выглядит это так: Фильтр по почвенным объектам, где ЗАГОЛОВОК содержит «почва» И ТИП равен «почвенные профили».
Для данного проекта техническая документация была не нужна, поэтому всё проектирование я проводил на бумаге, в виду чего показать модель приложения я не смогу. Такой подход был обусловлен стихийно-итеративным процессом разработки, когда у заказчика не по всем вопросам заранее был подготовлен ответ, в виду чего модель приложения несколько раз менялась и часть кода полностью переписывалась.
Но, несмотря на всё вышеперечисленное, лично мне проект очень нравится и работать над ним было очень приятно.