Всë проще - работодателя вообще не должно волновать, что ты там делаешь. Главное - к нужному сроку дать нужный результат. Если работник успевает быстрее - остальное время использует по своему усмотрению.
А если не успевает? Такое ведь тоже бывает, и в этом случае (в большинстве мест) результирующие убытки не вешаются на работника.
Если мои оценки времени хорошо откалиброваны (ха-ха...), то я решаю примерно равное число задач быстрее и медленнее изначально заявленного времени. Разумно чтобы суммарно результат был бы для меня таким же, как если бы все задачи я решал ровно за заявленное время. Если я получаю приз за более быстрое выполнение, он должен уравновешиваться штрафом за более медленное.
Причина 3: архитектурно UI и выполнение запроса разнесены так, что наладить между ними дополнительную коммуникацию сообщениями с оценкой признано слишком большим геморроем.
Там где есть предсказуемо долгая задача из однородных, доступных интерфейсу шагов, прогресс-бары по-моему вполне выживают.
Сейчас у всех стоят пластиковые, и сделать деревянные, даже в историческом здании, почему-то непозволительная роскошь!
Это эффект масштаба: если деревянных окон делается мало, то каждое окно стоит дороже при равном качестве (не знаю конкретных механизмов, но могу предположить: меньшая предсказуемость сбыта, отсутствие массовых поставок "древесины для рам", что-нибудь в таком духе).
никто их С++/С синьеров досконально не изучал стандарт языка - там только текста на десяток тысяч страниц
Вот к вопросу о "привирать". Как человек у которого Draft N4659 (это ±C++17) в закладках, сообщаю что страниц там 1485 (без оглавления и алфавитного указателя).
Конфликт не обязан звучать истошным криком, количество децибел действительно сильно зависит от аудитории. Но мысль что при редактуре текста на него надо обращать внимание и заострять - довольно общая (из другого угла ту же мысль подчёркивают Олди, она звучит у Эгри в "Искусстве драматургии").
Known-plaintext attack: приведите сообщение (хотя бы 128 байт) и зашифрованное сообщение и посмотрим, получится ли у нас восстановить ключ.
(Если этот режим атаки кажется неправдоподобным, приведите первые 128 байт сообщения и зашифрованное сообщение целиком, и посмотрим, получится ли восстановить вторую половину.)
Если уж говорить о модах для Civilization IV, то есть колоссальный Realism Invictus. Изменённое дерево технологий, различия религий, мягкие ограничения на число отрядов на одном тайле (если их число превышает "уровень логистики", все отряды получают минусы, чем их больше - тем более серьёзные), эпидемии и восстания рабов...
сейчас у такой игры будет лишь статус инди проекта
Вы говорите так, будто это что-то плохое. "Инди" - это всего лишь "независимый разработчик".
Проблема с бюджетом да, есть, и большую свинью в этом подложила в своё время озвучка (затраты на неё мало зависят от размера команды разработки), но с голосовыми нейронками эта проблема сейчас должна увять.
Но Hollow Knight делался командой в пять человек. Outer Wilds - меньше десяти.
Они про разное. Brainbench - про знание некоторых правил языка в вакууме, Leetcode - про знание структур данных языка, умение быстро и правильно понимать записанные определённым образом условия и умение сообразить приличный алгоритм. Полный провал Leetcode от реального разработчика выглядит странно, полный провал Brainbench... менее странно, там довольно много про "что сделает вот этот код, глубоко неуместный в реальном проекте".
В асимметричной криптографии чуть лучше. К примеру, можно показать что если у нас есть оракул, ломающий Диффи-Хеллмана, то его можно использовать для разложения на множители произвольного числа. (Т.е., конечно, у нас нет хорошего нижнего предела для задачи факторизации, но такая гарантия всё-таки не совсем ничего.)
Это как раз спорное ограничение. Оно иногда играет на руку (как когда АНБ порекомендовало определённые матрицы AESDES, а несколько лет спустя выяснилось что они устойчивы к новому методу атаки), но может играть и против (как неслучайность матриц "Стрибога" наводит людей на подозрения что они выбраны такими не из-за устойчивости, а, напротив, из-за внедрённого бэкдора).
Фундаментально, криптография - это наука об управлении доверием. Одно дело использовать библиотеку, в отношении которой вы доверяете что авторы приложили больше усилий чем можете приложить вы, и заметно другое - полагаться на таинственные рецепты, корректность которых вы в принципе не можете проверить.
Потому что обрабатывать пользовательский ввод приходится самим, коль скоро нужна уникальная логика. Да, здесь тоже есть место для проблем, и применяется то же правило: либо вы делаете всерьёз, либо полагаетесь на принцип Неуловимого Джо (возможно плюс минимальная защита от script kiddies, хотя с пришествием языковых моделей этот "минимум" тоже может оказаться чертовски высоко).
А необходимости писать свой безопасный протокол почти никогда нет, то есть узкий совет звучит как "не делайте этой ошибки на совсем уж ровном месте".
Если бы все сами работали с криптографией, то все имели бы представление о том, как верифицировать собственный протокол или какие типичные ошибки существуют.
К сожалению нет. Есть фундаментальное различие между ошибками функциональности и ошибками безопасности: первые могут быть обнаружены при обычном использовании, и обычно достаточно легко предъявить тест который демонстрирует проблему вне разумных сомнений. Вторые никак не сказываются на нормальной работе ПО (за совсем клиническими исключениями), и даже демонстрирующий уязвимость proof-of-concept вполне можно не понять или убедить себя что проблема несущественна.
Более педантичное правило звучало бы так: реализуйте безопасность всерьёз и с серьёзными затратами или не реализуйте её вовсе, потому что полумеры практически дают результат хуже чем если бы не реализовывали ничего - оно так же небезопасно, но теперь у вас есть ложные иллюзии.
Так это верно только до тех пор, пока в ВУЗе занимаются передачей знаний, а не налаживанием социальных контактов. А то вы получаете возможность "в безопасной среде тестировать интересные гипотезы", а что получает эксперт? Зарплату преподавателя и честь быть объектом тестирования?
Ещё Оруэлл писал, что для скверной прозы с политическим посылом характерна неточность, безличность и расплывчатость формулировок.
Negative long-term effects on the brain, especially in younger users.
The brain will reach full development at 25.
Эти два предложения помещены на одну панель, читателю предлагается предположить что они связаны. 25 лет наводят меня на мысль о миелинизации нервных волокон - это единственный известный мне физиологический процесс с подходящим порядком величины. Влияют ли как-либо социальные сети на этот процесс? Я не вижу никаких исследований, но был бы очень удивлён если бы это было так. Тогда при чём здесь вообще сроки развития мозга?
Справедливо, но это по-моему как-то совсем в сторону от приоритетов при найме. И опять же, одно дело кодировать только happy path как получится потому что функционал нужен уже позавчера, другое - в процессе этого самого кодирования класть себе грабли без которых можно обойтись сравнимыми усилиями (тут примеры зависят от языка, скажем в C++ писать в подобном "одноразовом" коде new вместо std::make_unique).
"Никто не заметит если я сделаю плохо" - вообще довольно странное основание чтобы делать плохо, даже если отвлечься от того, в каком хрустальном шаре вы подсмотрели "этот код не будет вызван с этими параметрами никогда в будущем" (а если это действительно так - вы поставили assert(n<=20, "size restriction violation")?).
Да, я совершенно согласен что программа должна быть в первую очередь корректной и только во вторую быстрой. Но это не значит что она не должна быть быстрой. Задержка даже в секунду, помноженная на число пользователей и число запусков, может сложиться в несколько суток. А в моём случае разница во времени из-за неудачной реализации иногда измеряется часами.
Опять же, "утечки" - часто следствие той же ментальности "и так сойдёт, ресурсов много". А потом я с интересом узнаю что у движка Blink есть лимит на количество сущностей, и приложение умудрилось его исчерпать.
Э... зачем гнать? Почему гнать? Просто обратил внимание что здесь лишние вычисления на ровном месте, и я бы советовал переписать вот так (там был не вложенный цикл, а вызов неподходящего метода контейнера, но не суть).
Я это к тому, что "нужно [только] для собесов" выглядит как миф который все друг другу пересказывают, а в реальности знание не только нужное, но и не у всех присутствующее. Разумеется, даже если у гипотетического кандидата плохо с алгоритмами и структурами данных, это может быть скомпенсировано тем что у него хорошо с чем-то другим. Но это минус, и минус вполне реальный.
Нравится мне этот квантор "всем". Абстрактно, в режиме "скажи пароль" - "самобалансирующееся дерево", может и да. А на практике не далее как на прошлой неделе я поймал коллегу на попытке написать код с квадратичным временем там где есть очевидное n*log(n). При том что во многом другом человек вполне компетентный.
очередного инфоцыганина типа Роберта Мартина
Что именно вложено в "инфоцыганина"? Насколько я помню, его советы не были вполне самоочевидными или вредными при разумном применении (понятно что любой совет способен навредить если применять его без мысли, но это, ИМХО, не претензия к совету).
вы можете прочитать весь четырёхтомник Кнута, все книжки Таненбаума, все статьи от индусов на Medium... Но какой от этого толк? Это никак не улучшает вас в вашей непосредственной профессиональной деятельности
Насколько я могу заметить, обычно это заявляют люди, не прочитавшие ничего из перечисленного.
Да, очевидной связи "я прочитал книгу Х, и затем сделал всё по буквальной инструкции со страницы 53, абзац 4" обычно нет. Будете смеяться, у инженеров Boston Dynamics её нет тоже.
Если у вас в голове не модель правил языка и предметной области разгребаемого легаси, а упорядоченный по алфавиту сборник частных рецептов "видишь X - пиши Y", то "изнутри" может казаться что суть любой другой книги - пополнение этого списка. А на деле это приводит к тому, что вы неспособны заметить, когда рецепт перестаёт быть адекватным задаче. Иные потом говорят: "ай-ай, какой плохой рецепт, какие инфоцыгане его придумали".
А если не успевает? Такое ведь тоже бывает, и в этом случае (в большинстве мест) результирующие убытки не вешаются на работника.
Если мои оценки времени хорошо откалиброваны (ха-ха...), то я решаю примерно равное число задач быстрее и медленнее изначально заявленного времени. Разумно чтобы суммарно результат был бы для меня таким же, как если бы все задачи я решал ровно за заявленное время. Если я получаю приз за более быстрое выполнение, он должен уравновешиваться штрафом за более медленное.
Причина 1: на этапе дизайна здесь вообще не думали что будет существенное ожидание, поставили анимацию на всякий неожиданный случай.
Причина 2: процесс состоит из десяти разных шагов, относительная скорость которых непредсказуема (например, запрос к десяти сайтам...). "Надпись "выполнено 99%" успокаивает только первые полчаса"©.
Причина 3: архитектурно UI и выполнение запроса разнесены так, что наладить между ними дополнительную коммуникацию сообщениями с оценкой признано слишком большим геморроем.
Там где есть предсказуемо долгая задача из однородных, доступных интерфейсу шагов, прогресс-бары по-моему вполне выживают.
Это эффект масштаба: если деревянных окон делается мало, то каждое окно стоит дороже при равном качестве (не знаю конкретных механизмов, но могу предположить: меньшая предсказуемость сбыта, отсутствие массовых поставок "древесины для рам", что-нибудь в таком духе).
Вот к вопросу о "привирать". Как человек у которого Draft N4659 (это ±C++17) в закладках, сообщаю что страниц там 1485 (без оглавления и алфавитного указателя).
Конфликт не обязан звучать истошным криком, количество децибел действительно сильно зависит от аудитории. Но мысль что при редактуре текста на него надо обращать внимание и заострять - довольно общая (из другого угла ту же мысль подчёркивают Олди, она звучит у Эгри в "Искусстве драматургии").
Known-plaintext attack: приведите сообщение (хотя бы 128 байт) и зашифрованное сообщение и посмотрим, получится ли у нас восстановить ключ.
(Если этот режим атаки кажется неправдоподобным, приведите первые 128 байт сообщения и зашифрованное сообщение целиком, и посмотрим, получится ли восстановить вторую половину.)
Если уж говорить о модах для Civilization IV, то есть колоссальный Realism Invictus. Изменённое дерево технологий, различия религий, мягкие ограничения на число отрядов на одном тайле (если их число превышает "уровень логистики", все отряды получают минусы, чем их больше - тем более серьёзные), эпидемии и восстания рабов...
Ещё несколько интересных механик однострочниками.
Achron (2011) - RTS, в которой можно отправлять свои войска назад во времени.
OneShot (2016) - квест, который опирается на то что он программа с файлами в вашей файловой системе.
A Blind Legend (2016) - action, в котором на экране не видно ничего.
Эадор (2009) - стратегия, в которой действие "загрузить сохранение" имеет внутриигровые последствия (довольно неприятные).
Вы говорите так, будто это что-то плохое. "Инди" - это всего лишь "независимый разработчик".
Проблема с бюджетом да, есть, и большую свинью в этом подложила в своё время озвучка (затраты на неё мало зависят от размера команды разработки), но с голосовыми нейронками эта проблема сейчас должна увять.
Но Hollow Knight делался командой в пять человек. Outer Wilds - меньше десяти.
Они про разное. Brainbench - про знание некоторых правил языка в вакууме, Leetcode - про знание структур данных языка, умение быстро и правильно понимать записанные определённым образом условия и умение сообразить приличный алгоритм. Полный провал Leetcode от реального разработчика выглядит странно, полный провал Brainbench... менее странно, там довольно много про "что сделает вот этот код, глубоко неуместный в реальном проекте".
В асимметричной криптографии чуть лучше. К примеру, можно показать что если у нас есть оракул, ломающий Диффи-Хеллмана, то его можно использовать для разложения на множители произвольного числа. (Т.е., конечно, у нас нет хорошего нижнего предела для задачи факторизации, но такая гарантия всё-таки не совсем ничего.)
Это как раз спорное ограничение. Оно иногда играет на руку (как когда АНБ порекомендовало определённые матрицы
AESDES, а несколько лет спустя выяснилось что они устойчивы к новому методу атаки), но может играть и против (как неслучайность матриц "Стрибога" наводит людей на подозрения что они выбраны такими не из-за устойчивости, а, напротив, из-за внедрённого бэкдора).Фундаментально, криптография - это наука об управлении доверием. Одно дело использовать библиотеку, в отношении которой вы доверяете что авторы приложили больше усилий чем можете приложить вы, и заметно другое - полагаться на таинственные рецепты, корректность которых вы в принципе не можете проверить.
Потому что обрабатывать пользовательский ввод приходится самим, коль скоро нужна уникальная логика. Да, здесь тоже есть место для проблем, и применяется то же правило: либо вы делаете всерьёз, либо полагаетесь на принцип Неуловимого Джо (возможно плюс минимальная защита от script kiddies, хотя с пришествием языковых моделей этот "минимум" тоже может оказаться чертовски высоко).
А необходимости писать свой безопасный протокол почти никогда нет, то есть узкий совет звучит как "не делайте этой ошибки на совсем уж ровном месте".
К сожалению нет. Есть фундаментальное различие между ошибками функциональности и ошибками безопасности: первые могут быть обнаружены при обычном использовании, и обычно достаточно легко предъявить тест который демонстрирует проблему вне разумных сомнений. Вторые никак не сказываются на нормальной работе ПО (за совсем клиническими исключениями), и даже демонстрирующий уязвимость proof-of-concept вполне можно не понять или убедить себя что проблема несущественна.
Более педантичное правило звучало бы так: реализуйте безопасность всерьёз и с серьёзными затратами или не реализуйте её вовсе, потому что полумеры практически дают результат хуже чем если бы не реализовывали ничего - оно так же небезопасно, но теперь у вас есть ложные иллюзии.
Так это верно только до тех пор, пока в ВУЗе занимаются передачей знаний, а не налаживанием социальных контактов. А то вы получаете возможность "в безопасной среде тестировать интересные гипотезы", а что получает эксперт? Зарплату преподавателя и честь быть объектом тестирования?
Ещё Оруэлл писал, что для скверной прозы с политическим посылом характерна неточность, безличность и расплывчатость формулировок.
Эти два предложения помещены на одну панель, читателю предлагается предположить что они связаны. 25 лет наводят меня на мысль о миелинизации нервных волокон - это единственный известный мне физиологический процесс с подходящим порядком величины. Влияют ли как-либо социальные сети на этот процесс? Я не вижу никаких исследований, но был бы очень удивлён если бы это было так. Тогда при чём здесь вообще сроки развития мозга?
Справедливо, но это по-моему как-то совсем в сторону от приоритетов при найме. И опять же, одно дело кодировать только happy path как получится потому что функционал нужен уже позавчера, другое - в процессе этого самого кодирования класть себе грабли без которых можно обойтись сравнимыми усилиями (тут примеры зависят от языка, скажем в C++ писать в подобном "одноразовом" коде
newвместоstd::make_unique)."Никто не заметит если я сделаю плохо" - вообще довольно странное основание чтобы делать плохо, даже если отвлечься от того, в каком хрустальном шаре вы подсмотрели "этот код не будет вызван с этими параметрами никогда в будущем" (а если это действительно так - вы поставили
assert(n<=20, "size restriction violation")?).Да, я совершенно согласен что программа должна быть в первую очередь корректной и только во вторую быстрой. Но это не значит что она не должна быть быстрой. Задержка даже в секунду, помноженная на число пользователей и число запусков, может сложиться в несколько суток. А в моём случае разница во времени из-за неудачной реализации иногда измеряется часами.
Опять же, "утечки" - часто следствие той же ментальности "и так сойдёт, ресурсов много". А потом я с интересом узнаю что у движка Blink есть лимит на количество сущностей, и приложение умудрилось его исчерпать.
Э... зачем гнать? Почему гнать? Просто обратил внимание что здесь лишние вычисления на ровном месте, и я бы советовал переписать вот так (там был не вложенный цикл, а вызов неподходящего метода контейнера, но не суть).
Я это к тому, что "нужно [только] для собесов" выглядит как миф который все друг другу пересказывают, а в реальности знание не только нужное, но и не у всех присутствующее. Разумеется, даже если у гипотетического кандидата плохо с алгоритмами и структурами данных, это может быть скомпенсировано тем что у него хорошо с чем-то другим. Но это минус, и минус вполне реальный.
Нравится мне этот квантор "всем". Абстрактно, в режиме "скажи пароль" - "самобалансирующееся дерево", может и да. А на практике не далее как на прошлой неделе я поймал коллегу на попытке написать код с квадратичным временем там где есть очевидное n*log(n). При том что во многом другом человек вполне компетентный.
Что именно вложено в "инфоцыганина"? Насколько я помню, его советы не были вполне самоочевидными или вредными при разумном применении (понятно что любой совет способен навредить если применять его без мысли, но это, ИМХО, не претензия к совету).
Насколько я могу заметить, обычно это заявляют люди, не прочитавшие ничего из перечисленного.
Да, очевидной связи "я прочитал книгу Х, и затем сделал всё по буквальной инструкции со страницы 53, абзац 4" обычно нет. Будете смеяться, у инженеров Boston Dynamics её нет тоже.
Если у вас в голове не модель правил языка и предметной области разгребаемого легаси, а упорядоченный по алфавиту сборник частных рецептов "видишь X - пиши Y", то "изнутри" может казаться что суть любой другой книги - пополнение этого списка. А на деле это приводит к тому, что вы неспособны заметить, когда рецепт перестаёт быть адекватным задаче. Иные потом говорят: "ай-ай, какой плохой рецепт, какие инфоцыгане его придумали".
Не должна. Проверка условия
[3, "tree", []] == 0в Python вполне корректна, условие не выполнено.Можете, но как только вы перетащили работу с типами во время исполнения - код от компилятора C++ весело помахал вам ручкой и скрылся в голубой дали.