Да, уже начиная с уровня gold такие гики попадаются. Они в первые пять секунд уже знают страну, а далее просто пытаются найти точное место.
И сам теперь научился десятка стран угадывать по каким-то деталям. Но все равно нужно очень хорошо понимать как устроена природа, какие деревья где встречаются и какая форма/цвет почвы где чаще всего встречается. Иногда захожу на Википедию этой страны и изучаю их устройства, потому что однажды увидел кучу плакатов с мусульманскими призывами, при этом много пальм (Индонезия/Малайзия) но движение правостороннее. Оказалось что в Филиппинах когда то был бунт и с тех пор в этих землях живут как в Индонезии.
Ещё один интересный проект - geoguessr, вы оказываетесь в случайном месте на карте с видом от Google Street view без возможности выйти обратно на вид сверху и разных подсказок(название улиц и домов поверх фото-панорамы) и ваша цель определить где вы оказались. Чем точнее, тем выше балл. Есть режим дуэлей, есть режим без возможности перемещаться и двигать/зумить. Последнее по сути выглядит так: вы видите фото от гул машины, задача найти где вы
Прошу дать совет: есть очередь из задач, примерно 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 секунд простоять на эскалаторе
Кажется, похожую проблему с дорожным движением уже когда-то решали
Да, уже начиная с уровня gold такие гики попадаются. Они в первые пять секунд уже знают страну, а далее просто пытаются найти точное место.
И сам теперь научился десятка стран угадывать по каким-то деталям. Но все равно нужно очень хорошо понимать как устроена природа, какие деревья где встречаются и какая форма/цвет почвы где чаще всего встречается. Иногда захожу на Википедию этой страны и изучаю их устройства, потому что однажды увидел кучу плакатов с мусульманскими призывами, при этом много пальм (Индонезия/Малайзия) но движение правостороннее. Оказалось что в Филиппинах когда то был бунт и с тех пор в этих землях живут как в Индонезии.
Так вот потихоньку учу много разных деталей)
Ещё один интересный проект - geoguessr, вы оказываетесь в случайном месте на карте с видом от Google Street view без возможности выйти обратно на вид сверху и разных подсказок(название улиц и домов поверх фото-панорамы) и ваша цель определить где вы оказались. Чем точнее, тем выше балл. Есть режим дуэлей, есть режим без возможности перемещаться и двигать/зумить. Последнее по сути выглядит так: вы видите фото от гул машины, задача найти где вы
Прошу дать совет: есть очередь из задач, примерно 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 секунд простоять на эскалаторе
Кажется, похожую проблему с дорожным движением уже когда-то решали
съездите в питер, покатайтесь в метро, и да, пробегите вверх на адмиралтейской, может быть поймете, почему там никто не бегает
На деле, если пропустил одного бегуна - придется пропустить всех остальных)
Когда люди видят что бегун остановился, внизу люди начинают хоть как-то заполнять оба ряда