Если считать хеш для каждой записи с уникальной солью (положить в ту же строчку таблицы, например), то для проверки каждой строки уже надо будет проверять примерно 10^10 хешей. Всё еще подъёмно, но гораздо дольше и дороже.
Если изрядно разбавить записи фейковыми хешами (которые не соответствуют никакой цифровой комбинации), то уже можно было бы сделать схему месяц-два устойчивую к подбору.
Дальше — да, уже архитектурно другое решение нужно.
Я еще прямее спрашиваю — про какие технологии (или части технологии) хотели бы на собеседовании говорить, а про какие не надо. Интереснее же понять, насколько кандидат глубоко знает, то, что считает своей сильной стороной. А то, что не знает — всё равно придётся освоить.
Полностью поддерживаю. Нафига вот мне при отборе кандидатов вчитываться в резюме, если HR их принесёт от силы 50 за раз? Всех, кто хотя бы на "4 из 10 баллов" попадает в то, что мне нужно — отправить в телефонный скрининг. Не угадал — отдал в скрининг? Потрачено 5 минут на телефонный разговор. Угадал? Отлично. Зачем было 3 ночи сидеть над резюме? Не угадал и выкинул из скрининга? Э… Ну значит что-то совсем неадекватное в резюме было.
И, да, согласен, поиск всего, что выше, чем "ведущий разработчик" — это точно не про советы, как заполнять резюме (тот ещё ритуальный танец с обеих сторон).
Интересная статья. Интересная не только, да и не столько главным тезисом. Сама тема, что "опытный", "старший" или "главный" должен давать высказаться другим или должен вовремя промолчать, чтобы не "задавить" других, не нова. Не банальна, но и не нова. Хорошо описанная аргументированная точка зрения.
Но гораздо интереснее тут следующее:
С одной стороны, описанные причины "помолчать" работают только в конструктивной, "неагрессивной", "нетоксичной" среде. В излишне политизированных корпорациях это часто невозможная практика: молчать или говорить, диктуется совершенно не конструктивными причинами. Так что поздравляю, Андрей, выходит, что JetBrains — конструктивная, неагрессивная, зрелая среда (кто бы собмневался).
С другой стороны — есть коллективы, где такие идеи кажутся азами, точно не стоящие не то что статьи, даже письма. Значит вам есть куда расти :)
А еще (может быть это личное впечатление, но) в JB тот же совет весьма актуален. У вас достаточно высокая планка, из-за этого даже на логарифмической шкале средний сотрудник JB во многих фундаментальных областях программирования (но не во всех практических!) также сильнее среднего "банкорпоративного" разработчика, как Андрей Бреслав по сравнению с таким сотрудником в дизайне ЯП. И тут возникает эффект, который я наблюдал в дискуссиях с сотрудниками JB. К слову — это не корпоративная специфика, большинство спикеров на конференциях, да и вообще многие сильные специалисты легко попадают в похожую ловушку, т. е. примерно та же цепочка срабатывает:
"Обычный" разработчик часто несёт чушь. Настолько часто, что это становится привычным.
Чушь типична. Т.е. послушав её десять раз и столько же раз обосновав, почему это чушь, разобрав её, часто кажется, что и в одиннадцатый раз это будет то же самое.
Такие разборы и коммуникации занимают много сил и времени
Сильному специалисту по привычке начинает казаться, что он прав — немного теряется критичность к себе.
Как итог — выводы становятся поспешными, аргументы и точка зрения другой стороны слегка хуже воспринимаются, причём в 99% случаев это даже незаметно. Более того, сильный специалист — он обычно таки умный и критичность восприятия вполне достаточная, чтобы не свалиться совсем в дичь. Просто ему чуть сложнее договориться с собеседником.
Сразу подчеркну — это не личный упрёк, я таких людей более чем понимаю. Становится действительно сложнее аналитически и критично подходить к своим решениям, когда 100 раз в год советуешь одно и то же. Тут, да, самое простое и логичное решение — вынести в постоянную практику явное принятие решения каждый раз — выслушать или высказать (любые сомнения в пользу "выслушать").
Соответственно — очень приятно видеть, что есть те, кто не только так или иначе осознаёт проблему, но и делятся опытом, как уменьшить её.
Ну так-то почти во всех языковых платформах нехватка разработчиков. А во всех остальных областях нехватка разработчиков, способных понять, о чём думали разработчики платформы.
Нехватка разработчиков в платформах (языках, стандартных библиотеках, среде исполнения), на мой взгляд, в основном из-за того, что среды разработки быстро обрастают грузом наследия и каждая следующая фича пилится сложнее предыдущих. С этой точки зрения, "академические" или "бесполезные" языки как раз и являются единственным местом, где можно проверить подходы, которые лет через Nдцать дойдут до мейнстрима.
Посмотрел на клавиатуру и аж вздрогнул от неприятных воспоминаний. Я надеюсь тому, кто придумал это [censored] расположение кнопочек между стрелками и Delete/End/PgDwn до сих пор икается. Причём засада примерно в 2001-2004 годах была, что эти [censored] кнопки были почти на всех клавиатурах.
Легитимность ПО для виртуализации (!) 12-летней выдержки (!!) на пользовательском компьютере (!!!) с непонятным образом такой же древней ОС (!!!!) — ну это так себе легитимность. Задумался: а нафига тянуть хламную vbox плюс какую-то мутную XP? А если запустить WSL, для которого, например, есть опубликованная "честная" Kali, и она весит 189 МБ?
Помните, как в 90-е и начале 2000-х при том, что поддержка Unicode в мэйнстримных ОС существовала уже многие годы, регулярно возникали проблемы с кириллицей в путях и прочих строковых данных?
Они и сейчас есть почти повсюду (JetBrains, Ansible, Gitlab, WSL, Visual Studio — это то, где за последний год сталкивался, где-то ошибки в продуктах, где-то в платформах/библиотеках). У меня на одном из компов дома на винде домашний каталог на кириллице и с пробелом, я все эти грабли собираю. Принципиально путь не меняю: если всё совсем не обходится, то либо на другом ПК, либо в виртуалке. Если хорошо воспроизводится — пишу тикет.
Не раздражён, но несколько разочарован. Я-то стал читать именно потому что недавно объяснял ту же тему (и надеялся, что есть что-то интересное). Увидел комментарий "странно, что минусуют", описал, что меня разочаровало.
Если интересно, могу описать, как я объяснял.
Другим (но не первоклассникам) я тоже объяснял. И если сравнить процент моего успеха в объяснении "что такое указатели", "функция, как значение" и "двоичная система", то "двоичная система" в понятности и усваиваемости безоговорочно лидирует.
Я вот не минусанул только потому что искренне против ставить минусы (я лучше 30 плюсов поставлю). Но рука уже тянулась :)
Для меня проблема этой статьи только одна: я без этой статьи и без рефлексирования "ах, сложно-сложно" объяснил сыну первокласснику эту тему за полчаса. Знаете, объяснить двоичную систему проще, чем ветвление, проще, чем рекурсию, да чего уж там — проще, чем "что такое бит", и зачем он нам нужен в компьютере и почему нужна двоичная, а не троичная (или еще какая) система исчисления.
Даже учитывая, что он сам этим интересуется — он всего лишь первоклассник, ему сложно объяснять многие вещи, но не двоичную систему. Ну, ок, конечно, в математике и программировании он явно выше среднего, но не так уж драматически.
Сама мысль о посадке с лёту в здание. Я могу представить такое в качестве трюка (с трудом), но в качестве штатной процедуры — ну никак. Мне страшно даже когда с одной стороны поверхность, я в ужасе, если с двух сторон, а уж когда с 5 сторон — ненене. Там на границе здания такие Навье-Стоксы забавные, что я даже непрерывное не пойду искать. Хотите проверить дёшево — купите мавик и попробуйте стабильно залетать им в форточку и садить там.
Разделение по высоте с одного направления не работает. Ну по крайней мере, если разница не 200+ метров. даже при разнице в 100 м нижнему будет очень весело.
Ну и здание будет огромным. ЛА надо безопасно затормозить, сектора посадки тоже потребуют места. Я сомневаюсь, что можно как-то сделать такое здание диаметром менее 25-30 метров даже чисто гипотетически. Ну и если высоту площадок приземления поднять хотя бы на 30-50 метров — это получается очень монументально и не дёшево.
Хотите показать обоснование, опять же — соорудите такой скворечник для мелких коптеров и покажите. Денег на это уйдёт относительно немного (я думаю, что даже $100K хватит, но не обещаю), польза в любом случае будет: технологии посадки в такой скворечник пригодятся даже без пассажиров.
"аэро площадки у каждого офиса" — такая площадка даже просто на хранение коптера примерно займёт 6-8 машиномест. С местом для взлёта — гораздо больше.
Для ваших предложений хотя бы для себя эскиз нарисуйте, ответьте себе что является главной инженерной проблемой.
В идеале это 3-5 сек на взлет до перехода в самолётный режим, и ещё столько же или меньше секунд на вертикальную посадку.
3-5 секунд для 100-200 метров "с места"? С паксом на борту? А потом "столько же или меньше секунд на вертикальную посадку"??? Таких адреналиновых наркоманов устойчивых к перегрузкам еще поискать надо будет.
Когда мне кто-то из коллег в 2017 году затирал про "скороаэеротаксидлявсех" я просто с ним вышел на парковку перед офисом, где, наверное, пара сотен машин стояла. Угу, давай представим, как к 9:00 сюда надо сделать хотя бы несколько десятков посадок (любых) коптеров, сколько это времени и места на парковке займёт. И, да, эта парковка была еще самым подходящим местом. Не забываем, что десяток висящих в очереди это уже на самом деле страшно (горючее лимитировано, а про аккумуляторы я даже не заикаюсь, все движутся, всем надо срочно, все "запасные" площадки также перегружены). Даже если всю парковку освободить — не поможёт. Ах, да, ещё конечно, в этот "колодец" я бы рискнул с опытным пилотом приземляться только до 7 м/с и в ясную погоду (и это тоже еще очень удачное место).
Разовые полёты возможны ровно потому, что их на несколько порядков меньше, чем автопередвижений.
Тут даже "эффективность" и "шумность" еще рано считать. Проще посчитать пропускную способность потенциально возводимой инфраструктуры (спойлер: её не хватит и на 5% автотрафика)
Ну как некуда — было +1.3 станет -1.3 :)
Так и не понял что будет с latency. А то этот показатель не только не улучшается, он даже слегка деградирует начиная с DDR2.
Если считать хеш для каждой записи с уникальной солью (положить в ту же строчку таблицы, например), то для проверки каждой строки уже надо будет проверять примерно 10^10 хешей. Всё еще подъёмно, но гораздо дольше и дороже.
Если изрядно разбавить записи фейковыми хешами (которые не соответствуют никакой цифровой комбинации), то уже можно было бы сделать схему месяц-два устойчивую к подбору.
Дальше — да, уже архитектурно другое решение нужно.
Я еще прямее спрашиваю — про какие технологии (или части технологии) хотели бы на собеседовании говорить, а про какие не надо. Интереснее же понять, насколько кандидат глубоко знает, то, что считает своей сильной стороной. А то, что не знает — всё равно придётся освоить.
Полностью поддерживаю. Нафига вот мне при отборе кандидатов вчитываться в резюме, если HR их принесёт от силы 50 за раз? Всех, кто хотя бы на "4 из 10 баллов" попадает в то, что мне нужно — отправить в телефонный скрининг. Не угадал — отдал в скрининг? Потрачено 5 минут на телефонный разговор. Угадал? Отлично. Зачем было 3 ночи сидеть над резюме? Не угадал и выкинул из скрининга? Э… Ну значит что-то совсем неадекватное в резюме было.
И, да, согласен, поиск всего, что выше, чем "ведущий разработчик" — это точно не про советы, как заполнять резюме (тот ещё ритуальный танец с обеих сторон).
Интересная статья. Интересная не только, да и не столько главным тезисом. Сама тема, что "опытный", "старший" или "главный" должен давать высказаться другим или должен вовремя промолчать, чтобы не "задавить" других, не нова. Не банальна, но и не нова. Хорошо описанная аргументированная точка зрения.
Но гораздо интереснее тут следующее:
С одной стороны, описанные причины "помолчать" работают только в конструктивной, "неагрессивной", "нетоксичной" среде. В излишне политизированных корпорациях это часто невозможная практика: молчать или говорить, диктуется совершенно не конструктивными причинами. Так что поздравляю, Андрей, выходит, что JetBrains — конструктивная, неагрессивная, зрелая среда (кто бы собмневался).
С другой стороны — есть коллективы, где такие идеи кажутся азами, точно не стоящие не то что статьи, даже письма. Значит вам есть куда расти :)
А еще (может быть это личное впечатление, но) в JB тот же совет весьма актуален. У вас достаточно высокая планка, из-за этого даже на логарифмической шкале средний сотрудник JB во многих фундаментальных областях программирования (но не во всех практических!) также сильнее среднего "банкорпоративного" разработчика, как Андрей Бреслав по сравнению с таким сотрудником в дизайне ЯП. И тут возникает эффект, который я наблюдал в дискуссиях с сотрудниками JB. К слову — это не корпоративная специфика, большинство спикеров на конференциях, да и вообще многие сильные специалисты легко попадают в похожую ловушку, т. е. примерно та же цепочка срабатывает:
Как итог — выводы становятся поспешными, аргументы и точка зрения другой стороны слегка хуже воспринимаются, причём в 99% случаев это даже незаметно. Более того, сильный специалист — он обычно таки умный и критичность восприятия вполне достаточная, чтобы не свалиться совсем в дичь. Просто ему чуть сложнее договориться с собеседником.
Сразу подчеркну — это не личный упрёк, я таких людей более чем понимаю. Становится действительно сложнее аналитически и критично подходить к своим решениям, когда 100 раз в год советуешь одно и то же. Тут, да, самое простое и логичное решение — вынести в постоянную практику явное принятие решения каждый раз — выслушать или высказать (любые сомнения в пользу "выслушать").
Соответственно — очень приятно видеть, что есть те, кто не только так или иначе осознаёт проблему, но и делятся опытом, как уменьшить её.
Надеюсь, что хомячки не пострадали.
Ну так-то почти во всех языковых платформах нехватка разработчиков. А во всех остальных областях нехватка разработчиков, способных понять, о чём думали разработчики платформы.
Нехватка разработчиков в платформах (языках, стандартных библиотеках, среде исполнения), на мой взгляд, в основном из-за того, что среды разработки быстро обрастают грузом наследия и каждая следующая фича пилится сложнее предыдущих. С этой точки зрения, "академические" или "бесполезные" языки как раз и являются единственным местом, где можно проверить подходы, которые лет через Nдцать дойдут до мейнстрима.
Посмотрел на клавиатуру и аж вздрогнул от неприятных воспоминаний. Я надеюсь тому, кто придумал это [censored] расположение кнопочек между стрелками и Delete/End/PgDwn до сих пор икается. Причём засада примерно в 2001-2004 годах была, что эти [censored] кнопки были почти на всех клавиатурах.
Легитимность ПО для виртуализации (!) 12-летней выдержки (!!) на пользовательском компьютере (!!!) с непонятным образом такой же древней ОС (!!!!) — ну это так себе легитимность.
Задумался: а нафига тянуть хламную vbox плюс какую-то мутную XP? А если запустить WSL, для которого, например, есть опубликованная "честная" Kali, и она весит 189 МБ?
Они и сейчас есть почти повсюду (JetBrains, Ansible, Gitlab, WSL, Visual Studio — это то, где за последний год сталкивался, где-то ошибки в продуктах, где-то в платформах/библиотеках). У меня на одном из компов дома на винде домашний каталог на кириллице и с пробелом, я все эти грабли собираю. Принципиально путь не меняю: если всё совсем не обходится, то либо на другом ПК, либо в виртуалке. Если хорошо воспроизводится — пишу тикет.
Не раздражён, но несколько разочарован. Я-то стал читать именно потому что недавно объяснял ту же тему (и надеялся, что есть что-то интересное). Увидел комментарий "странно, что минусуют", описал, что меня разочаровало.
Если интересно, могу описать, как я объяснял.
Другим (но не первоклассникам) я тоже объяснял. И если сравнить процент моего успеха в объяснении "что такое указатели", "функция, как значение" и "двоичная система", то "двоичная система" в понятности и усваиваемости безоговорочно лидирует.
Я вот не минусанул только потому что искренне против ставить минусы (я лучше 30 плюсов поставлю). Но рука уже тянулась :)
Для меня проблема этой статьи только одна: я без этой статьи и без рефлексирования "ах, сложно-сложно" объяснил сыну первокласснику эту тему за полчаса. Знаете, объяснить двоичную систему проще, чем ветвление, проще, чем рекурсию, да чего уж там — проще, чем "что такое бит", и зачем он нам нужен в компьютере и почему нужна двоичная, а не троичная (или еще какая) система исчисления.
Даже учитывая, что он сам этим интересуется — он всего лишь первоклассник, ему сложно объяснять многие вещи, но не двоичную систему. Ну, ок, конечно, в математике и программировании он явно выше среднего, но не так уж драматически.
А тут средние пальцы и какая-то фигня.
Эта идея практически невоплотима:
Хотите показать обоснование, опять же — соорудите такой скворечник для мелких коптеров и покажите. Денег на это уйдёт относительно немного (я думаю, что даже $100K хватит, но не обещаю), польза в любом случае будет: технологии посадки в такой скворечник пригодятся даже без пассажиров.
"аэро площадки у каждого офиса" — такая площадка даже просто на хранение коптера примерно займёт 6-8 машиномест. С местом для взлёта — гораздо больше.
Для ваших предложений хотя бы для себя эскиз нарисуйте, ответьте себе что является главной инженерной проблемой.
3-5 секунд для 100-200 метров "с места"? С паксом на борту? А потом "столько же или меньше секунд на вертикальную посадку"??? Таких адреналиновых наркоманов устойчивых к перегрузкам еще поискать надо будет.
Когда мне кто-то из коллег в 2017 году затирал про "скороаэеротаксидлявсех" я просто с ним вышел на парковку перед офисом, где, наверное, пара сотен машин стояла. Угу, давай представим, как к 9:00 сюда надо сделать хотя бы несколько десятков посадок (любых) коптеров, сколько это времени и места на парковке займёт. И, да, эта парковка была еще самым подходящим местом. Не забываем, что десяток висящих в очереди это уже на самом деле страшно (горючее лимитировано, а про аккумуляторы я даже не заикаюсь, все движутся, всем надо срочно, все "запасные" площадки также перегружены). Даже если всю парковку освободить — не поможёт. Ах, да, ещё конечно, в этот "колодец" я бы рискнул с опытным пилотом приземляться только до 7 м/с и в ясную погоду (и это тоже еще очень удачное место).
Разовые полёты возможны ровно потому, что их на несколько порядков меньше, чем автопередвижений.
Тут даже "эффективность" и "шумность" еще рано считать. Проще посчитать пропускную способность потенциально возводимой инфраструктуры (спойлер: её не хватит и на 5% автотрафика)
facepalm мне! )
del
В ближайшей убунте:
даёт
(конечно, 0.2 работает, конечно статья хорошая — просто момент, что не описано окружение, в котором проверяли)