• Неполнота науки: как жил и что доказал Курт Гёдель?
    0
    Если я правильно понял теорему о неполноте, мы, находясь внутри данной системы, не сможем ответить на эти фундаментальные вопросы вообще, т.к. эти параметры определяют саму систему и нас в том числе.

    Строго говоря, нет.
    Во-первых, эта теорема не касается ненаучных методов познания (религия, искусство).
    Во-вторых, она утверждает, что всегда найдутся какие-то вопросы, на которые мы не можем ответить, но не утверждает, что все интересующие нас вопросы останутся без ответа.
  • Почему программисты добавляют новые функции, но не убирают лишние?
    +1
    «Чтобы продать что-нибудь ненужное, нужно сначала купить что-нибудь ненужное» (с) кот Матроскин.

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

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

    Однако, спустя годы, когда я уже ушел с этого направления, общался с одним из бывших коллег на эту тему. Вот что он мне сказал: «когда ты ушел, наши просьбы что-то добавить стали выполняться легко и непринужденно, но теперь система превратилась в монстра». Это стало реальной проблемой. Дошло до того, что самый монстроидальный модуль переписали заново, вырезав все, что только можно.
  • Модуль для работы с sqlite3
    +1
    Каждая конкатенация приводит к созданию нового инстанса строки, что реализуется копированием всей существующей строки с добавлением новой части. То есть в худшем случае имеем нотацию O(N^2)

    Вот тут вы заблуждаетесь, большие строки js-движки при конкатенации не копируют. ru.stackoverflow.com/questions/694846/string-stringbuilder
  • Этюд по реализации ориентированного графа с единичными ребрами, используя PL/pgSQL
    0
    Если мы все еще говорим об оргструктуре, то это какая-то немыслимая для меня постановка. Можете привести пример из жизни, где такое может пригодиться?

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

    И хотя можно, не думаю, что стоит. Если вы хотите решать графовые задачи непременно в РСУБД общего назначения, то это значит, что у вас какая-то очень специфическая задача. Ну вот, например, в оргструктурах не бывает циклов, а это значит, не надо заморачиваться обнаружением этих самых циклов. А если соблюдается принцип единоначалия, то еще и путь между любой парой вершин единственен, а к его поиску можно применить существенные оптимизации.
  • Этюд по реализации ориентированного графа с единичными ребрами, используя PL/pgSQL
    +2
    Из текста осталось неясно:
    1. Для чего нарезали ребра графа на половинки?
    2. Чем не подошло типичное для такого сорта задач решение на рекурсивных CTE?

    Я бы эту задачу решал как-то так: www.db-fiddle.com/f/urNknBbgKFJ6x8B5aJJC7p/4
    Вроде проще получается.
  • Теоретические структуры данных и их применение в JavaScript. Ч1. Пары
    0
    GCD — greatest common divisor, наибольший общий делитель (НОД, а не НОК). Простите, но дальше этого момента читать не смог.
  • Как улучшить ваш API сервис на node.js. Часть 1
    +3
    Что касается содержания статьи. Вы в первом же совете предлагаете типичные грабли: структурирование файлов по техническим ролям, а не по компонентам. Почему это плохо? Читайте ссылку выше. Но и здравого смысла должно быть достаточно, чтобы увидеть: если вы захотите разобраться, как работают Users, то будете метаться минимум по трем папкам (controllers, models, routes). И так, разумеется, будет с любой компонентой.

    По моему опыту, единственный период жизни проект, когда такая структура дает хоть какой-то профит — это когда устаканивается инфраструктура и частно нужно «проходить рубанком» по всем компонентам скопом, внося однотипные правки. Но тут надо понимать, что этот период устаканивания временный (и он тем короче, чем больше опыта), а вот компоненты будут правиться всегда, пока проект жив.
  • Как улучшить ваш API сервис на node.js. Часть 1
    +3
    Не могу не оставить это здесь: Node.js Лучшие практики
  • Решение проблем неправильного использования памяти в Node.js
    0
    Вы точно на дату смотрели, прежде чем комментировать?
  • Стандарты проектирования баз данных
    0
    Спасибо. А то я уже начал переживать, каким образом MSSQL придумал выполнить второй запрос эффективнее первого на таких исходных данных.

    То, что планы получились одинаковыми — так в идеале и должно быть, поскольку запросы семантически эквивалентные. Но в жизни это происходит, к сожалению, не всегда, особенно с запросами похитрее. Огорчает и то, что третий вариант не всегда доступен, например, когда платформа, под которую пишется запрос, берет на себя сортировку и пагинацию, а программисту дает только базовый запрос написать. Мы с этим наелись в Oracle Application Express в свое время.
  • Стандарты проектирования баз данных
    0
    DDL и тексты запросов покажете? Хочу планы запросов посмотреть, для общего развития.
  • Стандарты проектирования баз данных
    0
    Да на каждом шагу. Самое типичное — 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.
  • Стандарты проектирования баз данных
    0
    Это смотря какой запрос. Если аналитический, для отчета на мильён строк — да, не надо. А если тащим десяток записей для веб-странички с пагианцией — уже не так однозначно, какой вариант будет эффективней работать.
  • Всё, что нужно знать о Progressive Web App (PWA)
    0
    Обновить файл в кэше из кода Service Worker'а элементарно. Единственное, Service Worker должен как-то понять, что обновление необходимо.
    Если делать это, как выше предложено (менять адрес файла), то можно даже старую версию файла из кэша удалить, чтобы место зря на устройстве не занимать.
    В общем, для всяких хитрых случаев, когда стандартного кэширования не хватает, вполне можно этот процесс под свой контроль взять.
  • «Троянский конь»: Дуров снова призвал пользователей удалить WhatsApp
    +2
    Все остальные их действия просто кричат о том насколько мало там профессионалов.

    Мне кажется, Вы здесь совершаете логическую ошибку. Если Вы обладаете информацией о провалах спецслужб, то вполне можете оценить, насколько много там непрофессионалов. Но сколько там профессионалов (тех, кто не прокалывается) — по общедоступной информации не можете никак.
  • Архитектура компьютерных систем 1 часть. Логические вентили
    +1
    Вы уверены? К слову, в гите текст этой функции другой, и он больше походит на правду.
  • Архитектура компьютерных систем 1 часть. Логические вентили
    0
    func xnor(v, s bool) bool {
    // и тут костыль
        return !(v || s) && !(v && s)
    }

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

    Хотя с основным посылом я согласен — jsonb во многих случаях выглядит предпочтительнее, чем EAV. Указываю только на то, что в общем случае нагрузка на БД не сводится к одним только select-ам.
  • Замена EAV на JSONB в PostgreSQL
    +3
    -- JSONB
    UPDATE entity_jsonb
    SET properties = jsonb_set(properties, '{"color"}', '"blue"')
    WHERE id = 120;

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

    В общем, в статье незаслуженно обойден вопрос о производительности записи и влиянии на WAL.
  • Создание REST API с Node.js и базой данных Oracle
    0
    Я тоже поначалу отнесся скептически, но потом сходил по ссылке на оригинал. Там не столько про REST на примере oracle, сколько про node-oracledb на примере REST. И мне показалось, что эта серия статей — неплохая вводная к документации. Во всяком случае, хотя уже давно с node-oracledb работаю, углядел в статьях пару фишек, которые прошли мимо меня при чтении документации.
  • Генетические алгоритмы (или Клиент всегда король — и часто дурак)
    +1
    Ну можно перебором, наверняка есть что-то умное

    Да даже без умного, совсем по-простому можно: https://jsbin.com/cozakeyude/1/edit?js,console
  • Почему на собеседованиях так часто спрашивают про связные списки
    0
    И еще: даже в отсортированном списке поиск по-прежнему линейный. Потому что если вы на любом шаге поиска можете прыгнуть сразу в желаемое место, то это уже не список, а какая-то другая структура данных. Например, дерево или массив. Но там вставка элемента в середину — отнюдь не такая тривиальная операция, как в списке.
  • Почему на собеседованиях так часто спрашивают про связные списки
    0
    Вы не учитываете, что это надо делать на каждом шаге, т.е. время не logN, а N*logN.
  • Почему на собеседованиях так часто спрашивают про связные списки
    +3
    Оверкилл, говорите? Ваше решение будет медленнее и не лучше по расходу памяти, чем у DrPass — ему нужно получить разрешение иметь всего один бит в каждом элементе списка под свои нужды (позволят ли это условия задачи — другой вопрос), а вам — целый указатель в отдельной структуре, которую надо еще поддерживать в отсортированном виде и в которой совершать поиск на каждом шаге обхода списка.
  • Почему на собеседованиях так часто спрашивают про связные списки
    +1
    1. Кому-то сложная, кому-то нет. Решать ее можно по-разному и ход мысли в процессе решения позволит что-то узнать о способностях кандидата. Но я согласен с автором — решение этой задачи мало что покажет об уровне владения языком, если это не С/С++.
    2. Тут вы и по времени, и по дополнительной памяти имеете линейную сложность, а в статье время линейное, а доп.память — константа. Так что новую статью, наверное, нет смысла делать.

    То, что вы придумали — это еще хороший алгоритм. Кандидат запросто может предложить линейную память и квадратичное время: хранить список указателей на пройденные вершины и на каждом шаге проверять текущую вершину на вхождение в список.
  • Всегда ли Node.js будет медленнее, чем Golang?
    +1
    Как работает µWebSockets не скажу, не пробовал его. А в стандартных стримах повторная отправка не нужна. Если write() вернул false, отправку рекомендуют приостанавливать до события drain. Но даже если проигнорировать рекомендацию и продолжить слать данные — они в конце концов будут отправлены, ничего не потеряется. Правда, в этом случае nodejs начнет кушать память под буферизацию и памяти может в итоге не хватить…

    Поэтому я люблю метод pipe() у стримов — если возникает backpressure во writable стриме, pipe() автоматически поставит на паузу readable стрим до события drain. Т.е. с pipe() в норме буферы не могут съесть памяти больше некоторой константы.
    Правда, это полностью верно только для стандартных стримов. Если самому создать класс с интерфейсом Readable Stream и не позаботиться, чтобы у него pipe() работал корректно, то на жор памяти нарваться очень легко.
  • Всегда ли Node.js будет медленнее, чем Golang?
    0
    В стандартных стримах ноды нужно дожидаться события drain nodejs.org/api/stream.html#stream_event_drain. Здесь, если я правильно понимаю, для той же цели есть unetworking.github.io/uWebSockets.js/generated/interfaces/websocketbehavior.html#drain
  • Что такое логическое программирование и зачем оно нам нужно
    0
    Чтобы гарантировать правильность сколько-нибудь сложной программы, ее нужно писать одновременно с доказательством. Доказать _уже_ написанную (без оглядки на способ доказательства) программу на языке общего назначения (скажем, Java), как правило, нереально.
  • Осваиваем async/await на реальном примере
    +1
    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 все равно придется разбираться с обещаниями, так что скрывать их из кода нет смысла.
  • Велосипедофобия
    0
    Например, как-то искал модуль для nodejs, реализующий файловое хранилище в локальной файловой системе. Функция была на тот момент второстепенной для проекта, надо было уметь «всего лишь» сохранять и извлекать файлы по id, поэтому не хотелось тащить монстров типа Jackrabbit. Все, что нашел, было или заброшено, или сыро, или годно только на совсем игрушечные объемы данных.
    В итоге хранилище весьма шустро «завелосипедили». Всё отлично, всё работает. Но со временем в системе появлялось все больше модулей, которые используют хранилище для своих нужд, соответственно, требования к его функциональности возросли. Самые неприятные, с точки зрения усилий по реализации, касались конкурентного доступа к файлам и задач текущего обслуживания хранилища.

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

    Не раз сталкивался с тем, что если все найденные готовые решения вот такие, то это значит, что я, как и авторы этих решений, где-то просчитался в архитектуре.
  • Колмогоровская сложность и наши поиски смысла
    +1
    Думаю, русские математики часто пишут не хуже… только почему-то мало подобного можно прочесть в оригинале на русском. Обидно.


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

    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
  • Как сделать поиск пользователей по GitHub без React + RxJS 6 + Recompose
    0
    Достаточно запоминать последнее успешное завершение запроса в серии однотипных запросов, чтобы суметь проигнорировать «опоздавшие» результаты:
    jsfiddle.net/fvau6s51/13
  • К вопросу производительности старых и новых версий ноды
    0
    Обновления самой Ноды изредка ломают обратную совместимость (в основном, отрубанием устаревших функций, для которых значительное время существует альтернатива), но это обычно легко отслеживается и правится, когда речь идет только о js-коде.

    А вот API для подключения расширений к Ноде на других языках несколько раз кардинально менялось. И если использовать модуль, написанный, скажем, на C++, который уже давно никем не сопровождается, то, чтобы его оживить, понадобится квалификация, скажем так, сильно отличающаяся от квалификации javascript-программиста.
  • ES6: полезные советы и неочевидные приёмы
    +4
    На код можно взглянуть, с помощью которого сделан замер?
  • Как мы моделируем предметную область в предикатах второго порядка и не замечаем этого
    0
    Не понял, какой смысл несет предикат f? Для assert'а же достаточно простого Tb — Ta < X. Или даже Tab < X, если в программе уже имеется вычисленная длительность интервала.
  • Как мы моделируем предметную область в предикатах второго порядка и не замечаем этого
    0
    Да, слишком замороченный пример я выбрал. Вот другой, более программистский: assert'ы — утверждения, которые должны быть истинны в заданных точках выполнения программы. Часто эти утверждения зависят от истории вычислений. Например, мы хотим сказать, что между точкой А и точкой Б должно пройти не больше X мс. Тут нас не интересует дата-время, а только длительность интервала времени от А до Б. Это тоже формализация понятия о времени, но другая. Все, что я хотел сказать: универсальной формализации нет, она всегда зависит от задачи, когда попроще, когда посложнее.
  • Как мы моделируем предметную область в предикатах второго порядка и не замечаем этого
    0
    Время, как дополнительная координата — это только один из вариантов. Есть задачи, где время надо понимать сложнее. Например, если нам требуется выразить, что с течением времени наши знания растут (т.е. мы допускаем незнание об истинности некоторых утверждений, но однажды обретенное знание — не меняется и не теряется) и мы хотим понять, какими эти знания могут стать (или могли быть), а какими — нет. Вот тут и появляются модели Крипке.
    А про неразрешимость я вроде бы ничего не говорил, только про зависимость решения от задачи.
  • Как мы моделируем предметную область в предикатах второго порядка и не замечаем этого
    0
    Конечно.
  • Как мы моделируем предметную область в предикатах второго порядка и не замечаем этого
    +1
    Тем, что классическая логика хорошо подходит только для описания положения дел в статике. Например, «эта машина — красная» (Цвет(Красный, Машина), тут я намеренно упрощаю, автор берет примеры, где аргументами являются не конкретные объекты, а множества) хорошо формулируется, если подразумевается конкретный момент времени. Если хочется в пределах одной теории говорить о разных моментах времени, то внезапно оказывается, что утверждение, истинное вчера, становится ложным сегодня. И приходится придумывать костыли, например, во все предикаты добавить дополнительный аргумент Т (Цвет(Красный, Машина, 27.03.2018) или, как у автора — не момент времени, а интервал).
    А это, в свою очередь, приводит к куче трудностей: множество, которому принадлежит Т — оно какую мощность имеет? Как эти элементы соотносятся между собой? Как описать «поведение» предикатов и функций с течением времени, если оно имеет какие-то известные закономерности?

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

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