Replicated replacing merge tree умеет в дедубликацию при вставке, видит последние n инсертов (вроде по умолчанию 50) и в случае если один и тот же батч данных прилетело, то второй раз просто будет игнорировать
Тоже продавал долю в бизнесе, поставили подобные условия. Сразу заявил, что ничто меня не удержит это соблюдать, и сразу сказал - я буду конкурировать.
К слову, долю заставили продать, наверное поэтому категорично высказался
И да, нашел изъяны в договоре и теперь открыто делаю такой же сервис, точь в точь) Благо, объем рынка это позволяет делать
у меня короткий ответ: он есть, и работает примерно так. Остальное на практике почти не используется. Главное понимать концепцию
Дальше собеседник начинает потноваться своими познаниями, как далеко он сам копнул.
Я: : "вы это применяете на продакшене?"
Собеседник: "нет. Просто было интересно спросить. А вот ещё вопрос: если сделать Object.create(.... А вот ещё: чем отличается .call и .apply?.."
Я: "Вы это применяете на продакшене?"
Ответ: "нет"
Занавес
Зачем дотошно спрашивать теорию, причем если ошибся в ответе - все, максимум мидл. Хотя концепцию рассказал и они согласись. Но им нужны детали, как будто только чтоб докопаться
поэтому отдельно выделили сферы, где можно не применять онлайн кассы - отдаленные регионы с плохим интернетом, отдаленные населенные пункты и так далее. все остальные - должны пробивать онлайн чеки, иначе штраф, примерно 30 тыс рублей за один непробитый чек
история с штрих-м в 2017 в декабре показала, что проще просто без чеков продавать
на самом деле есть 54ФЗ, в котором все чеки регламентируются, они должны отправляться в ОФД и так далее
Более того, сейчас многие магазины, особенно крупные, держат в согласованном состоянии кассы и склад. Тот же вкусвил, например, имеет хорошую интеграцию склада с кассой, пусть и с некоторой задержкой
вообще, в сфере retail в статье много сказано про глобальный рынок, потому что в рф в ритейле хорошо продвинулись
Мне кажется, этот способ станет стандартом и все к нему привыкнут
Исполнитель и заказчик будут понимать что цена "векторному направлению проекта вместо четкого ТЗ" - сложность в коммуникации
При этом бизнесу выгодно формат бег ТЗ, где можно на ходу менять цели и вообще направление. Рынок ведь тоже не стоит на месте, конкуренция растет, и выигрывает тот, кто быстрее решит новые проблемы клиентов. А когда проблемы устаканены, можно уделить внимание "красоте архитектуры"
бывают кейсы, когда надо по эскалатору идти, например когда сломался и надо спускаться пешком
в вашем случае дедушек и бабушек будете краном доставать, потому что они идти откажуться по таким ступенькам
Если вдруг хоть кто-то из-за этого хоть царапину получит, например на ноге когда будет спускаться - сразу засудят и отнимут пару мультов, плюс есть шанс натолкнуться на коллективный иск
Говорю из своего опыта, пару раз до конца добежал, на достаточно глубоких станциях
Теперь даже идти не вижу смысла, от силы 20 секунд сэкономить можно. И то, в мск на переходах сначало надо отстоять 2-3 минуты в толпе на вход в эскалатор, затем пробежать секунд 20, например на пересадках на кольцевой.
Намного проще оптимизировать то, что занимает много времени, чем "проход по левой стороне"
Если все будут оба ряда занимать, очередь перед эскалатором сократится на пару минут, но нужно будет лишние 20 секунд простоять на эскалаторе
Кажется, похожую проблему с дорожным движением уже когда-то решали
Я стою справа только чтобы меня не потревожили бегуны, чаще всего так делаю при свободном потоке
Но иногда появляется смелость и в час пик встаю слева, специально блокируя бегунов. Это очень страшно, бегуны начинают угрожать, благо наушники на полной громкости и игнор спасают, пока бегун не начнет руками меня трогать, чтобы физически сдвинуть
И тут последнее что делаю - поворачиваюсь и говорю прямо, что не буду пропускать специально, чтобы ускорить общий поток
Очень крутая статья! Ровно такого же подхода придерживался на работе, и до последнего не изменяя ему)
Перед тем как дать задачу команде, спрашивал, все ли ок. Если хоть капля сомнений появляется, сразу начинаем копать, что именно не нравится и так далее. В итоге чаще всего убираем лишнее, либо даём больше ресурсов на разработку. При этом команда понимает, что в случае багов именно они несут ответственность, поэтому всегда стараются сделать так, чтобы потом 10 раз не возвращаться. Кажется, что работаем медленно, но фичи в любом случае появляются и сервис при этом очень стабильно работает. И клиенты довольны, и команда довольна)
Весёлый момент из жизни: программист непременно отключил одну из фич на бекенде и никому не сказал. Через три недели выяснилось, что это никому не нужно, ведь ни один клиент даже не упомянул о сломанной странице. В итоге приняли решение удалить, чтобы не поддерживать мертвый кусок сервиса
тесла так и сделала. выкатила родстер, который был ужасным по удобству, но его быстро выкатили, проверили рынок. далее был модел эс, который тоже ужасный, я сидел несколько раз в них, там отделка как в солярисе, если не хуже
и только потом смогли выкатить модел 3 и остальные, где уже чуть чуть пахнет удобством, хотя даже до уровня тойоты не дотянули, про мерсы вспоминать даже не хочется
по сути, вот эти - спринты, короткие, для проверки гипотез. потому что в мире автопрома коротко - это сделать тачку за 1.5 года. рекорд из успешных моделей у тойоты приуса, 18 месяцев от глиняного прототипа до конвеера. У остальных в среднем этот путь занимает около 5 лет.
Мне хватает 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 секунд простоять на эскалаторе
Кажется, похожую проблему с дорожным движением уже когда-то решали
съездите в питер, покатайтесь в метро, и да, пробегите вверх на адмиралтейской, может быть поймете, почему там никто не бегает
На деле, если пропустил одного бегуна - придется пропустить всех остальных)
Когда люди видят что бегун остановился, внизу люди начинают хоть как-то заполнять оба ряда
Я стою справа только чтобы меня не потревожили бегуны, чаще всего так делаю при свободном потоке
Но иногда появляется смелость и в час пик встаю слева, специально блокируя бегунов. Это очень страшно, бегуны начинают угрожать, благо наушники на полной громкости и игнор спасают, пока бегун не начнет руками меня трогать, чтобы физически сдвинуть
И тут последнее что делаю - поворачиваюсь и говорю прямо, что не буду пропускать специально, чтобы ускорить общий поток
И если бегун совсем тупой - пропускаю
Только недавно прочитал новость о том, как Макс вылетел из сервера во время гонок и в гонках победил в итоге Смоляр
В Уфе часто заранее включают ожидание, хотя я стою на улице и такси ещё не доехал
Очень крутая статья! Ровно такого же подхода придерживался на работе, и до последнего не изменяя ему)
Перед тем как дать задачу команде, спрашивал, все ли ок. Если хоть капля сомнений появляется, сразу начинаем копать, что именно не нравится и так далее. В итоге чаще всего убираем лишнее, либо даём больше ресурсов на разработку. При этом команда понимает, что в случае багов именно они несут ответственность, поэтому всегда стараются сделать так, чтобы потом 10 раз не возвращаться. Кажется, что работаем медленно, но фичи в любом случае появляются и сервис при этом очень стабильно работает. И клиенты довольны, и команда довольна)
Весёлый момент из жизни: программист непременно отключил одну из фич на бекенде и никому не сказал. Через три недели выяснилось, что это никому не нужно, ведь ни один клиент даже не упомянул о сломанной странице. В итоге приняли решение удалить, чтобы не поддерживать мертвый кусок сервиса
# Unavailable in 3.9 and upRABBITMQ_DEFAULT_PASS_FILE
RABBITMQ_DEFAULT_USER_FILE
Я так понял, именно вот эти переменные deprecated. Обычные RABBITMQ_DEFAULT_USER актуален ещё
тесла так и сделала. выкатила родстер, который был ужасным по удобству, но его быстро выкатили, проверили рынок. далее был модел эс, который тоже ужасный, я сидел несколько раз в них, там отделка как в солярисе, если не хуже
и только потом смогли выкатить модел 3 и остальные, где уже чуть чуть пахнет удобством, хотя даже до уровня тойоты не дотянули, про мерсы вспоминать даже не хочется
по сути, вот эти - спринты, короткие, для проверки гипотез. потому что в мире автопрома коротко - это сделать тачку за 1.5 года. рекорд из успешных моделей у тойоты приуса, 18 месяцев от глиняного прототипа до конвеера. У остальных в среднем этот путь занимает около 5 лет.