• Веб-компоненты вместо React — очередная попытка
    +1
    В стандарте нет проблем с именами — обычно поставляется файл класса (дефолтный экспорт анонимного класса из модуля), а уже импортировать и регистрировать компонент можно под любым именем. Если в репозитариях так не делают — значит сами виноваты. Про svelte — спасибо, не знал что он умеет компилировать в старый JS, это ценно.
  • Прямая передача файлов между устройствами по WebRTC
    0
    Пробовал написать свой коммуникатор на WebRTC, действительно, мобильники не соединяются без TURN-сервера, а есть нужен TURN — то это уже никакой не P2P. Так и забросил проект в недоделанном виде.
  • Как мы Google Security Checkup проходили
    0
    Ужас. Я даже первый этап не прошел, после получения письма о необходимости записать видео на английском — бросил и отказался. Такое впечатление, что дают заработать сторонним консалтерам, которые делают «под ключ». Для стартапов не вариант.
  • Разработчик оценил сложность современных браузеров
    0
    Уже придумано, называется Flutter, который, по слухам, войдет в фуксию. Там отказались от CSS, и встроили стилизацию в разметку (дерево виджетов), плюс добавили декларативщины из React. Интересная штука, но без CSS очень и очень нечитабельно получается, увы.
  • Нейросети. Куда это все движется
    +1
    Вы забыли сортировку мусора на вибро-конвейере :)
  • Как улучшить ваш API сервис на node.js. Часть 1
    0
    Для pet-проекта решил поэкспериментировать с pet-рантаймом :). Очень нравится базовое API, все типизированное, на промисах. На баги не наталкивался, документация правда слабовата, писал им ишью, но начальник ответил, что пока не стабилизировали API, и подробную доку писать не будут. Зато исходники STD на удивление хорошо откомментированы, и дока особо не нужна — по щелчку из редактора проваливаешься в исходники любой либы, хоть сторонней хоть системной, очень удобно (преимущество импорта по URL). Производительность ввода-вывода вроде не выше чем у ноды, но детальных бенчей не делал. Главный вопрос — как будет развиваться экосистема, например, портирование экспресса, и т.д. Ну и понятно, в 21 веке писать на голом JS это моветон, тайпскрипт чудесный язык, хотя и к ноде он легко прикручивается. Я так понял, главная фишка Deno — это единственный портируемый бинарник самого рантайма + финальный бандл твоего приложения, просто 2 файлика, не нужно никаких инсталов, сторонних бандлеров, обновления каталога зависимостей, всей этой нодовской сложности.
    Резюме — продукт отличный, но опаздал лет эдак на 5.
  • Как улучшить ваш API сервис на node.js. Часть 1
    0

    Мой проект на Deno, и тоже ничего )

  • Что делает реактивную систему хорошей?
    0

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


    Вариант elm / flutter это теоретически интересно, но практически похоже дорого в реализации, по сути нужен толстый рантайм, интенсивная сборка мусора, и проч.

  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    0
    Так CTE оно для рекурсии придумано, произвольно обновить часть записей именованного курсора вы все равно не сможете. У меня давно еще была задача расчета плановой себестоимости по дереву BOM с учетом потерь и отходов на чистом SQL. Никакие синтаксические изыски этого тьюринг-полного языка не позволили избежать временных таблиц. Возможно лично я и ошибаюсь, но не от хорошей жизни процедурные расширения добвили во все СУБД.
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    0
    Хранимка + временная таблица, теперь даже в 1С так делают :)
  • Мой ответ тем, кто полагает, что значение TDD преувеличено
    0
    Точно. Но в этом случае мы приходим к классической технологии, по которой тесты пишут не сами разработчики, а специально обученные люди в тесном взаимодействии с аналитиками / заказчиками. У меня очень успешный опыт именно такого разделения — разработчик думает о будущих фичах, тестировщик о качестве существующих фич, и оба получают з/п. Ну и старое правило — одна голова хорошо, а две лучше.
  • Мой ответ тем, кто полагает, что значение TDD преувеличено
    +1
    OK, останемся каждый при своем мнении.
    PS
    Как правильно расшифровывается аббревиатура TDD :)
  • Мой ответ тем, кто полагает, что значение TDD преувеличено
    +4
    Если проверка делается в компайл-тайме, то тесты ненужны, а если в рантайме — привет TDD. Компилятор + статический анализатор (в некоторых языках это два в одном) — это бесплатный и очень быстрый инструмент поиска ошибок (в том числе и логических), и грех таким дешевым инструментом не воспользоваться. Тесты — это дорогой инструмент, требующий соизмеримых с разработкой трудозатрат, поэтому я выбираю компилятор. Возможно, кто-то выберет динамизм + тесты, не знаю.
  • Мой ответ тем, кто полагает, что значение TDD преувеличено
    +1
    Я согласен, но в вашем случае проверка, чтобы на покраску попадали только грунтованные кузова — делается в рантайме, а в моем случае — на стадии компиляции.
  • Мой ответ тем, кто полагает, что значение TDD преувеличено
    +2
    Cогласен, как раз сейчас пишу сложный прототип, и раз в неделю вынужден серьезно переделывать внутреннее API. Поэтому тесты — только интеграционные, в пограничных точках, иначе разработка вместо месяца займет год. А вот когда приходилось вносить точечные изменения в чужой коммерческий продукт — здесь да, и подробное ТЗ, и автотесты, и т.д.
  • Мой ответ тем, кто полагает, что значение TDD преувеличено
    0
    типами можно заменить самые примитивные тесты — тесты функций никаких других функций не вызывающих и на одних и тех же данных возвращающих одно и то же значение.
    Смотря как вы применяете типизацию. Если у вас например цикл производства какого-то агрегата, и операции объединены в цепочку / граф — нужно из каждой операции возвращать свой тип, например «кузов», «кузов грунтованый», «кузов покрашеный», а не просто «полуфабрикат». С такой системой типов можно частично отследить и ошибки композиции функций / операций.
  • Почему Rust лидирует в TechEmpower Framework Benchmark
    0
    или какие синхронизированные методы используются только из одного потока, что-бы «выключить» синхронизацию.
    Пожалуй, раст такое сможет в компайлтайме. Интересна не битва «GC против не-GC», а JIT против AOT. Собственно, зачем этот высокоуровневый байт-код, который нужно джитить, если есть низкоуровневый байт-код (WASM) или вообще натив? Мне кажется что идея виртуальных машин устаревает, и Java и .Net скоро сольют тому же WASI, потому что в нем нет предустановленного GC, система команд, как я понял, довольно близка нативу, а значит компиляторы могут малыми усилиями добавить себе еще один target.
    PS
    Например, TypeScript, компилируемый в WASM, красота жеж, жаль что нету.
  • Почему Rust лидирует в TechEmpower Framework Benchmark
    0
    На самом деле меня во многом Java не устраивает, но это не относится к vm, gc, производительности и возможностям отладки.
    Вообще интересно, когда я делаю бенчи на коленке — C# core оказывается быстрее чем Java, смотришь techempower — а в нем C# вообще довольно низко, и это странно.
    PS
    Я так понимаю, оба формата байт-кода не позволяют проводить глубокую оптимизацию, может поэтому и пилят альтернативу в виде WASI, где в компайл-тайм возможны чудеса.
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    0
    Ну не знаю. Бывает, что сама задача хорошо ложится на ФП, но чаще нужно специальным образом писать чтобы «переиспользовать ссылки на объекты не боясь что их кто-то изменит». В реальной жизни все хуже, я вот недавно делал бенчмарк, на котором Scala умерла, а комментаторы указали, что я выбрал неправильный алгоритм. То есть ФП работает только на правильных алгоритмах :) Я сколько не пробовал — суровая императивщина с указателями на кучу и циклами получалась быстрее всяких итераторов. А вот применительно к БД — подход уже интереснее, потому что в БД накладные расходы на изменение старой записи соизмеримы с накладными расходами на добавление новой. Другими словами, функциональщина в БД обходится дешевле чем в ОС.
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    0
    Остаток как сущность — для меня самого это странно, но в любое странное место нужно хоть раз сходить. У меня предчуствие, что это даст упрощение алгоритмов MRP, ведь и резерв и непокрытую потребность можно представить как разные типы остатков, сейчас как раз пытаюсь что-то подобное смоделировать.

    Функциональная функция (простите за тафталогизм) всегда возврщает новые данные, поэтому ФП так критикуем и непопулярен, ведь аллокации памяти это дорого. А если фунция ничего не возвращает, и не меняет старых данных, то это не функция вообще, а черная дыра :)

    По сути вы просто создаете транзакционный лог. Я бы на вашем месте это скорее блокчейн СУБД, а не функциональной СУБД называл бы. Ведь именно блокчейн это про аудируемость и т.п.
    Именно! Вы совершенно верно схватили суть! На такую схему навернуть блокчейн — пять минут программирования, просто вычислить хэш и положить в дерево Меркла. А вот если у нас есть мутабельный регистр «Остатки», то как его надежно защитить от подделок и ошибок? Никак.
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    0
    1) Теоретически можно менять и в закрытом, но это перезапись большого куска базы, долго и блокирующе. Издержи подхода.

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

    3) Если аналгогичный запрос движений по гравицапе уже был — запись будет в кэше, и ее достаточно актуализировать на новых документах. Если нас интересует нестандартная свертка (какой еще не запрашивали), но без сальдо и по конкретному периоду (например обороты за прошлый год) — индексировать плоский файл по timestamp — плевое дело. Если фильтр не по времени — тогда извините, фуллскан.
    PS
    В целом я не против ни СУБД ни индексов, для прототипа выбрал файл только пожалев свое время, но все же хочется минимизировать мутабельность, то есть неконтролируемая правка любых записей в любой момент. В западных ERP к этому прикладывают специальные усилия, но их недостаточно.
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    0
    NitroJunkie, по поводу вычисления остатков — отвечу развернуто. В ERP нам нужен граф сопоставлений — и для себестоимости, и для планирования. Есть 2 способа организации сопоставлений:
    1) проводка-проводка
    2) проводка-остаток
    Если мы выбираем первый случай, тогда мы можем расчет остатка оформить вычисляемой кэшируемой сверткой, в чисто-функциональном ключе. Я сознательно выбрал второй вариант «проводка — остаток», таким образом остаток нам нужен в системе как самостоятельная сущность, с уникальным ID. Какая может быть функциональщина при организации связей между сущностями?

    Любая функция (даже чистая) возвращает какие-то данные, в моем случае — новый документ типа «баланс», тогда как императивный подход подразумевает изменение старой записи регистра «баланс». Чувствуете разницу? Таким образом моя система намного ближе к принципам ФП, чем упомянутая 1С. Про вашу систему пока ничего определенного сказать не могу, решение с материализацией на лету — довольно сильное, но подходы к хранению данных принципиально другие, значит и никакого спора быть не может.
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    +1
    ФП на уровне документов и бизнес-агрегатов, а в реализации конечно императивка. Если вы пишете например на Scala, у вас функция внешне чистая, но внутри нее вполне допустимы и мутабельные переменные, и циклы, мы же не параноики. В целом согласен, и заголовок и некоторые тезисы статьи немного провокационны, но не более чем у других :)
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    0
    В иммутабельной части невозможно, а в мутабельной — при вставке задним числом — блокируется база, и последовательность документов пересоздается в памяти (удаляются старые баланcы начиная с точки изменения, новые пересоздаются по цепочке). Это если реальная правка задним числом (сторно). Если накладные расходы пришли в середине месяца — они просто дооценят текущие балансы, а старые останутся неизменными. То есть блокировка базы нужна будет далеко не всегда. На моем ноуте обработка миллиона документов в памяти — 0.6 секунды, на сервере время блокировки будет сотые. Конечно, если в вашей ERP открытый период — год, то моя схема вряд-ли подойдет :)
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    0
    Все императивно в триггере. Генерация нового баланса — Приход, Расход, Перемещение. Конечно, в проде нужно писать удобное API, но в прототипе, для целей демонстрации — самое то.
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    0
    Так и есть, потому что у меня балансы создаются каждый раз заново, и материализовывать просто нечего. Это не бага, а фича — история остатков / резервов / потребностей (это все разновидности балансов), прибитая гвоздями иммутабельности, весьма полезна в планировании покрытий и разруливании конфликтов.
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    0
    receivedQuantity 'Суммарный приход' = GROUP SUM quantity(ReceiptDetail d) BY item(d), stock(receipt(d));
    shippedQuantity 'Суммарный расход' = GROUP SUM quantity(ShipmentDetail d) BY item(d), stock(shipment(d));
    currentBalance 'Текущий остаток' (Item i, Stock s) = receivedQuantity (i, s) (-) shippedQuantity (i, s);
    Вы что, каждый раз рассчитываете остаток от рождества христова? Не верю. Значит остаток таки храните, а функциональщину обеспечиваете магическим рантаймом. Я о таком тоже думал, но передумал, ибо у меня хранятся все балансы на любой момент времени, и смысл функционалить тогда.
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    0
    Попробую, но все-таки наверное сначала резервы, потом планирование, и только потом учет. Учет штука более однозначная, в планировании же куча трудно-формализуемых вещей, на чем проекты ERP и ломаются. В планировании откат в прошлое это почти норма, а в учете это стихийное бедствие.
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    0
    Я не волшебник и не могу во все сразу. В проекте лежит скрипт обновления балансов, и триггеры на разноску покупок-продаж, это самое простое. Наверное, следующая статья (если будет) должна описывать управление резервами. А затем — планирование. Потому что с учетом в целом все понятно, не уверен что смогу решать системы линейных уравнений, но итеративно разрешить циклы думаю вполне реально.
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    0
    Блокировка ресурса это надо понимать резервирование сырья? Про резервирование мощностей понятно, в простом случае когда производственные центры взаимозаменяемы, задача по крайней мере формализуется :)
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    0
    Исчерпывающе!
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    –1
    Абсолютно верно, если данные лежат в стиле ООП — каждая сущность в отдельной таблице, связи p2p без ограничений, да еще по сложному ключу — нужен и сложный язык запросов. Преимущества — экономим место за счет нормализации. У меня идея ровно обратная — данные храним строго-упорядоченно, связи только назад и никогда вперед, любая коррекция это новый документ, и т.д. В этом случае нам нужны только простые свертки, оконные функции, и, возможно, вложенные reduce(). Приведите конкретный алгоритм ERP, который вы считаете сложным, я попробую его покрутить у себя.
    PS
    Вы в своем продукте замахнулись на гораздо большее — на универсальную СУБД, у меня задача проще — всего лишь ERP :)
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    0
    В целом соглашусь что бизнес-алгоритмы просты, но всеж бывают ньюансы. Например:
    — Зацикливание графа сопоставлений при наличии возвратных отходов или реклассификации готового продукта в полуфабрикат.
    — Дооценки сырья сильно задним числом (когда продукцию произвели и уже продали).
    — Коррекция потребностей, уже принятых в работу отделом закупок (купили, а это никому не нужно).
    — Коррекция планов производства внутри декады по причине форсмажора.
    — Управление резервами по приоритетам (автоматически снять резерв с менее важного, и отдать более важному).
    Это все может рекурсивно затрагивать старые данные, и наш принцип иммутабельность будет нарушаться. В классических ERP проще — я там могу в старых записях дозаполнить новые поля, а с журналом документов мне придется любую коррекцию чего-нибудь (да хоть резерва) оформлять отдельным документом. Я пока масштаб бедствия до конца не осознал, видимо нужно придумать какой-то радикально-сложный пример, может Andrew-BUSINESS имеет что-то готовое, либо придется самому ползти медленно и постепенно.
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    0
    Спасибо, обращусь за помощью как дойдем до планирования!
    Если раньше не брошу эту неприбыльную затею :)
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    0
    основная проблема в их обновлении при изменении данных от которых они зависят (инкрементальные обновления).
    Если алгоритм оформлен как reduce() то вообще не проблема — появились новые данные, скармливаем редьюсу, и он досчитывает свой аккумулятор. Проблема, если алгоритм не ложится на reduce(), а представляет, например, SQL — тогда инкрементальные обновления это сложно, и нужна СУБД. Самый типичный отчет — сводная таблица, если в агератах функции типа sum(), эта штука легко досчитывается и даже параллелится, а если там count_distinct(), то досчитывается, но не параллелится, и т.д.
    индексы единственное что может спасти.
    Собственно, да, у меня это кэш, кончится тем, что положу его в какой-нибудь Mongo, или даже Postgres. А вот исходные документы скорее останутся в бинарных файлах, так как СУБД отдают курсоры медленней чем файловая система, хотя вроде у оракла своя FS, не тестил.
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    0
    Я согласен, всякие ухищрения со слабыми мьютексами, lock-free каналами частично решают проблему масштабирования многопоточки, в той же лямбде предлагается по сути грязное чтение (устаревшие данные) для быстрой отдачи менее точного результата.

    Под ФП я понимаю (это неканонично) прежде всего работу на потоках иммутабельных исходных данных с помощью ленивых итераторов и их композиции. В терминах ERP — вычисления на потоке первичных документов. Конечно, данные, то есть документы, где-то хранятся, но зная что они неизменные, мы можем много чего оптимизировать. В частности распараллелить свой алгоритм «ручками», а не надеяться на рантайм.

    Конечно, в этом есть доля лукавства, ведь для любой свертки сложнее чем sum() нужен кэш ранее просмотренных документов (к которым вернуться уже невозможно), а кэш это и есть шаред стейт, со всеми вытекающими проблемами. Но пока я не вижу таких алгоритмов ERP, которые нельзя было бы реализовать таким способом. Пересопоставление в текущем периоде — да, это полное пересоздание мутабельной части журнала документов, то есть блокировка базы, что конечно хуже чем блокировка отдельных записей, но надежда в том что размер текущего периода — это миллионы транзакций, а не трилллионы, и вычисления в памяти переваривают это за секунды.
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    0
    Респект, уже :)
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    0
    Если говорить конкретно про масштабирование, то random access ему никак не мешает.
    Конечно мешает. Любой мьютекс на шаред-стейт приводит к ожиданиям потоков, а значит ограничивает параллелизм. Даже теорема есть специальная. Не от хорошей жизни придумали хаскель, где в принципе запрещен стейт, а производительность у него весьма впечатляет, по последним бенчам в блоге PsyHaSTe например.

    Опять же, если вы свои алгоритмы строите на итераторах без мутабельных таблиц — вам намного реже нужны транзакции, тем более распределенные, таким образом еще одно узкое место отпадает.

    PS
    По предыдущей ссылке, респект, прочитал, но вы предлагаете языковое улучшение, а не смену парадигмы, поэтому ваш подход назвать функциональным можно с бОльшей натяжкой, чем мой.
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    0
    Эхх, сразу не понял кто вы :) Давно хотел почитать, но руки не доходили. Обещаю изучить и ответить по существу через день. Пока навскидку лишь могу сказать следующее — SQL предполагает random access к данным, то есть можно табличек накидать как попало, в любой запрос воткнуть join, и очень толстый и умный рантайм (СУБД) все оптимально выполнит. У меня была идея радикальней — чтобы получить результат на чистых итераторах, где нет RA, а максимум back(), нужно:
    a) хранить данные специальным образом
    б) придумать специальный «потоковый» DSL
    в) реализовать продвинутый кэш
    г) партиционирование потока + seek() в виде дополнительной плюшки
    Честно говоря, понятия не имею, жизнеспособен такой подход или нет, наверняка исследования проводились, но я не нашел, на первый взгляд это дает возможность неограниченного масштабирования при сохранении рантайма простым. А значит диапазон применений — от аудита потока ЭСФ в масштабах страны, до рилтайм анализа сетевого трафика.
    PS
    Ушел читать про неочередной язык программирования…
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    0
    Для меня сейчас главное — понять насколько сложным и (не) понятным будет прикладной код для типовых алгоритмов типа расчета себестоимости в производстве или MRP, сколько промежуточных данных придется нагенерить, какие будут связи между этими данными, и т.д. Функциональщина предполагает работу с потоками данных, а SQL манипулирует стейтом, и это совершенно разные подходы.

    Все остальное просто лишняя работа, бинарная сериализация или компиляция в SQL — у меня нет свободных ресурсов чтобы это все писать, поэтому беру самое тупое и простое — цикл по файлу. В реальном продукте конечно это будет сделано по-другому (и не мной), наверняка все должно храниться в РСУБД с индексами, но это имеет смысл делать только тогда, когда имеет смысл делать.