Вот это довольно большая проблема, если подумать, сам формат общения с психологом требует доверия, а оно строится на врачебной тайне. И у психологов тоже есть своя этика и как можно доверять им, если они ее не соблюдают.
В результате только и остаётся, что искать их через знакомых, а всяким корпоративным большую часть не рассказывать, потому что это может быть использовано против тебя.
Вот метод поиска коррупционеров через интервью с психологом грубо нарушает врачебную этику, психолог должен сохранять врачебную тайну, а если он будет сливать то реакцию клиента, то это станет рано или поздно известно, что есть такие схематозы и просто помножит на ноль полезность психологов.
Знаете, помню было лет десять назад очень много комментариев и постов аналогичных, что не надо хоронить Delphi, а потом они все куда-то делись и кто вообще сейчас на Хабре о нем пишет?
Помню в школе учили на кумире и было ощущение, что пишешь на руссифицированном Паскале, но вообще среда разработки была довольно приятной и удобной, хотя была ещё досовской.
Не знаю, как по мне, перл это не то что хочется осиливать, его философия "There’s more than one way to do it" привела к избыточной сложности на ровном месте и засилию любителей однострочников, а дальнейшее развитие языка несколько раз заходило в тупик.
Так что я прекрасно понимаю желание людей свалить с него на Пайтон.
Так никому, ну кроме Редхата, вообще не вперлось старое пилить, многое же сделано просто just for fun. Какой фан в том чтобы старые версии патчить под хотелки трёх землекопов.
Вот мне кажется, что основная линия защиты в двухфакторной авторизации это как раз наличие двух различных устройств. Просто если злоумышленник таки получил доступ к устройству, то если на нём есть и второй фактор, то он не будет работать. Ну разве что задержит злоумышленника минут на 15.
Вообще, канбан, по ощущениям, требует большего уровня осознанности и ответственности от всех сторон. Это не всем по нраву, поэтому вот и хочется прикрываться какие-нибудь ритуалами.
И ещё, кажется, что канбан лучше работает, когда команда совсем небольшая. Сильно большие команды, при этом в принципе не жизнеспособны, а вот в средних некоторые элементы скрама неплохо помогают бороться с хаосом.
Хотя вот помню эти утомительные сессии планирования, когда берешь с потолка сторипойнты и пытаешься в спринт впихнуть работы чтобы он не лопнул. При том, что многие фичи, когда их делать начинаешь, сразу нарываются на тех долг, который не был запланирован, но который вот прямо надо сделать, иначе пара таких фичей ещё сверху и проект погибнет под грузом комбинаторного взрыва. А потом в конце спринта часть задач переезжала в следующий и приходилось резать скоуп. И начинались утомительные споры о том, что важнее а что нет.
Что для себя понял, что сроки, сторипойнты и все такое сами по себе не имеют смысла и ценности. Они нужны лишь для того, чтобы сприоритезировать что делать дальше. И тут сложность и длительность умножается на срочность задачи. В итоге где-то на этой связке между срочностью и трудоемкостью все и балансирует. А вот какие сроки в реальности будут, то это одному Ктулху известно.
Там это как раз может работать, а вот в случае с реальными процессорами, там же нет никакой логики в поддержке процессором тех или иных инструкций, может выйти более новый процессор, но без какого-нибудь avx512, а остальное у него будет. И в какой уровень микроархитектуры его определять?
Вот в riscv, так и вообще может быть совсем разный уровень микроархитектуры и поддержки дополнительных команд, но там это пишут в самом названии микроархитектуры, там есть какой-то более мне официальный процесс, но в x86 такого ведь нет.
Вот как истинный разраб, я этот снежный ком и не ощущаю, да и сам часто по своей инициативе какие-то новые технологии тащу. А аналитикой да, тоже бывает занимаюсь, но вот не очень люблю, когда надо уж очень много с разными людьми работать.
А за автора рад, что он нашел таки, что ему больше нравится, все же долго делать то, что в целом то получается, но не приносит внутреннего удовлетворения - это путь в выгорание.
Вот на тему mut тоже первое время тупил, что он не совсем про ту мутабельность, которая интуитивно понимается. Но потом мне рассказали, что в комьюнити было на эту тему обсуждение, что это ключевое слово надо было называть uniq, тогда бы все в голове сразу встало.
Ну, к сожалению языки не идеальны, в любом из них есть свои ошибки дизайна. Но общий тон статьи - это наброс и передергивание.
А чего это убивает? Просто решает свои приоритетные задачи. Хотя и ценой большого количества ключевых слов, что в целом то говорит о стремлении решать частные вопросы здесь и сейчас.
Ну так и Kotlin вот такой же, там тоже довольно много сахара.
Там там сам UI не очень много кушает, а кушают в основном всякие language серверы. Но Zed все же заметно более отзывчивый, а память нынче дешёвая.
Вот это довольно большая проблема, если подумать, сам формат общения с психологом требует доверия, а оно строится на врачебной тайне. И у психологов тоже есть своя этика и как можно доверять им, если они ее не соблюдают.
В результате только и остаётся, что искать их через знакомых, а всяким корпоративным большую часть не рассказывать, потому что это может быть использовано против тебя.
Сегодня же ещё не первое апреля
Вот метод поиска коррупционеров через интервью с психологом грубо нарушает врачебную этику, психолог должен сохранять врачебную тайну, а если он будет сливать то реакцию клиента, то это станет рано или поздно известно, что есть такие схематозы и просто помножит на ноль полезность психологов.
Знаете, помню было лет десять назад очень много комментариев и постов аналогичных, что не надо хоронить Delphi, а потом они все куда-то делись и кто вообще сейчас на Хабре о нем пишет?
Помню в школе учили на кумире и было ощущение, что пишешь на руссифицированном Паскале, но вообще среда разработки была довольно приятной и удобной, хотя была ещё досовской.
Не знаю, как по мне, перл это не то что хочется осиливать, его философия "There’s more than one way to do it" привела к избыточной сложности на ровном месте и засилию любителей однострочников, а дальнейшее развитие языка несколько раз заходило в тупик.
Так что я прекрасно понимаю желание людей свалить с него на Пайтон.
Так никому, ну кроме Редхата, вообще не вперлось старое пилить, многое же сделано просто just for fun. Какой фан в том чтобы старые версии патчить под хотелки трёх землекопов.
Вот мне кажется, что основная линия защиты в двухфакторной авторизации это как раз наличие двух различных устройств. Просто если злоумышленник таки получил доступ к устройству, то если на нём есть и второй фактор, то он не будет работать. Ну разве что задержит злоумышленника минут на 15.
Ну так такие люди разрушают конкретные компании, высвобождая место под солнцем для других, но они не разрушают всю индустрию сразу же.
Вот когда он окончательно похерит поиск Гугла, то на рынке поисковиков появится конкуренция. История с IE6 это все наглядно демонстрировала.
Вообще, канбан, по ощущениям, требует большего уровня осознанности и ответственности от всех сторон. Это не всем по нраву, поэтому вот и хочется прикрываться какие-нибудь ритуалами.
И ещё, кажется, что канбан лучше работает, когда команда совсем небольшая. Сильно большие команды, при этом в принципе не жизнеспособны, а вот в средних некоторые элементы скрама неплохо помогают бороться с хаосом.
Хотя вот помню эти утомительные сессии планирования, когда берешь с потолка сторипойнты и пытаешься в спринт впихнуть работы чтобы он не лопнул. При том, что многие фичи, когда их делать начинаешь, сразу нарываются на тех долг, который не был запланирован, но который вот прямо надо сделать, иначе пара таких фичей ещё сверху и проект погибнет под грузом комбинаторного взрыва. А потом в конце спринта часть задач переезжала в следующий и приходилось резать скоуп. И начинались утомительные споры о том, что важнее а что нет.
Что для себя понял, что сроки, сторипойнты и все такое сами по себе не имеют смысла и ценности. Они нужны лишь для того, чтобы сприоритезировать что делать дальше. И тут сложность и длительность умножается на срочность задачи. В итоге где-то на этой связке между срочностью и трудоемкостью все и балансирует. А вот какие сроки в реальности будут, то это одному Ктулху известно.
И много у Маска аварийных пусков? У шаттла, напомню, две катастрофы было.
Там это как раз может работать, а вот в случае с реальными процессорами, там же нет никакой логики в поддержке процессором тех или иных инструкций, может выйти более новый процессор, но без какого-нибудь avx512, а остальное у него будет. И в какой уровень микроархитектуры его определять?
Вот в riscv, так и вообще может быть совсем разный уровень микроархитектуры и поддержки дополнительных команд, но там это пишут в самом названии микроархитектуры, там есть какой-то более мне официальный процесс, но в x86 такого ведь нет.
Нравится то может он и не нравится, но он более понятный в своем мышлении, с ним проще взаимодействовать, если что-то надо.
И даже если он пошлет на три буквы, то хотя бы прямо и быстро, а не будет тянуть резину.
Вот как истинный разраб, я этот снежный ком и не ощущаю, да и сам часто по своей инициативе какие-то новые технологии тащу. А аналитикой да, тоже бывает занимаюсь, но вот не очень люблю, когда надо уж очень много с разными людьми работать.
А за автора рад, что он нашел таки, что ему больше нравится, все же долго делать то, что в целом то получается, но не приносит внутреннего удовлетворения - это путь в выгорание.
Почему рендер по качеству выглядит как школьная поделка из 2000 года?
Но люди то такие же остались
Вот на тему mut тоже первое время тупил, что он не совсем про ту мутабельность, которая интуитивно понимается. Но потом мне рассказали, что в комьюнити было на эту тему обсуждение, что это ключевое слово надо было называть uniq, тогда бы все в голове сразу встало.
Ну, к сожалению языки не идеальны, в любом из них есть свои ошибки дизайна. Но общий тон статьи - это наброс и передергивание.
Это все nighty, это все априори нестабильно. В Python же просто нет такой концепции, как нестабильные фичи. Это некорректное сравнение.
Ну не используйте nighty без особенно острой нужды и не будет вот этой боли, что язык якобы постоянно вносит breaking changes.
А чего это убивает? Просто решает свои приоритетные задачи. Хотя и ценой большого количества ключевых слов, что в целом то говорит о стремлении решать частные вопросы здесь и сейчас.
Ну так и Kotlin вот такой же, там тоже довольно много сахара.