Прошу дать совет: есть очередь из задач, примерно 120млн шт(например id, datetime) и надо их обрабатывать - сходить в другой сервис, получить данные и вернуть ответ в следующую очередь
Положить сразу 120млн сообщений в очередь некрасиво, я сделал доп очередь, в котором лежат сообщения в виде { minId, maxId}, далее обработчик извлекает все id в этом диапазоне и отравляет в следующую очередь
Что я сделал: при обработке minId, maxId проверяю длину следующий очереди, и если она больше чем X, то delay(t sec) , nack ()
В итоге у меня все очереди не превышают заданных лимитов, и я спокоен что ничего не утечет
есть три вида хоткеев: 1) дерево файлов 2) окно где код пишем 3) терминал, который у меня открыт в vscode снизу окна с кодом
мне нужно между ними быстро и удобно переключаться так, чтобы хоткеи были примерно одинаковыми и плюс чтобы терминал не съедал мои хоткеи. вот тут как раз и был затык, мне нужно было настроить хоткеи на переход с окна с кодом на терминал, с терминала на дерево файлов и с дерева файлов на терминал это было почти 4 года назад, уже не помню что именно не смог настроить, но помню что приходилось брать мышку чтобы просто переключить фокус с одного окна на другой
это и вызвало тошноту, потому что очень часто я перехожу между ними.
сейчас у меня terminator + vim, в терминаторе настроил переходы между окнами и табами, в виме настроил переходы между деревом и окном с кодом. при этом, если фокус держится на виме, то переход между окнами/табами в терминаторе корректно ловят хоткеи и переключаются. это надежно и очень удобно. работают как часы
поэтому теперь мышка абсолютно не нужна, разве чтоб в браузере серфить и в телеграм заходить. И то, в браузере стоит vimium, который тоже позволяет иногда обходится только клавой
Я сначала перешёл с vscode на вим просто чтобы изучить что это такое и почему о нем так много шума
Через 6 месяцев решил попробовать вернуться обратно в vscode и чуть не вырвало в прямом смысле: мне приходилось перемещать фокус взгляда между 1) монитором, 2) клавой, и 3) мышкой. При этом когда брал мышку не всегда сразу находил где именно находится курсор. Через 15 минут такого извращения понял что хочу просто положить руки на клаву и не отрывать взгляд от монитора. Это был чистый кайф
Replicated replacing merge tree умеет в дедубликацию при вставке, видит последние n инсертов (вроде по умолчанию 50) и в случае если один и тот же батч данных прилетело, то второй раз просто будет игнорировать
Тоже продавал долю в бизнесе, поставили подобные условия. Сразу заявил, что ничто меня не удержит это соблюдать, и сразу сказал - я буду конкурировать.
К слову, долю заставили продать, наверное поэтому категорично высказался
И да, нашел изъяны в договоре и теперь открыто делаю такой же сервис, точь в точь) Благо, объем рынка это позволяет делать
у меня короткий ответ: он есть, и работает примерно так. Остальное на практике почти не используется. Главное понимать концепцию
Дальше собеседник начинает потноваться своими познаниями, как далеко он сам копнул.
Я: : "вы это применяете на продакшене?"
Собеседник: "нет. Просто было интересно спросить. А вот ещё вопрос: если сделать Object.create(.... А вот ещё: чем отличается .call и .apply?.."
Я: "Вы это применяете на продакшене?"
Ответ: "нет"
Занавес
Зачем дотошно спрашивать теорию, причем если ошибся в ответе - все, максимум мидл. Хотя концепцию рассказал и они согласись. Но им нужны детали, как будто только чтоб докопаться
поэтому отдельно выделили сферы, где можно не применять онлайн кассы - отдаленные регионы с плохим интернетом, отдаленные населенные пункты и так далее. все остальные - должны пробивать онлайн чеки, иначе штраф, примерно 30 тыс рублей за один непробитый чек
история с штрих-м в 2017 в декабре показала, что проще просто без чеков продавать
на самом деле есть 54ФЗ, в котором все чеки регламентируются, они должны отправляться в ОФД и так далее
Более того, сейчас многие магазины, особенно крупные, держат в согласованном состоянии кассы и склад. Тот же вкусвил, например, имеет хорошую интеграцию склада с кассой, пусть и с некоторой задержкой
вообще, в сфере retail в статье много сказано про глобальный рынок, потому что в рф в ритейле хорошо продвинулись
Мне кажется, этот способ станет стандартом и все к нему привыкнут
Исполнитель и заказчик будут понимать что цена "векторному направлению проекта вместо четкого ТЗ" - сложность в коммуникации
При этом бизнесу выгодно формат бег ТЗ, где можно на ходу менять цели и вообще направление. Рынок ведь тоже не стоит на месте, конкуренция растет, и выигрывает тот, кто быстрее решит новые проблемы клиентов. А когда проблемы устаканены, можно уделить внимание "красоте архитектуры"
бывают кейсы, когда надо по эскалатору идти, например когда сломался и надо спускаться пешком
в вашем случае дедушек и бабушек будете краном доставать, потому что они идти откажуться по таким ступенькам
Если вдруг хоть кто-то из-за этого хоть царапину получит, например на ноге когда будет спускаться - сразу засудят и отнимут пару мультов, плюс есть шанс натолкнуться на коллективный иск
Говорю из своего опыта, пару раз до конца добежал, на достаточно глубоких станциях
Теперь даже идти не вижу смысла, от силы 20 секунд сэкономить можно. И то, в мск на переходах сначало надо отстоять 2-3 минуты в толпе на вход в эскалатор, затем пробежать секунд 20, например на пересадках на кольцевой.
Намного проще оптимизировать то, что занимает много времени, чем "проход по левой стороне"
Если все будут оба ряда занимать, очередь перед эскалатором сократится на пару минут, но нужно будет лишние 20 секунд простоять на эскалаторе
Кажется, похожую проблему с дорожным движением уже когда-то решали
Я стою справа только чтобы меня не потревожили бегуны, чаще всего так делаю при свободном потоке
Но иногда появляется смелость и в час пик встаю слева, специально блокируя бегунов. Это очень страшно, бегуны начинают угрожать, благо наушники на полной громкости и игнор спасают, пока бегун не начнет руками меня трогать, чтобы физически сдвинуть
И тут последнее что делаю - поворачиваюсь и говорю прямо, что не буду пропускать специально, чтобы ускорить общий поток
Прошу дать совет: есть очередь из задач, примерно 120млн шт(например id, datetime) и надо их обрабатывать - сходить в другой сервис, получить данные и вернуть ответ в следующую очередь
Положить сразу 120млн сообщений в очередь некрасиво, я сделал доп очередь, в котором лежат сообщения в виде { minId, maxId}, далее обработчик извлекает все id в этом диапазоне и отравляет в следующую очередь
Что я сделал: при обработке minId, maxId проверяю длину следующий очереди, и если она больше чем X, то delay(t sec) , nack ()
В итоге у меня все очереди не превышают заданных лимитов, и я спокоен что ничего не утечет
Нормальный ли этот подход?
Или в корне все криво?
есть три вида хоткеев:
1) дерево файлов
2) окно где код пишем
3) терминал, который у меня открыт в vscode снизу окна с кодом
мне нужно между ними быстро и удобно переключаться так, чтобы хоткеи были примерно одинаковыми и плюс чтобы терминал не съедал мои хоткеи. вот тут как раз и был затык, мне нужно было настроить хоткеи на переход с окна с кодом на терминал, с терминала на дерево файлов и с дерева файлов на терминал
это было почти 4 года назад, уже не помню что именно не смог настроить, но помню что приходилось брать мышку чтобы просто переключить фокус с одного окна на другой
это и вызвало тошноту, потому что очень часто я перехожу между ними.
сейчас у меня terminator + vim, в терминаторе настроил переходы между окнами и табами, в виме настроил переходы между деревом и окном с кодом. при этом, если фокус держится на виме, то переход между окнами/табами в терминаторе корректно ловят хоткеи и переключаются. это надежно и очень удобно. работают как часы
поэтому теперь мышка абсолютно не нужна, разве чтоб в браузере серфить и в телеграм заходить. И то, в браузере стоит vimium, который тоже позволяет иногда обходится только клавой
Я так понял чаще всего с первыми родами бывают долгие процессы
2+ обычно около часа
При этом первого мать может рожать 12+ часов
Я сначала перешёл с vscode на вим просто чтобы изучить что это такое и почему о нем так много шума
Через 6 месяцев решил попробовать вернуться обратно в vscode и чуть не вырвало в прямом смысле: мне приходилось перемещать фокус взгляда между 1) монитором, 2) клавой, и 3) мышкой. При этом когда брал мышку не всегда сразу находил где именно находится курсор. Через 15 минут такого извращения понял что хочу просто положить руки на клаву и не отрывать взгляд от монитора. Это был чистый кайф
Мне хватает postgres, select for update
Rbbitmq поднимается в 2 команды из докера, и почти не требует настроек и администрации для такой маленькой задачи
И при этом решает огромный пласт проблем при парсинге
Сам занимаюсь парсингом Wildberries, 100млн+ товаров в день, примерно 10к товаров с секунду
И со всем этим простой rabbotmq с persistent очередями справляется
Replicated replacing merge tree умеет в дедубликацию при вставке, видит последние n инсертов (вроде по умолчанию 50) и в случае если один и тот же батч данных прилетело, то второй раз просто будет игнорировать
Тоже продавал долю в бизнесе, поставили подобные условия. Сразу заявил, что ничто меня не удержит это соблюдать, и сразу сказал - я буду конкурировать.
К слову, долю заставили продать, наверное поэтому категорично высказался
И да, нашел изъяны в договоре и теперь открыто делаю такой же сервис, точь в точь) Благо, объем рынка это позволяет делать
Как раз-таки процесс никто не трогает. Работают лишь над ценностью для пользователей
Если можно урезать фичу так, что ценность сохранится или немного уменьшиться - то разработчик предлагает урезать это ради уменьшения Time to market
у меня короткий ответ: он есть, и работает примерно так. Остальное на практике почти не используется. Главное понимать концепцию
Дальше собеседник начинает потноваться своими познаниями, как далеко он сам копнул.
Я: : "вы это применяете на продакшене?"
Собеседник: "нет. Просто было интересно спросить. А вот ещё вопрос: если сделать Object.create(.... А вот ещё: чем отличается .call и .apply?.."
Я: "Вы это применяете на продакшене?"
Ответ: "нет"
Занавес
Зачем дотошно спрашивать теорию, причем если ошибся в ответе - все, максимум мидл. Хотя концепцию рассказал и они согласись. Но им нужны детали, как будто только чтоб докопаться
Ок, до свидания найти ботаника)
а потом компилирует и выбрасывает все типы
я так понял ts нужен только в процессе разработки, в продакшене он ничем не отличается от нативного js
54 фз не позволяет пробивать чек без связи с офд
поэтому отдельно выделили сферы, где можно не применять онлайн кассы - отдаленные регионы с плохим интернетом, отдаленные населенные пункты и так далее. все остальные - должны пробивать онлайн чеки, иначе штраф, примерно 30 тыс рублей за один непробитый чек
история с штрих-м в 2017 в декабре показала, что проще просто без чеков продавать
на самом деле есть 54ФЗ, в котором все чеки регламентируются, они должны отправляться в ОФД и так далее
Более того, сейчас многие магазины, особенно крупные, держат в согласованном состоянии кассы и склад. Тот же вкусвил, например, имеет хорошую интеграцию склада с кассой, пусть и с некоторой задержкой
вообще, в сфере retail в статье много сказано про глобальный рынок, потому что в рф в ритейле хорошо продвинулись
Мне кажется, этот способ станет стандартом и все к нему привыкнут
Исполнитель и заказчик будут понимать что цена "векторному направлению проекта вместо четкого ТЗ" - сложность в коммуникации
При этом бизнесу выгодно формат бег ТЗ, где можно на ходу менять цели и вообще направление. Рынок ведь тоже не стоит на месте, конкуренция растет, и выигрывает тот, кто быстрее решит новые проблемы клиентов. А когда проблемы устаканены, можно уделить внимание "красоте архитектуры"
бывают кейсы, когда надо по эскалатору идти, например когда сломался и надо спускаться пешком
в вашем случае дедушек и бабушек будете краном доставать, потому что они идти откажуться по таким ступенькам
Если вдруг хоть кто-то из-за этого хоть царапину получит, например на ноге когда будет спускаться - сразу засудят и отнимут пару мультов, плюс есть шанс натолкнуться на коллективный иск
Говорю из своего опыта, пару раз до конца добежал, на достаточно глубоких станциях
Теперь даже идти не вижу смысла, от силы 20 секунд сэкономить можно. И то, в мск на переходах сначало надо отстоять 2-3 минуты в толпе на вход в эскалатор, затем пробежать секунд 20, например на пересадках на кольцевой.
Намного проще оптимизировать то, что занимает много времени, чем "проход по левой стороне"
Если все будут оба ряда занимать, очередь перед эскалатором сократится на пару минут, но нужно будет лишние 20 секунд простоять на эскалаторе
Кажется, похожую проблему с дорожным движением уже когда-то решали
съездите в питер, покатайтесь в метро, и да, пробегите вверх на адмиралтейской, может быть поймете, почему там никто не бегает
На деле, если пропустил одного бегуна - придется пропустить всех остальных)
Когда люди видят что бегун остановился, внизу люди начинают хоть как-то заполнять оба ряда
Я стою справа только чтобы меня не потревожили бегуны, чаще всего так делаю при свободном потоке
Но иногда появляется смелость и в час пик встаю слева, специально блокируя бегунов. Это очень страшно, бегуны начинают угрожать, благо наушники на полной громкости и игнор спасают, пока бегун не начнет руками меня трогать, чтобы физически сдвинуть
И тут последнее что делаю - поворачиваюсь и говорю прямо, что не буду пропускать специально, чтобы ускорить общий поток
И если бегун совсем тупой - пропускаю
Только недавно прочитал новость о том, как Макс вылетел из сервера во время гонок и в гонках победил в итоге Смоляр