Нет. Потому что в процессе работы обучать можно только тому что надо. А при централизованном обучении — обучать, чтобы работодатели были довольны, придется вообще всему, что существует. А это очень-очень много времени.
Люди не должны массово гуглить, люди должны обращаться к документации. Из этого следует, что и "учить гуглить" никого не нужно.
Зато следует, что нужно учить писать документацию. А это умение, почему-то, вообще в требуемых работодателям навыках практически не упоминается. И вообще считается чем-то, что само как-то появится.
Хотя по хорошему тоже должно отдельно тренироваться.
Времена изменились и теперь у меня небольшая распределённая система и куча многопоточный обработки. И я понимаю, что джунов я обучить в приемлемый срок не могу. Основная проблема — нет навыка формулировать и решать задачи (в довольно широком смысле). Другая проблема — микроскопический кругозор.
А почему понимание многопоточности должно решаться, как ниже предлагается. кругозором и пет-проектами? Оно, создается прокачкой на 1000+ задачек вида 'написать..., найти ошибку в....'. На разных языках и в разных модельных ситуациях. И вот после этого человек race condition сразу видеть будет. Но решение 1000+ задачек — оно тоже время обучения. Причем другие работодатели, с большой вероятностью будут думать на такие затраты времени 'какой-то ненужной фигне обучают, лучше бы потратили время на <подставить что-то, нужное им>'
Работодатель физически не может платить 2-3 года зп джуну и его наставнику, чтобы его учить.
А все равно так или иначе будет платить. Может, не в таком виде, но будет. Потому что студенту, пока учится, нужно на что-то жить и его преподавателям нужно платить зарплату.
Соответственно, и студент и система образования захотят эти деньги получить. Причем — с работодателя. Больше неоткуда. Т.е. если будет система образования, из которой выходят люди, готовые к работе — то и платить так или иначе придется больше.
Объём теоретических знаний, который нужен программисту это 2-3 тысячи страниц. Туда влезут базовые алгоритмы, ОС, БД, сети и обзор платформы вроде Java или .NET (что включает в себя вещи вроде сборки, GC, многопоточность). Не спеша можно за год осилить, но университеты за 6 лет этого дать не могут. Так что да, проблема с образованием есть и она серьезная.
Причем в достаточно большой степени именно потому, что студенты "набирают опыт работы", который будут требовать при устройстве на работу. Вместо того, чтобы читать учебники, книжки и последовательно разбираться в нужных технологиях. И нет, набираемый "опыт работы" — плохая этому замена. Потому что получается, что хватаются несвязные кусочки со StackOverflow.
Собственно, я давно сторонник точки зрения "если у тебя есть время работать — значит, тебя плохо учат".
И все это только ради того, чтобы нельзя было понять, что 4c78b3a1-b569-4c46-a05b-911411e0543e@google.com не совпадает с a49a9740-b6d7-11ea-8b6e-0800200c9a66 и не является на самом деле username@google.com?
Уже упомянутая генерация номера карты для каждой покупки — это же костыль, вставленный для обхода уязвимости в системе, которую нельзя убрать из соображений совместимости. (А именно той уязвимости, что почему-то делает просто номер карты чем-то ценным, угрожающим мошенническим снятием денег и поэтому нуждающемся в защите). И всей это морокой с токинезацией никто бы не занимался, если бы этой уязвимости не было.
Так собственная аутентификация, силами самого ресурса — обычно email в качестве логина. Вот его и спрашивают, чтобы все более-менее единообразно было с точки зрения учетной записи.
Проще ввести одну строку цифр, которая IBAN. "Неправильно продиктовал" — поймается контрольной суммой в номере. И, скорее всего, его не будут диктовать, а просто пришлют текстовым сообщение.
Ну т.е. уже начались костыли — перевод на самом деле не по номеру телефона, а по номер телефона+инициалы. Плюс переводить деньги, вообще говоря, можно не только человеку, но и организации — там с инициалами плохо.
Почему бы сразу устойчивый идентификатор не использовать?
так чтобы человек который переводит понимал что он не ошибся и деньги будут доставлены кому и планировалось.
Проблема только в том, что в номере телефона нет контрольной суммы. И человек не понимает, что не ошибся в наборе.
А если телефон выбирается из контактов и ничего набирать на надо — то точно так же не надо набирать номер банковского счета для получения денег, который может в контакте лежать.
Чип есть не у всех, вы смотрите на РФ которая очень даже продвинутая, а вот например в США большая часть банкоматов читает только магнитную полосу…
Даже в США уже несколько лет идет EMV liability shift. И банк, который не поменял банкомат на тот, который умеет читать чип, по сути, согласился вернуть деньги на чипованную карточку буквально по первому слову пользователя этой карточки.
Поэтому в процессе было очень смешно. Банкам хотелось и безопасность повысить и сделать так, чтобы карты с чипом не распространялись слишком быстро. В прессе были статьи о том, что карточка с чипом карта — это безопаснее. И одновременно же — что запоминать PIN — это страшно неудобно, сложно и старый способ с полосой был лучше. После чего внедрялись терминалы, где надо расписываться стилом. где-то так(Youtube). После чего продавцы жаловались, что, чипованные карты скорость прохождения очереди замедляют.
К сожалению, бумажное устройство стремительно устаревает. Я так понимаю, что изготовление подделки, которую нельзя распознать без сложного оборудования — стало очень простым.
Но я не очень поддерживаю идею единого, на все случаи годного паспорта-карточки. Слишком много прав в одном устройстве концентрируется и единая точка отказа создается. Вот тут объяснял, как это с моей дочки зрения должно выглядеть.
Ну и еще неплохо то из них, в котором официальная ЭЦП хранится, выполнять не в виде карточки, а с корпусом, служащим штампом личной печати (например, в таком, как у японцев это выглядит). И электронику для сканнеров биометрии есть куда поместить, и защищенности (скажем, пожароустойчивость) можно добавить, выбрав правильный материал, и использовать можно на бумажных документах в дополнении к подписи. И, самое главное — солидность-официальность придает. А то у нас большая часть людей так до сих пор и не понимает, как этой ЭЦП обращаться надо. Может, если это будет в форм-факторе "большая круглая печать" — дойдет.
Не совсем. Если купить телефон и поломать у него все интерфейсы (беспроводные и, по возможности, проводные) — то следить за актуальностью софта нужно гораздо меньше.
Собственно, вся идея не лишена смысла, если бы применялся не телефон, а специально разработанное (пусть и на базе телефонов) под это дело устройство.
Так не надо ничего постоянно синхронизировать. Та подсеть, которая вам выдана (еще раз — это не то, что на внешнем интерфейсе) выдается практически навечно и не меняется. Соответственно, поднимаешь сервис, выбираешь для него IP из сервисной сети. Прописываешь IP в DNS и больше оно никогда не меняется.
Работает это все дорожно приблизительно так:
На внешнем интерфейсе маршрутизатора провайдер дает, скажем
2001:db8:0:0:aaaa:bbbb:cccc:dddd (любым способом). Этот адрес никого не интересует и может быть более-менее произвольно провайдером меняться
Одновременно он выдает клиенту 2001:0db8:0000:ee00::/56 и маршрутизирует ее на этот адрес.
Клиент берет одну из /64 (например, 2001:0db8:0000:ee10::/64) в качестве адресов внутреннего сегмента для своих устройств — из нее адреса устройства будут автоматически получать. Если не страдать паранойей — всегда одни и те же, т.к. по MAC адресу генерироваться будут.
Еще одну сетку /64 (например, 2001:0db8:0000:ee11::/64) выбираем для для адресов сервисов.
Теперь что делаем, когда поднимаем сервис:
Есть у нас устройство, где сервис хотим поднять с адресом 2001:0db8:0000:ee10:1234:5678:9abc:def1 — это адрес постоянный внутри сегмента
Выбираем адрес из сервисной сети (2001:0db8:0000:ee11:2345:6789:abcd:ef01/128), вешаем его статиком на интерфейсе того устройства, где сервис живет (т.е рядом с 2001:0db8:0000:ee10:1234:5678:9abc:def1).
Прописываем 2001:0db8:0000:ee11:2345:6789:abcd:ef01 в DNS в виде servicename.mydomain.home
На маршрутизаторе прописываем маршрут 2001:0db8:0000:ee11:2345:6789:abcd:ef01 via 2001:0db8:0000:ee10:1234:5678:9abc:def1 и открываем нужные порты
Все.
Когда хотим сервис на другую железку перенести — переносим 2001:0db8:0000:ee11:2345:6789:abcd:ef01/128 уже на нее и меняем маршрут.
Уже писал тут где-то рядом. Тот адрес, который внешний на маршрутизаторе — он в случае с IPv6 вообще не должен для сервисов использоваться. Сервисы вешаются в отдельную подсетку, которая вырезается из тех адресов, что абоненту выданы. И это подсетка — она не из /64 с внешнего интерфейса.
Просто вот это желание использовать "внешний адрес" — это привычка от IPv4, когда адресов абоненту мало давали.
Ну, технически, это все-таки будет NAT-ом (адреса в пакетах меняются все-таки). Просто не таким сложным, как в случае с IPv4. А просто и тупо заменяем один адрес на другой и отправляем дальше, не занимаясь разными connection tracking.
Хотя лучше бы взять одну из подсеток из твоей /56, /48 специально для адресов публичных сервисов, назначать адреса из нее на том хосте, где сервис живет. А на маршрутизаторе прописывать маршрут "этот адрес — вон на том сервере".
Нет. Потому что в процессе работы обучать можно только тому что надо. А при централизованном обучении — обучать, чтобы работодатели были довольны, придется вообще всему, что существует. А это очень-очень много времени.
Зато следует, что нужно учить писать документацию. А это умение, почему-то, вообще в требуемых работодателям навыках практически не упоминается. И вообще считается чем-то, что само как-то появится.
Хотя по хорошему тоже должно отдельно тренироваться.
А почему понимание многопоточности должно решаться, как ниже предлагается. кругозором и пет-проектами? Оно, создается прокачкой на 1000+ задачек вида 'написать..., найти ошибку в....'. На разных языках и в разных модельных ситуациях. И вот после этого человек race condition сразу видеть будет. Но решение 1000+ задачек — оно тоже время обучения. Причем другие работодатели, с большой вероятностью будут думать на такие затраты времени 'какой-то ненужной фигне обучают, лучше бы потратили время на <подставить что-то, нужное им>'
А все равно так или иначе будет платить. Может, не в таком виде, но будет. Потому что студенту, пока учится, нужно на что-то жить и его преподавателям нужно платить зарплату.
Соответственно, и студент и система образования захотят эти деньги получить. Причем — с работодателя. Больше неоткуда. Т.е. если будет система образования, из которой выходят люди, готовые к работе — то и платить так или иначе придется больше.
Причем в достаточно большой степени именно потому, что студенты "набирают опыт работы", который будут требовать при устройстве на работу. Вместо того, чтобы читать учебники, книжки и последовательно разбираться в нужных технологиях. И нет, набираемый "опыт работы" — плохая этому замена. Потому что получается, что хватаются несвязные кусочки со StackOverflow.
Собственно, я давно сторонник точки зрения "если у тебя есть время работать — значит, тебя плохо учат".
Я так понимаю, имелась в виду EMV Payment Tokenisation
Насколько именно можно считать, что там 'при каждом платеже номер карты генерируется' — вопрос несколько спорный, но рекламируется оно именно так.
И все это только ради того, чтобы нельзя было понять, что 4c78b3a1-b569-4c46-a05b-911411e0543e@google.com не совпадает с a49a9740-b6d7-11ea-8b6e-0800200c9a66 и не является на самом деле username@google.com?
Уже упомянутая генерация номера карты для каждой покупки — это же костыль, вставленный для обхода уязвимости в системе, которую нельзя убрать из соображений совместимости. (А именно той уязвимости, что почему-то делает просто номер карты чем-то ценным, угрожающим мошенническим снятием денег и поэтому нуждающемся в защите). И всей это морокой с токинезацией никто бы не занимался, если бы этой уязвимости не было.
Так собственная аутентификация, силами самого ресурса — обычно email в качестве логина. Вот его и спрашивают, чтобы все более-менее единообразно было с точки зрения учетной записи.
В IBAN она 2 цифры
Из таких соображений легче переводить сразу не по номеру телефона, а по номеру паспорта — он еще короче.
Проще ввести одну строку цифр, которая IBAN. "Неправильно продиктовал" — поймается контрольной суммой в номере. И, скорее всего, его не будут диктовать, а просто пришлют текстовым сообщение.
Ну т.е. уже начались костыли — перевод на самом деле не по номеру телефона, а по номер телефона+инициалы. Плюс переводить деньги, вообще говоря, можно не только человеку, но и организации — там с инициалами плохо.
Почему бы сразу устойчивый идентификатор не использовать?
Проблема только в том, что в номере телефона нет контрольной суммы. И человек не понимает, что не ошибся в наборе.
А если телефон выбирается из контактов и ничего набирать на надо — то точно так же не надо набирать номер банковского счета для получения денег, который может в контакте лежать.
Даже в США уже несколько лет идет EMV liability shift. И банк, который не поменял банкомат на тот, который умеет читать чип, по сути, согласился вернуть деньги на чипованную карточку буквально по первому слову пользователя этой карточки.
Поэтому в процессе было очень смешно. Банкам хотелось и безопасность повысить и сделать так, чтобы карты с чипом не распространялись слишком быстро. В прессе были статьи о том, что карточка с чипом карта — это безопаснее. И одновременно же — что запоминать PIN — это страшно неудобно, сложно и старый способ с полосой был лучше. После чего внедрялись терминалы, где надо расписываться стилом. где-то так(Youtube). После чего продавцы жаловались, что, чипованные карты скорость прохождения очереди замедляют.
К сожалению, бумажное устройство стремительно устаревает. Я так понимаю, что изготовление подделки, которую нельзя распознать без сложного оборудования — стало очень простым.
Но я не очень поддерживаю идею единого, на все случаи годного паспорта-карточки. Слишком много прав в одном устройстве концентрируется и единая точка отказа создается. Вот тут объяснял, как это с моей дочки зрения должно выглядеть.
Ну и еще неплохо то из них, в котором официальная ЭЦП хранится, выполнять не в виде карточки, а с корпусом, служащим штампом личной печати (например, в таком, как у японцев это выглядит). И электронику для сканнеров биометрии есть куда поместить, и защищенности (скажем, пожароустойчивость) можно добавить, выбрав правильный материал, и использовать можно на бумажных документах в дополнении к подписи. И, самое главное — солидность-официальность придает. А то у нас большая часть людей так до сих пор и не понимает, как этой ЭЦП обращаться надо. Может, если это будет в форм-факторе "большая круглая печать" — дойдет.
Не совсем. Если купить телефон и поломать у него все интерфейсы (беспроводные и, по возможности, проводные) — то следить за актуальностью софта нужно гораздо меньше.
Собственно, вся идея не лишена смысла, если бы применялся не телефон, а специально разработанное (пусть и на базе телефонов) под это дело устройство.
При должной автоматизации точка синхронизации одна — адрес, записанный в DNS. А в остальных местах он может проставляться по читаемому имени.
Сценарий с резервным каналом — надо смотреть, как адреса назначаются в том префиксе, что провайдер отдал.
Если руками — то у сервисных сеток и адресов у сервиса будет по две штуки. Из адресов одного провайдера и из адресов другого.
Так не надо ничего постоянно синхронизировать. Та подсеть, которая вам выдана (еще раз — это не то, что на внешнем интерфейсе) выдается практически навечно и не меняется. Соответственно, поднимаешь сервис, выбираешь для него IP из сервисной сети. Прописываешь IP в DNS и больше оно никогда не меняется.
Работает это все дорожно приблизительно так:
На внешнем интерфейсе маршрутизатора провайдер дает, скажем
2001:db8:0:0:aaaa:bbbb:cccc:dddd (любым способом). Этот адрес никого не интересует и может быть более-менее произвольно провайдером меняться
Одновременно он выдает клиенту 2001:0db8:0000:ee00::/56 и маршрутизирует ее на этот адрес.
Клиент берет одну из /64 (например, 2001:0db8:0000:ee10::/64) в качестве адресов внутреннего сегмента для своих устройств — из нее адреса устройства будут автоматически получать. Если не страдать паранойей — всегда одни и те же, т.к. по MAC адресу генерироваться будут.
Еще одну сетку /64 (например, 2001:0db8:0000:ee11::/64) выбираем для для адресов сервисов.
Теперь что делаем, когда поднимаем сервис:
Есть у нас устройство, где сервис хотим поднять с адресом 2001:0db8:0000:ee10:1234:5678:9abc:def1 — это адрес постоянный внутри сегмента
Выбираем адрес из сервисной сети (2001:0db8:0000:ee11:2345:6789:abcd:ef01/128), вешаем его статиком на интерфейсе того устройства, где сервис живет (т.е рядом с 2001:0db8:0000:ee10:1234:5678:9abc:def1).
Прописываем 2001:0db8:0000:ee11:2345:6789:abcd:ef01 в DNS в виде servicename.mydomain.home
На маршрутизаторе прописываем маршрут 2001:0db8:0000:ee11:2345:6789:abcd:ef01 via 2001:0db8:0000:ee10:1234:5678:9abc:def1 и открываем нужные порты
Все.
Когда хотим сервис на другую железку перенести — переносим 2001:0db8:0000:ee11:2345:6789:abcd:ef01/128 уже на нее и меняем маршрут.
Уже писал тут где-то рядом. Тот адрес, который внешний на маршрутизаторе — он в случае с IPv6 вообще не должен для сервисов использоваться. Сервисы вешаются в отдельную подсетку, которая вырезается из тех адресов, что абоненту выданы. И это подсетка — она не из /64 с внешнего интерфейса.
Просто вот это желание использовать "внешний адрес" — это привычка от IPv4, когда адресов абоненту мало давали.
Ну, технически, это все-таки будет NAT-ом (адреса в пакетах меняются все-таки). Просто не таким сложным, как в случае с IPv4. А просто и тупо заменяем один адрес на другой и отправляем дальше, не занимаясь разными connection tracking.
Хотя лучше бы взять одну из подсеток из твоей /56, /48 специально для адресов публичных сервисов, назначать адреса из нее на том хосте, где сервис живет. А на маршрутизаторе прописывать маршрут "этот адрес — вон на том сервере".