Технически, конечно, компиляция (или интерпретация). Компьютеры пока не научились джаваскрипт исполнять непосредственно, поэтому, совсем без компиляции/интерпретации не обойтись, очевидно :)
Я имел ввиду компиляцию джаваскрипта перед запуском на Node.
На мой взгляд, гибкий процесс разработки сам по себе хорош.
Проблемы с ним возникают из-за плохого внедрения.
В методологии есть приемы и техники для каждой роли, и каждый из них дает полномочия и рычаги одной роли, и накладывает обязательства на другую.
Например, ежедневные митинги высоко котируются заказчиком, поскольку дают ему больше осведомленности о процессе, и накладывают обязательства на разработчика по поддержанию определенной скорости разработки и графика работы.
Другой пример: фиксированный объем спринта дает больше свободы разработчикам (они могут работать в более свободном темпе, например, растянуть задачи равномерно на спринт, или напрячься, но освободить день или два), и накладывает ограничения на стейкхолдеров и владельца продукта (вынуждая их подавлять позывы "АААА ПРОСТОЙ РЕСУРСА!!!!!1").
В принципе, любая часть методологии так или иначе "выгодна" одной из ролей, и "невыгодна" другой. ("Выгодна" в кавычках, поскольку цель у команды одна, и выгода одна тоже, но количество усилий и действий может сильно различаться в зависимости от внедренных частей аджайла).
Так вот, к чему я веду: чтобы аджайл внедрился успешно, нужен баланс обязательств и привилегий. Однако, на практике в 90% случаев есть перекос, и угадайте, в чью сторону (посильнее нагрузить разработчиков, и дать побольше инструментов контроля заказчику). В достижении конечной цели это мешает всем, но с точки зрения морали на проекте страдают сильнее всего исполнители, заказчики же получают иллюзию контроля (Опять же, это именно иллюзия, разработчик при желании сможет выкроить себе нужно количество свободного времени, и проверить факт, что он намеренно затянул разработку, невозможно.).
Хуже того, наиболее важные части, такие как приоритезация бэклога, фиксированные спринты, минимизация регрессии при выборе фич, добавление только фич, которые можно использовать по окончании спринта — это все обычно отбрасывается как "неважное" (не дающее дополнительных рычагов менеджменту). Превращение стенд-апов из инструмента координации и информирования в отчетность и инструмент контроля — из той же серии.
В итоге внедряется особый, галерный "аутсорсинговый" вариант аджайла, который справедливо воспринимается разработчиками как меньшее, конечно, по сравнению с совковым менеджментом, зло, но все же с изрядным скептицизмом.
Я только за аджайл, и считаю его передовой методологией сегодня.
Но прочитав комментарий PkXwmpgN я подумал, может я что-то пропустил, и бывают методологии без выматывающих митингов и нелепых действий?
Проблема, повторюсь, в том, что это логика защиты данных, и решать ее надо на уровне данных (хотя сами вычисления прав доступа станут частью бизнес-логики).
CQRS создан для оптимизации производительности (ну и плюс некоторые задачи на него хорошо ложаться), он не декларирует никак доступ к данным (ну за исключением разделения read/write data model), и ждать от него изящества в работе с данными не стоит, разве что можно добавлять фильтрацию по правам при восстановлении агрегата из набора событий.
Изящного решения этой проблемы нет даже в DDD, есть только более-менее удачные для конкретного проекта.
Удачное решение, как по мне, — это дополнительная модель данных, автоматически включающая секьюрити.
Я делаю так: есть два вида секьюрити: безопасность данных и безопасность операций.
Секьюрити операций сейчас пропустим.
Безопасность данных — это ограничение доступа к "чужим" данным, как на чтение, так и на запись. Реализуется она в виде фильтров данных, либо на стороне базы (row-level security или самопальный велосипед), либо генерацией и применением SQL фильтра (where) ко всем (в том числе update) запросам из сервера приложения. Если используется LINQ, можно такой фильтр генерировать в терминах доменной модели.
Основная проблема — это создать архитектуру данных, которая позволит сохранить баланс между избыточностью (денормализацией данных) и производительностью таких секьюрити-фильтров.
Отвечая более конкретно на ваш вопрос — если запись и чтение происходят в два источника, то логику придется дублировать, другой вопрос, что можно дублирование минимизировать, используя похожую структуру данных в read model и master data, интерфейсы и полиморфизм и т.п. Ну и конечно, надо отделить вычисление прав пользователя от преобразования набора прав в конкретный фильтр для сущности.
Спасибо за подробное описание. За годы работы выработал в себе интуитивное правило, которое только сейчас осознал: все библиотеки отстой, и чем четче граница между ними и бизнес-кодом с данными, тем лучше.
Основная идея Реакта — это быстрое обновление представления по новым (независимым от существующих) данным. В идеале — берем данные, рендерим вью, меняем данные (как угодно), даем вью — получаем оптимальное (ну или хотя бы достаточно быстрое) обновление представления.
Для меня в этой концепции самое привлекательное — это максимальная изоляция состояния и представления друг от друга, и связь между ними по четким, минимальным и контролируемым каналам. Тот же редакс хорош не тем, что он понятный или простой, или удобно ложится на джаваскрипт — он запутанный, особенно с непривычки, требует усвоения новых паттернов, и сложен для выражения в недофункциональном джаваскрипте.
Но при этом всем он вообще не требует вью для своей работы. Он не требует библиотек, наследования, использования своих сервисов или своей реализаций коллекций. И это прекрасно, а вдвойне прекрасно, что их там некуда впихивать (иначе кто-нибудь их туда точно впихнул бы).
Что больше всего раздражало в Нокауте: конвертация и расширение загруженного JSON-a в Observable. Иначе не работали даже примитивные формы редактирования. Это проникновение библиотеки на уровень, где ее не должно быть, и без нее можно обойтись, когда постоянно нужно помнить, что у тебя — данные, а что — модели, и почему же, все-таки, они не могут быть одним и тем же.
Их очень легко оказывается недостаточно для какой-нибудь очередной задачи. С IQueryable таких проблем практически нет.
Таких проблем нет, есть другие — размазанный и дублированный код доступа к данным, который расположен в не предназначенном для него слое, который невозможно протестировать и инкапсулировать, например, в базе, при необходимости.
А в традиционном репозитории шаг влево-шаг вправо от голого CRUD — и привет.
Ну, в общем-то, в этом и смысл репозитория, так-то можно и SQL писать в коде, что, в определенном приближении, равноценно LINQ запросам в бизнес-логике.
Вроде для Студии тоже экспериментировали с ReSharper Server, хз, чем закончилось.
Технически, конечно, компиляция (или интерпретация). Компьютеры пока не научились джаваскрипт исполнять непосредственно, поэтому, совсем без компиляции/интерпретации не обойтись, очевидно :)
Я имел ввиду компиляцию джаваскрипта перед запуском на Node.
Ну в плане возможностей языка, я думаю, из мейнстрима — C# один из лидеров.
По экосистеме и популярности — вы правы.
Да в том-то и дело, что хотелось бы без babel. Он, конечно, крутой, но все-таки отсутствие компиляции круче, чем самая крутая компиляция.
then после catch не правильно, если, конечно, не хотите попасть в оба.
Резолвить по тем же правилам, что и пути в
require. Сделали бы хоть простейшую поддержку в виде трансформации в require/module.exports.На мой взгляд, гибкий процесс разработки сам по себе хорош.
Проблемы с ним возникают из-за плохого внедрения.
В методологии есть приемы и техники для каждой роли, и каждый из них дает полномочия и рычаги одной роли, и накладывает обязательства на другую.
Например, ежедневные митинги высоко котируются заказчиком, поскольку дают ему больше осведомленности о процессе, и накладывают обязательства на разработчика по поддержанию определенной скорости разработки и графика работы.
Другой пример: фиксированный объем спринта дает больше свободы разработчикам (они могут работать в более свободном темпе, например, растянуть задачи равномерно на спринт, или напрячься, но освободить день или два), и накладывает ограничения на стейкхолдеров и владельца продукта (вынуждая их подавлять позывы "АААА ПРОСТОЙ РЕСУРСА!!!!!1").
В принципе, любая часть методологии так или иначе "выгодна" одной из ролей, и "невыгодна" другой. ("Выгодна" в кавычках, поскольку цель у команды одна, и выгода одна тоже, но количество усилий и действий может сильно различаться в зависимости от внедренных частей аджайла).
Так вот, к чему я веду: чтобы аджайл внедрился успешно, нужен баланс обязательств и привилегий. Однако, на практике в 90% случаев есть перекос, и угадайте, в чью сторону (посильнее нагрузить разработчиков, и дать побольше инструментов контроля заказчику). В достижении конечной цели это мешает всем, но с точки зрения морали на проекте страдают сильнее всего исполнители, заказчики же получают иллюзию контроля (Опять же, это именно иллюзия, разработчик при желании сможет выкроить себе нужно количество свободного времени, и проверить факт, что он намеренно затянул разработку, невозможно.).
Хуже того, наиболее важные части, такие как приоритезация бэклога, фиксированные спринты, минимизация регрессии при выборе фич, добавление только фич, которые можно использовать по окончании спринта — это все обычно отбрасывается как "неважное" (не дающее дополнительных рычагов менеджменту). Превращение стенд-апов из инструмента координации и информирования в отчетность и инструмент контроля — из той же серии.
В итоге внедряется особый,
галерный"аутсорсинговый" вариант аджайла, который справедливо воспринимается разработчиками как меньшее, конечно, по сравнению с совковым менеджментом, зло, но все же с изрядным скептицизмом.Немного уточню: митинги и дурацкие ритуалы можно привнести в любую методологию разработки, к сожалению.
Ну это уже проблемы менеджера, а не разработчиков, и уж никак не методологии.
Поддержу.
Особенный случай — это когда инициатива внедрения аджайл исходит от заказчика. Во всех виденных мною случаях это значит daily meeting и все.
Я только за аджайл, и считаю его передовой методологией сегодня.
Но прочитав комментарий PkXwmpgN я подумал, может я что-то пропустил, и бывают методологии без выматывающих митингов и нелепых действий?
Какая по-вашему идеальная методология?
По идее, вот это
функционал Unit Of Work.
Проблема, повторюсь, в том, что это логика защиты данных, и решать ее надо на уровне данных (хотя сами вычисления прав доступа станут частью бизнес-логики).
CQRS создан для оптимизации производительности (ну и плюс некоторые задачи на него хорошо ложаться), он не декларирует никак доступ к данным (ну за исключением разделения read/write data model), и ждать от него изящества в работе с данными не стоит, разве что можно добавлять фильтрацию по правам при восстановлении агрегата из набора событий.
Изящного решения этой проблемы нет даже в DDD, есть только более-менее удачные для конкретного проекта.
Удачное решение, как по мне, — это дополнительная модель данных, автоматически включающая секьюрити.
Я делаю так: есть два вида секьюрити: безопасность данных и безопасность операций.
Секьюрити операций сейчас пропустим.
Безопасность данных — это ограничение доступа к "чужим" данным, как на чтение, так и на запись. Реализуется она в виде фильтров данных, либо на стороне базы (row-level security или самопальный велосипед), либо генерацией и применением SQL фильтра (
where) ко всем (в том числеupdate) запросам из сервера приложения. Если используется LINQ, можно такой фильтр генерировать в терминах доменной модели.Основная проблема — это создать архитектуру данных, которая позволит сохранить баланс между избыточностью (денормализацией данных) и производительностью таких секьюрити-фильтров.
Отвечая более конкретно на ваш вопрос — если запись и чтение происходят в два источника, то логику придется дублировать, другой вопрос, что можно дублирование минимизировать, используя похожую структуру данных в read model и master data, интерфейсы и полиморфизм и т.п. Ну и конечно, надо отделить вычисление прав пользователя от преобразования набора прав в конкретный фильтр для сущности.
Спасибо за подробное описание. За годы работы выработал в себе интуитивное правило, которое только сейчас осознал: все библиотеки отстой, и чем четче граница между ними и бизнес-кодом с данными, тем лучше.
В общем-то, можно добавить, что CQS (разделение чтения и изменения данных) — это крайне полезный паттерн при любой архитектуре.
Основная идея Реакта — это быстрое обновление представления по новым (независимым от существующих) данным. В идеале — берем данные, рендерим вью, меняем данные (как угодно), даем вью — получаем оптимальное (ну или хотя бы достаточно быстрое) обновление представления.
Для меня в этой концепции самое привлекательное — это максимальная изоляция состояния и представления друг от друга, и связь между ними по четким, минимальным и контролируемым каналам. Тот же редакс хорош не тем, что он понятный или простой, или удобно ложится на джаваскрипт — он запутанный, особенно с непривычки, требует усвоения новых паттернов, и сложен для выражения в недофункциональном джаваскрипте.
Но при этом всем он вообще не требует вью для своей работы. Он не требует библиотек, наследования, использования своих сервисов или своей реализаций коллекций. И это прекрасно, а вдвойне прекрасно, что их там некуда впихивать (иначе кто-нибудь их туда точно впихнул бы).
Что больше всего раздражало в Нокауте: конвертация и расширение загруженного JSON-a в Observable. Иначе не работали даже примитивные формы редактирования. Это проникновение библиотеки на уровень, где ее не должно быть, и без нее можно обойтись, когда постоянно нужно помнить, что у тебя — данные, а что — модели, и почему же, все-таки, они не могут быть одним и тем же.
Таких проблем нет, есть другие — размазанный и дублированный код доступа к данным, который расположен в не предназначенном для него слое, который невозможно протестировать и инкапсулировать, например, в базе, при необходимости.
Ну, в общем-то, в этом и смысл репозитория, так-то можно и SQL писать в коде, что, в определенном приближении, равноценно LINQ запросам в бизнес-логике.