В Японии в больших компаниях очень хорошие сверхурочные. Но как правило, они насчитываются и оплачиваются после N сверхурочных часов в месяц, буфер такой. И достаточно коллег видел, которых пинком отправляли домой чтоб не засиживались. А при 4 дневке, переработать буфер получается нереальным, вот и укладывается такой засидельщик в рабочий день и домой.
Используем Electron + React + cвоя библиотека виджетов для in-house приложений. Непосредственно занимаюсь GIS приложением. Сократили число пользователей лицензии ArcGIS в компании наполовину, компенсируем своим приложением, добавляем новый функционал по-запросу. Добавляем в пакет Elasticsearch (+ снапшоты статичных данных), хорошо подходит для spatial данных. Ёмкие операции, вроде генерации сеток (mesh grid), heatmaps или симуляция движения объектов (одновременно) на карте (Elasticsearch scroll + nodejs stream) — перебрасываем на web workers. Команда небольшая — 2 человека. Коммерческих приложений в интернете хватает, но личного опыта не было.
Приятно видеть работу коллеги, хотя и бывшего, в Хабре. Давно была тема Реализуем RESTful Web Service на Scala. Тогда автор предпочел Unfiltired для данной задачи.
Хочу поделиться своей наработкой: AngularJS + gulp
В пакет входит: gulp-uglify, gulp-jshint, gulp-concat, gulp-sass, gulp-jade, livereload и еще пара модулей.
Для информации; знакомый программист давно работает над проектом под названием Xitrum. Xitrum is an async and clustered Scala web framework and HTTP(S) server
on top of Netty and Hazelcast ngocdaothanh.github.com/xitrum/
Интересное решение задачи, но, по-моему, feed и mobile несколько иного рода группировка чем, например, api.
Не имеет смысла дублировать контроллеры когда можно выводить ответ (response) в разных форматах и использовать соответствующие типы шаблонов. Если же задача состоит в инкапсуляции или изоляции данного раздела приложения, удобнее вывести часть кода в движок (engine).
Извиняюсь за БД, имелось ввиду DB. Пусть будет «заказчик» и «потребитель», но всё равно, у них разные атрибуты. Всё таки я сторонник де-нормализации БД. Пускай будет больше таблиц, чем больше программного вычисления.
У типов как «обычный пользователь» и «администратор» больше разных аттрибутов чем одинаковых. Поэтому, будет правильным сделать две разные модели для них. Чего вы добились полиморфизмом? 3 таблицы в BD vs 2-х.
Принцип «Polymorphism» я понимаю, но по обстоятельству, может быть целесообразным использовать два типа Юзеров. Я понимаю если это разные уровни «Редактоpа» в какой-то блоговой системе, но если это Админ и Юзер, или, Читатель и Публикатор, то тут сама идея полиморфизма как-то ни к месту.
.pipe(sass({errLogToConsole: true}))И тогда watcher не падает
gulp --env=developmentилиgulp --env=stagingБилд
gulp build --env=productionФайлы конфигурации среды (development, staging, production) находятся в папке src/scripts/config
Тест
карма стартВ пакет входит: gulp-uglify, gulp-jshint, gulp-concat, gulp-sass, gulp-jade, livereload и еще пара модулей.
github.com/tundrax/angular-gulp/
Жду пост про promises and deferreds в роутере.
Xitrum is an async and clustered Scala web framework and HTTP(S) server on top of Netty and Hazelcastngocdaothanh.github.com/xitrum/
Не имеет смысла дублировать контроллеры когда можно выводить ответ (response) в разных форматах и использовать соответствующие типы шаблонов. Если же задача состоит в инкапсуляции или изоляции данного раздела приложения, удобнее вывести часть кода в движок (engine).
Без объявления attr_accessible вообще невозможно сохранить данные кроме тех, что Devise определяет по-умолчанию.
А чем Вас не устраивает вариант 2-х отдельных «ролей» в Devise?
real 0m34.269s
user 0m25.560s
sys 0m8.231s