Мне кажется что такой подход больше подходит для server-to-server взаимодействия.
У меня вопрос про API для фронтов, тут немного другая история.
Например, если список задач запрашивается на "сегодня", бэк может увидеть что между задачами есть какой-то перерыв и может предложить сходить в этот перерыв, например, в театр или кино. Но чтобы реализовать такую логику, бэк должен точно знать что задачи запрашиваются именно на "сегодня", т.к., если задачи запрашиваются на "вчера", то предлагать куда-то сходить бессмысленно.
При server-to-server взаимодействии это было бы два разных запроса: дай список задач с такого-то по такое-то время, дай список мероприятий.
Я разобрался: всё дело в @IdClass который был установлен для EmployeeHotelPermissionsEntity и содержал HotelEntity. Если его убрать, то HotelEntity не обновляется (как и задумано).
1. Не только пуша, но и коммитов;
2. Если достаточно активно коммитить, можно посчитать время между первым и последним коммитом.
3. Посекундная оценка, конечно, не нужна. А вот примерное представление составить хотелось бы.
Естественно, никто не запрещает слишком много знать. Вопрос, скорее, в позиционировании и целях разработчика. Кто-то себя позиционирует как IT-специалиста, а кто-то как PL/SQL-программиста. И у того и у другого есть будущее. Для первого - CTO, для второго - инженер БД. А вот удел абстрактного "веб-мастера" - это интернет-магазин среднего качества на популярной CMS.
И да, по моим наблюдениям на рынке востребованы два типа специалистов:
1. Умеет все и сразу. Сайт с нуля / на CMS, систему учета на Qt, сервер поднять.
2. Знает узкую область и ничего больше. Но знает свою область на 6 с плюсом. Например, проектирует БД Oracle.
Если я правильно понимаю, тут советуют или платные аналоги Метрики или Event Tracker от гугл аналитики. Задача не в том, чтобы получить больше функционала от вебвизора, а в том, что бы не отдавать аналитику на сторону.
Тут дело в том, что он редкий или в том, что не известно на Haswell ли? Можно поставить любой другой, в котором есть уверенность, что он будет работать. Например, у вас какой? :)
Ну как вариант - те же спам базы но с таргетированием по платежеспособности отдельно взятого человека и его интересам. Нанести какой-то реальный вред, думаю, не возможно (разве что погрозить сдать в налоговую, скажем так, недекларированные финансовые операции).
У меня вопрос про API для фронтов, тут немного другая история.
Например, если список задач запрашивается на "сегодня", бэк может увидеть что между задачами есть какой-то перерыв и может предложить сходить в этот перерыв, например, в театр или кино. Но чтобы реализовать такую логику, бэк должен точно знать что задачи запрашиваются именно на "сегодня", т.к., если задачи запрашиваются на "вчера", то предлагать куда-то сходить бессмысленно.
При server-to-server взаимодействии это было бы два разных запроса: дай список задач с такого-то по такое-то время, дай список мероприятий.