With the Gemset or on the Gemset

Nowadays, from the high level, the web development is much like Lego playing rather than hardcore coding experience. Has the future arrived? Maybe, but we still could not leave budget and deadline aside while we don’t have assembly instruction having a zillion of different blocks.

Transcript

1. С Gemset'ом или на Gemset'е Sergey Dolganov, Evil Martians SUMMER SAINT P RUBYCONF 2017
6. ?
7. ?
14. ???
15. ???
17. "Незрелых" зависимостей не избежать? Инструкция по применению Между "зрелыми" и "незрелыми" зависимостями существует большая разница. "Незрелые" зависимости могут создать конфликты даже в "простых" на первый взгляд случаях. "Незрелые" зависимости приводят к появлению "паразитных"/искусcтвенных ограничений в системе.
18. "Незрелых" зависимостей не избежать? Инструкция по применению Когда выбора нет и "незрелые" зависимости становятся частью проекта, то нужен особый подход — "карантин" и "обеспечение воспроизводимости". "Карантин" обеспечиваем тестами. "Воспроизводимость" обеспечиваем документацией.
19. Подключили новый гем в проект. Что дальше? 1. Заложите время на проверку документации к проекту. Оказалось недостаточно? - Оформите свои записки в произвольной форме. - Отправьте Pull Request с документацией в проект. - Сохраните/привяжите записки к исходному коду своего проекта. 2. Покройте тестами все случаи использования сторонней библиотеки, обеспечив "карантин".
20. Подключили новый гем в проект. Что дальше? 1. Заложите время на проверку документации к проекту. Оказалось недостаточно? - Оформите свои записки в произвольной форме. - Отправьте Pull Request с документацией в проект. - Сохраните/привяжите записки к исходному коду своего проекта. 2. Покройте тестами все случаи использования сторонней библиотеки, обеспечив "карантин".
21. Сложность в принятии архитектурных решений
22. Как сделать архитектуру "неуязвимой" ? Перед каждым решением задай себе вопрос: "А как оно может мне А как оно может мне навредить? навредить?".
23. Как сделать архитектуру "неуязвимой" ? Перед каждым решением задай себе вопрос: "А как оно может мне А как оно может мне навредить? навредить?".
24. Опробуем? Service Other service Feature X 1. Главный риск — отсутствие изолированности. 2. Обязательно выпускаем обновленную версию сервиса, чтобы найти регрессии в реальной эксплуатации. 3. Вот теперь мы готовы к реализации новой фичи. 100% Code Coverage Non-transactional
25. Сначала устраняем вред, потом думаем о приемуществах!
26. ?????
27. Риски в контексте процесса разработки
28. "Плохие" процессы съедают производительность
29. Критерий эффективного процесса разработки С течением времени: 1. Кол-во регрессий примерно константно и не имеет тренда к увеличению 2. Новые фичи выпускаются в срок
30. Почему разработчикам НЕ должно быть все равно?
31. Плохие процессы? Отсекай лишнее 1. Фокусируемся на вреде 2. Затем на выпуске новых фич
32. Плохие процессы? Отсекай лишнее Фокусируемся на вреде Затем на выпуске новых фич
33. RECAP: Качество продукта в т.ч. ответственность разработчика, значит разработчику не должно быть все равно на процесс разработки Чтобы оценить качество процесса разработки нужна линейка. Например, число выпускаемых фич и кол-во появляющихся ошибок. Чтобы сделать свой продукт надежным, замеры необходимо делать регулярно и реагировать на отклонения В качестве эвристики для улучшения качества, попробуйте "отсекать все лишнее" на каждой итерации.
34. "Отсекай лишнее" в естественных условиях?
35. "Отсекай лишнее" в естественных условиях?
41. Развитие современных технологий в IT
43. Стандартный комплект инструментов на Ruby rubocop — since 2012 rspec — since 2005 docker — since 2008 puma — since 2011 bundler-audit — since 2013 heroku — since 2008
44. Используют то, о чем пишут Daily Downloads Count Daily Downloads Raiting Source: Bestgems.org 295 156 295 156 295 156 36 865 36 865 36 865 5 884 5 884 5 884 503 503 503 39 39 39 6 6 6 3 3 3 1 1 1 Total Downloads Ranks 1 100 500 2,000 10,000 50,000 100,000 126,454 0 100k 200k 300k 400k Highcharts.com
45. Используют то, о чем пишут Daily Downloads Count Daily Downloads Raiting Source: Bestgems.org 295 156 295 156 295 156 36 865 36 865 36 865 5 884 5 884 5 884 503 503 503 39 39 39 6 6 6 3 3 3 1 1 1 Total Downloads Ranks 1 100 500 2,000 10,000 50,000 100,000 126,454 0 100k 200k 300k 400k Highcharts.com
46. Пишут о том, что используют Новые средства для Explore проектов Новые способы ранжирования open-source инструментов
47. Пишут о том, что используют Новые средства для Explore проектов Новые способы ранжирования open-source инструментов
48. Пишут о том, что используют Новые средства для Explore проектов Новые способы ранжирования open-source инструментов
49. Пишут о том, что используют Новые средства для Explore проектов Новые способы ранжирования open-source инструментов
50. Пишут о том, что используют Новые средства для Explore проектов Новые способы ранжирования open-source инструментов Ossvald А ты уверен в своих зависимостях?
54. Необходимость фиксировать "новые" знания
55. Необходимость фиксировать "новые" знания
56. Программирование — моделирование предметной области Исходный код = модель Документация = знания о контексте
57. Программирование — моделирование предметной области Исходный код = модель Документация = знания о контексте
58. А ты уже внес свой вклад в open-source? В долг у создателей open- source программ
59. А ты уже внес свой вклад в open-source? В долг у создателей open- source программ
60. Почему по-прежнему стоит выбрать Ruby? язык Ruby — "выбор читателей" Документация — это "почему?" и "зачем?" Исходный код — это "как?" В Ruby — тесты читаются как часть документации В Ruby — исходный код читается к описание работающей модели
61. Выводы Писать на Ruby — это писать быстро и понятно. Быть профессиональным разработчиком — значит делать "неуязвимые" решения в любых условиях. "Неуязвимые" решения борются с рисками, а не витают в облаках новых возможностей Помните, зачем мы пишем программы. Фиксируйте и делитесь знаниями. Помогайте писать документацию open-source проектам.
62. Выводы Писать на Ruby — это писать быстро и понятно. Быть профессиональным разработчиком — значит делать "неуязвимые" решения в любых условиях. "Неуязвимые" решения борются с рисками, а не витают в облаках новых возможностей Помните, зачем мы пишем программы. Фиксируйте и делитесь знаниями. Помогайте писать документацию open-source проектам.
64. Наши агенты повсюду