То ли у нас проект такой, то ли что, но основная работа происходит именно над видами и контроллерами в терминах MVC. Бизнес логика по сути не сложная и о том как мы покрыли ее cucumberовскими юнит-тестами и они у нас за 20 секунд пробегают — неинтересно. А интеграционные тесты при каждом коммите запускать надо чтобы отловить регрессию в контроллере или сломанный, к примеру, JavaScript на клиентской стороне.
Вообще говоря, самостоятельно выполнить требования ФЗ-152 будет очень тяжело. Дело в том, что начиная с К2 и выше в комплекс технических мероприятий почти наверняка войдет установка средств криптографической защиты информации. Но их Вашей компании никто не продаст, если у Вас нет лицензий ФСБ на работу с криптографией. И даже если где-то взять, то самостоятельная их установка без лицензии юридически не легитимна. То есть, варягов звать придется по-любому или получать лицензию на криптографию.
А откуда Вы знаете что Ваш провайдер не заворачивает трафик через прозрачный и незаметный squid чтобы сэкономить чуток полосы. А в логах сквида все-все урлы есть.
Все тесты пишем на русском. Поскольку часто программист додумывает интерфейс, а часто и логику, именно в момент написания теста, то лишняя нагрузка на мозг — лишняя. Мы вот так привыкли — ну что уж теперь поделать.
1. СУБД бэкапить rsyncом нельзя — будут коцаные базы при восстановлении.
2. Описываемый gem backup rsync умеет, и при этом получаются тоже только инкременты. Но при этом надо выбирать — или инкремент и один бэкап, или 14 последних, но инкремента не будет. Ведь чтобы был инкремент надо сравнивать с тем что уже забэкаплено. А если бэкап один и админ проспит беду, на следующую ночь неправильные файлы заменят правильные и в бэкапе.
3. Сейчас на среднем серваке у нас по 100Гб и миллионы файлов (в основном картинки из статей, написанных юзерами в CMS). rsync длится часами — пробовали, знаем.
4. rsync не шлет письма, не шифрует. Разговора нет — можно все баш-скриптом реализовать. И получится то же самое на bash. Так зачем писать больше?
Огурец — дело вкуса. Просто после огурца тяжело лично мне на rspec обратно переходить, хотя приходится местами в унаследованных проектах. Родной язык он такой родной — определить в чем дело быстрее в разы.
Да, но сохраняется возможность создавать чисто Web кроссплатформенные приложения для внутреннего пользования, например энтерпрайз документооборот. К тому же, есть ноутбуки и удаленка. Хотя, с другой стороны, это таки минус.
Вообще говоря, куче программистов, дизайнеров, художников, которые что-то могут больше всего нужны менеджеры, которые будут искать заказчиков и сводить специалистов в одном со специалистами в другом. То, чем в больших конторах занимается руководство и коммерческий отдел. Кто возьмется?
Рутокен Web — это же только авторизация. Во всяком случае, из описания такое мнение складывается. Можно при помощи него, например, подписать содержимое текстового поля в форме не передавая закрытый ключ на сервер?
Евгений, разъясните пожалуйста почему не удастся сертифицировать что-либо чисто Webовское — JS/Flash/Silverlight? Интерес у многих большой, а у нас лицензия на подходе, думаем заняться попутно и этим.
2. Описываемый gem backup rsync умеет, и при этом получаются тоже только инкременты. Но при этом надо выбирать — или инкремент и один бэкап, или 14 последних, но инкремента не будет. Ведь чтобы был инкремент надо сравнивать с тем что уже забэкаплено. А если бэкап один и админ проспит беду, на следующую ночь неправильные файлы заменят правильные и в бэкапе.
3. Сейчас на среднем серваке у нас по 100Гб и миллионы файлов (в основном картинки из статей, написанных юзерами в CMS). rsync длится часами — пробовали, знаем.
4. rsync не шлет письма, не шифрует. Разговора нет — можно все баш-скриптом реализовать. И получится то же самое на bash. Так зачем писать больше?