Забавно. Недавно решал ту же проблему, но мой АМД вместо загрузки модулей просто ждёт пока модуль появится (у меня все скрипты грузятся стандартно броузером). То есть точно так же заявляется модуль-прокладка и когда броузер его загрузил, заканчивается иницализация зависимостей.
то есть я не один такой. в итоге я купил себе небольшой, бойкий и недорогой андроид, который использую, как телефон(sic!), твиттер и точку доступа для бОльших братьев если нужно.
лол чо ;) я никогда не буду основываться исключительно на предположениях. я никогда не буду основываться исключительно на предположениях. я никогда не буду основываться исключительно на предположениях.
так стоп. я играю в «возьмём мутно написаный алогритм и сделаем его ещё мутней».
то есть оптимизация здесь совсем в кавычках и о скорости речи нет. только о всё большей нечитаемости кода.
Как они скромно показали форму логина в фб и не показали экранную клавиатуру и попытку залогиниться. Такой размер не применим к обычным приложениям. Это не преимущество а недостаток. «Умные» часы можно делать на андроиде, но идти минималистским путём.
1. В конторе, где я сейчас работаю, следующая схема:
Два билда в TFS:
— Один просто билд+юнит тесты, второй — билд+интеграционные тесты.
— Второй в начале воссоздаёт виртуальную машину из чистого образа, инсталлирует в неё все msi и запускает систему. После этого запускает интеграционные тесты, работающие с реальной БД и прочая. Для совсем внешних зависимостей используется самодельный SoapMock.
Архитектура разбита так, что в юнит тестах Entity не тестируется (её как бы тестирует микрософт), но есть ДБ слой, который эмулируется.
2. Если в контроллерах много бизнес логики — это уже признак того, что возможно не всё чисто. Бизнес логику стоит выносить из контроллера, пусть он занимается только роутингом и сборкой моделей из данных, получаемых из отдельных модулей. Вот как раз эти модули можно легко и просто тестировать без привязки к контексту контроллера. И одтельно, если хочется, можно тогда тестировать сами контроллеры, передавая им эмулированые провайдеры бизнес логики. DI rulez.
то есть когда один апп сервер вносит новые данные, транзакция заканчивается и после они отправляются в бекап и уже оттуда синхронизируются в другие серверы? то есть ACID не будет?
То есть (is) теперь (now) рейтинг статьи (article) намного лучше (better)?
Но если статья перевод вчерашней на смишную (то есть смысл тот же), то у меня вопрос: а как происходит синхронизация данных между модулями (partitions)? То есть если всё в памяти и периодически синхронизируется в бэкенд (backend) то как обеспечивается что у всех модулей одни и те же данные?
В случае с магазином, это не критично, но допустим, сиистема обслуживает некую ММОРПГ и нужно, чтоб любые два игрока, оказавшись в одном контексте, видели одно и то же и всё время а не иногда.
*Это я вслух думаю. Конечного идеального решения у меня в голове пока нет*
При том, что сам сталкивался с этой проблемой, мне кажется эти библиотеки решают не ту проблему.
Кмк, проблема не в том, как передать в яваскрипт аякс-урл а в том, что яваскрипт воспринимается, как небольшое дополнение к серверной бизнес-логике. Конечно, если на весь проект, единственный аякс запрос — это что-то вроде вернуть общее количество записей в БД, тогда можно и адрес метода в тег сгенирировать.
Но если в каждом контроллере есть хотя бы один аякс метод и к тому же к нему появляются параметры — стоит задуматься об комбинации аякс-апи / MVC-фреймворк. Сильно много времени это не заберёт, но во-первых, вынудит явно сформулировать интерфейс (REST например) на сервере и освободит клиент от жёсткой зависимости. Тот же Angular прекрасно умеет подставлять значения в запросы и все пути можно описать в одном месте.
Опять же это открывает дорогу для других клиентов (вот затребует клиент не только веб сайт, но и десктоп или вообще, мобильную апп).
tinyAMD X
то есть я не один такой. в итоге я купил себе небольшой, бойкий и недорогой андроид, который использую, как телефон(sic!), твиттер и точку доступа для бОльших братьев если нужно.
то есть оптимизация здесь совсем в кавычках и о скорости речи нет. только о всё большей нечитаемости кода.
Два билда в TFS:
— Один просто билд+юнит тесты, второй — билд+интеграционные тесты.
— Второй в начале воссоздаёт виртуальную машину из чистого образа, инсталлирует в неё все msi и запускает систему. После этого запускает интеграционные тесты, работающие с реальной БД и прочая. Для совсем внешних зависимостей используется самодельный SoapMock.
Архитектура разбита так, что в юнит тестах Entity не тестируется (её как бы тестирует микрософт), но есть ДБ слой, который эмулируется.
2. Если в контроллерах много бизнес логики — это уже признак того, что возможно не всё чисто. Бизнес логику стоит выносить из контроллера, пусть он занимается только роутингом и сборкой моделей из данных, получаемых из отдельных модулей. Вот как раз эти модули можно легко и просто тестировать без привязки к контексту контроллера. И одтельно, если хочется, можно тогда тестировать сами контроллеры, передавая им эмулированые провайдеры бизнес логики. DI rulez.
Но если статья перевод вчерашней на смишную (то есть смысл тот же), то у меня вопрос: а как происходит синхронизация данных между модулями (partitions)? То есть если всё в памяти и периодически синхронизируется в бэкенд (backend) то как обеспечивается что у всех модулей одни и те же данные?
В случае с магазином, это не критично, но допустим, сиистема обслуживает некую ММОРПГ и нужно, чтоб любые два игрока, оказавшись в одном контексте, видели одно и то же и всё время а не иногда.
При том, что сам сталкивался с этой проблемой, мне кажется эти библиотеки решают не ту проблему.
Кмк, проблема не в том, как передать в яваскрипт аякс-урл а в том, что яваскрипт воспринимается, как небольшое дополнение к серверной бизнес-логике. Конечно, если на весь проект, единственный аякс запрос — это что-то вроде вернуть общее количество записей в БД, тогда можно и адрес метода в тег сгенирировать.
Но если в каждом контроллере есть хотя бы один аякс метод и к тому же к нему появляются параметры — стоит задуматься об комбинации аякс-апи / MVC-фреймворк. Сильно много времени это не заберёт, но во-первых, вынудит явно сформулировать интерфейс (REST например) на сервере и освободит клиент от жёсткой зависимости. Тот же Angular прекрасно умеет подставлять значения в запросы и все пути можно описать в одном месте.
Опять же это открывает дорогу для других клиентов (вот затребует клиент не только веб сайт, но и десктоп или вообще, мобильную апп).
в свойствах апп есть флажок «показывать уведомления». сервис это не остановит, но самореклама исчезнет.