Евгений Кочуров evkochurov

Если я правильно понял теорему о неполноте, мы, находясь внутри данной системы, не сможем ответить на эти фундаментальные вопросы вообще, т.к. эти параметры определяют саму систему и нас в том числе.

Строго говоря, нет.
Во-первых, эта теорема не касается ненаучных методов познания (религия, искусство).
Во-вторых, она утверждает, что всегда найдутся какие-то вопросы, на которые мы не можем ответить, но не утверждает, что все интересующие нас вопросы останутся без ответа.

«Чтобы продать что-нибудь ненужное, нужно сначала купить что-нибудь ненужное» (с) кот Матроскин.

У меня был такой случай. Когда-то давно работал на сопровождении СЭД, и ко мне прилетали задачи от внедренцев типа: добавь такое-то поле, добавь такую-то кнопку, добавь такой-то контроль. Спрашиваю: какую проблему хотите этим решить? Отвечают: ну вот такую-то. Самый частый мой ответ: вам достаточно будет воспользоваться вот такими-то существующими функциями.

За этот подход ребята из внедрения меня иногда поругивали (порой, заслуженно :)) — мало того, что обсуждения и поиск альтернативных решений требовал от них дополнительных усилий, так потом же еще и заказчика за его же деньги приходилось убеждать, что его хотелку мы делать не будем, кушайте то, что есть.

Однако, спустя годы, когда я уже ушел с этого направления, общался с одним из бывших коллег на эту тему. Вот что он мне сказал: «когда ты ушел, наши просьбы что-то добавить стали выполняться легко и непринужденно, но теперь система превратилась в монстра». Это стало реальной проблемой. Дошло до того, что самый монстроидальный модуль переписали заново, вырезав все, что только можно.

Каждая конкатенация приводит к созданию нового инстанса строки, что реализуется копированием всей существующей строки с добавлением новой части. То есть в худшем случае имеем нотацию O(N^2)

Вот тут вы заблуждаетесь, большие строки js-движки при конкатенации не копируют. ru.stackoverflow.com/questions/694846/string-stringbuilder

Если мы все еще говорим об оргструктуре, то это какая-то немыслимая для меня постановка. Можете привести пример из жизни, где такое может пригодиться?

Если же мы говорим о поиске кратчайшего пути в абстрактном (т.е. до приземления в некоторой предметной области) графе, то да, можно. Рекурсивный запрос — это обычный поиск вширь по графу, а уж что делать с найденными путями (какие характеристики путей собирать, что и в какой момент отбросить, как отсортировать и т.д.), зависит от конкретной задачи.

И хотя можно, не думаю, что стоит. Если вы хотите решать графовые задачи непременно в РСУБД общего назначения, то это значит, что у вас какая-то очень специфическая задача. Ну вот, например, в оргструктурах не бывает циклов, а это значит, не надо заморачиваться обнаружением этих самых циклов. А если соблюдается принцип единоначалия, то еще и путь между любой парой вершин единственен, а к его поиску можно применить существенные оптимизации.

Из текста осталось неясно:
1. Для чего нарезали ребра графа на половинки?
2. Чем не подошло типичное для такого сорта задач решение на рекурсивных CTE?

Я бы эту задачу решал как-то так: www.db-fiddle.com/f/urNknBbgKFJ6x8B5aJJC7p/4
Вроде проще получается.

GCD — greatest common divisor, наибольший общий делитель (НОД, а не НОК). Простите, но дальше этого момента читать не смог.

Что касается содержания статьи. Вы в первом же совете предлагаете типичные грабли: структурирование файлов по техническим ролям, а не по компонентам. Почему это плохо? Читайте ссылку выше. Но и здравого смысла должно быть достаточно, чтобы увидеть: если вы захотите разобраться, как работают Users, то будете метаться минимум по трем папкам (controllers, models, routes). И так, разумеется, будет с любой компонентой.

По моему опыту, единственный период жизни проект, когда такая структура дает хоть какой-то профит — это когда устаканивается инфраструктура и частно нужно «проходить рубанком» по всем компонентам скопом, внося однотипные правки. Но тут надо понимать, что этот период устаканивания временный (и он тем короче, чем больше опыта), а вот компоненты будут правиться всегда, пока проект жив.

Не могу не оставить это здесь: Node.js Лучшие практики

Вы точно на дату смотрели, прежде чем комментировать?

Спасибо. А то я уже начал переживать, каким образом MSSQL придумал выполнить второй запрос эффективнее первого на таких исходных данных.

То, что планы получились одинаковыми — так в идеале и должно быть, поскольку запросы семантически эквивалентные. Но в жизни это происходит, к сожалению, не всегда, особенно с запросами похитрее. Огорчает и то, что третий вариант не всегда доступен, например, когда платформа, под которую пишется запрос, берет на себя сортировку и пагинацию, а программисту дает только базовый запрос написать. Мы с этим наелись в Oracle Application Express в свое время.

DDL и тексты запросов покажете? Хочу планы запросов посмотреть, для общего развития.

Да на каждом шагу. Самое типичное — join десятка таблиц + order by.
www.db-fiddle.com/f/uSjTZ1u5zFZKqBjwLesi6c/1
Запрос #1 в пять раз быстрее #2. Если посмотреть в планы запросов, то понятно, что это еще не предел, с ростом данных и числа join-ов разрыв будет расти.

Понято, что конкретно в данном случае запрос #2 можно переписать в запрос #3. Но, во-первых, на практике вы не всегда будете иметь возможность протащить (order by + limit) вглубь запроса. А во-вторых, план запроса #3 ничем не лучше плана #1. Вот конкретно в данном случае выполняется за сопоставимое время, но все же чуть дольше, чем #1.

Можно пенять, что, мол, планировщик глуповат у PG. Не принимается :) У Оракла та же история. Про современный MS SQL ничего не могу сказать, т.к. не работал с ним уже лет 10.

Это смотря какой запрос. Если аналитический, для отчета на мильён строк — да, не надо. А если тащим десяток записей для веб-странички с пагианцией — уже не так однозначно, какой вариант будет эффективней работать.

Обновить файл в кэше из кода Service Worker'а элементарно. Единственное, Service Worker должен как-то понять, что обновление необходимо.
Если делать это, как выше предложено (менять адрес файла), то можно даже старую версию файла из кэша удалить, чтобы место зря на устройстве не занимать.
В общем, для всяких хитрых случаев, когда стандартного кэширования не хватает, вполне можно этот процесс под свой контроль взять.

Все остальные их действия просто кричат о том насколько мало там профессионалов.

Мне кажется, Вы здесь совершаете логическую ошибку. Если Вы обладаете информацией о провалах спецслужб, то вполне можете оценить, насколько много там непрофессионалов. Но сколько там профессионалов (тех, кто не прокалывается) — по общедоступной информации не можете никак.

Вы уверены? К слову, в гите текст этой функции другой, и он больше походит на правду.

func xnor(v, s bool) bool {
// и тут костыль
    return !(v || s) && !(v && s)
}

А затестить костылик не забыли случаем? xnor(1,1) возвращает неверный результат.

Да, это быстро, но на физическом уровне создается новая версия строки а не перезаписывается существующая, т.е. мы получаем полную копию всего jsonb (с заменой одного поля), в то время, как в EAV — только копию строки, содержащей измененное значение. Как интенсивные обновления больших jsonb повлияют на размер WAL и TOAST-таблиц, на поведение VACUUM — вопрос, который я бы игнорировать поостерегся.

Хотя с основным посылом я согласен — jsonb во многих случаях выглядит предпочтительнее, чем EAV. Указываю только на то, что в общем случае нагрузка на БД не сводится к одним только select-ам.

-- JSONB
UPDATE entity_jsonb
SET properties = jsonb_set(properties, '{"color"}', '"blue"')
WHERE id = 120;

Надо иметь ввиду, что значение в колонке properties заменяется целиком. Теперь представим, что JSON-ы, которые мы храним, достаточно большие. И если типичная нагрузка — это частые обновления отдельно взятых полей JSON-а, то EAV может оказаться и на голову эффективнее.

В общем, в статье незаслуженно обойден вопрос о производительности записи и влиянии на WAL.

Я тоже поначалу отнесся скептически, но потом сходил по ссылке на оригинал. Там не столько про REST на примере oracle, сколько про node-oracledb на примере REST. И мне показалось, что эта серия статей — неплохая вводная к документации. Во всяком случае, хотя уже давно с node-oracledb работаю, углядел в статьях пару фишек, которые прошли мимо меня при чтении документации.

Ну можно перебором, наверняка есть что-то умное

Да даже без умного, совсем по-простому можно: https://jsbin.com/cozakeyude/1/edit?js,console

И еще: даже в отсортированном списке поиск по-прежнему линейный. Потому что если вы на любом шаге поиска можете прыгнуть сразу в желаемое место, то это уже не список, а какая-то другая структура данных. Например, дерево или массив. Но там вставка элемента в середину — отнюдь не такая тривиальная операция, как в списке.

Вы не учитываете, что это надо делать на каждом шаге, т.е. время не logN, а N*logN.

Оверкилл, говорите? Ваше решение будет медленнее и не лучше по расходу памяти, чем у DrPass — ему нужно получить разрешение иметь всего один бит в каждом элементе списка под свои нужды (позволят ли это условия задачи — другой вопрос), а вам — целый указатель в отдельной структуре, которую надо еще поддерживать в отсортированном виде и в которой совершать поиск на каждом шаге обхода списка.

1. Кому-то сложная, кому-то нет. Решать ее можно по-разному и ход мысли в процессе решения позволит что-то узнать о способностях кандидата. Но я согласен с автором — решение этой задачи мало что покажет об уровне владения языком, если это не С/С++.
2. Тут вы и по времени, и по дополнительной памяти имеете линейную сложность, а в статье время линейное, а доп.память — константа. Так что новую статью, наверное, нет смысла делать.

То, что вы придумали — это еще хороший алгоритм. Кандидат запросто может предложить линейную память и квадратичное время: хранить список указателей на пройденные вершины и на каждом шаге проверять текущую вершину на вхождение в список.

Как работает µWebSockets не скажу, не пробовал его. А в стандартных стримах повторная отправка не нужна. Если write() вернул false, отправку рекомендуют приостанавливать до события drain. Но даже если проигнорировать рекомендацию и продолжить слать данные — они в конце концов будут отправлены, ничего не потеряется. Правда, в этом случае nodejs начнет кушать память под буферизацию и памяти может в итоге не хватить…

Поэтому я люблю метод pipe() у стримов — если возникает backpressure во writable стриме, pipe() автоматически поставит на паузу readable стрим до события drain. Т.е. с pipe() в норме буферы не могут съесть памяти больше некоторой константы.
Правда, это полностью верно только для стандартных стримов. Если самому создать класс с интерфейсом Readable Stream и не позаботиться, чтобы у него pipe() работал корректно, то на жор памяти нарваться очень легко.

В стандартных стримах ноды нужно дожидаться события drain nodejs.org/api/stream.html#stream_event_drain. Здесь, если я правильно понимаю, для той же цели есть unetworking.github.io/uWebSockets.js/generated/interfaces/websocketbehavior.html#drain

Чтобы гарантировать правильность сколько-нибудь сложной программы, ее нужно писать одновременно с доказательством. Доказать _уже_ написанную (без оглядки на способ доказательства) программу на языке общего назначения (скажем, Java), как правило, нереально.

async function parallel(m){return await Promise.all(m)};

А какой смысл в этой функции? Скрыть из кода упоминание Promise? Но асинхронная функция всегда возвращает обещание, поэтому было бы достаточно написать так:

function parallel(m){return Promise.all(m)};

Эффект тот же, но работать будет быстрее, так как не создает совершенно лишнее по смыслу обещание-обертку, которое разрешается после разрешения обещания Promise.all(). Проверял только на NodeJS v8.11.3, возможно, когда-нибудь оптимизатор и такие вещи научится упрощать.

Но на мой взгляд, гораздо лучше вызывать Promise.all() напрямую, без оберток. В любом сколько-нибудь реальном применении async/await все равно придется разбираться с обещаниями, так что скрывать их из кода нет смысла.

Например, как-то искал модуль для nodejs, реализующий файловое хранилище в локальной файловой системе. Функция была на тот момент второстепенной для проекта, надо было уметь «всего лишь» сохранять и извлекать файлы по id, поэтому не хотелось тащить монстров типа Jackrabbit. Все, что нашел, было или заброшено, или сыро, или годно только на совсем игрушечные объемы данных.
В итоге хранилище весьма шустро «завелосипедили». Всё отлично, всё работает. Но со временем в системе появлялось все больше модулей, которые используют хранилище для своих нужд, соответственно, требования к его функциональности возросли. Самые неприятные, с точки зрения усилий по реализации, касались конкурентного доступа к файлам и задач текущего обслуживания хранилища.

Очень похоже, что интеграция со специализированным хранилищем обошлась бы дешевле велосипеда. Собственно, в чем тут архитектурный просчет: на тот момент в используемом стеке технологий на стороне сервера приложений была только nodejs, и хотелось обойтись без добавления всяких tomcat'ов только ради «второстепенной» задачи. Стремились как раз таки сэкономить. Просчет не смертельный, но все же просчет.

Если готовое решение не поддерживается, не особо развивается и не особо известно, то его скорее всего вообще лучше обойти стороной.

Не раз сталкивался с тем, что если все найденные готовые решения вот такие, то это значит, что я, как и авторы этих решений, где-то просчитался в архитектуре.

Думаю, русские математики часто пишут не хуже… только почему-то мало подобного можно прочесть в оригинале на русском. Обидно.

На эту тему Непейвода интересно в свое время писал.

nepejvoda-n-n.livejournal.com/tag/%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%20%D0%A7%D0%B5%D0%B9%D1%82%D0%B8%D0%BD%D0%B0

Достаточно запоминать последнее успешное завершение запроса в серии однотипных запросов, чтобы суметь проигнорировать «опоздавшие» результаты:
jsfiddle.net/fvau6s51/13

Обновления самой Ноды изредка ломают обратную совместимость (в основном, отрубанием устаревших функций, для которых значительное время существует альтернатива), но это обычно легко отслеживается и правится, когда речь идет только о js-коде.

А вот API для подключения расширений к Ноде на других языках несколько раз кардинально менялось. И если использовать модуль, написанный, скажем, на C++, который уже давно никем не сопровождается, то, чтобы его оживить, понадобится квалификация, скажем так, сильно отличающаяся от квалификации javascript-программиста.

На код можно взглянуть, с помощью которого сделан замер?

Не понял, какой смысл несет предикат f? Для assert'а же достаточно простого Tb — Ta < X. Или даже Tab < X, если в программе уже имеется вычисленная длительность интервала.

Да, слишком замороченный пример я выбрал. Вот другой, более программистский: assert'ы — утверждения, которые должны быть истинны в заданных точках выполнения программы. Часто эти утверждения зависят от истории вычислений. Например, мы хотим сказать, что между точкой А и точкой Б должно пройти не больше X мс. Тут нас не интересует дата-время, а только длительность интервала времени от А до Б. Это тоже формализация понятия о времени, но другая. Все, что я хотел сказать: универсальной формализации нет, она всегда зависит от задачи, когда попроще, когда посложнее.

Время, как дополнительная координата — это только один из вариантов. Есть задачи, где время надо понимать сложнее. Например, если нам требуется выразить, что с течением времени наши знания растут (т.е. мы допускаем незнание об истинности некоторых утверждений, но однажды обретенное знание — не меняется и не теряется) и мы хотим понять, какими эти знания могут стать (или могли быть), а какими — нет. Вот тут и появляются модели Крипке.
А про неразрешимость я вроде бы ничего не говорил, только про зависимость решения от задачи.

Конечно.

Тем, что классическая логика хорошо подходит только для описания положения дел в статике. Например, «эта машина — красная» (Цвет(Красный, Машина), тут я намеренно упрощаю, автор берет примеры, где аргументами являются не конкретные объекты, а множества) хорошо формулируется, если подразумевается конкретный момент времени. Если хочется в пределах одной теории говорить о разных моментах времени, то внезапно оказывается, что утверждение, истинное вчера, становится ложным сегодня. И приходится придумывать костыли, например, во все предикаты добавить дополнительный аргумент Т (Цвет(Красный, Машина, 27.03.2018) или, как у автора — не момент времени, а интервал).
А это, в свою очередь, приводит к куче трудностей: множество, которому принадлежит Т — оно какую мощность имеет? Как эти элементы соотносятся между собой? Как описать «поведение» предикатов и функций с течением времени, если оно имеет какие-то известные закономерности?

Т.е. не то чтобы на эти вопросы нельзя ответить, просто универсального ответа нет, и формализация времени, если уж уж в качестве формализма взята классическая логика, всегда делается под конкретную задачу.

Насколько я могу понять, автор и пытается с этими трудностями разобраться. Но как-то не с того конца…