Понимаю) Подобные излишне пафосные высказывания о поисковом инструменте выглядят нелепо и даже ламерски. Ведь есть же специализированные средства под конкретные задачи: дебаг, профайлинг, визуализаторы, навигация по синтаксису в конце концов.
Но, тем не менее, когда возникает проблема, полная неопределенности, и в голове только блеклые предположения, на помощь приходит именно Поиск! Молниеносная скорость даже на больших объемах кода, мощный предпросмотр, фильтры, поддержка регулярок. Все это позволяет быстро проверять самые расплывчатые запросы и, что немаловажно, легко менять их на другие. Порядок результатов тут не так важен, в отличии от полноты выборки.
Кстати, во время таких мозговых штурмов, чтобы окно не пропадало, его можно зафиксировать (иконка Pin в правом верхнем углу).
А Find Window используется как тягач, позволяющий выполнить кропотливую обработку, но без возможности изменить курс. Хотя он тоже красавчик, это точно!
640кб оперативки? Не, это слишком по-богатому. Не забывайте, мы в космосе! В нашем распоряжении бесконечное количество магнитных бобин, но оперативки завезли только на 1к, для просмотра сайтов. Файлы с логами в формате "USER_ID:URL\n" (1 символ - 1 байт). Поэтому
Первый день:
Открываем поток на чтение файла первого дня
Не спеша читаем ид пользователя (пока не дойдем до знака ":")
Проверяем, если файла "1-USER_ID" не существует, то создаем поток на запись этого файла и побайтово записываем туда урл (пока не дойдем до знака "\n")
Если файл есть и он пустой, то пропускаем
Если файл есть и он не пустой, то открываем еще один поток на его чтение и побайтово читаем с двух потоков до первого отличия, и если такое находится - делаем файл пустым.
День второй:
По аналогии читаем файл 2-го дня, получив ид пользователя, проверяем файл "1-USER_ID", если файл есть и он пустой, либо его содержимое не совпадает - то это лояльный пользователь. Удаляем файл 1-USER_ID и мигаем светодиодом два раза.
Это точно!) Я вообще больше рофлил, чем пытался дать ценный совет. Эти "любимые задачки" от глубоко окопавшихся в конторе сансеев всегда обрастают таким искусственным налетом, что сложно их воспринимать как реальные кейсы. Решать с закосом под продакшен или под спортивное программирование? Выбор похож на две чашки с ядом, к которому у собеседующего уже отличный иммунитет.
Если уже идти во все тяжкие оптимизации, то зачем вообще держать множества для страниц?
Можно обойтись простым <userId>: <string>. При этом не пустое значение будет означать, что у пользователем посещена только эта страница. А пустое значение - признак посещения более одной страницы. Т.е.
Первый день:
Если пользователя (ключа) нет в коллекции, то добавить туда вместе со значением страницы
Если пользователь есть, и значение страницы пустое, то пропустить.
Если пользователь есть, и значение страницы не совпадает с текущим, то заменить его на пустоту.
Второй день:
Если пользователь есть, и у него либо пустая строка (признак), либо строка не совпадает - то это лояльный пользователь.
Спасибо, попробую! Вообще, я больше хотел популяризовать ValueResolver, в котором можно самостоятельно вклинится в алгоритм переливания запроса в дто. Если Mapping Request Data обладает такой же гибкостью, то супер!
- Здравствуйте, желаете поговорить об апиплатформ? У нас контроллеры светятся от счастья, но на алтарь пойдут ваши модели, мы нашинкуем их дополнительными атрибутами, эти атрибуты с помощью других атрибутов перемешаем по группам (поверьте, это так удобно!), подсадим на круд-иглу, и политику доступов тоже заберем себе. Интересует? - Спасибо, но мне бы просто генератор апи интерфейса (которым даже пользоваться будут в основном для экспорта в постмен/инсомнию).
Но теперь на их главной странице красуется ApiResource, без каких-либо обязательств. И я в растерянности) Возможно сам себе навертел это все на мозги.
Не уверен, что понял вопрос. Поэтому если отвечу не то, не обессудь)
Контроллер с его сигнатурой входа/выхода - это и есть интерфейс (контракт). А его реализация - сервис, где можно задействовать вот это вот всё. Так что здесь отображение кода не мешает ООП, а лишь гарантирует достоверность спецификации (хоть и делает ее более куцей). За кадром остались тесты, которые будут следить, чтобы контракт конкретной версии апи не поменялся. Но если документация использует не код, а дополнительные нотации - то тесты ее не защитят.
Большое спасибо! Наши фронты тоже поддержали эту мысль, что "сила в правде", и работать с актуальным апи без купюр лучше, чем с намарафеченной хнёй. Кажется, искусственное описание вместо отображения реальности - поворот не туда.
Понимаю) Подобные излишне пафосные высказывания о поисковом инструменте выглядят нелепо и даже ламерски. Ведь есть же специализированные средства под конкретные задачи: дебаг, профайлинг, визуализаторы, навигация по синтаксису в конце концов.
Но, тем не менее, когда возникает проблема, полная неопределенности, и в голове только блеклые предположения, на помощь приходит именно Поиск! Молниеносная скорость даже на больших объемах кода, мощный предпросмотр, фильтры, поддержка регулярок. Все это позволяет быстро проверять самые расплывчатые запросы и, что немаловажно, легко менять их на другие. Порядок результатов тут не так важен, в отличии от полноты выборки.
Кстати, во время таких мозговых штурмов, чтобы окно не пропадало, его можно зафиксировать (иконка Pin в правом верхнем углу).
А Find Window используется как тягач, позволяющий выполнить кропотливую обработку, но без возможности изменить курс. Хотя он тоже красавчик, это точно!
640кб оперативки? Не, это слишком по-богатому. Не забывайте, мы в космосе! В нашем распоряжении бесконечное количество магнитных бобин, но оперативки завезли только на 1к, для просмотра сайтов. Файлы с логами в формате "USER_ID:URL\n" (1 символ - 1 байт). Поэтому
Первый день:
Открываем поток на чтение файла первого дня
Не спеша читаем ид пользователя (пока не дойдем до знака ":")
Проверяем, если файла "1-USER_ID" не существует, то создаем поток на запись этого файла и побайтово записываем туда урл (пока не дойдем до знака "\n")
Если файл есть и он пустой, то пропускаем
Если файл есть и он не пустой, то открываем еще один поток на его чтение и побайтово читаем с двух потоков до первого отличия, и если такое находится - делаем файл пустым.
День второй:
По аналогии читаем файл 2-го дня, получив ид пользователя, проверяем файл "1-USER_ID", если файл есть и он пустой, либо его содержимое не совпадает - то это лояльный пользователь. Удаляем файл 1-USER_ID и мигаем светодиодом два раза.
Это точно!) Я вообще больше рофлил, чем пытался дать ценный совет. Эти "любимые задачки" от глубоко окопавшихся в конторе сансеев всегда обрастают таким искусственным налетом, что сложно их воспринимать как реальные кейсы. Решать с закосом под продакшен или под спортивное программирование? Выбор похож на две чашки с ядом, к которому у собеседующего уже отличный иммунитет.
Если уже идти во все тяжкие оптимизации, то зачем вообще держать множества для страниц?
Можно обойтись простым <userId>: <string>. При этом не пустое значение будет означать, что у пользователем посещена только эта страница. А пустое значение - признак посещения более одной страницы. Т.е.
Первый день:
Если пользователя (ключа) нет в коллекции, то добавить туда вместе со значением страницы
Если пользователь есть, и значение страницы пустое, то пропустить.
Если пользователь есть, и значение страницы не совпадает с текущим, то заменить его на пустоту.
Второй день:
Если пользователь есть, и у него либо пустая строка (признак), либо строка не совпадает - то это лояльный пользователь.
Спасибо, попробую! Вообще, я больше хотел популяризовать ValueResolver, в котором можно самостоятельно вклинится в алгоритм переливания запроса в дто. Если Mapping Request Data обладает такой же гибкостью, то супер!
Мое знакомство с этой штукой было примерно таким:
Но теперь на их главной странице красуется ApiResource, без каких-либо обязательств. И я в растерянности) Возможно сам себе навертел это все на мозги.
Не уверен, что понял вопрос. Поэтому если отвечу не то, не обессудь)
Контроллер с его сигнатурой входа/выхода - это и есть интерфейс (контракт). А его реализация - сервис, где можно задействовать вот это вот всё. Так что здесь отображение кода не мешает ООП, а лишь гарантирует достоверность спецификации (хоть и делает ее более куцей). За кадром остались тесты, которые будут следить, чтобы контракт конкретной версии апи не поменялся. Но если документация использует не код, а дополнительные нотации - то тесты ее не защитят.
Большое спасибо! Наши фронты тоже поддержали эту мысль, что "сила в правде", и работать с актуальным апи без купюр лучше, чем с намарафеченной хнёй. Кажется, искусственное описание вместо отображения реальности - поворот не туда.