Там все сложно. Плотность извилин кореллирует с объёмом черепной коробки тоже.. тем более в пределах вида. Поэтому действия чуваков с "черепомерками" не совсем бессмысленные. Ещё количество соединений важно. У врановых вон мозгов мало, но сеть плотнее.
Надо смотреть объем черепной коробки, он кореллирует с развитием когнитивных функций.
Но есть факты деградации. Объём мозга у дикой лесной кошки (европейский лесной кот, Felis silvestris silvestris) больше, чем у домашней кошки (Felis silvestris f. catus) потому что в процессе одомашнивания большой мозг стал им не нужен. И это всего за срок немногим меньше 8000 лет.
Вы не поняли. Речь именно о деградации когнитивных функций. Электричество и мобильная связь не сделала нас глупее. А вот ИИ вполне может, просто потому что мы не будем пользоваться мозгами как инструментом.. простейший и доступный каждому пример с калькуляторами: зачем запоминать таблицу умножения, если есть калькулятор? Вроде бы логично. Но мой дед мог меня развлекать перемножением четырехзначных чисел в уме, а для меня это уже сложно. Уже сейчас есть мнение, что зачем запоминать что-то если можно загуглить.. биология вещь упрямая, если какой-то навык не используется, то орган его воспроизводящий атрофируется. Я именно об этом.
Я абсолютно уверен в появлении "неолуддитов" и целых поселений "новых амишей" где все будет делаться без помощи ИИ. Просто дайте технологическим кампаниям время чтобы развить нейронки.. и капитализм сделает все остальное.
Но в массе интереснее, как быстро мы когнетивно деградируем, и станем безнадежно зависимы от ИИ ?
Все люди косячат. И нейронки косячат. Но раз все косячат — значит, у агентов с людьми паритет, разве нет?
Нет это не так работает. Агент, это китайская комната на стероидах. Она выполняет указания без понимания сути в рамках граничных условий и контекстного окна. Агент не задает вопросов на основе своего опыта.. более того у него нет опыта, а есть условная база данных весов.
И наконец, как предприниматель, вы должны понимать, что нанимая разработчиков, если это не бомжфриланс за три банана, вы чаще всего получаете некоторую гарантию.. у которой есть физический и юридический адрес для выставления претензий. В случае косяка агента, вы можете только грустно смотреть в даль.
Естественно что для "перекрасьте мне кнопку в зеленый цвет" дешевле использовать агента, но если вам надо запустить что-то сложнее лендинга, и с нуля.. уже нет.
Ну значит вы никогда понастоящему не работали с данными. Потому что реляции по ключам реальны только там где они существуют с первого дня, а в жизни все немного иначе. В жизни есть дубли, есть поврежденные и фрагментированные данные. Данные которые вы получаете, но не управляете. У нас основная бд с которой работает подразделение получает данные с оборудования через xml дампы и принтауты консольных команд. Каждый день потенциально новый тип у существующей колонки, и появление новых. Никаких первичных ключей или признаков уникальности не предусмотрено в принципе. Максимум этой базы - синтетические id которые корректны только от аплоада до аплоада.
Тоже самое с картографическими данными коих у нас великое множество
Проблема в том, что подход из статьи только увеличивает энтропию и количество обьектов.
Ответ: неотличимо от ручного джойна
Что характерно нет никакого этому подтверждения, потому что похоже в статье отсутствует план запроса до-после, или какой-либо бенчмарк. У джентельменов принято верить на слово, и если в pg в все именно так, то это замечательно, но к примеру в sql server использование методов.. смерти подобно потому что код в большинстве случаев не разматывается оптимизатором, как в случае вью или сахарных CTE.
не компонуется в цепочки вида client(document(di))
Лично мое мнение, как человека который последние 10 лет только и делает, что пялится в SQL.. за такое надо немного бить, может быть даже палкой. Во первых за то что это здорово снижает читаемость и понимание кода. Я абсолютно уверен, что пять одинаковых ON не многословность, а явное намерение.
Во вторых, за нейминг в приведенном примере. Табличные и скалярные методы опять же должны выражать намерение в названии.. а тут его нет. В третьих..
CREATE FUNCTION client_document_list(profile) RETURNS SETOF document LANGUAGE sql STABLE PARALLEL SAFEAS $$ SELECT * FROM public.documentWHERE (client_id) = (($1).client_id) $$;
.. я не большой специалист в Pg, но это выглядит так словно мы одной нагой залезли в N+1 проблему. Делать это преимуществом по сравнению с JOIN.. ну такое. В принципе это не проблема для подможества, где использование LATERAL это норма.
В четвертых, у вас появляется единая точка отказа, думаю тут комментировать не надо. Мы надеемся что с client_document_list будет все хорошо.. надежда плохой попутчик там где должна быть уверенность.
Установка — одна команда
Только вот недавно обсуждали что использование пайплайна в командах из сомнительных источников это плохая практика, и вот опять.
Более того на больших базах их и не думали создавать. У меня сейчас в работе несколько БД.. и они никогда не видели первичных ключей, связей и тд. Просто потому что половина данных ежедневно или ежечасно перегружается с нуля из внешних систем
Если честно не совсем понял чего вам не хватало. Код стал куда более контринтуитивным, потому что часть логики потенциально спрятана от читающего запрос.
Мне кажется, что после успеха VSinder, который что ска характерно привел к покупке и закрытию сервиса, нишевость - это очевидное условие чтобы что-то выстрелило
А вот что интересно, так это улучшения по части CoreCLR. Обещает «почти моментальный запуск в Play Mode и ускорение сборки шейдеров на 90%. Если хотя бы часть из этого правда, то уже неплохо.»
Согласно их roadmap в билдах мы увидим CoreCLR еще не скоро, пока только в редакторе.
Я подозреваю месяцы для внедрения системы расширения превратились в годы, или там есть какие-то сдвиги?
Я думал, что с напиливанием апдейтов для dual carriage там что-то да поменялось.. оказывается нет
Домклик ?
Я бы не стал публиковать это в корпоративном блоге :D
Кстати, есть кто активный геймер? На стиме маркировка нейрослопа работает, или нет?
Главное чтобы не клиповое мышление победило
Там все сложно. Плотность извилин кореллирует с объёмом черепной коробки тоже.. тем более в пределах вида. Поэтому действия чуваков с "черепомерками" не совсем бессмысленные. Ещё количество соединений важно. У врановых вон мозгов мало, но сеть плотнее.
Надо смотреть объем черепной коробки, он кореллирует с развитием когнитивных функций.
Но есть факты деградации. Объём мозга у дикой лесной кошки (европейский лесной кот, Felis silvestris silvestris) больше, чем у домашней кошки (Felis silvestris f. catus) потому что в процессе одомашнивания большой мозг стал им не нужен. И это всего за срок немногим меньше 8000 лет.
Вы не поняли. Речь именно о деградации когнитивных функций. Электричество и мобильная связь не сделала нас глупее. А вот ИИ вполне может, просто потому что мы не будем пользоваться мозгами как инструментом.. простейший и доступный каждому пример с калькуляторами: зачем запоминать таблицу умножения, если есть калькулятор? Вроде бы логично. Но мой дед мог меня развлекать перемножением четырехзначных чисел в уме, а для меня это уже сложно. Уже сейчас есть мнение, что зачем запоминать что-то если можно загуглить.. биология вещь упрямая, если какой-то навык не используется, то орган его воспроизводящий атрофируется. Я именно об этом.
Я абсолютно уверен в появлении "неолуддитов" и целых поселений "новых амишей" где все будет делаться без помощи ИИ. Просто дайте технологическим кампаниям время чтобы развить нейронки.. и капитализм сделает все остальное.
Но в массе интереснее, как быстро мы когнетивно деградируем, и станем безнадежно зависимы от ИИ ?
Нет это не так работает. Агент, это китайская комната на стероидах. Она выполняет указания без понимания сути в рамках граничных условий и контекстного окна. Агент не задает вопросов на основе своего опыта.. более того у него нет опыта, а есть условная база данных весов.
И наконец, как предприниматель, вы должны понимать, что нанимая разработчиков, если это не бомжфриланс за три банана, вы чаще всего получаете некоторую гарантию.. у которой есть физический и юридический адрес для выставления претензий. В случае косяка агента, вы можете только грустно смотреть в даль.
Естественно что для "перекрасьте мне кнопку в зеленый цвет" дешевле использовать агента, но если вам надо запустить что-то сложнее лендинга, и с нуля.. уже нет.
Если вы получаете примерно одинаковый негативный фидбек, то со статьей определенно что-то не то
Ну значит вы никогда понастоящему не работали с данными. Потому что реляции по ключам реальны только там где они существуют с первого дня, а в жизни все немного иначе. В жизни есть дубли, есть поврежденные и фрагментированные данные. Данные которые вы получаете, но не управляете. У нас основная бд с которой работает подразделение получает данные с оборудования через xml дампы и принтауты консольных команд. Каждый день потенциально новый тип у существующей колонки, и появление новых. Никаких первичных ключей или признаков уникальности не предусмотрено в принципе. Максимум этой базы - синтетические id которые корректны только от аплоада до аплоада.
Тоже самое с картографическими данными коих у нас великое множество
в целом согласен с https://habr.com/ru/articles/1065796/comments/#comment_30292374
Проблема в том, что подход из статьи только увеличивает энтропию и количество обьектов.
Что характерно нет никакого этому подтверждения, потому что похоже в статье отсутствует план запроса до-после, или какой-либо бенчмарк. У джентельменов принято верить на слово, и если в pg в все именно так, то это замечательно, но к примеру в sql server использование методов.. смерти подобно потому что код в большинстве случаев не разматывается оптимизатором, как в случае вью или сахарных CTE.
Лично мое мнение, как человека который последние 10 лет только и делает, что пялится в SQL.. за такое надо немного бить, может быть даже палкой. Во первых за то что это здорово снижает читаемость и понимание кода. Я абсолютно уверен, что пять одинаковых ON не многословность, а явное намерение.
Во вторых, за нейминг в приведенном примере. Табличные и скалярные методы опять же должны выражать намерение в названии.. а тут его нет. В третьих..
.. я не большой специалист в Pg, но это выглядит так словно мы одной нагой залезли в N+1 проблему. Делать это преимуществом по сравнению с JOIN.. ну такое. В принципе это не проблема для подможества, где использование LATERAL это норма.
В четвертых, у вас появляется единая точка отказа, думаю тут комментировать не надо. Мы надеемся что с
client_document_listбудет все хорошо.. надежда плохой попутчик там где должна быть уверенность.Только вот недавно обсуждали что использование пайплайна в командах из сомнительных источников это плохая практика, и вот опять.
Более того на больших базах их и не думали создавать. У меня сейчас в работе несколько БД.. и они никогда не видели первичных ключей, связей и тд. Просто потому что половина данных ежедневно или ежечасно перегружается с нуля из внешних систем
Если честно не совсем понял чего вам не хватало. Код стал куда более контринтуитивным, потому что часть логики потенциально спрятана от читающего запрос.
По моему лучше немного переплатить и взять бюджетную механику,
например такую
shark attak x87, такой же трехрежимный кусочек говнеца, но он хотябы кастомизируемый и ремонтопригодный
чем мембранную
Мне кажется, что после успеха VSinder, который что ска характерно привел к покупке и закрытию сервиса, нишевость - это очевидное условие чтобы что-то выстрелило
Это и было массовое применение :D
Согласно их roadmap в билдах мы увидим CoreCLR еще не скоро, пока только в редакторе.