это плохая статья. судя по заголовку - целевая аудитория "начинающие", а при этом для объяснения подходов употребляются неочевидные термины, которые сами никак не поясняются.
модель предсказывает правильную метку входных данных
Логистическая регрессия - не выполняет статистическую классификацию, а оценивает параметры логистической модели
Ну это вообще перл
Случайные леса. Это алгоритм, который использует bootstrap-агрегацию и метод случайного подпространства для выращивания отдельных деревьев с целью получения мощного агрегированного предиктора, способного как к классификации, так и к регрессии.
А почему дюрации ограничены 18 месяцами? Не полезно было бы иметь возможность искать длинные облигации для фиксирования высокой ставки на более длительный период (5, 10 лет)?
Интересно читать про оживление классики ). А есть гдето описание конкретных приложух, что удалось поднять на ios'е древнем?
Там кстати я еще заметил на своем древнем айпаде, что много сайтов весьма критичных для минимальной работы с вебом выдают сообщение "браузер не поддерживается, байбай". Это для PWA не мешает?
Выглядит как симптоматическое лечение. Я бы ожидал, что JIT должен отрабатывать все-таки один раз на запрос, дальше он скэшируется, и больше в этом запросе не должно наблюдаться проблем. У клиента дашборд тормозил при первом запросе или при повторных запросах также?
Также, интересно проверить, не будет ли воспроизводится пробелема с JITом, но без докера?
>>Зависимость от внутренних сервисов — прописываем, чтобы в случае инцидента можно было быстро проверить, всё ли в порядке в соседних командах, ускорить поиск причин.
Если вы имеете ввиду, внутренние сервисы вашей компании, но которые управляются другими командами, то по хорошему они тоже должны быть встроены в процесс инцидент-менеджмента с SLA и т.п. Т.е. если у вас обнаружен инцидент, то у них тоже он должен подниматься по цепочке (как тот изза которого у вас он случился, так и тот который вы у них спровоцируете) и они также его должны отрабатывать соответственно.
Именно так, и ровно все что вы привели в качестве критериев: "свой опыт, и возможности языка и его runtime, и наличие нужных библиотек, наличие поддержки этих библиотек, наличие разработчиков на рынке и возможность их нанять" - го не является здесь очевидным выбором. Поэтому и спрашивал - в чем его бенефит-то в результате?
Статья пахнет нулевыми, столами дэфо, скрипящими стульями и "начальниками". Так-то многое по делу, просто формулировки и самодовольство за ними выдает вот этот флер жажды быть "начальником". Большая часть пунктов она негласна, т.к. "если это надо объяснять, то это не надо объяснять". В частности, автор спалился на
Опоздания лучше побеждать не беседами. Надо ставить вход по карточкам и автоматически вычитать из ЗП опоздания. Так вы избежите объяснений по вполне ясному вопросу - опозданиям.
Здесь очевидно, что это вредный совет. Опоздун просто может заплатить за то что имеет возможность положить болт на то о чем договорились с начальником. А если такая привилегия есть, то значит начальник ничем не руководит больше.
Читаю код и приёмы которые используются для того чтобы реализовать тот или иной достаточно низкоуровневый функционал (подключения, пулинг, транзакции) - в чем бенефит Go в результате перед языками где есть достаточное количество устоявшихся библиотек и фреймворков?
Не очень понял что вас изумляет в последних двух вопросах.
Что значит "зачем в кластере поднимать pgadmin"? там речь идет о вебморде pgadmin, т.е. серверная часть предлагается развернуть внутри кластера, а юзер будет пользовать webморду
Во втором, я не увидел что речь идет про "боевой кластер". Вполне нормально на тестовом окружении дать такой доступ.
Ну она больше справочник, а хотелось бы "вот hello-world плагин, он устроен вот так, его можно расширять вот так", потому что я далек от написания таких компонентов, и по справочнику понять общую концепцию разработки сложно.
Так вот наконец и закончили двигатель, а то так и пилили бы бесконечно как роснано
это плохая статья. судя по заголовку - целевая аудитория "начинающие", а при этом для объяснения подходов употребляются неочевидные термины, которые сами никак не поясняются.
Ну это вообще перл
А почему дюрации ограничены 18 месяцами? Не полезно было бы иметь возможность искать длинные облигации для фиксирования высокой ставки на более длительный период (5, 10 лет)?
Это буквально менее часа езды на машине
Ооо, хакер спец. я туда статьи писал хнык-хнык
Супер, спасибо. А какими вы альтернативами тестировали бы linux vps?
Лучше бы батарею сделали чтоб держала неделю хотя бы.
Интересно читать про оживление классики ). А есть гдето описание конкретных приложух, что удалось поднять на ios'е древнем?
Там кстати я еще заметил на своем древнем айпаде, что много сайтов весьма критичных для минимальной работы с вебом выдают сообщение "браузер не поддерживается, байбай". Это для PWA не мешает?
На мой взгляд, имеет смысл все же города в странах сравнивать. Уровень жизни и стоимость в пределах одной страны может очень сильно варьироваться
понятно. Да, судя по документации jitа в pg много с настройками не разгуляешься.
Выглядит как симптоматическое лечение. Я бы ожидал, что JIT должен отрабатывать все-таки один раз на запрос, дальше он скэшируется, и больше в этом запросе не должно наблюдаться проблем. У клиента дашборд тормозил при первом запросе или при повторных запросах также?
Также, интересно проверить, не будет ли воспроизводится пробелема с JITом, но без докера?
>>Зависимость от внутренних сервисов — прописываем, чтобы в случае инцидента можно было быстро проверить, всё ли в порядке в соседних командах, ускорить поиск причин.
Если вы имеете ввиду, внутренние сервисы вашей компании, но которые управляются другими командами, то по хорошему они тоже должны быть встроены в процесс инцидент-менеджмента с SLA и т.п. Т.е. если у вас обнаружен инцидент, то у них тоже он должен подниматься по цепочке (как тот изза которого у вас он случился, так и тот который вы у них спровоцируете) и они также его должны отрабатывать соответственно.
а почту у вас как сделать к этому домену? :)
Именно так, и ровно все что вы привели в качестве критериев: "свой опыт, и возможности языка и его runtime, и наличие нужных библиотек, наличие поддержки этих библиотек, наличие разработчиков на рынке и возможность их нанять" - го не является здесь очевидным выбором. Поэтому и спрашивал - в чем его бенефит-то в результате?
Статья пахнет нулевыми, столами дэфо, скрипящими стульями и "начальниками". Так-то многое по делу, просто формулировки и самодовольство за ними выдает вот этот флер жажды быть "начальником". Большая часть пунктов она негласна, т.к. "если это надо объяснять, то это не надо объяснять". В частности, автор спалился на
Здесь очевидно, что это вредный совет. Опоздун просто может заплатить за то что имеет возможность положить болт на то о чем договорились с начальником. А если такая привилегия есть, то значит начальник ничем не руководит больше.
Читаю код и приёмы которые используются для того чтобы реализовать тот или иной достаточно низкоуровневый функционал (подключения, пулинг, транзакции) - в чем бенефит Go в результате перед языками где есть достаточное количество устоявшихся библиотек и фреймворков?
Ну среди колхозников
делать-то что?
Не очень понял что вас изумляет в последних двух вопросах.
Что значит "зачем в кластере поднимать pgadmin"? там речь идет о вебморде pgadmin, т.е. серверная часть предлагается развернуть внутри кластера, а юзер будет пользовать webморду
Во втором, я не увидел что речь идет про "боевой кластер". Вполне нормально на тестовом окружении дать такой доступ.
Ну она больше справочник, а хотелось бы "вот hello-world плагин, он устроен вот так, его можно расширять вот так", потому что я далек от написания таких компонентов, и по справочнику понять общую концепцию разработки сложно.