Если есть желание - давайте организуем телеграм / дискорд чат для обсуждения более серьезных вещей и внутренней реализации. Я разрабатываю и поддерживаю коннектор Spark для Tarantool и мне тоже очень не хватает литературы и обмена мнениями. Фактически единственное, чем остаётся пользоваться - это документация Spark Internals (сильно устаревшая местами и неполна) и исходники. Я попытался немного исправить ситуацию, и сделал доклад по внутренней части Spark по результатам своих раскопок (https://jpoint.ru/talks/84b0f81d9de64bf2a0ea2d20e1304bd1/) - надеюсь, этот материал можно будет улучшить и развить до новой версии Spark Internals.
Однажды И.С.Баха спросили, как ему удаётся так виртуозно играть на органе. Бах, который играл на органе каждый день по нескольку часов, ответил: "Всё просто. Всего лишь в нужное время нужный палец опускается на нужную клавишу."
Да, свой настоящий уровень владения задачами с литкода, который достигается тренировками. Причем есть консенсус в комьюнити, сколько и каких задач надо решить, есть сайты, которые помогают спланировать подготовку, и отчеты тех, кто готовился и прошёл.
Я не знаю, сколько интервью вы прошли, но кажется об этих вещах не в курсе.
Каким образом получается оценка "хз"? Я сомневаюсь, что так много людей идут на собесы, надеясь только на фотографическую память и молча из головы вытаскивают готовое решение. Речь идет о запоминании алгоритма и его крайних случаев, а не о тексте буква в букву (хотя в условиях 45 минут именно это помогает писать быстрее - ты помнишь как выглядит код, и знаешь как он работает).
Ответ простой -- никому не нужно решение литкода
Эмм, почему тогда эти компании дают задачи из Литкода и рекомендуют его решать? В Литкоде даже есть разделы, помеченные именами определенных компаний.
кандидат ошибочно думает, что сейчас от выучит наизусть литкод и получит оффер сразу на staff позицию
А если кандидат изначально подается на стаффа? Ему предлагаются те же этапы с Литкодом, что и на мидла. Но кроме них надо еще и системный дизайн по-проходить на моках.
Можете поделиться, как "гриндинг" ухудшает исход собеседования? Как удавалось узнать, что кандидат уложился во время собеседования с написанием кода не потому, что гений, а потому что набил руку на десятке таких задач и помнит как выглядит код quicksort?
Люди начинают сейчас готовиться за полгода до собеседования и даже после первого звонка с рекрутером вы обсуждаете, что первое техническое имеет смысл назначить на несколько месяцев вперед, чтобы успеть подготовиться. Компании все равно, какая ситуация у кандидата (а по вашему рассказу выходит, что лучше всего назначать технику сразу на ту же неделю, чтобы гриндинга точно не было), собеседующих инженеров инструктируют за что ставить и снимать баллы, и считают на основе этого оценки, и им тоже все равно какая ситуация у кандидата, они ожидают увидеть результат за 45 минут, который вписывается в их матрицу оценок.
Это мнение очень похоже на защиту "элитарности" этого подхода и что если кто-то этот ценз прошёл, то он своего рода "особенный". Это правда, но нанимают не только гениев, которые сходу могут решить любую задачу (такие наверняка существуют, но не все из них пойдут программировать и далее в гугл, так значит сколько их в процентном соотношении?), но и в основном тех, кто "загриндил". Неспроста сейчас прямо рекомендуют эйчары и сотрудники из этих компаний и эти книги, и мок-интервью, и решать литкод. Если ты можешь прийти и сходу решить любую такую задачу - это из разряда исключений. Тем более что есть все черты стандартизованного экзамена - детально разобрано как должен быть построен ответ, что ожидается если рекрутер задает вопрос типа X, как надо приступать к написанию кода и т.д. И обращаются с прошедшими отбор так же, как с любыми другими работниками в других компаниях из других секторов - сокращения, стандартизованные перформанс ревью для повышения производительности и прочие "пивоты" (Amazon Pivot program), неизбежное "кранчевание" с овертаймами и т.д. Здесь нет никакой элитарности, и людям теперь надо как-то доказывать самим себе и окружающим, зачем они бежали эту стометровку. В то время пока ты только готовишься, тебе предельно ясно, зачем ты тратишь силы и здоровье - ради пары лет нормального заработка, щепотки акций, громкой строчки в резюме и новых болячек. FAANG это теперь такой спорт и музыка, только начинают готовиться пока не с 5 лет - может, через 10 лет так и будет.
Про инфляцию LeetCode уже давно понятно - если раньше все в один голос заявляли что достаточно fizzbuzz для технического этапа, сейчас приходишь на собес и за 45 минут должен либо три простых задачи выдать в работающем виде (было у меня в Facebook, 2020), либо хард, когда ты имеешь возможность уложиться во время и выдать правильный код только если знаешь задачу наизусть (было у меня в этом году), потому что печатаешь и объясняешь решение практически без остановки, посидеть-подумать нет времени.
Я сейчас конкретно при попытке устройства в FAANG конкурирую с китайцами, индусами и молодыми студентами, у которых есть время и силы чтобы реально прорешать и запомнить как минимум 150 задач и пройти около 10 мок-собеседований по систем дизайну, успев при этом перечитать несколько специализированных книг по подготовке именно к собеседованиям. И хотя я постоянно уделяю этому время, когда мне удаётся, всё равно для полноценной подготовки и конкуренции с этими ребятами мне необходимо бросить работу, семью и ботать по восемь часов в день (обычно у меня есть 1-4 часа в неделю).
Любая такая система хакается ("crack this coding interview!") и даже если 20 лет назад она давала нужные результаты, сейчас она достоверна так же, как уличный термометр, на который падает солнце. Сейчас это просто ценз на зарплаты и строчку в резюме, так как от желающих нет отбоя.
Следующим шагом рекомендую запретить строить дома с окнами на запад, а в имеющихся зданиях западные окна наглухо заложить. На компасе надо оставить только три стороны света из четырёх. Из курса географии убрать любые карты с изображениями Западного полушария.
Оценивается не частота появления, а количество до заданного (большого), причем простых определенного свойства. И если например таких простых до какого-либо огромного N по статистике окажется некое представимое M, то их всех можно вычислить (а тогда, например, их не стоит использовать для криптографии).
Это не замена Redis, это решение другого класса. Говоря простыми словами, Редису нельзя доверить хранение вашей базы авторизации пользователей сайта, а Тарантулу-Пикодате можно. Не очень далёким родственником будет SAP Hana, со всеми оговорками "реляционная vs не-реляционная БД".
Теперь расскажите как раздеплоить ваш тарантул через докер контейнеры
Собираете образ с приложением с помощью cartridge pack docker или используете свой на базе нужной вам ОС, подключая репозиторий Тарантула, как описано на сайте.
Описываете docker-compose.yml c указанием вашего образа / делаете docker run -d ваш_образ / прописываете образ в конфигурацию Docker Swarm, etc...
?????
PROFIT!
Вроде, ничего сложного.
Что мне с этой консолью делать?
А что вы хотите сделать?
Это обычная консоль инстанса Тарантула, вы можете вызывать box.cfg, посмотреть содержимое спейсов через box.space.myspace:select(), переключиться в SQL режим, выполнить любой Lua-код, обратиться к API Cartridge или других модулей. Всё это есть в документации на сайте, а также в примерах в github и статьях тут, на Хабре.
выдаёт 404 ошибку - такой страницы не существует.
Грустно, что у нас здесь был косяк, но мы непрерывно исправляем документацию. Сообщить о таком косяке очень просто: надо выделить строчку и нажать Ctrl+Enter, а потом нажать "Отправить".
Шёл 2021 год, докер медленно сдавал позиции демонлесс утилитам
в instances.yml описаны инстансы на локалхостах которые "запускаются командой cartridge start" - вы там docker-compose впилили ещё в картридж?
Cartridge -- не только ценный мех фреймворк, но и обвязка из инструментов для работы с кластером Tarantool, cartridge-cli. cartridge start - это часть cartridge-cli. Уже есть развёрнутая статья о том, что такое cartridge-cli: https://habr.com/ru/company/mailru/blog/548228/
в статье ни слова о том, как управлять реальными инстансами, а только всё на кошках, которые подняты локально
Однако, во-первых, Kafka Streams — не одно и то же, что и описанная выше очередь, и может быть оверкиллом для ващей задачи, а во-вторых — создание своей реализации чего-то похожего на Kafka Streams не получится уместить в одну статью:)
Если есть желание - давайте организуем телеграм / дискорд чат для обсуждения более серьезных вещей и внутренней реализации. Я разрабатываю и поддерживаю коннектор Spark для Tarantool и мне тоже очень не хватает литературы и обмена мнениями. Фактически единственное, чем остаётся пользоваться - это документация Spark Internals (сильно устаревшая местами и неполна) и исходники.
Я попытался немного исправить ситуацию, и сделал доклад по внутренней части Spark по результатам своих раскопок (https://jpoint.ru/talks/84b0f81d9de64bf2a0ea2d20e1304bd1/) - надеюсь, этот материал можно будет улучшить и развить до новой версии Spark Internals.
Пишите в личку или в другие контакты, буду рад.
Однажды И.С.Баха спросили, как ему удаётся так виртуозно играть на органе. Бах, который играл на органе каждый день по нескольку часов, ответил: "Всё просто. Всего лишь в нужное время нужный палец опускается на нужную клавишу."
Да, свой настоящий уровень владения задачами с литкода, который достигается тренировками. Причем есть консенсус в комьюнити, сколько и каких задач надо решить, есть сайты, которые помогают спланировать подготовку, и отчеты тех, кто готовился и прошёл.
Я не знаю, сколько интервью вы прошли, но кажется об этих вещах не в курсе.
Каким образом получается оценка "хз"? Я сомневаюсь, что так много людей идут на собесы, надеясь только на фотографическую память и молча из головы вытаскивают готовое решение. Речь идет о запоминании алгоритма и его крайних случаев, а не о тексте буква в букву (хотя в условиях 45 минут именно это помогает писать быстрее - ты помнишь как выглядит код, и знаешь как он работает).
Эмм, почему тогда эти компании дают задачи из Литкода и рекомендуют его решать? В Литкоде даже есть разделы, помеченные именами определенных компаний.
А если кандидат изначально подается на стаффа? Ему предлагаются те же этапы с Литкодом, что и на мидла. Но кроме них надо еще и системный дизайн по-проходить на моках.
Можете поделиться, как "гриндинг" ухудшает исход собеседования? Как удавалось узнать, что кандидат уложился во время собеседования с написанием кода не потому, что гений, а потому что набил руку на десятке таких задач и помнит как выглядит код quicksort?
Люди начинают сейчас готовиться за полгода до собеседования и даже после первого звонка с рекрутером вы обсуждаете, что первое техническое имеет смысл назначить на несколько месяцев вперед, чтобы успеть подготовиться. Компании все равно, какая ситуация у кандидата (а по вашему рассказу выходит, что лучше всего назначать технику сразу на ту же неделю, чтобы гриндинга точно не было), собеседующих инженеров инструктируют за что ставить и снимать баллы, и считают на основе этого оценки, и им тоже все равно какая ситуация у кандидата, они ожидают увидеть результат за 45 минут, который вписывается в их матрицу оценок.
Это мнение очень похоже на защиту "элитарности" этого подхода и что если кто-то этот ценз прошёл, то он своего рода "особенный". Это правда, но нанимают не только гениев, которые сходу могут решить любую задачу (такие наверняка существуют, но не все из них пойдут программировать и далее в гугл, так значит сколько их в процентном соотношении?), но и в основном тех, кто "загриндил". Неспроста сейчас прямо рекомендуют эйчары и сотрудники из этих компаний и эти книги, и мок-интервью, и решать литкод. Если ты можешь прийти и сходу решить любую такую задачу - это из разряда исключений. Тем более что есть все черты стандартизованного экзамена - детально разобрано как должен быть построен ответ, что ожидается если рекрутер задает вопрос типа X, как надо приступать к написанию кода и т.д. И обращаются с прошедшими отбор так же, как с любыми другими работниками в других компаниях из других секторов - сокращения, стандартизованные перформанс ревью для повышения производительности и прочие "пивоты" (Amazon Pivot program), неизбежное "кранчевание" с овертаймами и т.д. Здесь нет никакой элитарности, и людям теперь надо как-то доказывать самим себе и окружающим, зачем они бежали эту стометровку. В то время пока ты только готовишься, тебе предельно ясно, зачем ты тратишь силы и здоровье - ради пары лет нормального заработка, щепотки акций, громкой строчки в резюме и новых болячек. FAANG это теперь такой спорт и музыка, только начинают готовиться пока не с 5 лет - может, через 10 лет так и будет.
Про инфляцию LeetCode уже давно понятно - если раньше все в один голос заявляли что достаточно fizzbuzz для технического этапа, сейчас приходишь на собес и за 45 минут должен либо три простых задачи выдать в работающем виде (было у меня в Facebook, 2020), либо хард, когда ты имеешь возможность уложиться во время и выдать правильный код только если знаешь задачу наизусть (было у меня в этом году), потому что печатаешь и объясняешь решение практически без остановки, посидеть-подумать нет времени.
Я сейчас конкретно при попытке устройства в FAANG конкурирую с китайцами, индусами и молодыми студентами, у которых есть время и силы чтобы реально прорешать и запомнить как минимум 150 задач и пройти около 10 мок-собеседований по систем дизайну, успев при этом перечитать несколько специализированных книг по подготовке именно к собеседованиям. И хотя я постоянно уделяю этому время, когда мне удаётся, всё равно для полноценной подготовки и конкуренции с этими ребятами мне необходимо бросить работу, семью и ботать по восемь часов в день (обычно у меня есть 1-4 часа в неделю).
Любая такая система хакается ("crack this coding interview!") и даже если 20 лет назад она давала нужные результаты, сейчас она достоверна так же, как уличный термометр, на который падает солнце. Сейчас это просто ценз на зарплаты и строчку в резюме, так как от желающих нет отбоя.
Следующим шагом рекомендую запретить строить дома с окнами на запад, а в имеющихся зданиях западные окна наглухо заложить. На компасе надо оставить только три стороны света из четырёх. Из курса географии убрать любые карты с изображениями Западного полушария.
Оценивается не частота появления, а количество до заданного (большого), причем простых определенного свойства. И если например таких простых до какого-либо огромного N по статистике окажется некое представимое M, то их всех можно вычислить (а тогда, например, их не стоит использовать для криптографии).
Всё-таки не Жорж Батай, а Жан Бодрийяр наверное. Вы специально допустили эту ошибку? ?
Кмк верный ответ мог бы быть "Смотря как пищит. Если коротко и один раз - значит всё в порядке."
Это не замена Redis, это решение другого класса. Говоря простыми словами, Редису нельзя доверить хранение вашей базы авторизации пользователей сайта, а Тарантулу-Пикодате можно. Не очень далёким родственником будет SAP Hana, со всеми оговорками "реляционная vs не-реляционная БД".
Собираете образ с приложением с помощью
cartridge pack dockerили используете свой на базе нужной вам ОС, подключая репозиторий Тарантула, как описано на сайте.Описываете
docker-compose.ymlc указанием вашего образа / делаетеdocker run -d ваш_образ/ прописываете образ в конфигурацию Docker Swarm, etc...?????
PROFIT!
Вроде, ничего сложного.
А что вы хотите сделать?
Это обычная консоль инстанса Тарантула, вы можете вызывать
box.cfg, посмотреть содержимое спейсов черезbox.space.myspace:select(), переключиться в SQL режим, выполнить любой Lua-код, обратиться к API Cartridge или других модулей. Всё это есть в документации на сайте, а также в примерах в github и статьях тут, на Хабре.Грустно, что у нас здесь был косяк, но мы непрерывно исправляем документацию. Сообщить о таком косяке очень просто: надо выделить строчку и нажать Ctrl+Enter, а потом нажать "Отправить".
Ну так попробуйте Kubernetes operator для Tarantool.
Cartridge -- не только
ценный мехфреймворк, но и обвязка из инструментов для работы с кластером Tarantool, cartridge-cli. cartridge start - это часть cartridge-cli. Уже есть развёрнутая статья о том, что такое cartridge-cli: https://habr.com/ru/company/mailru/blog/548228/Используйте ansible. Об этом у нас уже написаны отдельные развёрнутые статьи:
https://habr.com/ru/company/mailru/blog/478710/
И даже прям реальный кейс прода на 500 инстансов, совсем не "на кошках":
https://habr.com/ru/company/mailru/blog/543086/
Используйте cartridge connect: https://www.tarantool.io/ru/doc/latest/book/cartridge/cartridge_cli/#usage
Наверное, в статье не хватает раскрытия, как Java-драйвер позволяет работать с хранилищем vshard. `ProxyTarantoolTupleClient` как раз для этого.
Драйвер запаковывает запрос в msgpack и передаёт Тарантулу по бинарному протоколу iproto, а потом парсит ответ обратно в Java-типы.
Развивается инструмент миграций для Tarantool Cartridge: https://github.com/tarantool/migrations/
Приходите в чат, у нескольких человек уже получалось запустить (под WSL), в том числе из наших разработчиков, так что это не очень сложно.
А мы тут как раз запилили удобный инструмент для фидбека на документацию прямо на сайте, может придёте и напишете о своей проблеме?
В правом нижнем углу страницы есть кнопка:
Откроется форма:
Из этой формы фидбек попадает прямо в задачи.
Так и на Lua/Tarantool эти приложения давно существуют, можно посмотреть на tarantool/queue или на moonlibs/xqueue.
Однако, во-первых, Kafka Streams — не одно и то же, что и описанная выше очередь, и может быть оверкиллом для ващей задачи, а во-вторых — создание своей реализации чего-то похожего на Kafka Streams не получится уместить в одну статью:)