МИТАП - собрались участники, на сцену выходит седой 40-летний разработчик. Коллеги, карьера зависит от людей вокруг. Хотите сделать карьеру - научитесь понимать потребности и оказывать влияние на людей. И поскольку у нас тут остались выделенные время и деньги, гоу в бар!
Автор приводит ссылку на сравнение C++ реализаций exceptions vs std::expected. А затем достаточно голословно добавляет про Rust. Сравнить exceptions vs C-style - отличная мысль, а результат приведенный @beeruser, похоже, раскрывает лукавство автора и обесценивает все сказанное им о производительности.
Статья хайповая, но уровень кмк не высокий. Начиная от восторга, что Java не завершает процесс, а что-то сообщает пользователям, до мнения о том, что исключения как-то волшебно работают. На самом деле, все это сделано ручками, либо разработчиков компиляторов, либо системных библиотек и приложений. И под капотом исключений те же самые if-ы (плюс код логики раскрутки стека). Ну а не завершить процесс в случае необработанной ошибки, это то еще преимущество)
Ну и отдельно хочу заметить, что автор смешивает два разных типа исключений. Те, которые выбрасывает сама программа через throw, и те, которые приходят из OS. Обработка вторых, это отдельная тема, на мой взгляд не имеющая отношения к вопросу.
Самое классное ретро я видел в одном банке. Я тогда проработал в команде всего неделю и попал на завершение внедрения скрама. В течение 1.5 часов команда лила помои на руководство и непосредственно тимлида, инициатора скрама. Он сидел красный и пытался отшучиваться. Это было первое и последнее ретро за те несколько лет, что я там работал. Но такой счастливой команды, как та, после той встречи, я больше никогда не встречал)
Затронута интересная тема, спасибо! Но со своей стороны не могу не добавить:
refresh token изначально выдается при авторизации пользователя вместе с access token
Поле version инкрементируется при каждом изменении данных авторизации (пароля)
Описываемая схема «Контроль версий» используется для того, чтобы заблеклистить refresh token (потому что система его не помнит и он не может быть просто добавлен в blacklist)
Да ну, человек просто описал свою ситуацию и свое мнение почему он в ней оказался. Ситуация тяжелая, но описание максимально спокойное. Я рад, что у кого-то все хорошо, но также очень приветствую людей, которые могут честно поделиться свой историей. А советы как жить... их даже своему ребенку сложно давать, не то что незнакомцу в интернете, уж простите)
Люблю эту поговорку, но прошу заметить, что она апеллирует к индивиду. Вопрос не в объекте, а в субъекте. Один сдюжит изменить, другому нужно смириться.
Что касается влияния данной статьи на существующие процессы, то полагаю, что это возможно. (1) в ней достаточно аргументов и историй, чтобы вызвать какую-то рефлексию, (2) ее прочитают люди, проводящие интервью и набирающие к себе в команды.
По сути вопроса - что может быть хорошего в том, что экзамен перестал отвечать на вопрос, знает ли кандидат предмет (какими бы объективными причинами это не обосновывалось).
«Нытье» - это как-то обидно звучит. Есть разные пути. Кто-то принимает происходящее вокруг как оно есть и действует согласно обстоятельствам. А кто-то начинает спорить с действительностью и в итоге может даже что-то изменить. Мне не кажется, что жизнь была бы лучше, если все бы выбирали 1-ый вариант)
Если бы не «Простой» уровень сложности статьи, я бы не стал читать. NP-полные задачи, динамическое (да и линейное) программирование, а тем более эксклюзивные авторские методы требуют большой самоотдачи для понимания)
Но в данном случае, вроде все просто написано:
Основной посыл состоит в том, что мы разбиваем одну большую экспоненциальную задачу на ряд более простых экспоненциальных задач. Но общее время работы последовательности мелких задач значительно меньше, чем решение одной большой задачи.
В голове сразу: 2^3N >> 2^N + 2^N + 2^N. Вау! Но как же он смог разбить большую задачу? А точно сумма решений мелких задач равна решению большой? Такое ведь надо доказывать...
Очень хочется получить ответы на эти вопросы! Читаем дальше:
Кратко повторю суть метода: Начало такое же, как у моделей MTZ и DFJ.
Первое отличие состоит в том, что мы не будем указывать верхнюю границу для x. (…) Так мы уменьшаем число ограничений линейного решателя на x неравенств.
Ещё одна оптимизация, которая не учитывалась в прошлых работах: мы добавляем ограничения только для тех подмножеств, размер которых не превышает половины n
и это всё)
не утверждаю, что метод не рабочий, и даже что он не «наибыстрейший», но его суть осталась для меня не раскрыта.
Обнаружил, что подхожу под 9 из 10 типов (все кроме Зачинщика конфликтов). Кажется, что так не должно быть)
В целом, классификация вызывает вопросы. Кажется, что можно, как минимум, объединить прокрастинатор и выгоревший, одинокий волк и всезнайка, перфекционист и ненадежный.
Что касается «лечения», то оно должно быть разным:
Если человека не воодушевляет работа, компания может попробовать его мотивировать. Если это невозможно, пусть отправит его в отпуск. Там он придет в себя и найдет другую работу.
Если человек со сложным характером - тут только либо приспосабливаться, либо увольнять. Пытаться его изменить - это путь к варианту 1.
Ну и если «сложных» инженеров больше 1-2, то развиваться и работать над собой необходимо уже руководству)
Не понимаю почему разработчики накинулись на Эрика)
Однако, заметьте, он признает, что Гугл сознательно теряет в эффективности ради комфорта сотрудников! А потом, ну реально у него опыта в ИТ до фига, и я бы на месте студентов (да и не только) прислушался бы к его мнению.
Для тех, кто дочитал статью до конца, но не нашел абзаца про то, зачем вообще весь этот геморрой) Дело в том, что в универсальных процессорах операция ‘div’ в несколько раз медленнее, чем ‘mul’. Почему так, это тема отдельной статьи)
Может я какой-то неправильный разработчик, но уже давно не испытывал потребности в подобных списках. Наверное с тех пор, когда собирал библиотеки и утилиты на dvd-r, так ни разу ими и не воспользовавшись)
Все так быстро устаревает. Поиск в гугле покажет, что наиболее популярно и не заброшено автором много лет назад. Рядом же будут ссылки на сравнения, отзывы, туториалы.
Но авторам списков по-любому респект за трудолюбие!
Ситуация неприятная, но она бы не возникла, если бы у мед. учреждений в регионах была бы возможность принимать решения. Думаю, тогда конкуренция могла бы сыграть свою роль, и победителем стал бы лучший (я помню про коррупцию, но все же). Так то зоопарк систем не есть хорошо.
Что касается работников компаний, я бы смотрел оптимистичнее - просто перейдут в новую монополию, будут там ту же работу работать.
Выскажу непопулярное мнение. Проблема UB в C++ сильно преувеличена. Исторически стандарт C++ не представляет собой парадигму «все что не запрещено, то разрешено», он лишь описывает как надо применять язык. Если ситуация явно не описана, то делать так лучше не надо.
А если делаешь, то на свой страх и риск. Проверь на разных компиляторах и архитектурах, расставь defines, укажи в system requirements. Обычно с таким сталкиваются крупные проекты, которые могут себе позволить тратить на это ресурсы.
Язык C++ создавался во времена, когда просто добавление макросов в язык делало его хитом. Никому в голову не приходило создавать что-то настолько строго определенное как например Rust. Contracts, constrains, const variables, муниципальный фильтр - вызвали бы непонимание у программистов тех времен.
Я бы «закопал стюардессу». Новые версии стандарта, на мой взгляд, пытаются изменить парадигму языка не меняя сам язык. Это во-первых выглядит сомнительно, а во-вторых отвлекает от реальных сложностей разработки на C++.
МИТАП - собрались участники, на сцену выходит седой 40-летний разработчик. Коллеги, карьера зависит от людей вокруг. Хотите сделать карьеру - научитесь понимать потребности и оказывать влияние на людей. И поскольку у нас тут остались выделенные время и деньги, гоу в бар!
Я бы не советовал использовать статьи для изучения чего-либо нового. Книга - таков путь!
Автор приводит ссылку на сравнение C++ реализаций exceptions vs std::expected. А затем достаточно голословно добавляет про Rust. Сравнить exceptions vs C-style - отличная мысль, а результат приведенный @beeruser, похоже, раскрывает лукавство автора и обесценивает все сказанное им о производительности.
Статья хайповая, но уровень кмк не высокий. Начиная от восторга, что Java не завершает процесс, а что-то сообщает пользователям, до мнения о том, что исключения как-то волшебно работают. На самом деле, все это сделано ручками, либо разработчиков компиляторов, либо системных библиотек и приложений. И под капотом исключений те же самые if-ы (плюс код логики раскрутки стека). Ну а не завершить процесс в случае необработанной ошибки, это то еще преимущество)
Ну и отдельно хочу заметить, что автор смешивает два разных типа исключений. Те, которые выбрасывает сама программа через throw, и те, которые приходят из OS. Обработка вторых, это отдельная тема, на мой взгляд не имеющая отношения к вопросу.
Самое классное ретро я видел в одном банке. Я тогда проработал в команде всего неделю и попал на завершение внедрения скрама. В течение 1.5 часов команда лила помои на руководство и непосредственно тимлида, инициатора скрама. Он сидел красный и пытался отшучиваться. Это было первое и последнее ретро за те несколько лет, что я там работал. Но такой счастливой команды, как та, после той встречи, я больше никогда не встречал)
Тимлид тоже не пропал, вскоре ушел на повышение)
Затронута интересная тема, спасибо! Но со своей стороны не могу не добавить:
refresh token изначально выдается при авторизации пользователя вместе с access token
Поле version инкрементируется при каждом изменении данных авторизации (пароля)
Описываемая схема «Контроль версий» используется для того, чтобы заблеклистить refresh token (потому что система его не помнит и он не может быть просто добавлен в blacklist)
Да ну, человек просто описал свою ситуацию и свое мнение почему он в ней оказался. Ситуация тяжелая, но описание максимально спокойное. Я рад, что у кого-то все хорошо, но также очень приветствую людей, которые могут честно поделиться свой историей. А советы как жить... их даже своему ребенку сложно давать, не то что незнакомцу в интернете, уж простите)
Люблю эту поговорку, но прошу заметить, что она апеллирует к индивиду. Вопрос не в объекте, а в субъекте. Один сдюжит изменить, другому нужно смириться.
Что касается влияния данной статьи на существующие процессы, то полагаю, что это возможно. (1) в ней достаточно аргументов и историй, чтобы вызвать какую-то рефлексию, (2) ее прочитают люди, проводящие интервью и набирающие к себе в команды.
По сути вопроса - что может быть хорошего в том, что экзамен перестал отвечать на вопрос, знает ли кандидат предмет (какими бы объективными причинами это не обосновывалось).
«Нытье» - это как-то обидно звучит. Есть разные пути. Кто-то принимает происходящее вокруг как оно есть и действует согласно обстоятельствам. А кто-то начинает спорить с действительностью и в итоге может даже что-то изменить. Мне не кажется, что жизнь была бы лучше, если все бы выбирали 1-ый вариант)
Если бы не «Простой» уровень сложности статьи, я бы не стал читать. NP-полные задачи, динамическое (да и линейное) программирование, а тем более эксклюзивные авторские методы требуют большой самоотдачи для понимания)
Но в данном случае, вроде все просто написано:
В голове сразу: 2^3N >> 2^N + 2^N + 2^N. Вау! Но как же он смог разбить большую задачу? А точно сумма решений мелких задач равна решению большой? Такое ведь надо доказывать...
Очень хочется получить ответы на эти вопросы! Читаем дальше:
и это всё)
не утверждаю, что метод не рабочий, и даже что он не «наибыстрейший», но его суть осталась для меня не раскрыта.
Обнаружил, что подхожу под 9 из 10 типов (все кроме Зачинщика конфликтов). Кажется, что так не должно быть)
В целом, классификация вызывает вопросы. Кажется, что можно, как минимум, объединить прокрастинатор и выгоревший, одинокий волк и всезнайка, перфекционист и ненадежный.
Что касается «лечения», то оно должно быть разным:
Если человека не воодушевляет работа, компания может попробовать его мотивировать. Если это невозможно, пусть отправит его в отпуск. Там он придет в себя и найдет другую работу.
Если человек со сложным характером - тут только либо приспосабливаться, либо увольнять. Пытаться его изменить - это путь к варианту 1.
Ну и если «сложных» инженеров больше 1-2, то развиваться и работать над собой необходимо уже руководству)
Непонимаю почему разработчики накинулись на Эрика)Однако, заметьте, он признает, что Гугл сознательно теряет в эффективности ради комфорта сотрудников! А потом, ну реально у него опыта в ИТ до фига, и я бы на месте студентов (да и не только) прислушался бы к его мнению.
из статьи не очень понятно, чем отличается использованная оптимизированная версия от стандартной?
Для тех, кто дочитал статью до конца, но не нашел абзаца про то, зачем вообще весь этот геморрой) Дело в том, что в универсальных процессорах операция ‘div’ в несколько раз медленнее, чем ‘mul’. Почему так, это тема отдельной статьи)
Циферки по операциям можно посмотреть тут: https://www.agner.org/optimize/instruction_tables.pdf
Российский автопром проектирует новый автомобиль. Надежный, обычный и реалистичный? Нееет! Уникальный, инновационный и концептуальный? Дааа!
Может я какой-то неправильный разработчик, но уже давно не испытывал потребности в подобных списках. Наверное с тех пор, когда собирал библиотеки и утилиты на dvd-r, так ни разу ими и не воспользовавшись)
Все так быстро устаревает. Поиск в гугле покажет, что наиболее популярно и не заброшено автором много лет назад. Рядом же будут ссылки на сравнения, отзывы, туториалы.
Но авторам списков по-любому респект за трудолюбие!
Ситуация неприятная, но она бы не возникла, если бы у мед. учреждений в регионах была бы возможность принимать решения. Думаю, тогда конкуренция могла бы сыграть свою роль, и победителем стал бы лучший (я помню про коррупцию, но все же). Так то зоопарк систем не есть хорошо.
Что касается работников компаний, я бы смотрел оптимистичнее - просто перейдут в новую монополию, будут там ту же работу работать.
Если вопрос нужны ли такие статьи, то ответ «да» возможен при одном условии. Надо разобраться и рассказать почему такие «неожиданные» результаты.
Можно конечно просто вкинуть как есть, но если в комменты придет профи, то будет неприятно)
Цифры впечатляют! Но не очень понятно, куда делась реляционная БД, зачем кэшу персистентность и как будет организован sync)
Снова телеграм блокировать? Не учит их жизнь)
Выскажу непопулярное мнение. Проблема UB в C++ сильно преувеличена. Исторически стандарт C++ не представляет собой парадигму «все что не запрещено, то разрешено», он лишь описывает как надо применять язык. Если ситуация явно не описана, то делать так лучше не надо.
А если делаешь, то на свой страх и риск. Проверь на разных компиляторах и архитектурах, расставь defines, укажи в system requirements. Обычно с таким сталкиваются крупные проекты, которые могут себе позволить тратить на это ресурсы.
Язык C++ создавался во времена, когда просто добавление макросов в язык делало его хитом. Никому в голову не приходило создавать что-то настолько строго определенное как например Rust. Contracts, constrains, const variables, муниципальный фильтр - вызвали бы непонимание у программистов тех времен.
Я бы «закопал стюардессу». Новые версии стандарта, на мой взгляд, пытаются изменить парадигму языка не меняя сам язык. Это во-первых выглядит сомнительно, а во-вторых отвлекает от реальных сложностей разработки на C++.