Если рассматривать сегодняшние алгоритмы машинного обучения с движением от невежества (низ) к осознанию (верх) то текущие алгоритмы похожи на прыжок. После прыжка происходит замедление скорости развития (обучающая способность) и неминуемый разворот и падение (переобучение). Все усилия сводятся к попыткам приложить как можно больше сил к прыжку, что увеличивает высоту прыжка но кардинально не меняет результатов. Прокачивая прыжки мы увеличиваем высоту, но не учимся летать. Для освоения техники «контролируемого полета» потребуется переосмыслить некоторые базовые принципы.
Нагрузка на сервер является важным звеном администрирования веб сервера, отслеживание запросов помогает быстро искать ошибочные запросы и устранять их раньше чем они вернуться к вам со статистикой вебмастера. По умолчанию в конфигурационном файле веб сервера апаче закоментрировано определение хоста в dns что в свою очередь еще больше усложняет понимание того, что приходит на сайте. Упростить все это удалось написанием скрипта отображающего все запросы к веб серверу в режиме реального времени. Сохраняя несколько сотен запросов удалось посчитать время загрузки. Это процент от реально прошедшего времени суммы времени потраченных на вывод ресурсов. Удобный вывод времени затраченного на выполнение каждой страницы сайта стал незаменим в поиске слабых мест. Небольшой массив со списком шаблонов поисковых систем позволил выделить их отдельным цветом в ленте запросов.
Залогом успеха в любой профессии в наше время является максимальная оптимизация производственного процесса. Но есть вещи которые стали стандартом в определенной сфере. Работа с ними требует долгого изучения и продолжительной практики. Одной из таких слабых мест веб разработки является база данных. Сопровождение и администрирование вносит огромные накладные расходы тем временем в подавляющем большенстве проектов функционал баз данных остается не востребованным. Как привлекательно совместить простоту работы с файлами, гибкость и функционал реляционных баз данных. Как хочется свести создание резервной копии базы данных к простому копированию одного единственного файла.
Данные в любом приложении являются ключевым фактором простоты их понимания. Со временем вырабатывается определенный подход к их выборке, обработке и обновлению. Если обрабатывая данные вы все еще задумываетесь над тем в какой форме хранить ваши данные, как из списка выбрать то что нужно — возможно данный подход упростит вашу жизнь. Основные требования к хранению данных могли бы звучать как то так:
Структура максимально близкая к реляционной. Подобная форма хранения данных завоевала популярность у разработчиков и мы не будем от нее отказываться.
Данные должны обеспечивать простоту доступа к основному элементу по идентификатору. Взаимосвязи со смежными элементами строятся на основе использования вторичного ключа в качестве указателя на основной элемент. Быстрый доступ будет плюсом.
Повторное использование списка данных. Единожды получив срез данных должна оставаться возможность, обращение к любому из элементов по его основному ключу или совпадению со значением одного или нескольких атрибутов а также построение списков из выборки.
Дополнительным бонусом будет использование «налету» что позволит обращаться к объектам через несколько уровней.
Однозначная поддержка перехода по любым из возможных связей: один ко многим, много к одному и много ко многим. Возможность быстрой модификации логики связей при дальнейших изменениях структуры данных.
