Каша из шпал или как готовят рельсы в Progress Engine

Transcript

1. Каша из шпал Или как готовят рельсы* в Progress Engine * ruby on rails 2014
2. Меня зовут Алексей Поимцев и я разработчик основатель компании Progress Engine
3. www.progress-engine.ru
4. Я не буду рассказывать о том… • Как использовать какой-то конкретный gem • Что надо пользоваться системами контроля версий • Что надо пользоваться issue/bug трекерами • Что надо сразу писать код хорошо, а не по правилу “Когда-нибудь переделаем” • Что не надо стесняться задавать вопросы, если вы чего-то не знаете или не понимаете
5. Я буду рассказывать о том… • С какими проблемами мы столкнулись, прежде чем наладили процесс разработки в Progress Engine • Как мы победили эти проблемы • Какие уроки мы из этого вынесли …а также я немного расскажу про несколько интересных проектов, которые вам могут пригодиться в работе.
6. Проблема 1. Сложность сбора требований к проекту и приемки его заказчиком
7. • У заказчика почти никогда нет адекватного ТЗ • Заказчик редко может четко сформулировать требования к продукту • Разработчики и заказчик говорят на разных языках и часто не понимают друг друга
8. Решение: gherkin / cucumber
9. • Возможность четко структурировать требования к проекту • Возможность использования тестов как ТЗ, в том числе и для использования в договоре • Возможность использования в связке с Capybara для интеграционных тестов
10. Несколько реальных кейсов • Плохой - Клиент недоволен, gherkin нет • Средний - Клиент недоволен, gherkin есть • Хороший - Клиент доволен, gherkin есть
11. Проблема 2. Постоянно меняющиеся требования
12. • Заказчик постоянно что-то уточняет, у него нет четкого видения продукта • Заказчик меняет требования к продукту в каждой итерации • Меняются разработчики на проекте
13. Решение: continuous integration
14. • Любые изменения в коде тестируются • 99% защита от случайных ошибок • Нет критической необходимости проверять весь код после внесения мелких правок
15. Проблема 3. Повторяющиеся задачи по DevOps
16. • Плюс-минус однотипные задачи настройки новых серверов • Необходимость поддерживать серверный парк в актуальном состоянии
17. Решение: ansible(puppet/chef)
18. • Единожды настроенные скрипты, которые могут использоваться многократно • Возможность описать в yaml-конфиге серверные задачи фактически любой сложности • Легкость обучения любого разработчика • Возможность локального тестирования в vagrant
19. Проблема 4. Много кода
20. • Огромное количество повторяющегося кода(особенно в scaffold'ах) • Соответственно - тратится много времени на вычитывание кода в поисках ошибки
21. Решение: использование concern'ов и inherited_resources/decent_exposure
22. • Повторяющийся код переносится в concern • Основные CRUD-операции закрываются inherited_resources
23. Проблема 5. Качественная верстка
24. • Не все верстальщики знают rails • При переносе готовой верстки в Rails-проект возможны ошибки
25. Решение: haml/slim и middleman
26. • Проблема не-закрытого тэга останется в прошлом • Можно сделать заглушки на методы backend'а • Легко научить верстальщика без опыта в rails • Легко делать и деплоить даже статичные сайты через rsync
27. Проблема 6. Много зависимостей
28. • Многие зависимости уже не используются • Необходимо следить за совместимостью версий • Функциональность ряда gem’ов может быть написана двумя строками кода
29. Решение: оставлять в Gemfile только часто используемые гемы
30. Проблема 7. Вокруг столько всего интересного…
31. Решение: не забывайте про RND
32. Одно из наших свежих исследований это ….
33. RethinkDB
34. Сплошные плюсы • Open source • Вышли из Y-Combinator • Очень динамично развивающаяся экосистема • Core team быстро отвечает на вопросы
35. Сплошные плюсы • Драйвера для многих языков программирования • Не забыты ruby (gem rethinkdb) и rails (gem nobrainer) • Единственная nosql БД с поддержкой join
36. Сплошные плюсы • Кластер из коробки • Sharding и репликация в 2 клика • Красивый admin web ui
38. …но не все идеально • Нет триггеров и хранимых процедур • Нет инкрементального бэкапа • Нет нормального мониторинга
39. …но не все идеально • Плохо проработаны механизмы миграции на новые версии • Авторы пока что не публикуют реальные референсы • Есть мелкие и не очень баги, впрочем - не мешающие использовать в production
40. +7 (926) 889-16-32 alexey.poimtsev@progress-engine.ru www.progress-engine.ru Вопросы?