Длинные легаси методы без тестов. У меня есть аргументы против разбиения ради разбиения:
1) засорение истории изменений. Пока метод такой какой он есть, через blame можно сразу увидеть зачем писалась та или иная строка. Если же всё было зарефачено ради компактности, то всё что видно в истории — это последний рефакторинг. Когда кто и зачем написал конкретный блок кода — становится совершенно непонятно. Как вариант можно сначала разобраться и перенести это знание в тесты, но объём усилий уходящий на рефакторинг возрастёт на порядок.
2) Отсутствие юнит тестов. Без них рефакторинг, даже такой безобидный как extract method, превратится в ходьбу по минному полю.
Но это о том, что касается легаси кода. Продолжать так писать, даже при сопровождении этого кода, это преступление.
Важно: все URL-ы на css должны быть без параметров (query string) — т.е. без ?key=value. Это важно. Без этого mapping не будет работать. Если css запрашиваются с параметрами (у меня так было), то на такой случай есть плагин для хрома, позволяющий убрать параметры). Сходу не нашёл — если важно, пишите — посмотрю, когда буду на работе.
Недавно открыл для себя возможность редактировать стили из проекта прямо в хроме. При том что сам веб сервис задеплоен в war контейнере, хром позволяет замапить стили с веб-сервиса на локальные файлы, так что все исправления происходят прямо в папке проекта. Сам хром тут же подхватывает эти изменения.
И самое удивительное — то, что стили у меня в SCSS, а Хром в редакторе и инспекторе открывает корректный scss файл.
Диалог, который наверняка состоялся за кадром:
Ребят, вы готовы заплатить за хостинг в 50 раз больше?
Нет проблем!
В неидеальном мире этот дилог происходит так:
Наш полугодовой бюджет на хостинг улетел за 1 месяц, что будем делать?
Режьте мощности! И оптимизируйте северную часть, асап!
Ну если вдруг нахлебаетесь с настройкой путей в каждом проекте — то милости прошу попробовать Lazy Delphi Builder. Впрочем, в Delphi насколько я помню можно указывать внешние профили сборки, и это позволяет упростить настройку путей — так что msbuild это тоже очень хорошо. Для сборки 1-2 проектов идеально (просто).
> Если интересно – выложу и вторую часть про подбор каналов общения в сети и бренд-журналистику.
Очень интересно. С огромным удовольствием читаю все ваши статьи.
У BilleniumSoft был готовый продукт — Citadel для сжатия и шифрования DFM-ок в Delphi программах. Последняя поддерживаемая версия судя по информации на сайте — Delphi 2009.
Мягкие бипы (как оповещения об смс в самсунговых телефонах) при успешном выполнении шага (просканировал, положил на весы) имхо, лучше чем тишина. Голосовое сопровождение раздражает, согласен. Как и громкие бипы.
> Хлеб иногда хорошо покупать нарезанным. У нас продают заранее нарезанный хлеб, который стоит дороже на рубль-два. В Европе и Африке почти везде стоят вот такие хлеборезки. Можно засунуть туда что угодно. Что-то подсказывает мне, что это решение лучше:
В Риге есть такие резалки — но они обычно для испеченного в магазине хлеба. А весь остальной хлеб продаётся уже упакованным в полиэтиленовые/бумажные пакеты. Бывает как порезанным так и нет (зависит от производителя).
Вот что действительно радует — так это аналогичные резалки в мясных отделах. Правда работают с ними только работники магазина. Очень удобно брать колбасу/мясо на развес и сразу просить порезать. Особенно если берешь для посиделки в большой компании.
> Тут я с Вами полностью согласен. Есть еще вариант использовать:
В принципе да. Но может возникнуть еще необходимость отката стороннего пакета, например. В общем и целом, автоматизированная переустановка узла с нуля — это наверно наиболее оптимальный способ.
А кстати, (может и было в какой статье, но я позабыл), а вы с помощью puppet-a только окружение настраиваете, или deployment тоже делаете?
И еще интересующий меня вопрос — не сталкивались вы с ситуацией, когда надо с помощью паппета управлять сенситивными данными (например конфигурационными файлами с паролями), но при этом сами данные спрятать даже от тех кто имеет доступ к исходникам модулей и может управлять паппетом — создавать/удалять ноды? И если да, то как решали? Или как решили бы, если б пришлось столкнуться? =)
Мне действительно интересно поговорить об этом =) Поэтому я позволю себе добавить несколько комментариев, и задать еще несколько вопросов.
> По поводу модулей: у вас очень идеальное представление :)
Есть такое. =) Понятно, что реальность полна компромиссов.
> для нас «дешевле» в этом случае отправить машину на полный цикл ресетапа, нежели заниматься точечной чисткой. Готового и на 100% отработанного решения по подобной чистке паппетом у нас нет, есть только мысли.
Вот я тоже не нашёл хорошего и простого способа откатывать изменения с паппетом. Теоретически, есть идеи — в духе писать для каждого изменения скрипт отката, но времени это потребует неприлично много. И если есть возможность пересоздать систему с нуля, то лучше так и сделать.
> Далее… Разработчики у нас не пишут модулей для паппета, да и чего бы то ни было для него они не пишут, всем этим занимается команда эксплуатации.
Моя логика: создание модуля для паппета — это разработка, так что человек создающий модуль в момент создания модуля вполне может быть назван разработчиком.
> Проверка на локальной машины – только синтаксис, все остальное проверить невозможно в силу не одинаковой среды на localhost и боевой или условно боевой машине.
1) Я вас здесь недопонимаю. Имхо — модули бывают разными. Могут быть линейным, а могут содержать какую-то простейшую логику (и в зависимости от параметров/фактов выполнять разные действия). И вот эту логику не так-то просто протестировать в реале, зато с этим отлично справляется rspec. Но rspec тесты ещё нужно написать. Впрочем, если тестов нет, то и тестировать нечего.
2) По поводу неодинаковой среды. Есть же виртуальные машины + vagrant. С ним можно довольно быстро поднять виртуалку + выполнить нужные скрипты. Всё в консоли. Неужели не используете?
У меня появилось подозрение, что говоря о модулях мы возможно о говорим о немного разных вещах. По крайней мере я.
Так вот, модуль в моём понимании может быть как
1) библиотечный модуль реализующий какой-либо функционал (скачивание и распаковка файла, установка и настройка какого-либо сервиса в зависимости от переданных параметров) — в общем, то что обычно выкладывают на puppet.forge.
2) конкретный модуль, делающий конкретное дело. Обычно такие модули либо используют другие модули (библиотечные) с конкретными параметрами, либо просто заточены на выполнение простейших действий. Эти, как мне кажется, почти всегда можно заменить парой библиотечных и внешним конфигуратором типа hiera.
> Т.е. отвечая на вопросы про тесты – тесты не пишутся, по крайней мере в том виде, в котором они могут быть знакомы разработчику.
А почему? Было ли это осознанным выбором? (или может просто никто не заморачивался изучением этого вопроса)
Про выкладку по частям — очень разумно. Я тоже так делал. А вот stages у себя не использовал — как-то не придумал применения.
external_node scripts — это имеется в виду External Node Classifier или что-то еще? Насколько я понял из презентации — у вас его роль выполняет foreman, не?
Интересен полный workflow создания модулей.
Попробую сформулировать идеальный workflow (как я его себе представляю) и в нём расставить вопросы, а вы уж не обессудьте поправить где что не так.
* вот разработчик начинает делать новый модуль, и вот сделал.
* сначала он проверяет его работу на локальной машине [предположение]?
* пишутся ли тесты? rspec, smoke, integration, ещё какие-то? всегда ли? в каких случаях не пишутся?
* ну предположим, что разработчик написал не только модуль, но и все тесты к нему и локально эти тесты для этого модуля проходят.
* Что дальше?
* Предположим, что дальше было бы здорово проверить что этот модуль не свалится в связке с другими модулями (интеграционный тест). Есть такое? Как проверяете?
* Предположим, что разработчик решил, что его код достаточно стабилен и отправляет его на сервер. Что там? Снова тесты прогоняются? На отдельно выделенном сервере? Создаются ли какие-то чистые виртуалки на которых проверяются разные конфигурации? Или выкатывается на какую-то часть production серверов?
Ну и еще:
При обновлении модулей, обновление сразу везде накатывается? Или по частям — сначала на 5 серверов, если всё ок, то еще на 5? А что будет если обновление вызвало бяку и надо его срочно откатить (довольно болезненный для меня вопрос в своё время).
Используете environment-ы в puppet-e? mcollective? hiera?
Длинные легаси методы без тестов. У меня есть аргументы против разбиения ради разбиения:
1) засорение истории изменений. Пока метод такой какой он есть, через blame можно сразу увидеть зачем писалась та или иная строка. Если же всё было зарефачено ради компактности, то всё что видно в истории — это последний рефакторинг. Когда кто и зачем написал конкретный блок кода — становится совершенно непонятно. Как вариант можно сначала разобраться и перенести это знание в тесты, но объём усилий уходящий на рефакторинг возрастёт на порядок.
2) Отсутствие юнит тестов. Без них рефакторинг, даже такой безобидный как extract method, превратится в ходьбу по минному полю.
Но это о том, что касается легаси кода. Продолжать так писать, даже при сопровождении этого кода, это преступление.
А в вашем af тоже что-то подобное используется?
Спасибо большое. Было очень интересно читать.
Если ansible неделя, chef — недели, то puppet — это месяцы. Особенно если с нуля строить.
Забыли уточнить, что предложение работает не для всех стран.
Сегодня наткнулся. В закладке Sources (редакторе кода) Ctrl+D — работает так же как и в Sublime Text — multiselect.
Я настраивал по обучалке Sass Source Maps + Chrome = Magic. Чуть более подробно — в справке к devtools.
Если вкратце:
И самое удивительное — то, что стили у меня в SCSS, а Хром в редакторе и инспекторе открывает корректный scss файл.
Ребят, вы готовы заплатить за хостинг в 50 раз больше?
Нет проблем!
В неидеальном мире этот дилог происходит так:
Наш полугодовой бюджет на хостинг улетел за 1 месяц, что будем делать?
Режьте мощности! И оптимизируйте северную часть, асап!
Очень интересно. С огромным удовольствием читаю все ваши статьи.
п.с. fyi
Но выглядит оно примерно так (упаковка кстати частенько бывает с дырочками):
В Риге есть такие резалки — но они обычно для испеченного в магазине хлеба. А весь остальной хлеб продаётся уже упакованным в полиэтиленовые/бумажные пакеты. Бывает как порезанным так и нет (зависит от производителя).
Вот что действительно радует — так это аналогичные резалки в мясных отделах. Правда работают с ними только работники магазина. Очень удобно брать колбасу/мясо на развес и сразу просить порезать. Особенно если берешь для посиделки в большой компании.
> Тут я с Вами полностью согласен. Есть еще вариант использовать:
В принципе да. Но может возникнуть еще необходимость отката стороннего пакета, например. В общем и целом, автоматизированная переустановка узла с нуля — это наверно наиболее оптимальный способ.
А кстати, (может и было в какой статье, но я позабыл), а вы с помощью puppet-a только окружение настраиваете, или deployment тоже делаете?
И еще интересующий меня вопрос — не сталкивались вы с ситуацией, когда надо с помощью паппета управлять сенситивными данными (например конфигурационными файлами с паролями), но при этом сами данные спрятать даже от тех кто имеет доступ к исходникам модулей и может управлять паппетом — создавать/удалять ноды? И если да, то как решали? Или как решили бы, если б пришлось столкнуться? =)
Мне действительно интересно поговорить об этом =) Поэтому я позволю себе добавить несколько комментариев, и задать еще несколько вопросов.
> По поводу модулей: у вас очень идеальное представление :)
Есть такое. =) Понятно, что реальность полна компромиссов.
> для нас «дешевле» в этом случае отправить машину на полный цикл ресетапа, нежели заниматься точечной чисткой. Готового и на 100% отработанного решения по подобной чистке паппетом у нас нет, есть только мысли.
Вот я тоже не нашёл хорошего и простого способа откатывать изменения с паппетом. Теоретически, есть идеи — в духе писать для каждого изменения скрипт отката, но времени это потребует неприлично много. И если есть возможность пересоздать систему с нуля, то лучше так и сделать.
> Далее… Разработчики у нас не пишут модулей для паппета, да и чего бы то ни было для него они не пишут, всем этим занимается команда эксплуатации.
Моя логика: создание модуля для паппета — это разработка, так что человек создающий модуль в момент создания модуля вполне может быть назван разработчиком.
> Проверка на локальной машины – только синтаксис, все остальное проверить невозможно в силу не одинаковой среды на localhost и боевой или условно боевой машине.
1) Я вас здесь недопонимаю. Имхо — модули бывают разными. Могут быть линейным, а могут содержать какую-то простейшую логику (и в зависимости от параметров/фактов выполнять разные действия). И вот эту логику не так-то просто протестировать в реале, зато с этим отлично справляется rspec. Но rspec тесты ещё нужно написать. Впрочем, если тестов нет, то и тестировать нечего.
2) По поводу неодинаковой среды. Есть же виртуальные машины + vagrant. С ним можно довольно быстро поднять виртуалку + выполнить нужные скрипты. Всё в консоли. Неужели не используете?
У меня появилось подозрение, что говоря о модулях мы возможно о говорим о немного разных вещах. По крайней мере я.
Так вот, модуль в моём понимании может быть как
1) библиотечный модуль реализующий какой-либо функционал (скачивание и распаковка файла, установка и настройка какого-либо сервиса в зависимости от переданных параметров) — в общем, то что обычно выкладывают на puppet.forge.
2) конкретный модуль, делающий конкретное дело. Обычно такие модули либо используют другие модули (библиотечные) с конкретными параметрами, либо просто заточены на выполнение простейших действий. Эти, как мне кажется, почти всегда можно заменить парой библиотечных и внешним конфигуратором типа hiera.
> Т.е. отвечая на вопросы про тесты – тесты не пишутся, по крайней мере в том виде, в котором они могут быть знакомы разработчику.
А почему? Было ли это осознанным выбором? (или может просто никто не заморачивался изучением этого вопроса)
Про выкладку по частям — очень разумно. Я тоже так делал. А вот stages у себя не использовал — как-то не придумал применения.
Интересен полный workflow создания модулей.
Попробую сформулировать идеальный workflow (как я его себе представляю) и в нём расставить вопросы, а вы уж не обессудьте поправить где что не так.
* вот разработчик начинает делать новый модуль, и вот сделал.
* сначала он проверяет его работу на локальной машине [предположение]?
* пишутся ли тесты? rspec, smoke, integration, ещё какие-то? всегда ли? в каких случаях не пишутся?
* ну предположим, что разработчик написал не только модуль, но и все тесты к нему и локально эти тесты для этого модуля проходят.
* Что дальше?
* Предположим, что дальше было бы здорово проверить что этот модуль не свалится в связке с другими модулями (интеграционный тест). Есть такое? Как проверяете?
* Предположим, что разработчик решил, что его код достаточно стабилен и отправляет его на сервер. Что там? Снова тесты прогоняются? На отдельно выделенном сервере? Создаются ли какие-то чистые виртуалки на которых проверяются разные конфигурации? Или выкатывается на какую-то часть production серверов?
Ну и еще:
При обновлении модулей, обновление сразу везде накатывается? Или по частям — сначала на 5 серверов, если всё ок, то еще на 5? А что будет если обновление вызвало бяку и надо его срочно откатить (довольно болезненный для меня вопрос в своё время).
Используете environment-ы в puppet-e? mcollective? hiera?