Сборка Angular 2 приложения — это боль и страдания. Продакшн билд приложения с компиляцией шаблонов и использованием ДевЭкстрим занимает… 8.5 минут!!!
Да, можно использовать watch, так что при сохранении изменений сборка будет запускаться автоматически. Но это не решает проблемы. 1. На практике все выглядит так: я ввожу часть кода, сохраняю, запускается сборка, пока она длится, я ввожу следующий код и сохраняю — в результате получается устаревший бандл, без последних правок. Кто-нибудь сталкивался с такой проблемой? Как вы ее решаете?
Постигая дзен двухсекундными ожиданиями после полусекундных правок.
Существует опция вебпака watchOptions.aggregateTimeout и watchOptions.poll, которая теоретические добавляет задержку перед запуском билда после изменений.
У менеджера по продажам — процент с продаж. Если продаж нет, менеджер увольняется сам, т.к. ничего не зарабатывает. Почему их нет — это вопрос, который должен волновать руководителя только применительно к предприятию, не к конкретному менеджеру.
Если окажется, что она круглые сутки обзванивает клиентов — что это поменяет?
Невозможно контролировать реальную загруженность сотрудника, который сам оценивает время выполнения своей работы. Давать задачу на оценку другому сотруднику нет смысла, т.к. затраты времени индивидуальны для каждой задачи.
Контролировать рабочий процесс не имеет смысла, т.к. если человек не хочет работать быстро, он будет работать медленно вне зависимости от того, что он будет фактически делать. Даже в условиях тотального контроля он будет печатать одним пальцем, только еще и будет испытывать раздражение.
Для стандартизируемой работы нет смысла учитывать что-либо, кроме фактической производительности и качества. Обычно для стандартизируемой работы используется некий минимальный требуемый объем плюс оплата за выработку. Это используется в такси, швейке и много где еще. Контролировать занятость не нужно.
Кто-нибудь вообще знает пример, где может помочь учет фактической занятости?
Не совсем в тему микросервисов, но хочу заметить, что слово "бизнес" применительно к архитектуре приложения не имеет (в общем случае) отношения к коммерции, а обозначает ту "пользу", которую приносит конкретное приложение.
Поэтому сервис авторизации для конкретного приложения — это бизнес-функциональность, но в то же время используемая библиотека для OAuth2 — это уже не бизнес-часть, т.к. она универсальна и не привязана к предметной области.
Поэтому суммирование массива — не бизнес-функциональность, если у нас, конечно, не приложение по суммированию массивов (Excel).
Это должно быть заложено на этапе разработки. Просто запустить несколько инстансов, которые указывают на разные базы, не получится, т.к. запросы будут идти на случайный инстанс. Либо "умный" роутинг запросов на лоад балансере, но это, как мне кажется, крайняя и сложная мера.
Если брать полный стейтлесс монолит, то он будет идентичен микросервисам в плане цены масштабирования только при условии, что хранилище данных масштабируется независимо.
Однако нагруженные микросервисы можно вынести на отдельные базы, если они допускают определенную несогласованность данных. Монолит так масштабировать обычно нельзя, т.к. некоторые части должны все-таки работать с согласованным хранилищем.
Плюс (тут я не уверен, чисто как идея) — не будет ли проблем при запуске на одной машине нагрузки разных типов — множества быстрых запросов или маленького количества медленных, либо грузящих диск, или процессор.
Если монолит — полный stateless и содержит в себе только обработчики запросов — то разницы нету.
Если монолит содержит в себе какое-то состояние — явное или неявное (кеши, сессии в памяти, восстановленные CQRS агрегаты ), или поведение — задачи по расписанию и т.п. — то разница есть, и значительная.
О преимуществах микросервисов стоит судить не с точки зрения "модули, которые общаються по хттп вместо in-process call, зачем?", а с точки зрения облачного развертывания. Это скорее набор микро-приложений (а не модулей), которые друг с другом взаимодействуют мало и редко.
Представьте банковские сервисы: сервис курсов валют запрашивают миллион раз в день, сервис свифт-переводов — тысячу раз. В облаке дешевле отмасштабировать только нагруженный сервис — деплой и контейнер дешевые (бесплатные), плюс автомасштабирование от облачного вендора будет дешевле.
Это пример синтетический, потому что аналогичный код на джаваскрипте работает так же, как и тайпскриптовый, и выдает ошибку в том же месте. Если бы джаваскрипт падал там же, где выдает ошибку флоу, тогда можно было бы говорить, что поведение тайпскрипта некорректно.
Флоу пытается изменить сущность джаваскрипта, тайпскрипт — только привнести опциональные аннотации типов. В этом их разница.
Вы, собственно, подтверждаете мои слова: целевая аудитория TypeScript это огромная когорта C# программистов, которым легче принять что-то промежуточное между JavaScript и C#, чем чистый JavaScript сам по себе.
А применимо к контексту это означает, что неплохо было бы размять мозги и принять JavaScript таким, каков он есть, не полагаясь на внешние костыли.
Ага, то-то джаваскрипт обзавелся извращением под названием jsdoc, который, помимо комментирования, еще и пытается добавлять информацию о типах.
Хмм, разве качество — это не бизнес-требование? :)
Сборка Angular 2 приложения — это боль и страдания. Продакшн билд приложения с компиляцией шаблонов и использованием ДевЭкстрим занимает… 8.5 минут!!!
Постигая дзен двухсекундными ожиданиями после полусекундных правок.
Существует опция вебпака watchOptions.aggregateTimeout и watchOptions.poll, которая теоретические добавляет задержку перед запуском билда после изменений.
У менеджера по продажам — процент с продаж. Если продаж нет, менеджер увольняется сам, т.к. ничего не зарабатывает. Почему их нет — это вопрос, который должен волновать руководителя только применительно к предприятию, не к конкретному менеджеру.
Если окажется, что она круглые сутки обзванивает клиентов — что это поменяет?
Невозможно контролировать реальную загруженность сотрудника, который сам оценивает время выполнения своей работы. Давать задачу на оценку другому сотруднику нет смысла, т.к. затраты времени индивидуальны для каждой задачи.
Контролировать рабочий процесс не имеет смысла, т.к. если человек не хочет работать быстро, он будет работать медленно вне зависимости от того, что он будет фактически делать. Даже в условиях тотального контроля он будет печатать одним пальцем, только еще и будет испытывать раздражение.
Для стандартизируемой работы нет смысла учитывать что-либо, кроме фактической производительности и качества. Обычно для стандартизируемой работы используется некий минимальный требуемый объем плюс оплата за выработку. Это используется в такси, швейке и много где еще. Контролировать занятость не нужно.
Кто-нибудь вообще знает пример, где может помочь учет фактической занятости?
Такое впечатление, что микросервисы, по-вашему, — это как dll, только доступные по сети.
Не совсем в тему микросервисов, но хочу заметить, что слово "бизнес" применительно к архитектуре приложения не имеет (в общем случае) отношения к коммерции, а обозначает ту "пользу", которую приносит конкретное приложение.
Поэтому сервис авторизации для конкретного приложения — это бизнес-функциональность, но в то же время используемая библиотека для OAuth2 — это уже не бизнес-часть, т.к. она универсальна и не привязана к предметной области.
Поэтому суммирование массива — не бизнес-функциональность, если у нас, конечно, не приложение по суммированию массивов (Excel).
"Резко" микросервисным не становится. Смотря что крон запускает. Если какую-то часть приложения, то приложение уже не монолит.
Пережатие видео и картинок, загружаемых пользователями, например.
Просто замечание: насчет Флоу не знаю, но тайпскрипт — это не "статическая типизация".
Это должно быть заложено на этапе разработки. Просто запустить несколько инстансов, которые указывают на разные базы, не получится, т.к. запросы будут идти на случайный инстанс. Либо "умный" роутинг запросов на лоад балансере, но это, как мне кажется, крайняя и сложная мера.
Если брать полный стейтлесс монолит, то он будет идентичен микросервисам в плане цены масштабирования только при условии, что хранилище данных масштабируется независимо.
Однако нагруженные микросервисы можно вынести на отдельные базы, если они допускают определенную несогласованность данных. Монолит так масштабировать обычно нельзя, т.к. некоторые части должны все-таки работать с согласованным хранилищем.
Плюс (тут я не уверен, чисто как идея) — не будет ли проблем при запуске на одной машине нагрузки разных типов — множества быстрых запросов или маленького количества медленных, либо грузящих диск, или процессор.
Если монолит — полный stateless и содержит в себе только обработчики запросов — то разницы нету.
Если монолит содержит в себе какое-то состояние — явное или неявное (кеши, сессии в памяти, восстановленные CQRS агрегаты ), или поведение — задачи по расписанию и т.п. — то разница есть, и значительная.
О преимуществах микросервисов стоит судить не с точки зрения "модули, которые общаються по хттп вместо in-process call, зачем?", а с точки зрения облачного развертывания. Это скорее набор микро-приложений (а не модулей), которые друг с другом взаимодействуют мало и редко.
Представьте банковские сервисы: сервис курсов валют запрашивают миллион раз в день, сервис свифт-переводов — тысячу раз. В облаке дешевле отмасштабировать только нагруженный сервис — деплой и контейнер дешевые (бесплатные), плюс автомасштабирование от облачного вендора будет дешевле.
Появились средства контейнеризации, облака — и достали из закромов старый прием и назвали по-новому.
Мы все еще про тайпскрипт говорим? Там тоже
типизацияаннотация типами опциональная. О каком принуждении идет речь?Подозреваю, что вы тайпскрипт не знаете, а думаете, что это нечто типа Java, только компилируется в джаваскрипт.
Это пример синтетический, потому что аналогичный код на джаваскрипте работает так же, как и тайпскриптовый, и выдает ошибку в том же месте. Если бы джаваскрипт падал там же, где выдает ошибку флоу, тогда можно было бы говорить, что поведение тайпскрипта некорректно.
Флоу пытается изменить сущность джаваскрипта, тайпскрипт — только привнести опциональные аннотации типов. В этом их разница.
Ага, то-то джаваскрипт обзавелся извращением под названием jsdoc, который, помимо комментирования, еще и пытается добавлять информацию о типах.
Спасибо. И отдельно — за поддержку Linq2Db.
Ну в тайпскрипте тоже со структурной типизацией и отсутствием номинальной проблем не возникает.