Встречался в практике случай, когда систему, написанную в середине двухтысячных "переписывали" на современный стек. С микросервисами, SPA и т.д. При этом всё API, поведение и даже стили должны были остаться неизменными. За этим следила команда усердных и бесконечно терпеливых QA инженеров из Индии. Они просто сравнивали старое и новое приложения и писали отчёты об ошибках, если их поведение различалось.
Трудно себе представить более демотивирующую программиста деятельность, чем такое "переписывание". Это ведь не исправление — это воспроизведение.
Вот только есть проблема. Обосновать переписывание старого проекта и выделение на это ресурсов перед вышестоящим начальством можно. А вот увеличение расходов, связанное с внешне незаметной внутренней миграцией грозит лишь лишением премий в связи с объективным падением эффективности разработки.
Сравнивать уместно разве что с lerna run. Lerna, конечно же, куда более мощный инструмент.
Так вот, lerna run может работать с деревом зависимостей и запустить скрипт, например, только для зависимостей. Но вот запустить несколько скриптов одновременно, передать в них параметры, и указать какие из них можно выполнять параллельно, а какие — только последовательно в Lerna нельзя. Насколько мне известно.
В общем дело — в тонкой настройке. Которая может сильно ускорить сборку в некоторых случаях.
Очень бы хотелось. Сейчас не могу сказать ничего определённого. Но если продолжу, то многое придётся пересмотреть. Прежде всего — для борьбы с излишней сложностью компилятора. Именно эта сложность и помешала выпустить сколько-нибудь пригодную для работы версию o42a.
Автор может делать со своим кодом что захочет. В том числе и лицензию сменить. Предыдущие же версии так и останутся под старой лицензией — иначе это нарушает права пользователей.
А никак. Если предоставить возможность пользоваться сервисом, не распространяя его как приложение (например, реализовав его в виде веб-приложения), то можно не предоставлять исходный код, не нарушая при этом GPL. Чтобы закрыть эту лазейку и придумали AGPL — «усиленную» версию GPL, покрывающую и этот случай.
Владелец прав на распространение (копирайт) != автор. Если над проектом работает команда, то создаётся компания/команда/группа и копирайт оформляется на неё. А авторы указываются отдельно.
Для проекта open source стоит ещё рассмотреть MPL 2.0. Своеобразная лицензия, что-то среднее между LGPL и BSD. От LGPL отличается отсутствием заморочек со статическим связыванием. Это может оказаться важным для программ на ЯП, в которых динамическое связывание не предусмотрено.
Не знаю про название. Если честно, то для меня такой приём в новинку. Но, наверное, в терминологии Java уместнее говорить о фабрике, а не об указателе на функцию.
Предпочитаю в си-шном коде использовать double-checked locking (с барьерами памяти). Это позволяет модифицировать только само поле, а указатель на функцию не менять. Возможно, так будет чуть быстрее: предсказание переходов лучше сработает.
Зря вы, наверное, акцентировали внимание на «одиночке». Щас апологеты «правильного» кода вас подвергнут обструкции.
Этот приём, вообще-то, прекрасно подходит для более общего случая. А именно для отложенной («ленивой») инициализации полей в многопоточном приложении. И поля эти — не обязательно статические.
Обратите внимание на вызов getClass(). Сама возможность этого вызова означает наличие класса.
В общем, по моему мнению, как бы авторы не пытались запудрить мозги со своим «лямбда — это не классы» на деле — это всё-таки классы. И не избавятся они от этого факта, покуда в JVM не появится отдельная сущность для лямба-функций. Чего не произойдёт никогда. Рад буду ошибиться.
То есть бинарный предикат представляется как пара объект/словарь.
А как планируется представлять предикаты большей арности?
Гибрид. Без
defineProperty
и условных операторов:Встречался в практике случай, когда систему, написанную в середине двухтысячных "переписывали" на современный стек. С микросервисами, SPA и т.д. При этом всё API, поведение и даже стили должны были остаться неизменными. За этим следила команда усердных и бесконечно терпеливых QA инженеров из Индии. Они просто сравнивали старое и новое приложения и писали отчёты об ошибках, если их поведение различалось.
Трудно себе представить более демотивирующую программиста деятельность, чем такое "переписывание". Это ведь не исправление — это воспроизведение.
Вот только есть проблема. Обосновать переписывание старого проекта и выделение на это ресурсов перед вышестоящим начальством можно. А вот увеличение расходов, связанное с внешне незаметной внутренней миграцией грозит лишь лишением премий в связи с объективным падением эффективности разработки.
Ещё бы не брюзжать. Там пасторы басурманские псалмы поют по-ненашему: National Association of Pastoral Musicians
А система самобранная npmjs.com кличется.
А какие форматы логов поддерживает ваша смотрелка? Как насчёт logfmt? JSON? Может, ещё какие-то структурированные логи?
Сравнивать уместно разве что с
lerna run
. Lerna, конечно же, куда более мощный инструмент.Так вот,
lerna run
может работать с деревом зависимостей и запустить скрипт, например, только для зависимостей. Но вот запустить несколько скриптов одновременно, передать в них параметры, и указать какие из них можно выполнять параллельно, а какие — только последовательно в Lerna нельзя. Насколько мне известно.В общем дело — в тонкой настройке. Которая может сильно ускорить сборку в некоторых случаях.
Что-то здесь ничего не написано про аннотации
/*#__PURE__*/
Есть готовый перечень вообще-то.
Предпочитаю в си-шном коде использовать double-checked locking (с барьерами памяти). Это позволяет модифицировать только само поле, а указатель на функцию не менять. Возможно, так будет чуть быстрее: предсказание переходов лучше сработает.
Этот приём, вообще-то, прекрасно подходит для более общего случая. А именно для отложенной («ленивой») инициализации полей в многопоточном приложении. И поля эти — не обязательно статические.
Кстати, в коде тесте у вас ошибка: У класса ByteArrayOutputStream нет конструктора без параметров. Так что он даже не скомпилируется.
В общем, по моему мнению, как бы авторы не пытались запудрить мозги со своим «лямбда — это не классы» на деле — это всё-таки классы. И не избавятся они от этого факта, покуда в JVM не появится отдельная сущность для лямба-функций. Чего не произойдёт никогда. Рад буду ошибиться.