Наворотить, конечно, можно что угодно — "бумага все терпит".
Главное условие, чтобы интерфейс конфигурирования был удобен и понятен для конечного пользователя, равно как присутствовали примеры и хоть минимальная документация в ридми в репе, тогда проблем не возникнет.
Другое дело, если написанная конфигурация не поддерживает что-то, или просто не известно, как это конфигурировать, ввиду отсутствия доков, и для элементарного использования приходится лезть в кишки, то естественно это работать не будет.
Была у нас конфигурация iptables и, очевидно, использовалась повсеместно — сотни серверов, физических и виртуальных("облака" отнесем виртуальным), разные заказчики и конечно разные среды, так вот за 5 лет эта конфигурация прошла лишь 1 мажорную и 2 минорных версии — в первом случае совместимость конфигурации была частично потеряна, ввиду типа передачи параметров, в двух других случаях, естественно нет, хоть и добавлялась поддержка всех таблиц и цепочек, управление ipset.
P.S. Подобный подход в написании конфигураций успешно применяю более 5 лет, работали с ними мои сотрудники разных уровней компетенции и проблем не возникало, кроме того поставленный процесс CI, содержащий тестирование позволял легко проверить конечный результат в считаные минуты, что делало внесение тех или иных изменений простым и предсказуемым.
P.P.S Сталкивался в работе и с подходом одна конфигурация — один енв, максимум хардкода, копипаст между енвами, неправильный уровень абстракции конфигурационной единицы. Одна закравшаяся ошибка разлеталась на кучи енвов благодаря копипасту, управление становилось настолько проблематичным, что в подавляющем большинстве, внесение изменений осуществлялось вручную, а затем подгонялось в конфигурации под сделанное вручную, в лучшем случае — в худшем оставлялось как есть.
Десятки часов работы, зато все при деле=)
А нету двух абсолютно одинаковых проектов и требования в них постоянно меняются
Вынужден не согласиться, различные проекты могут использовать одни и те же куски кода, которые Ansible и выносит в такие модули как роли, а поведение ролей и переопределение параметров осуществляется через плейбук.
Допустим на проектах используется haproxy, на одном как балансировщик, на другом как реверс-прокси. Пишется роль покрывающая все эти случаи и используется одна, на всех проектах.
Конфигурация в данном случае выглядит достаточно просто:
Формируется данный конфиг в процессе шаблонизации jinja:
{% for server_type,configuration in haproxy_install.servers.items() %}
{% for server,parameters in configuration.items() %}
{{ server_type }} {{ server }}
{% for parameter,properties in parameters.items() %}
{% if parameter == 'servers' %}
{% for instance,params in properties.items() %}
{% if instance is not in [ 'global' ] %}
server {{ instance }} {{ params.url }} {{ (params.parameters|default(properties.global|default([])))|join(' ') }}
{% endif %}
{% endfor %}
{% else %}
{% if properties is mapping %}
{% for key,value in properties.items() %}
{{ parameter }} {{ key }} {{ value }}
{% endfor %}
{% elif ((properties is not mapping) and (properties is not string) and (properties is iterable)) %}
{% for value in properties %}
{{ parameter }} {{ value }}
{% endfor %}
{% else %}
{{ parameter }} {{ properties }}
{% endif %}
{% endif %}
{% endfor %}
{% endfor %}
{% endfor %}
Естественно, что в роли есть еще дефолты других параметров, например параметры запуска демона для юнита, логирования, пользователи, cipher-сьюты сервера для SSL и так далее, и тому подобное. Все они записываются в дефолты и, при желании переписываются в плейбуке. Ansible не самый удобный CM инструмент для подобных вещей, как например SaltStack или тот же Puppet, однако, при желании, можно и его заставить делать то, что требуется:
Старайтесь не использовать словари для переменных. Ansible не позволяет удобно переопределять отдельные значения в словаре.
Никогда не понимал деления на Windows/Linux/Unix администраторов если честно.
По вопросу — смысл есть всегда, поскольку Development Operations никогда не был привязан к утилитам или операционным системам. Процессы разработки, равно как их автоматизация и оптимизация присутствуют на всех мыслимых и немыслимых платформах.
Знания Windows платформ и их администрирования достаточно сильно востребовано в разработке игр, системных утилит, из языков C/C++, C#, да и взрастить конвергентную среду с полной интеграцией Windows и Linux серверов, и рабочих станций очень распространенная задача. Например, компания использует AD, аналитики/data-science/художники работают на Windows/MacOS, девелоперы на Linux/MacOS, продакшен енв полностью на Linux — требуется прозрачная авторизация на проде, с применением групповых политик, двухфакторной авторизации, управлением ssh-ключами доступа. Как результат появляется задача — настройка федеративных отношений между AD, FreeIPA, интеграция с UbiKey.
Еще часто востребованная задача — автоматическая подготовка окружения сборки для триумвирата(Linux/Windows/MacOS), либо вообще кросс-компиляция, правда последняя обычно на Linux осуществляется=)
Что же, скотской она становится, когда ожидания и реалии не совпадают, когда требования к реализации не соответствуют административным ресурсам, когда ответственность не совпадает с полномочиями. Большинство проблем в данной области связаны именно с административными ограничениями и/или недоработками. С техникой просто решать вопросы, а вот с людьми нет.
Относительно смысла жизни — не уверен, что он связан с каким бы то ни было типом творчества, но здесь каждому свое. Однако, и разработка, и автоматизация тоже вид творчества и умалять это не стоит.
Можно просто на коленке что-то нафигачить, а можно продумать архитектуру решения, оценить риски, сбалансировать экономические затраты и создать действительно произведение инженерного искусства.
Кто как, а я лично испытываю истинное наслаждение от хорошо реализованных систем автоматизации, нежели от полотен Рубенса или творчества композиторов.
Ну что же вы снова выдираете админов из контекста:)
Я же говорю, что в большинстве случаев к нам приходят именно админы:)
Я вообще пришел в DevOps с QA где и занимался на самом деле DevOps когда этого слова вообще не было.
И правильно. Сначала это действительно делали разработчики, либо QA-automation инженеры потому что это именно им и необходимо, затем решили высвободить их, так и появились Build engineer, которые автоматизировали то, что им скажут и в точности так, как им скажут. Затем выделились Configuration Management инженеры, были даже такие позиции — CM engineer, которые настраивали именно среды для запуска систем и Build Engineer'ы, которые отвечали за системы сборки. В энтерпрайзе так уже много лет, возможно малым командам было непозволительно содержать такой штат и появились именно подходы "you build it, you run it". И наверное как-то так и появились утилитарные ребята, что пишут код для написанного кода, стандартизируют подходы, и т.д. и т.п.
Была у нас пара попыток QA engineer взять, но одна отказалась, поскольку ей было не интересно заниматься этим, а другой не имел общего представления о SDLC, тест-кейс менеджменте и т.д.
Все зависит от масштабов надо полагать. Если одна команда разработки, то скорее нет, чем да. Если таких команд с десяток, требования пересекаются, но есть уникальные моменты и эти моменты могут так или иначе повлиять на другие, то уже потребуется.
Ребята,
есть несколько проблем которые я попытался затронуть, наверное зря я их скомкал в одной статье, потому и показалось кому-то, что вопрос именно в стоимости — это не так. Кто-то усмотрел, что я вижу в этой специальности админа — тоже некорректно.
DevOps — подход/владелец процесса, позволяющий организовать Процессы разработки (Development Operations) наиболее оптимальным способом в каждой конкретной ситуации, участвуя в таких смежных дисциплинах, как разработка, тестирование, управление поставками, планирование поставок. DevOps, не важно как персона или процесс, включает в себя функции и системного администратора, ops'a кому угодно, и билд-инженера, и даже продукт-оунера, если под продуктом подразумевается процесс поставки, и еще много различных прикладных дисциплин инженерии, в том числе управление рисками.
Это понимание достаточно большого пласта аспектов процессной организации и технических реализаций и возможных ограничений.
Как и написано в статье:
«Для выполнения подобного рода работ и обязанностей данная персона должна иметь средства управления не только процессами разработки, тестирования, но и управления инфраструктурой продукта, а также планирования ресурсов. DevOps в данном понимании не может находится ни в IT, ни в R&D, ни даже в PMO, он должен иметь влияние во всех этих областях — технический директор компании, Chief Technical Officer.»
Касательно стоимости — да, человек, что способен управлять таким набором ожиданий и ограничений, назовем его DevOps, действительно может и должен стоить дорого.
Реалии же рынка таковы, что за лейблом DevOps Engineer, в действительности, часто скрываются именно системные администраторы, умеющие пользоваться теми или иными модными утилитами, зачастую не понимая их функции, назначения, возможностей.
Я собеседовал себе в команду очень большое количество «DevOps» инженеров различных грейдов и в подавляющем большинстве это были именно системные администраторы — IT operations, если угодно.
Если на стадии Junior еще можно не понимать какие-то аспекты разработки, а просто строить как видишь, руководствоваться напрямую, без осмысления, информацией от разработчиков — тоже нормально, опыт есть переосмысление ошибок прошлых, то вот на грейдах от Middle и старше это практически непозволительно.
IT Operations не просто так выставляет определенные ограничения на продуктивных средах, это тоже опыт, опыт поддержания систем в высокой доступности и некорректные действия со стороны разработчика, пусть даже по незнанию, не должны все похоронить. Так появляются регламенты, правила, к слову правило не деплоится в пятницу вечером ровно также появилось. Опыт старших грейдов персоналий участвующих в Development Operations позволяет учесть и оценить риски, возможные взаимные влияния Development и Operations, за счет чего, собственно, и достигается гибкость и скорость.
Вилки з.п. у нас достаточно широкие, я сам бился за их расширение, однако даже это не позволило набирать готовых инженеров, способных на исполнение обязанностей с минимальным обучением, их основная проблема — отсутствие именно процессных знаний, иногда даже основ.
Вакансии компаний представлены, дабы показать, что этим компаниям не нужен DevOps, наоборот, они ищут именно системных администраторов, способных покрыть ту или иную область и, если бы они точнее описали свои желания, они бы поняли, что им нужен системный администратор, способный к быстрым изменениям в инфраструктуре, читать как не закостеневший человек с политикой — «держать и не пущать».
Потому и получается например, что нам приходится брать Operations и добавлять принципы и подходы Development, также пытались в обратку, но единицам из Development интересны Operations, рассматриваются в большинстве случаев лишь как ненужные ограничения.
Естественно речь идет о российском рынке специалистов в области ИТ и, явным образом, указано сравнение с Системными администраторами.
Я не говорю о стоимости ИТ-специалистов в мире, сравнивать зп между странами в лоб, будет некорректно, и не говорю о разнице в ней между США, Финляндией, Россией, Англией и т.д., естественно разница высока, но и стоимость жизни, равно как размер налогообложения.
Относительно дороговизны — все понимают, что при переходе в Senior грейд, рамки между стоимостью специалистов стираются и Senior DevOps Engineer может стоить столько же, сколько Senior Render Engineer, Senior C++ Developer и т.д. Но Senior должен быть действительно Senior, а не обычный тулзист.
На самом деле, когда приходит хороший сисадмин, в большинстве случаев, мы отдаем предпочтение именно ему, потому что его проще научить автоматизации и процессной части, нежели когда приходится учить основам человека, который знает эти утилиты, но не знает почему они и для чего они используются.
немного о зарплатах на рынке и ожиданиях соискателей;
немного о том, что в действительности ожидают от соискателей;
немного о неправильных подходах в компании и подмене понятий,
в общем обо всем понемногу.
Хы… я тоже такое видел, только не в развернутую варку, а в джарку, упакованную в варку — библиотеку — классик впиливали =)))
Вообще, меня всегда удивляет, когда берут достаточно жирную тулу, читать как комбайн, а затем для ускорения сборки отключают zip — это как купить автомобиль для повседневной езды, но для снижения времени разгона выкинуть сиденья или для повышения устойчивости сделать жесткую подвеску в ущерб комфорту.
Мое мнение, если хочется сделать эту сборку быстрой, нужно убрать оверхед удобства.
Как-то на тренинге я сравнивал время сборки примитивной варки тулами Ant+Ivy, Maven, Gradle. Скорость сборки чистого прогона, но с прогретым кэшем зависимостей, была 3 сек, 7 сек, 19 сек соответственно.
Я более чем уверен, что если написать майк файл, варка соберется гораздо быстрее.
Слева стоит обычный кулер — встаем в разрыв магистрали на кран для холодной воды, по принципу сообщающихся сосудов будет наполняться. Надо только с уровнем кулера, либо кофемашины поиграться, поскольку на данный момент даже при половинном опустошении кулера контейнер кофемашины перестанет заполняться.
Вопрос был лишь потому, что необходимо понять, почему человек 2 года читает литературу по программированию на JS, но не может найти применение полученным знаниям.
Только теперь мне немного непонятно, почему вы не можете найти применение в столь широкой области как автоматизация процессов технологических производств, тем более на нефтеперерабатывающем заводе. Понятное дело, что в реальные процессы вам никто не даст лезть, однако можно создать, основываясь на имеющихся у вас данных со SCADA систем эмулятор вашего тех процесса и добавить обработчик каких-либо исключений, либо экспертную систему отказов процессов, либо расчет повышения эффективности процесса основываясь на реальных показателях ректификационных колонн, ЭЛОУ на сырье, может быть установок компаундирования. Не знаю конкретно на каком этапе процесса вы находитесь, но в действительности это не так и важно. Смотрите на свою текущую, рутинную работу и улучшайте ее, повторюсь, может на эмулированных данных, но все же.
Главным в процессе практического обучения является применимость в рамках текущих задач, текущей работы.
Вопрос за «тюнинг ядра» на клиентах, ну понятно поигрались tcp, хотя используете udp, но зачем например увеличивать количество подключений по unix-сокетам? Также очень странно выглядит то, что вы отключаете icmp-reply, видимо для повышения безопасности, но в тоже время включаете форвардинг на клиентских нодах. Форвардинг необходим только на ноде с syslog-ng, поскольку там docker, ну и увеличение кол-ва подключений на unix-сокеты, хотя для запуска 4 контейнеров тоже не особо актуально.
Зачем использовать syslog-ng для форвардинга nginx логов на syslog-сервер, если он и сам может слать логи по сети напрямую на tcp/udp сокеты?
Если проект не содержит данной информации, значит просто форкаете и ведете разработку какого-то полезного модуля, либо патча, возможно улучшение блока кода, быть может расширяете функциональность через фиксы TODO, стараясь соответствовать текущему стилю кода, затем создаете пул-реквест, а дальше мейнтейнеры подскажут, где подправить и что подправить, но будьте готовы к критике и, возможно, к тому что ваши изменения не примут.
Ошибок боятся не надо, все мы человеки, все мы ошибаемся. Глаза боятся — руки делают.
Естественно статья писалась вечерами, либо по утру. Однако, притянуть за уши можно что угодно, когда тебе это необходимо. Например, если в статье есть сниппеты с кодом, то вряд ли стиль кода да и общая логика будет отличаться от тех, что используешь на работе, мозг у человека один и работает шаблонами для снижения затрат на интеллектуальную активность и куски кода будут похожи.
Более того, бывает и так, что загружен на работе основными задачами, но очень давно хотелось сделать что-то новое, упрощающее твой рабочий процесс в целом, ты тратишь свое время, а затем используешь полностью готовое решение в компании, но вот только попробуй потом это докажи. Даже коммиты датируемые 1 января никого особо не смущают.
Наворотить, конечно, можно что угодно — "бумага все терпит".
Главное условие, чтобы интерфейс конфигурирования был удобен и понятен для конечного пользователя, равно как присутствовали примеры и хоть минимальная документация в ридми в репе, тогда проблем не возникнет.
Другое дело, если написанная конфигурация не поддерживает что-то, или просто не известно, как это конфигурировать, ввиду отсутствия доков, и для элементарного использования приходится лезть в кишки, то естественно это работать не будет.
Была у нас конфигурация iptables и, очевидно, использовалась повсеместно — сотни серверов, физических и виртуальных("облака" отнесем виртуальным), разные заказчики и конечно разные среды, так вот за 5 лет эта конфигурация прошла лишь 1 мажорную и 2 минорных версии — в первом случае совместимость конфигурации была частично потеряна, ввиду типа передачи параметров, в двух других случаях, естественно нет, хоть и добавлялась поддержка всех таблиц и цепочек, управление ipset.
P.S. Подобный подход в написании конфигураций успешно применяю более 5 лет, работали с ними мои сотрудники разных уровней компетенции и проблем не возникало, кроме того поставленный процесс CI, содержащий тестирование позволял легко проверить конечный результат в считаные минуты, что делало внесение тех или иных изменений простым и предсказуемым.
P.P.S Сталкивался в работе и с подходом одна конфигурация — один енв, максимум хардкода, копипаст между енвами, неправильный уровень абстракции конфигурационной единицы. Одна закравшаяся ошибка разлеталась на кучи енвов благодаря копипасту, управление становилось настолько проблематичным, что в подавляющем большинстве, внесение изменений осуществлялось вручную, а затем подгонялось в конфигурации под сделанное вручную, в лучшем случае — в худшем оставлялось как есть.
Десятки часов работы, зато все при деле=)
Вынужден не согласиться, различные проекты могут использовать одни и те же куски кода, которые Ansible и выносит в такие модули как роли, а поведение ролей и переопределение параметров осуществляется через плейбук.
Допустим на проектах используется haproxy, на одном как балансировщик, на другом как реверс-прокси. Пишется роль покрывающая все эти случаи и используется одна, на всех проектах.
Конфигурация в данном случае выглядит достаточно просто:
Формируется данный конфиг в процессе шаблонизации jinja:
Естественно, что в роли есть еще дефолты других параметров, например параметры запуска демона для юнита, логирования, пользователи, cipher-сьюты сервера для SSL и так далее, и тому подобное. Все они записываются в дефолты и, при желании переписываются в плейбуке. Ansible не самый удобный CM инструмент для подобных вещей, как например SaltStack или тот же Puppet, однако, при желании, можно и его заставить делать то, что требуется:
nspk — Списки нет, а словари запросто.
Далее в роли используем мерженные значения из "{{ haproxy_install }}"
Собственно, пример выше, как раз таки показывает как использовать именно унифицированные роли и отказаться от копи-паста и тонн мусорных репозиториев.
amarao — Нет конечно, но вот шаблонизации через jinja вполне себе.
По вопросу — смысл есть всегда, поскольку Development Operations никогда не был привязан к утилитам или операционным системам. Процессы разработки, равно как их автоматизация и оптимизация присутствуют на всех мыслимых и немыслимых платформах.
Знания Windows платформ и их администрирования достаточно сильно востребовано в разработке игр, системных утилит, из языков C/C++, C#, да и взрастить конвергентную среду с полной интеграцией Windows и Linux серверов, и рабочих станций очень распространенная задача. Например, компания использует AD, аналитики/data-science/художники работают на Windows/MacOS, девелоперы на Linux/MacOS, продакшен енв полностью на Linux — требуется прозрачная авторизация на проде, с применением групповых политик, двухфакторной авторизации, управлением ssh-ключами доступа. Как результат появляется задача — настройка федеративных отношений между AD, FreeIPA, интеграция с UbiKey.
Еще часто востребованная задача — автоматическая подготовка окружения сборки для триумвирата(Linux/Windows/MacOS), либо вообще кросс-компиляция, правда последняя обычно на Linux осуществляется=)
Пробуйте, учитесь, развивайтесь.
Что же, скотской она становится, когда ожидания и реалии не совпадают, когда требования к реализации не соответствуют административным ресурсам, когда ответственность не совпадает с полномочиями. Большинство проблем в данной области связаны именно с административными ограничениями и/или недоработками. С техникой просто решать вопросы, а вот с людьми нет.
Относительно смысла жизни — не уверен, что он связан с каким бы то ни было типом творчества, но здесь каждому свое. Однако, и разработка, и автоматизация тоже вид творчества и умалять это не стоит.
Можно просто на коленке что-то нафигачить, а можно продумать архитектуру решения, оценить риски, сбалансировать экономические затраты и создать действительно произведение инженерного искусства.
Кто как, а я лично испытываю истинное наслаждение от хорошо реализованных систем автоматизации, нежели от полотен Рубенса или творчества композиторов.
Ну что же вы снова выдираете админов из контекста:)
Я же говорю, что в большинстве случаев к нам приходят именно админы:)
есть несколько проблем которые я попытался затронуть, наверное зря я их скомкал в одной статье, потому и показалось кому-то, что вопрос именно в стоимости — это не так. Кто-то усмотрел, что я вижу в этой специальности админа — тоже некорректно.
DevOps — подход/владелец процесса, позволяющий организовать Процессы разработки (Development Operations) наиболее оптимальным способом в каждой конкретной ситуации, участвуя в таких смежных дисциплинах, как разработка, тестирование, управление поставками, планирование поставок. DevOps, не важно как персона или процесс, включает в себя функции и системного администратора, ops'a кому угодно, и билд-инженера, и даже продукт-оунера, если под продуктом подразумевается процесс поставки, и еще много различных прикладных дисциплин инженерии, в том числе управление рисками.
Это понимание достаточно большого пласта аспектов процессной организации и технических реализаций и возможных ограничений.
Как и написано в статье:
«Для выполнения подобного рода работ и обязанностей данная персона должна иметь средства управления не только процессами разработки, тестирования, но и управления инфраструктурой продукта, а также планирования ресурсов. DevOps в данном понимании не может находится ни в IT, ни в R&D, ни даже в PMO, он должен иметь влияние во всех этих областях — технический директор компании, Chief Technical Officer.»
Касательно стоимости — да, человек, что способен управлять таким набором ожиданий и ограничений, назовем его DevOps, действительно может и должен стоить дорого.
Реалии же рынка таковы, что за лейблом DevOps Engineer, в действительности, часто скрываются именно системные администраторы, умеющие пользоваться теми или иными модными утилитами, зачастую не понимая их функции, назначения, возможностей.
Я собеседовал себе в команду очень большое количество «DevOps» инженеров различных грейдов и в подавляющем большинстве это были именно системные администраторы — IT operations, если угодно.
Если на стадии Junior еще можно не понимать какие-то аспекты разработки, а просто строить как видишь, руководствоваться напрямую, без осмысления, информацией от разработчиков — тоже нормально, опыт есть переосмысление ошибок прошлых, то вот на грейдах от Middle и старше это практически непозволительно.
IT Operations не просто так выставляет определенные ограничения на продуктивных средах, это тоже опыт, опыт поддержания систем в высокой доступности и некорректные действия со стороны разработчика, пусть даже по незнанию, не должны все похоронить. Так появляются регламенты, правила, к слову правило не деплоится в пятницу вечером ровно также появилось. Опыт старших грейдов персоналий участвующих в Development Operations позволяет учесть и оценить риски, возможные взаимные влияния Development и Operations, за счет чего, собственно, и достигается гибкость и скорость.
Вилки з.п. у нас достаточно широкие, я сам бился за их расширение, однако даже это не позволило набирать готовых инженеров, способных на исполнение обязанностей с минимальным обучением, их основная проблема — отсутствие именно процессных знаний, иногда даже основ.
Вакансии компаний представлены, дабы показать, что этим компаниям не нужен DevOps, наоборот, они ищут именно системных администраторов, способных покрыть ту или иную область и, если бы они точнее описали свои желания, они бы поняли, что им нужен системный администратор, способный к быстрым изменениям в инфраструктуре, читать как не закостеневший человек с политикой — «держать и не пущать».
Потому и получается например, что нам приходится брать Operations и добавлять принципы и подходы Development, также пытались в обратку, но единицам из Development интересны Operations, рассматриваются в большинстве случаев лишь как ненужные ограничения.
Я не говорю о стоимости ИТ-специалистов в мире, сравнивать зп между странами в лоб, будет некорректно, и не говорю о разнице в ней между США, Финляндией, Россией, Англией и т.д., естественно разница высока, но и стоимость жизни, равно как размер налогообложения.
Относительно дороговизны — все понимают, что при переходе в Senior грейд, рамки между стоимостью специалистов стираются и Senior DevOps Engineer может стоить столько же, сколько Senior Render Engineer, Senior C++ Developer и т.д. Но Senior должен быть действительно Senior, а не обычный тулзист.
немного о том, что в действительности ожидают от соискателей;
немного о неправильных подходах в компании и подмене понятий,
в общем обо всем понемногу.
Понять не могу зачем в Intellij продуктах во встроенной консоли переопределили поведение на использование Ctrl+C/Ctrl+V.
Вообще, меня всегда удивляет, когда берут достаточно жирную тулу, читать как комбайн, а затем для ускорения сборки отключают zip — это как купить автомобиль для повседневной езды, но для снижения времени разгона выкинуть сиденья или для повышения устойчивости сделать жесткую подвеску в ущерб комфорту.
Мое мнение, если хочется сделать эту сборку быстрой, нужно убрать оверхед удобства.
Как-то на тренинге я сравнивал время сборки примитивной варки тулами Ant+Ivy, Maven, Gradle. Скорость сборки чистого прогона, но с прогретым кэшем зависимостей, была 3 сек, 7 сек, 19 сек соответственно.
Я более чем уверен, что если написать майк файл, варка соберется гораздо быстрее.
Либо шашечки, либо ехать.
*сарказм*
Только теперь мне немного непонятно, почему вы не можете найти применение в столь широкой области как автоматизация процессов технологических производств, тем более на нефтеперерабатывающем заводе. Понятное дело, что в реальные процессы вам никто не даст лезть, однако можно создать, основываясь на имеющихся у вас данных со SCADA систем эмулятор вашего тех процесса и добавить обработчик каких-либо исключений, либо экспертную систему отказов процессов, либо расчет повышения эффективности процесса основываясь на реальных показателях ректификационных колонн, ЭЛОУ на сырье, может быть установок компаундирования. Не знаю конкретно на каком этапе процесса вы находитесь, но в действительности это не так и важно. Смотрите на свою текущую, рутинную работу и улучшайте ее, повторюсь, может на эмулированных данных, но все же.
Главным в процессе практического обучения является применимость в рамках текущих задач, текущей работы.
Зачем использовать syslog-ng для форвардинга nginx логов на syslog-сервер, если он и сам может слать логи по сети напрямую на tcp/udp сокеты?
Так может не стоит продолжать раз так туго идет, зачем себя насиловать? Может стоит посмотреть в сторону других языков, технологий?
Каждый крупный проект содержит список требований, ограничений, равно как и рекомендаций:
Если проект не содержит данной информации, значит просто форкаете и ведете разработку какого-то полезного модуля, либо патча, возможно улучшение блока кода, быть может расширяете функциональность через фиксы TODO, стараясь соответствовать текущему стилю кода, затем создаете пул-реквест, а дальше мейнтейнеры подскажут, где подправить и что подправить, но будьте готовы к критике и, возможно, к тому что ваши изменения не примут.
Ошибок боятся не надо, все мы человеки, все мы ошибаемся. Глаза боятся — руки делают.
Более того, бывает и так, что загружен на работе основными задачами, но очень давно хотелось сделать что-то новое, упрощающее твой рабочий процесс в целом, ты тратишь свое время, а затем используешь полностью готовое решение в компании, но вот только попробуй потом это докажи. Даже коммиты датируемые 1 января никого особо не смущают.