Тоже как-то сэкономил компании лям благодаря своим кривым рукам и... Хабрахабру.
Компания использовала сторонний (но отечественный) сервис по вводу/выводу денег пользователей. Во время очередного рефакторинга я накосячил, и ID кошелька превратился в 0. Удивившись, что API не выдало ошибки, капнул чуть глубже, и... пробил дно)
Оказалось, что пользователь может вывести деньги с чужих кошельков на свои реквизиты всего парой строчек JS.
Дрожащими от предвкушения руками расписал тикет безопасности в техподдержку сервиса. Уже думал, куда поставить феррари, которую мне безусловно вручат за найденную уязвимость. Все-таки даже у нас там было пользовательских кошельков на сумму больше лимона y.e., а ведь были конторы и покрупнее. Но не тут-то было.
Ответили не сразу и без энтузиазма. В максимально сдержанном стиле поблагодарили за подробное описание и сказали, что пофиксят проблему в одном из следующих плановых релизов.
Я выпал в осадок... В течение недели пытался достучаться до них, объясняя всю критичность найденного. Бесполезно. Отвечали медленно, неохотно. Ускорять выход фикса не собирались, давать вознаграждение - тем более.
Контраст между ожиданием и реальностью был так силен, что я даже подумал, что веду беседу с неэтичными сотрудниками, которые сами собираются воспользоваться уязвимостью. Попросил связать с лидом отдела безопасности. Отказали и добавили, что собираются закрыть тикет, если у меня больше нет вопросов.
И тогда, просто из вредности, я написал примерно так: "Вопросов нет. Просто не хотел, чтобы ваше руководство удивилось, когда прочтет об этом на Хабре".
И тут случилось чудо! Ответ последовал буквально в считанные минуты! В нем просили встречи на уровне руководителей компании в удобное нам время. По итогу, выдали бессрочный платиновый аккаунт сервиса, а меня назвали молодцом.
P.S. Кстати, в то время у меня даже не было аккаунта на Хабре xD
Понимаю) Подобные излишне пафосные высказывания о поисковом инструменте выглядят нелепо и даже ламерски. Ведь есть же специализированные средства под конкретные задачи: дебаг, профайлинг, визуализаторы, навигация по синтаксису в конце концов.
Но, тем не менее, когда возникает проблема, полная неопределенности, и в голове только блеклые предположения, на помощь приходит именно Поиск! Молниеносная скорость даже на больших объемах кода, мощный предпросмотр, фильтры, поддержка регулярок. Все это позволяет быстро проверять самые расплывчатые запросы и, что немаловажно, легко менять их на другие. Порядок результатов тут не так важен, в отличии от полноты выборки.
Кстати, во время таких мозговых штурмов, чтобы окно не пропадало, его можно зафиксировать (иконка 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, без каких-либо обязательств. И я в растерянности) Возможно сам себе навертел это все на мозги.
Не уверен, что понял вопрос. Поэтому если отвечу не то, не обессудь)
Контроллер с его сигнатурой входа/выхода - это и есть интерфейс (контракт). А его реализация - сервис, где можно задействовать вот это вот всё. Так что здесь отображение кода не мешает ООП, а лишь гарантирует достоверность спецификации (хоть и делает ее более куцей). За кадром остались тесты, которые будут следить, чтобы контракт конкретной версии апи не поменялся. Но если документация использует не код, а дополнительные нотации - то тесты ее не защитят.
Большое спасибо! Наши фронты тоже поддержали эту мысль, что "сила в правде", и работать с актуальным апи без купюр лучше, чем с намарафеченной хнёй. Кажется, искусственное описание вместо отображения реальности - поворот не туда.
Будет лучше (для меня), если это останется безликой байкой. Как поется в песне: "Я бы мог открыть ответ тот, но йог велел хранить секрет, вот."
Тоже как-то сэкономил компании лям благодаря своим кривым рукам и... Хабрахабру.
Компания использовала сторонний (но отечественный) сервис по вводу/выводу денег пользователей. Во время очередного рефакторинга я накосячил, и ID кошелька превратился в 0. Удивившись, что API не выдало ошибки, капнул чуть глубже, и... пробил дно)
Оказалось, что пользователь может вывести деньги с чужих кошельков на свои реквизиты всего парой строчек JS.
Дрожащими от предвкушения руками расписал тикет безопасности в техподдержку сервиса. Уже думал, куда поставить феррари, которую мне безусловно вручат за найденную уязвимость. Все-таки даже у нас там было пользовательских кошельков на сумму больше лимона y.e., а ведь были конторы и покрупнее. Но не тут-то было.
Ответили не сразу и без энтузиазма. В максимально сдержанном стиле поблагодарили за подробное описание и сказали, что пофиксят проблему в одном из следующих плановых релизов.
Я выпал в осадок... В течение недели пытался достучаться до них, объясняя всю критичность найденного. Бесполезно. Отвечали медленно, неохотно. Ускорять выход фикса не собирались, давать вознаграждение - тем более.
Контраст между ожиданием и реальностью был так силен, что я даже подумал, что веду беседу с неэтичными сотрудниками, которые сами собираются воспользоваться уязвимостью. Попросил связать с лидом отдела безопасности. Отказали и добавили, что собираются закрыть тикет, если у меня больше нет вопросов.
И тогда, просто из вредности, я написал примерно так: "Вопросов нет. Просто не хотел, чтобы ваше руководство удивилось, когда прочтет об этом на Хабре".
И тут случилось чудо! Ответ последовал буквально в считанные минуты! В нем просили встречи на уровне руководителей компании в удобное нам время. По итогу, выдали бессрочный платиновый аккаунт сервиса, а меня назвали молодцом.
P.S. Кстати, в то время у меня даже не было аккаунта на Хабре xD
Может быть "панчеры"? Добиваются победы (зависание экрана) ударами джостика по телику.
Понимаю) Подобные излишне пафосные высказывания о поисковом инструменте выглядят нелепо и даже ламерски. Ведь есть же специализированные средства под конкретные задачи: дебаг, профайлинг, визуализаторы, навигация по синтаксису в конце концов.
Но, тем не менее, когда возникает проблема, полная неопределенности, и в голове только блеклые предположения, на помощь приходит именно Поиск! Молниеносная скорость даже на больших объемах кода, мощный предпросмотр, фильтры, поддержка регулярок. Все это позволяет быстро проверять самые расплывчатые запросы и, что немаловажно, легко менять их на другие. Порядок результатов тут не так важен, в отличии от полноты выборки.
Кстати, во время таких мозговых штурмов, чтобы окно не пропадало, его можно зафиксировать (иконка 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, без каких-либо обязательств. И я в растерянности) Возможно сам себе навертел это все на мозги.
Не уверен, что понял вопрос. Поэтому если отвечу не то, не обессудь)
Контроллер с его сигнатурой входа/выхода - это и есть интерфейс (контракт). А его реализация - сервис, где можно задействовать вот это вот всё. Так что здесь отображение кода не мешает ООП, а лишь гарантирует достоверность спецификации (хоть и делает ее более куцей). За кадром остались тесты, которые будут следить, чтобы контракт конкретной версии апи не поменялся. Но если документация использует не код, а дополнительные нотации - то тесты ее не защитят.
Большое спасибо! Наши фронты тоже поддержали эту мысль, что "сила в правде", и работать с актуальным апи без купюр лучше, чем с намарафеченной хнёй. Кажется, искусственное описание вместо отображения реальности - поворот не туда.