Точно не скажу, но тут по моему была статья, что они специально уменьшают скорость скачиванию и каждый раз генерируется ключ. В этой статье было показано, как обходить это и скачивать на быстрой скорости
Действительно, доказательства для программистов и математиков не одно и то же. К примеру, для доказательства теоремы Ферма (Напомню, не существует такого n, чтоб выполялось a^n+b^n=c^n) можно задать любое n, которое за линейное время точно не найдет решение для этого уравнения и это не является для математиков доказательством, что теорема Ферма верна. Поэтому и Эндрю Уайлс доказал его не с помощью компьютера, а с помощью матаппарата.
Почитайте Книга шифров. Тайная история шифров и их расшифровки Саймона Сингха, написано доступным языком, очень легко читается. Там вся история шифрования, ну и в частности история создания Энигмы и взлома Раевским.
По опыту могу сказать, что бывает такое: Заказчик инженерный отдел, состоящих из 5 сотрудников, которые ставят задачу заказчику, каждый по своей части. Все эти сотрудники проработали 10 лет в этой компании в своей позиции и как следствие отличные спецы в своей сфере. Но вот беда, из-за этого, многие ключевые моменты не отмечают при постановки задачи. Точно не из-за злого умысла, что хотят скрыть что-то от исполнителя, т.к. они заинтересованное лицо, а просто, многие вещи для них кажется само-собой разумеющемися, я для меня, как исполнителя, совсем эти вещи не очевидны. Конечно, я понимаю, как описано в статье, нужно задавать правильные и наводящие вопросы. И все равно, когда работа выполнена и прошли тесты и работа выведена в Production, может через месяц всплывает, что программа не работает выдает ошибку, что нашла не соответствие, например, во входных данных. Когда обращаешься к заказчику, что это за не шаблонные входные данные? К примеру, ответ такой: ну это было лет 5 назад и мы уже такие данные давно не использовали, а теперь они опять есть. Конечно же абсолютно точно формат входящих данных строго обговаривался и прописывался в ТЗ. Это часто встречающаяся проблема в моей практике.
Действительно сталкивался, что менее квалифицированные специалисты переоценивают свои навыки, особенно в международных компаниях у нас. Но это прокатывает иногда на собеседованиях.
Это математический подход - не всегда доверять авторитетам. Как в третьем законе Финэйгла - "В любом наборе исходных данных самая надежная величина, не требующая никакой проверки, является ошибочной"
Точно не скажу, но тут по моему была статья, что они специально уменьшают скорость скачиванию и каждый раз генерируется ключ. В этой статье было показано, как обходить это и скачивать на быстрой скорости
Действительно, доказательства для программистов и математиков не одно и то же. К примеру, для доказательства теоремы Ферма (Напомню, не существует такого n, чтоб выполялось a^n+b^n=c^n) можно задать любое n, которое за линейное время точно не найдет решение для этого уравнения и это не является для математиков доказательством, что теорема Ферма верна. Поэтому и Эндрю Уайлс доказал его не с помощью компьютера, а с помощью матаппарата.
Почитайте Книга шифров. Тайная история шифров и их расшифровки Саймона Сингха, написано доступным языком, очень легко читается. Там вся история шифрования, ну и в частности история создания Энигмы и взлома Раевским.
А почему не упомянули язык ЛЯПАС - Лгический Язык Представления Алгоритвом Синтеза?
Очень понравилась статья, многого не знал
По опыту могу сказать, что бывает такое: Заказчик инженерный отдел, состоящих из 5 сотрудников, которые ставят задачу заказчику, каждый по своей части. Все эти сотрудники проработали 10 лет в этой компании в своей позиции и как следствие отличные спецы в своей сфере. Но вот беда, из-за этого, многие ключевые моменты не отмечают при постановки задачи. Точно не из-за злого умысла, что хотят скрыть что-то от исполнителя, т.к. они заинтересованное лицо, а просто, многие вещи для них кажется само-собой разумеющемися, я для меня, как исполнителя, совсем эти вещи не очевидны. Конечно, я понимаю, как описано в статье, нужно задавать правильные и наводящие вопросы. И все равно, когда работа выполнена и прошли тесты и работа выведена в Production, может через месяц всплывает, что программа не работает выдает ошибку, что нашла не соответствие, например, во входных данных. Когда обращаешься к заказчику, что это за не шаблонные входные данные? К примеру, ответ такой: ну это было лет 5 назад и мы уже такие данные давно не использовали, а теперь они опять есть. Конечно же абсолютно точно формат входящих данных строго обговаривался и прописывался в ТЗ. Это часто встречающаяся проблема в моей практике.
Первая исторя прям как у меня, с единственной поправкой, что занимаюсь с RPA и все, что с ней связано, а также бизнес аналитикой
Насколько мне известно, то гражданин Америки платит налог в США, не зависимо от того, в какой стране он живет и работает
Действительно сталкивался, что менее квалифицированные специалисты переоценивают свои навыки, особенно в международных компаниях у нас. Но это прокатывает иногда на собеседованиях.
Это математический подход - не всегда доверять авторитетам. Как в третьем законе Финэйгла - "В любом наборе исходных данных самая надежная величина, не требующая никакой проверки, является ошибочной"
Если ваши помысли чисты и ваш проект осчисливил хотя бы одного из ваших подопечных, то продолжайте и никого не слушайте.
Приведен очень хороший пример для начинающих, чтоб понять ООП, поделюсь с детьми.
Спасибо за статью, нужно будет глянуть указанные книги.
А развер Эйлер был не швецарский и русский математик?