Ранее в VK сообщили, что сотрудники центра безопасности мессенджера Max в июле 2025 года заблокировали (за нарушения пункта 4 «Права и обязанности Пользователя») более 10 тыс. телефонных номеров мошенников, которые чаще всего предпринимали попытки выдать себя за сотрудников банков, правоохранительных органов или государственных сервисов.
Я не понимаю. Почему для "сотрудников банков, правоохранительных органов или государственных сервисов" просто не сделан белый список? Классика же: верифицированные аккаунты. Это примерно единственное, что могло бы сделать этот мессенджер полезнее конкурентов.
Поржал над заголовком. Не бывает много тестирования, если чатгпт научат хотя бы баги воспроизводить (убрав из описания страшное слово "sometimes") и изолировать (перебрав варианты воспроизведения и оставив минимальный) – уже праздник, ценность освоивших его тестировщиков резко возрастёт.
"Уточнение"? Да вы мастер преуменьшений. Вашу статью по сути похоронили одним очевидным любому программисту вопросом, показав вашу некомпетентность в освещаемом вопросе, а вы называете это "уточнением"?!
Санитайзинг – чистка от запрещённого (удалением или заменой, например 0x02 удалить или заменить на тире, как в статье). Эскейпинг – обратимая замена запрещённого (как в вашем примере для символов пунктуации).
В общем, всё вы знаете, только термины почему-то мимо прошли :-)
Глядите, если у вас есть N разных типов – то для каждого визитора вам надо написать N разных функций и положить их в него. А для switch – написать N разных case. И будете вы это писать ровно в том же месте. И даже компилятор проверит одинаково (все ли функции есть, если ваш визитор соответствует типу визитора, или все ли варианты тэга вписаны в case в случае switch).
Т.е. у вас точно так же расползётся всё по всему проекту, только ещё добавится фабрика.
Так что воспринимайте использование discriminated union, как visitor на минималках.
Для визитора надо не POD-типы, а полноценные объекты с VMT (ну или в случае JS – с лежащим в объекте или его прототипе "виртуальным" методом).
Соответственно, если эти объекты не в вашем же коде созданы, а, как это часто бывает в JS, пришли извне в сериализованном виде – для того, чтобы вы могли пользоваться визитором, вам всё равно вначале придётся их сконвертировать в "жирные" объекты со всеми методами – а для этого написать тот же switch-case или ещё что. Зачастую это перебор.
(Если кто не застал – это прикол времён Фидонета, когда буква 'Н' сжиралась, если я не путаю, GoldEdом. Ещё буква 'р' была проклята – в результате зачастую даже раскладку русификатора делали так, что гни заменялись на латинские 'H' и 'p' соответственно... Думаю, если сейчас погуглить русские слова с такой заменой – найдётся много текстов с артефактами тех времён).
Автор очень странный. Первым делом делается санитайзинг или эскейпинг пользовательского ввода (это всё равно жёсткая необходимость и это уже решает проблему), а потом можно удовлетворять своё любопытство, выясняя, откуда там 0x02.
Не удивлюсь, если они там отфильтровали только 0x02, а если юзер скопипастит туда 0x03 – опять что-то навернётся. А то и вообще придёт маленький Бобби Тэйблс (xkcd#327).
Очень много слов вокруг очень простой и привычной всем концепции. Да, конечно, typescript делает её удобнее за счёт автоматического сужения типов – но то же самое он делает и для прочих type guards (типа булевых функций с пометкой x is T – имело смысл сравнивать с ними)
Для работы с опытными программистами – как правило, будет только мешать. А для работы с джунами нужен опытный программист, иначе они такого наворотят...
Я как-то думал, что продактов растят из людей с уже большим опытом – либо большой опыт программиста, либо большой опыт в бизнесе.
Есть чувство, что для тех, кто знает используемую терминологию и привычен к используемому матаппарату, её содержание тривиально (выписать все формулы займёт меньше времени, чем прочитать статью), а прочим надо пояснять, что такое преобразование Парка-Горева, преобразование Кларке и т.п.
Я не минусил, но, увидев такие вопросы на собесе, задал бы встречный вопрос: у вас такое в коде? И, напротив, собеседуя кого-то – больше порадовался бы не пониманию смысла этого, а воплю "какой ... это написал?"
Ну и, соответственно, на этом этапе примеры на собесе можно отдать под рефакторинг: типа, не нравится? А как бы вы написали? Тут и понимание закоулков языка проверите (хотя оно и не столь критично), и умение писать читаемый код.
А вот совсем беда – если человек такие фрагменты кода просто не заметит. Особенно если он их поймёт неправильно (но и если правильно – тоже не супер).
Почему большинство языков проектируется по "принципу наименьшего удивления", а тут то цепные сравнения с оператором "is", то множественное наследование с "кто первый встал, того и тапки" (если б я в реальном коде увидел такое наследование – я б орал на написавшего его... А вообще в приличных местах множественное наследование допускается или от интерфейсов, или от миксинов, чтобы не допустить такой неоднозначности), то иммутабельных/хэшируемых массивов нет (ну тут ладно, такую хрень всё равно в голову бы не пришло написать).
Так эксперимент-то вы провели? А то лично для меня выглядит весьма вероятным, что минификация кода или не влияет на эффективность его разбора LLM вообще (грубо говоря, занимаемая токеном память не зависит от его длины), или влияет в лучшую сторону (имя токена используется как дополнительная информация, вроде его типа. Эта гипотеза подтверждается тем, что автокомплит в XCode и VS Code реагирует уже на имя переменной).
Ты, возможно, себя сравниваешь с одноклассниками, одногруппниками, коллегами или друзьями, у которых это легко получается, а у тебя нет. Но здесь нужно понимать, что у каждого свой темп, и твоему мозгу просто нужно больше времени.
Так это и значит нет способностей. Если тебе надо в 3-5 раз больше сил и времени, чем другим – как ещё это назвать?
Понятно, что терпение и труд всё перетрут, но себя надо оценивать здраво.
Я не понимаю. Почему для "сотрудников банков, правоохранительных органов или государственных сервисов" просто не сделан белый список? Классика же: верифицированные аккаунты. Это примерно единственное, что могло бы сделать этот мессенджер полезнее конкурентов.
Некоторые любят свою работу, и им не в кайф вместо неё бездельничать. А про учёт времени вы всё правильно говорите.
В воспроизведении и изоляции много тупого перебора – и эту работу точно есть резон передать роботу. Пусть человек ему идеи подаёт.
Поржал над заголовком. Не бывает много тестирования, если чатгпт научат хотя бы баги воспроизводить (убрав из описания страшное слово "sometimes") и изолировать (перебрав варианты воспроизведения и оставив минимальный) – уже праздник, ценность освоивших его тестировщиков резко возрастёт.
Любопытно, нельзя ли их рутовать через test point.
"Уточнение"? Да вы мастер преуменьшений. Вашу статью по сути похоронили одним очевидным любому программисту вопросом, показав вашу некомпетентность в освещаемом вопросе, а вы называете это "уточнением"?!
Санитайзинг – чистка от запрещённого (удалением или заменой, например 0x02 удалить или заменить на тире, как в статье). Эскейпинг – обратимая замена запрещённого (как в вашем примере для символов пунктуации).
В общем, всё вы знаете, только термины почему-то мимо прошли :-)
Глядите, если у вас есть N разных типов – то для каждого визитора вам надо написать N разных функций и положить их в него. А для switch – написать N разных case. И будете вы это писать ровно в том же месте. И даже компилятор проверит одинаково (все ли функции есть, если ваш визитор соответствует типу визитора, или все ли варианты тэга вписаны в case в случае switch).
Т.е. у вас точно так же расползётся всё по всему проекту, только ещё добавится фабрика.
Так что воспринимайте использование discriminated union, как visitor на минималках.
Для визитора надо не POD-типы, а полноценные объекты с VMT (ну или в случае JS – с лежащим в объекте или его прототипе "виртуальным" методом).
Соответственно, если эти объекты не в вашем же коде созданы, а, как это часто бывает в JS, пришли извне в сериализованном виде – для того, чтобы вы могли пользоваться визитором, вам всё равно вначале придётся их сконвертировать в "жирные" объекты со всеми методами – а для этого написать тот же switch-case или ещё что. Зачастую это перебор.
МЕЯ ВИДО? (c)
(Если кто не застал – это прикол времён Фидонета, когда буква 'Н' сжиралась, если я не путаю, GoldEdом. Ещё буква 'р' была проклята – в результате зачастую даже раскладку русификатора делали так, что гни заменялись на латинские 'H' и 'p' соответственно... Думаю, если сейчас погуглить русские слова с такой заменой – найдётся много текстов с артефактами тех времён).
Автор очень странный. Первым делом делается санитайзинг или эскейпинг пользовательского ввода (это всё равно жёсткая необходимость и это уже решает проблему), а потом можно удовлетворять своё любопытство, выясняя, откуда там 0x02.
Не удивлюсь, если они там отфильтровали только 0x02, а если юзер скопипастит туда 0x03 – опять что-то навернётся. А то и вообще придёт маленький Бобби Тэйблс (xkcd#327).
Это не sum type, а его частный случай.
Очень много слов вокруг очень простой и привычной всем концепции. Да, конечно, typescript делает её удобнее за счёт автоматического сужения типов – но то же самое он делает и для прочих type guards (типа булевых функций с пометкой x is T – имело смысл сравнивать с ними)
А куда можно применить джуниор продакта?
Для работы с опытными программистами – как правило, будет только мешать. А для работы с джунами нужен опытный программист, иначе они такого наворотят...
Я как-то думал, что продактов растят из людей с уже большим опытом – либо большой опыт программиста, либо большой опыт в бизнесе.
Прошу прощения, а на кого ориентирована статья?
Есть чувство, что для тех, кто знает используемую терминологию и привычен к используемому матаппарату, её содержание тривиально (выписать все формулы займёт меньше времени, чем прочитать статью), а прочим надо пояснять, что такое преобразование Парка-Горева, преобразование Кларке и т.п.
Обычно вроде не 30, побольше. И в обе стороны: закладываются, что часы могут быть немного сбиты.
Я не минусил, но, увидев такие вопросы на собесе, задал бы встречный вопрос: у вас такое в коде? И, напротив, собеседуя кого-то – больше порадовался бы не пониманию смысла этого, а воплю "какой ... это написал?"
Ну и, соответственно, на этом этапе примеры на собесе можно отдать под рефакторинг: типа, не нравится? А как бы вы написали? Тут и понимание закоулков языка проверите (хотя оно и не столь критично), и умение писать читаемый код.
А вот совсем беда – если человек такие фрагменты кода просто не заметит. Особенно если он их поймёт неправильно (но и если правильно – тоже не супер).
Спасибо, убили всё желание пользоваться Питоном.
Почему большинство языков проектируется по "принципу наименьшего удивления", а тут то цепные сравнения с оператором "is", то множественное наследование с "кто первый встал, того и тапки" (если б я в реальном коде увидел такое наследование – я б орал на написавшего его... А вообще в приличных местах множественное наследование допускается или от интерфейсов, или от миксинов, чтобы не допустить такой неоднозначности), то иммутабельных/хэшируемых массивов нет (ну тут ладно, такую хрень всё равно в голову бы не пришло написать).
Так эксперимент-то вы провели? А то лично для меня выглядит весьма вероятным, что минификация кода или не влияет на эффективность его разбора LLM вообще (грубо говоря, занимаемая токеном память не зависит от его длины), или влияет в лучшую сторону (имя токена используется как дополнительная информация, вроде его типа. Эта гипотеза подтверждается тем, что автокомплит в XCode и VS Code реагирует уже на имя переменной).
Так это и значит нет способностей. Если тебе надо в 3-5 раз больше сил и времени, чем другим – как ещё это назвать?
Понятно, что терпение и труд всё перетрут, но себя надо оценивать здраво.