Литкод и егэ это как раз и заучивание «видишь вопрос А напиши ответ Б», вы на права сдавали там теорию так предлагается сдавать? Это все, по моему опыту, никак не мешает скопировать потом класс вместо добавления if внутри. Зато 100500 задач на литкоде и 999 баллов.
Вот обучение работе с источниками (поиск в библиотеке, проверка по источникам утверждения и проверка новизны), на мой взгляд, дают гораздо больше пользы в решении проблем «надо сделать А, делал ли кто это раньше и как это сделать с минимальными затратами».
Что тогда не начертательная геометрия? Или аналитическая химия? Ну или иностранный язык. Вот уж что что, а основы высшей математики сводятся к заучиванию формул и рефлексу "видишь X - применяешь формулу Y" что потом замечательно вылетает из головы и сводится к полутора землекопам.
Проблема не в том приучен ли человек к паттернам, а в том готов ли включить голову и разобраться в вопросе. Если у человека прокачан навык заучивания паттернов он и будет использовать их не делая даже попытки понять в чем смысл задач.
Про накостылить, чаще всего как раз и когда начинаешь разбираться то слышишь "я знаю паттерн XXX который все говорят что надо применять"
Мне такое вещали со школы и за 20+ лет в IT. Может вы мне расскажете как знание математики поможет ускорить шлепание crud формочек, что мне и требуется от джунов. Или может где-то в учебнике по высшей математике (я не нашел) написано как не поддаваться искушению накостылить, а написать в общий чат с вопросом?
Люди стремятся улучшить свой уровень жизни уменьшив при этом усилия. Если в частном секторе можно делать свою работу за Х, а в госсекторе платят Y и еще и навешивают допнагрузку пытаясь оторвать заслуги, то при соотношении X >> Y выбор очевиден. Если первые уровни пирамиды не закрыты, то последующие не имеют ценности.
А по каким критериям вы его выбирали? Какой flavor? Какой storage engine? Из вашего описания складывается ощущение что это было сделано по принципу "у меня была книжка". Ну или когда готовое решение, например Wordpress, это диктует.
Судя по выбору MySQL только из-за удобства, а не по принципу что лучше подойдет (иногда даже в пределах одного проекта) у вас стек действительно очень влияет, команда при любых нестандартных ситуациях ничего не сделает.
Это связано с когнитивным искажением что callerID всегда равен номеру который присвоил оператор договору. Авторизация по нему это эквивалент доверию заявлению «меня зовут Вася» в банке.
Возможно я мало знаю реалии Российской телефонии, но вроде в случае SS7 оператор получает идентификатор станции и может проверить что номер принадлежит отправителю (с учетом настроенного обмена по портированым номерам это не должно вызвать сложности)
А в случае SIP есть STIR/SHAKEN реализация которого не вызывает race condition из описания системы антифрод которую я смог найти в интернете (когда оператор от которого отправляется звонок отправляет информацию о нем в централизованную базу, а принимающий оператор проверяет есть ли этот флаг. Там любая задержка на запись может положить весь функционал)
Есть ли у кого менее общее описание работы этого кроме "ОНО РАБОТАЕТ" с учетом таких вещей как звонки с телефонов находящихся в роуминге?
А, так мы об этом. В таком случае идеографическая письменность может нести поток больше 150 бит в секунду легко на очень узком канале. В зависимости от кодирования ширина потока может быть узким местом (иероглифы в несжатом UltraHD гораздо большую полосу пропускания требуют чем азбука морзе) и иметь возможность передать больший объем информации (не факт что значимой в ней будет больше 150 бит/с) с меньшей задержкой в еденицу времени это хорошо и не является чем-то излишним.
В качестве эксперимента попробуйте взять текст какой-либо статьи и посмотреть какую ширину пропускного канала необходимо если ее передать: 1. Голосом 2. В виде картинки (например TIFF, как у факсов) 3. В виде текста
Во всех этих случаях мы получим один объем полезной информации, но в разных типах кодирования ее.
Если взять голос, то слушать телефонный звонок в HD кодеке гораздо психологически комфортнее чем в GSM кодеке. Именно поэтому HD кодеки и начали использовать в мобильной связи.
Зато в резюме смотрится внушительно "сервис с нагрузкой 100500RPS", правда на самом деле это оказывается 100RPS в базарный день от клиентов, но у нас же 50 микросервисов обменивающихся информацией и производящих синхронизацию данных.
Видел решение когда на каждое изменение в микросервисе юзеров всем остальным рассылался апдейт данных на случай если они у себя что-то меняют. Было около 20 подписчиков каждый из которых был запущен в нескольких экземплярах для надежности.
Это да, но разговор то шел не об аналитических субд, а о субд для продакшна. В аналитических субд если аналитик1 затормозит запрос аналитика2 они могут выяснить свои отношения на ножах. А если в продакшн системе аналитик залочит базу в момент когда пришло много пользователей с рекламы, то бюджет уже будет потрачен без прибыли.
Это становится дорого когда это превышает 50-60Tb данных, до тех времен это гораздо дешевле чем работа DBA + DevOPS + Monitoring engineer которые следят за тем что бы их запросы не рушили продакшн.
На больших базах там да, уже проблемы. Но большинство проектов которым уже требуются аналитики с их выборками много меньше данных имеют.
Литкод и егэ это как раз и заучивание «видишь вопрос А напиши ответ Б», вы на права сдавали там теорию так предлагается сдавать? Это все, по моему опыту, никак не мешает скопировать потом класс вместо добавления if внутри. Зато 100500 задач на литкоде и 999 баллов.
Вот обучение работе с источниками (поиск в библиотеке, проверка по источникам утверждения и проверка новизны), на мой взгляд, дают гораздо больше пользы в решении проблем «надо сделать А, делал ли кто это раньше и как это сделать с минимальными затратами».
Что тогда не начертательная геометрия? Или аналитическая химия? Ну или иностранный язык. Вот уж что что, а основы высшей математики сводятся к заучиванию формул и рефлексу "видишь X - применяешь формулу Y" что потом замечательно вылетает из головы и сводится к полутора землекопам.
Проблема не в том приучен ли человек к паттернам, а в том готов ли включить голову и разобраться в вопросе. Если у человека прокачан навык заучивания паттернов он и будет использовать их не делая даже попытки понять в чем смысл задач.
Про накостылить, чаще всего как раз и когда начинаешь разбираться то слышишь "я знаю паттерн XXX который все говорят что надо применять"
Мне такое вещали со школы и за 20+ лет в IT. Может вы мне расскажете как знание математики поможет ускорить шлепание crud формочек, что мне и требуется от джунов. Или может где-то в учебнике по высшей математике (я не нашел) написано как не поддаваться искушению накостылить, а написать в общий чат с вопросом?
Думаю если убрать метрику с сайта, то и поток прекратится. Если надо a-b тестирование, то можно hotjar подключить.
Штрафовать надо компанию, как она будет поступать с этими штрафами уже без разницы. Только так у них появится стимул что-то менять и решать проблему.
Люди стремятся улучшить свой уровень жизни уменьшив при этом усилия. Если в частном секторе можно делать свою работу за Х, а в госсекторе платят Y и еще и навешивают допнагрузку пытаясь оторвать заслуги, то при соотношении X >> Y выбор очевиден. Если первые уровни пирамиды не закрыты, то последующие не имеют ценности.
Возможно ждут пока накопится достаточное количество траффика чтоб показать рекламу при редиректе/отправить на фишинг. Как в свое время сделал gmail.ru
А по каким критериям вы его выбирали? Какой flavor? Какой storage engine? Из вашего описания складывается ощущение что это было сделано по принципу "у меня была книжка". Ну или когда готовое решение, например Wordpress, это диктует.
Судя по выбору MySQL только из-за удобства, а не по принципу что лучше подойдет (иногда даже в пределах одного проекта) у вас стек действительно очень влияет, команда при любых нестандартных ситуациях ничего не сделает.
Это связано с когнитивным искажением что callerID всегда равен номеру который присвоил оператор договору. Авторизация по нему это эквивалент доверию заявлению «меня зовут Вася» в банке.
А если мы все так при оценке расписали и оценили разве мы не получили весь цикл планирования водопада?
Возможно я мало знаю реалии Российской телефонии, но вроде в случае SS7 оператор получает идентификатор станции и может проверить что номер принадлежит отправителю (с учетом настроенного обмена по портированым номерам это не должно вызвать сложности)
А в случае SIP есть STIR/SHAKEN реализация которого не вызывает race condition из описания системы антифрод которую я смог найти в интернете (когда оператор от которого отправляется звонок отправляет информацию о нем в централизованную базу, а принимающий оператор проверяет есть ли этот флаг. Там любая задержка на запись может положить весь функционал)
Есть ли у кого менее общее описание работы этого кроме "ОНО РАБОТАЕТ" с учетом таких вещей как звонки с телефонов находящихся в роуминге?
А в случае роуминга как происходит это?
Скорее всего это еще связано со стоимостью приема платежей.
Возможно при определенной скидке стоимость комиссии за платеж будет больше стоимости игры
Не совсем, Google использует feature extraction которые более короткие и потом на их базе восстанавливает оригинал. Этакий gzip на нейросетях.
А, так мы об этом. В таком случае идеографическая письменность может нести поток больше 150 бит в секунду легко на очень узком канале. В зависимости от кодирования ширина потока может быть узким местом (иероглифы в несжатом UltraHD гораздо большую полосу пропускания требуют чем азбука морзе) и иметь возможность передать больший объем информации (не факт что значимой в ней будет больше 150 бит/с) с меньшей задержкой в еденицу времени это хорошо и не является чем-то излишним.
В качестве эксперимента попробуйте взять текст какой-либо статьи и посмотреть какую ширину пропускного канала необходимо если ее передать:
1. Голосом
2. В виде картинки (например TIFF, как у факсов)
3. В виде текста
Во всех этих случаях мы получим один объем полезной информации, но в разных типах кодирования ее.
Если взять голос, то слушать телефонный звонок в HD кодеке гораздо психологически комфортнее чем в GSM кодеке. Именно поэтому HD кодеки и начали использовать в мобильной связи.
Даже https://en.wikipedia.org/wiki/Codec_2 хочет не менее 450 бит/с, интересно что это за кодек такой на 150 бит.
Зато в резюме смотрится внушительно "сервис с нагрузкой 100500RPS", правда на самом деле это оказывается 100RPS в базарный день от клиентов, но у нас же 50 микросервисов обменивающихся информацией и производящих синхронизацию данных.
Видел решение когда на каждое изменение в микросервисе юзеров всем остальным рассылался апдейт данных на случай если они у себя что-то меняют. Было около 20 подписчиков каждый из которых был запущен в нескольких экземплярах для надежности.
Это да, но разговор то шел не об аналитических субд, а о субд для продакшна. В аналитических субд если аналитик1 затормозит запрос аналитика2 они могут выяснить свои отношения на ножах. А если в продакшн системе аналитик залочит базу в момент когда пришло много пользователей с рекламы, то бюджет уже будет потрачен без прибыли.
Это становится дорого когда это превышает 50-60Tb данных, до тех времен это гораздо дешевле чем работа DBA + DevOPS + Monitoring engineer которые следят за тем что бы их запросы не рушили продакшн.
На больших базах там да, уже проблемы. Но большинство проектов которым уже требуются аналитики с их выборками много меньше данных имеют.