Конечно сервис по «помощи» в генерации CSR — это прям отличный троянский конь нашего времени! Жесть. Я могу понять — клиенты не разбираются в Безопасности и особенностях всяких.
Но! Куда смотрели DigiCert? Откуда такое пренебрежение аудитом своих реселлеров — даже поверхностному?! Любой поставщик своих крупных дилеров знает и аудирует в той или иной степени.
Насчет настройки — да, я с вами согласен: любая настройка вносящая существенное изменение поведения системы довольна чувствительна.
По мне — так зависшие транзакции — это существенное неправильное поведение системы, оно не должно происходить в штатном режиме. Как раз настройка СУБД для «прибивания» такой ситуации позволит таки высвободить задействованные ресурсы, и продолжить работу системы. Однако нужно понимать, что произошел сбой — который желательно отработать на прикладном уровне.
Подход в статье предполагает отработку ситуации на прикладном уровне — да, это предпочтительнее. Просто это нужно реализовывать, а настроука СУБД может защитить от ситуации «из коробки», а «разгребание» последствий — дело DBA.
Конечно, дело вкуса что использовать. Я бы совместил — настроку в СУБД, и, по возможности, отработку зависания транзакций в прикладном решении (в админке?)
Про сложность системы я с вами согласен. Однако те же компьютерные науки выработали вполне работающее решение — повышение уровня абстракции.
То есть, вместо выдумывания — как заставить один уровень нейросетей работать, можно попытаться реализовать многоуровневую систему, каждый следующий уровень которой будет оперировать уже обработанными данными с предыдущего уровня.
Насчет отхода от философии — даже в компьютерных науках есть такая отчасти философская штука как архитектура приложений и систем. Да, это теоретические построения. Просто на определенном уровне понимания приходит мысль, что лучше хорошей практики может быть только хорошая теория. В статье мы ясно видим — есть ряд хороших практик. Нужна хорошая теория, и психология может подсказать — в каком направлении ее искать. Междисциплинарная синергия — довольно надежная кладезь новых идей.
Эмм. А что — в больших базах данных нет возможности сделать default timeout на транзакцию?
Типа, кому надо длинную транзакцию делать — пусть в явном виде указывает большой тайм-аут, а для обычных «зависших» транзакций система сама их пришибёт через какое-то время (конечно, с записью в лог этого славного деяния).
Интересно, а когда все наработки психологии попробуют применить — не только любопытство и набивание шишек? Страхи, подсознательная страхи (простые обученные сторонние модели с защитой от сильно неправильного поведения), лень, пресыщение, эмоции в целом — это же все важные части обучения.
Понимаю, что есть мнение о психологии как о недонауке, но вижу тут как раз поле для экспериментов. Возможно, что прививанием человеческих механизмов психики нейросетям мы сможем и механизмы психики изучить!
Отсутствие публично декларируемых целей не позволяет привнести разумность в регулирование. Отсюда любой маразм может быть оправдан — «ну, мы ж должны регулировать и контролировать».
«Мы долго шли, не понимая — куда, и очень удивились прийдя не туда!»
Ну — как умер. Тьма API у сервисов построена как REST, а значит REST жив. Facebook, Instagram, Google,…
Другой вопрос, что есть более перспективные технологии — разные, да хоть GraphQL. Realtime API появляются. Да много чего напридумывали для специфических задач и исправления недостатков REST.
Стандарта REST особенно не сформировалось — как ограничивать выборку полей ресурса, как фильтрацию/отбор делать, и тп.
Не совсем понимаю — в чем проблема с POST запросами — это запросы на изменение. Что тут кэшировать? Запросы на чтение делаются через GET (http://graphql.org/learn/serving-over-http/). Да, кэширование для HTTP, наверное, не подойдет, но есть специализированные решения.
Про кэширование: graphql.org/learn/caching
В целом: предлагают клиентам самими делать нужное кэширование.
В нашей стране часто регулирование не сопровождается публичным объявлением целей и критериев эффективности. Отсюда — всякий маразм, как, например, штрафы за ошибки в документах валютного контроля. Для бизнеса самый главный штраф — это удерживание выручки. Неясно, с какой целью нужно бизнес подвергать штрафам
Страничка www.tensorflow.org/api_docs намекает, что API на питоне — это #1, остальное (даже С++) — это немного не дотягивает. Так что — самое хардкорное и полноценное использование TF — это задействовать API через питон. Впрочем, не суть важно
Любые перемены порождают как сторонников, так и противников. Станки, паровые машины, авто, компьютеры, а вот теперь — роботы.
Но никто не отменит ясного и очевидного факта, что наше благосостояние с появлением роботов растёт. Поэтому шансов на запрет роботов просто нет.
Конечно сервис по «помощи» в генерации CSR — это прям отличный троянский конь нашего времени! Жесть. Я могу понять — клиенты не разбираются в Безопасности и особенностях всяких.
Но! Куда смотрели DigiCert? Откуда такое пренебрежение аудитом своих реселлеров — даже поверхностному?! Любой поставщик своих крупных дилеров знает и аудирует в той или иной степени.
По мне — так зависшие транзакции — это существенное неправильное поведение системы, оно не должно происходить в штатном режиме. Как раз настройка СУБД для «прибивания» такой ситуации позволит таки высвободить задействованные ресурсы, и продолжить работу системы. Однако нужно понимать, что произошел сбой — который желательно отработать на прикладном уровне.
Подход в статье предполагает отработку ситуации на прикладном уровне — да, это предпочтительнее. Просто это нужно реализовывать, а настроука СУБД может защитить от ситуации «из коробки», а «разгребание» последствий — дело DBA.
Конечно, дело вкуса что использовать. Я бы совместил — настроку в СУБД, и, по возможности, отработку зависания транзакций в прикладном решении (в админке?)
То есть, вместо выдумывания — как заставить один уровень нейросетей работать, можно попытаться реализовать многоуровневую систему, каждый следующий уровень которой будет оперировать уже обработанными данными с предыдущего уровня.
Насчет отхода от философии — даже в компьютерных науках есть такая отчасти философская штука как архитектура приложений и систем. Да, это теоретические построения. Просто на определенном уровне понимания приходит мысль, что лучше хорошей практики может быть только хорошая теория. В статье мы ясно видим — есть ряд хороших практик. Нужна хорошая теория, и психология может подсказать — в каком направлении ее искать. Междисциплинарная синергия — довольно надежная кладезь новых идей.
Side note: сколько столкнулось в комментах мировоззрений!
Эмм. А что — в больших базах данных нет возможности сделать default timeout на транзакцию?
Типа, кому надо длинную транзакцию делать — пусть в явном виде указывает большой тайм-аут, а для обычных «зависших» транзакций система сама их пришибёт через какое-то время (конечно, с записью в лог этого славного деяния).
Интересно, а когда все наработки психологии попробуют применить — не только любопытство и набивание шишек? Страхи, подсознательная страхи (простые обученные сторонние модели с защитой от сильно неправильного поведения), лень, пресыщение, эмоции в целом — это же все важные части обучения.
Понимаю, что есть мнение о психологии как о недонауке, но вижу тут как раз поле для экспериментов. Возможно, что прививанием человеческих механизмов психики нейросетям мы сможем и механизмы психики изучить!
Очень круто! Crispr бы так доставить, чтобы он только раковую клетку резал
Из плюсов: вместо хайповых терминов «нейронные сети», разговор идёт о старой доброй математике. Это круто, это немножко в глубину вопроса.
Вот бы ещё помимо глубины дать направления размышлений по перспективе — попредметнее!
Прийдется купить книжку чтобы изучить))
Комменты, более того, минимум такие же интересные, как статья.
Отсутствие публично декларируемых целей не позволяет привнести разумность в регулирование. Отсюда любой маразм может быть оправдан — «ну, мы ж должны регулировать и контролировать».
«Мы долго шли, не понимая — куда, и очень удивились прийдя не туда!»
Другой вопрос, что есть более перспективные технологии — разные, да хоть GraphQL. Realtime API появляются. Да много чего напридумывали для специфических задач и исправления недостатков REST.
Стандарта REST особенно не сформировалось — как ограничивать выборку полей ресурса, как фильтрацию/отбор делать, и тп.
Про кэширование: graphql.org/learn/caching
В целом: предлагают клиентам самими делать нужное кэширование.
GraphQL решает похожие проблемы с управлением объемом выборки, но относительно стандартизированным путём.
Не в курсе, впрочем, если под .net graphQL сервер
В нашей стране часто регулирование не сопровождается публичным объявлением целей и критериев эффективности. Отсюда — всякий маразм, как, например, штрафы за ошибки в документах валютного контроля. Для бизнеса самый главный штраф — это удерживание выручки. Неясно, с какой целью нужно бизнес подвергать штрафам
TF реализован на С++. А вот клиентская библиотека самая продвинутая у него — на питоне. Что считать «чистым TF»?
Или я что то путаю?
Интересно бы сравнить с чем-то типа Сульфакрилата: менее токсичен? Как там дело с аллергией — если биопродукт, она вполне возможна.