Агент же откуда-то взялся? Не внезапно неизвестно откуда позвонил.
Вот когда первый раз с ним встречались (лично или онлайново)- контактами и обменяться.
В первом случае все легче: кладём трубку и перезванивает в банк сами.
Тогда придется вспоминать "какое-том у меня секретное слово было". Банку же тоже убеждаться надо в личности абонента звонящего. Так что уж лучше кодами.
Завтра я куплю себе симку и выясню что она у всех внесена в спамфильтр.
…
Но вот недавно я продолбал несколько звонков от своего агента по квартире, потому что его мобильный у меня высвечивался как "чтототам_мед"
А это вопрос телефонного этикета, который современным реалиям перестал соответствовать. Агент должен был кинуть свой контакт(ы), где, в частности, должны быть номера, с которых он звонить будет. А владелец новой симки, соответственно, должен кидать своим контактам — "я сейчас этим номером пользуюсь". После чего номера добавляются в белый список.
Надо механизм подтверждения того, что тот кто звонить — действительно тот, за кого себя выдает. Для банков может выглядеть приблизительно так (YouTube). Обращаем внимание на дату ролика.
Клиент банка: "И как мне проверить, что вы действительно из банка ABC"?
Оператор: говорит одноразовый код подтверждения
Клиент банка: его проверяет, говорит уже свой одноразовый код
Оператор: проверяет код клиента.
В конкретном случае ролик рекламный и поэтому генератор встроен в банковскую карту. Но никто не мешает выбрать вариант попроще. Хотя бы те же скретч-карты.
Спам же глушиться личными черно-белыми списками опять же с усиленным подтверждением личности того, кто звонил. CallerId надо чинить. Можно даже не трогая протоколы телефонной сети, средствами терминалов, если телефонные сети его чинить не хотят. Посылать после поднятия трубки криптографически заверенную SMS или эквивалент, которыми звонящий представляется. Или прямо в голосовом канале пиликать. А телефон пускай уже думает, что с этим делать.
Базовый активный словарный запас — 1500-2000 слов. Именно их обычно целенаправленно учат. Потом человек его подтягивает до десятков тысяч слов пассивного запаса.
Ни и сколько из нас наизусть помнит 1500-2000 классов стандартной библиотеки (может сразу пользоваться ими, не залезая в подсказки)?
А десятки тысяч пассивного наберется(т.е. пользоваться не умею, но понимаю, что делает, не залезая в тот же хелп)?
Ну да, обычно дают не просто список слов со словами 'выучить', а еще кучу фраз и примеров, где эти слова употребляются, а потом еще заставляют не меньшую кучу употреблений конкретно этих слов сделать самостоятельно (в рамках обучения, не реального использования языка).
В любом случае с 'само выучится в процессе работы' даже близко не лежит.
Ну вот это наше "не надо специально учить библиотеку" и есть полный эквивалент.
Результат будет, возможно, даже, хороший. Но, также как с естественным языком, если учить/зубрить специально и под руководством тех людей, которые этим процессом управлять умеют — результат будут получше и получится быстрее.
Смотрим снова аналогию с иностранным языком. Слова, когда учат язык, именно зубрят. Не все подряд, конечно, а по методикам, но именно зубрят. А не 'какие больше используешь, так и запомнятся'. И когда учат много языков — учат слова каждого.
Это нормально для людей, которым не дают время разобраться, а подкидывают следующую задачу. Нет, понятно про в 'свободное время'. Но если то, в чем нужно разобраться, применимо исключительно в рамках текущего проекта и больше нигде — то желающих разбираться в свободное время будет маловато.
Вообще, не совсем. Сравним с обычным, человеческим, но иностранным языком. Нужно на нем какую-нибудь статью написать на заданную тему. Там тоже подумать/прочитать — большая часть работы. Но скорость написания статьи будет довольно разной в случае 'знаю иностранный язык' и в случае 'знаю иностранный язык со словарем' (т.е. как раз вариант, когда знаю, что слово есть, могу его найти, но вот прямо сразу написать не могу).
Т.е. если я не помню как называется нужная мне функция — не страшно, главное что я помню, что она есть.
Знание функций стандартной библиотеки и используемого фреймворка дает беглость. — Есть некоторая разница, пишешь нужную функцию сразу, или тратишь на поиск как-там-она-называлась пусть даже 10 секунд. Потому что эти секунды накапливаются.
Влияние, конечно, не так чтобы сильное, но оно есть.
Теги давно расставлять не надо. Еще во времена спама в почте проходили. Обучаем свой личный фильтр — он и будет фильтровать. А сейчас, во времена чрезмерно умных нейросеток — так фильтр будет наверняка еще умнее будет, чем используемые тогда методы.
На самом деле именно с CCDT может и не получиться. Про нее должны были явно и стразу сказать те, кто правильный, по рекомендациям IBM, кластер менеджеров очередей разворачивали и конфигурировали.
А если не сказали — то с большой вероятностью кластера нет, а есть просто несколько менеджеров очередей, на которых почему-то очереди одинаково называются. В этом случае CCDT будут проблемы — создавать его самому, а не использовать тот, что кластер отдает, несколько сложно.
Если работа с командой, занимающейся очередями, совместная — то еще имеет смысл выяснить, действительно ли нужно случайно-равномерное распределение по двум плечам.
Весьма вероятно, что достаточно только того, чтобы было резервирование на случай падения одного из менеджеров. Это будет еще один способ использования, который, насколько я помню, конфигурируется просто указанием резервного менеджера очередей в connection url/адресе подключения.
Мне казалось, что в IBM MQ все это должно делается штатным способом через client channel definition table (CCDT). А то что тут описано — это ручное повторение того функционала, что и так в клиентских библиотеках IBM MQ есть.
У радиолюбителей своих протоколов какое-то нездоровое количество. Даже, кажется, на хабре несколько статей было. Я как-то попробовал сунуться во все это, пытаясь, из любопытства, понять, какой канал можно получить из обычных бытовых раций и вообще просто акустикой по воздуху — так понял, что ничего не понимаю и отполз.
Но 'железный' модем сейчас иметь, как показывает тот же minimodem, даже им смысла никакого нет — все отлично вычисляется процессором.
Больше интересует не то что точками, а чтобы начертание было разборчивым и не портилось при небрежном/быстром рукописном написании. В этом Perfo, например, 'К' и 'H' станут совершенно неразличимы, если их в таком виде руками написать. Хочется чего-нибудь рукописного (не в смысле внешнего вида а в смысле удобства письма) без таких плохих особенностей.
Требование 'печатного' вида — просто предположение, что подобный шрифт именно так и будет выглядеть.
А можете подсказать подходящий для тех же целей кириллический шрифт?
Присоединяюсь к этому вопросу с изменением: хочется не непрерывный курсив, а рукописный шрифт 'печатного' вида. Такой, что удобно писать от руки и своим начертанием разборчивости помогает. Например, часто упоминаемый в подобном контексте чертежный шрифт близок к требуемому, но у него, как минимум, 'л' и 'п' слишком похоже. И пишется он не так чтобы очень удобно.
бизнесу важно, чтобы проект вообще был написан, в разумные сроки, за разумные деньги и был поддерживаем
А теперь вспоминаем, что большая часть затрат на проект обычно приходится как раз на этап эксплуатации и поддержки, когда оригинальная команды разработки (или даже вся) во всем этом не участвует. И понимаем, что для удешевления этой части нужно каких-то других софт-скилов хотеть, не тех, что в статье написана.
Так что хотеть надо сумрачного гения документирования. Такого, чтобы если кто прочитал результат его работы — так сразу и понял, как система устроена и как ее чинить и допиливать.
С оптикой, я подозреваю, будут некие проблемы — наверняка дорогая и сложная получится. За положением взгляда, скорее всего, следить просто дешевле получится.
Но да, все то же самое делается без всяких OLED — таким же полупрозрачным экраном, на который картинку проектором проецируют.
Агент же откуда-то взялся? Не внезапно неизвестно откуда позвонил.
Вот когда первый раз с ним встречались (лично или онлайново)- контактами и обменяться.
Тогда придется вспоминать "какое-том у меня секретное слово было". Банку же тоже убеждаться надо в личности абонента звонящего. Так что уж лучше кодами.
А это вопрос телефонного этикета, который современным реалиям перестал соответствовать. Агент должен был кинуть свой контакт(ы), где, в частности, должны быть номера, с которых он звонить будет. А владелец новой симки, соответственно, должен кидать своим контактам — "я сейчас этим номером пользуюсь". После чего номера добавляются в белый список.
По сути надо:
Надо механизм подтверждения того, что тот кто звонить — действительно тот, за кого себя выдает. Для банков может выглядеть приблизительно так (YouTube). Обращаем внимание на дату ролика.
Клиент банка: "И как мне проверить, что вы действительно из банка ABC"?
Оператор: говорит одноразовый код подтверждения
Клиент банка: его проверяет, говорит уже свой одноразовый код
Оператор: проверяет код клиента.
В конкретном случае ролик рекламный и поэтому генератор встроен в банковскую карту. Но никто не мешает выбрать вариант попроще. Хотя бы те же скретч-карты.
Спам же глушиться личными черно-белыми списками опять же с усиленным подтверждением личности того, кто звонил. CallerId надо чинить. Можно даже не трогая протоколы телефонной сети, средствами терминалов, если телефонные сети его чинить не хотят. Посылать после поднятия трубки криптографически заверенную SMS или эквивалент, которыми звонящий представляется. Или прямо в голосовом канале пиликать. А телефон пускай уже думает, что с этим делать.
Базовый активный словарный запас — 1500-2000 слов. Именно их обычно целенаправленно учат. Потом человек его подтягивает до десятков тысяч слов пассивного запаса.
Ни и сколько из нас наизусть помнит 1500-2000 классов стандартной библиотеки (может сразу пользоваться ими, не залезая в подсказки)?
А десятки тысяч пассивного наберется(т.е. пользоваться не умею, но понимаю, что делает, не залезая в тот же хелп)?
Ну да, обычно дают не просто список слов со словами 'выучить', а еще кучу фраз и примеров, где эти слова употребляются, а потом еще заставляют не меньшую кучу употреблений конкретно этих слов сделать самостоятельно (в рамках обучения, не реального использования языка).
В любом случае с 'само выучится в процессе работы' даже близко не лежит.
Ну вот это наше "не надо специально учить библиотеку" и есть полный эквивалент.
Результат будет, возможно, даже, хороший. Но, также как с естественным языком, если учить/зубрить специально и под руководством тех людей, которые этим процессом управлять умеют — результат будут получше и получится быстрее.
Смотрим снова аналогию с иностранным языком. Слова, когда учат язык, именно зубрят. Не все подряд, конечно, а по методикам, но именно зубрят. А не 'какие больше используешь, так и запомнятся'. И когда учат много языков — учат слова каждого.
Это нормально для людей, которым не дают время разобраться, а подкидывают следующую задачу. Нет, понятно про в 'свободное время'. Но если то, в чем нужно разобраться, применимо исключительно в рамках текущего проекта и больше нигде — то желающих разбираться в свободное время будет маловато.
Вообще, не совсем. Сравним с обычным, человеческим, но иностранным языком. Нужно на нем какую-нибудь статью написать на заданную тему. Там тоже подумать/прочитать — большая часть работы. Но скорость написания статьи будет довольно разной в случае 'знаю иностранный язык' и в случае 'знаю иностранный язык со словарем' (т.е. как раз вариант, когда знаю, что слово есть, могу его найти, но вот прямо сразу написать не могу).
Знание функций стандартной библиотеки и используемого фреймворка дает беглость. — Есть некоторая разница, пишешь нужную функцию сразу, или тратишь на поиск как-там-она-называлась пусть даже 10 секунд. Потому что эти секунды накапливаются.
Влияние, конечно, не так чтобы сильное, но оно есть.
Теги давно расставлять не надо. Еще во времена спама в почте проходили. Обучаем свой личный фильтр — он и будет фильтровать. А сейчас, во времена чрезмерно умных нейросеток — так фильтр будет наверняка еще умнее будет, чем используемые тогда методы.
На самом деле именно с CCDT может и не получиться. Про нее должны были явно и стразу сказать те, кто правильный, по рекомендациям IBM, кластер менеджеров очередей разворачивали и конфигурировали.
А если не сказали — то с большой вероятностью кластера нет, а есть просто несколько менеджеров очередей, на которых почему-то очереди одинаково называются. В этом случае CCDT будут проблемы — создавать его самому, а не использовать тот, что кластер отдает, несколько сложно.
Если работа с командой, занимающейся очередями, совместная — то еще имеет смысл выяснить, действительно ли нужно случайно-равномерное распределение по двум плечам.
Весьма вероятно, что достаточно только того, чтобы было резервирование на случай падения одного из менеджеров. Это будет еще один способ использования, который, насколько я помню, конфигурируется просто указанием резервного менеджера очередей в connection url/адресе подключения.
Мне казалось, что в IBM MQ все это должно делается штатным способом через client channel definition table (CCDT). А то что тут описано — это ручное повторение того функционала, что и так в клиентских библиотеках IBM MQ есть.
У радиолюбителей своих протоколов какое-то нездоровое количество. Даже, кажется, на хабре несколько статей было. Я как-то попробовал сунуться во все это, пытаясь, из любопытства, понять, какой канал можно получить из обычных бытовых раций и вообще просто акустикой по воздуху — так понял, что ничего не понимаю и отполз.
Но 'железный' модем сейчас иметь, как показывает тот же minimodem, даже им смысла никакого нет — все отлично вычисляется процессором.
Совсем быстро не надо. Достаточно, чтобы рука не уставала.
А идея заменять не подходит — требуется не личное письмо а то, что кто-то другой читать будет.
Т.е. рукописный шрифт для всяких умеренно коротких записок, вручную заполняемых документов итд итп.
Вопрос, похоже, плохо сформулировал.
Больше интересует не то что точками, а чтобы начертание было разборчивым и не портилось при небрежном/быстром рукописном написании. В этом Perfo, например, 'К' и 'H' станут совершенно неразличимы, если их в таком виде руками написать. Хочется чего-нибудь рукописного (не в смысле внешнего вида а в смысле удобства письма) без таких плохих особенностей.
Требование 'печатного' вида — просто предположение, что подобный шрифт именно так и будет выглядеть.
Присоединяюсь к этому вопросу с изменением: хочется не непрерывный курсив, а рукописный шрифт 'печатного' вида. Такой, что удобно писать от руки и своим начертанием разборчивости помогает. Например, часто упоминаемый в подобном контексте чертежный шрифт близок к требуемому, но у него, как минимум, 'л' и 'п' слишком похоже. И пишется он не так чтобы очень удобно.
А теперь вспоминаем, что большая часть затрат на проект обычно приходится как раз на этап эксплуатации и поддержки, когда оригинальная команды разработки (или даже вся) во всем этом не участвует. И понимаем, что для удешевления этой части нужно каких-то других софт-скилов хотеть, не тех, что в статье написана.
Так что хотеть надо сумрачного гения документирования. Такого, чтобы если кто прочитал результат его работы — так сразу и понял, как система устроена и как ее чинить и допиливать.
С оптикой, я подозреваю, будут некие проблемы — наверняка дорогая и сложная получится. За положением взгляда, скорее всего, следить просто дешевле получится.
Но да, все то же самое делается без всяких OLED — таким же полупрозрачным экраном, на который картинку проектором проецируют.
Ну так нам для одного и нужно — того, что в кабине управления сидит и рычаги/кнопки нажимает.