Это неделя с открытым исходным кодом в SitePoint! Всю неделю мы публикуем статьи, посвященные всему, что связано с открытым исходным кодом, свободным программным обеспечением и сообществом, поэтому постоянно проверяйте тег OSW на наличие последних обновлений.
Apache Groovy — это многогранный язык программирования общего назначения для платформы Java. Хотя в первую очередь это объектно-ориентированный язык с множеством динамических функций, он также поддерживает функциональное программирование, статическую проверку типов и статическую компиляцию. В этой статье рассматриваются некоторые интересные аспекты истории Groovy и некоторые важные руководящие принципы, которые помогают поддерживать активный проект с открытым исходным кодом.
Что такое Groovy и почему меня это должно волновать?
Существует множество доступных языков программирования и несколько популярных альтернатив Java, специально разработанных для работы на JVM, так что же такого особенного в Groovy? Groovy особенно известен своими:
- тесная интеграция с Java и низкая обучаемость
- поддержка нескольких парадигм функциональных и объектно-ориентированных стилей
- гибкий синтаксис и производительные библиотеки
- расширяемость с помощью метапрограммирования
- возможности сценариев
- поддержка доменных языков (DSL)
Это также один из наиболее широко используемых альтернативных языков для JVM с загрузками около 12 миллионов в год и постоянно растет. Но это не статья о возможностях Groovy, а описание роли открытого исходного кода в эволюции Groovy.
Groovy был проектом с открытым исходным кодом с самого начала. Он начался с желания иметь возможность программировать с использованием меньшего количества стандартного кода, чем вы могли бы использовать Ruby, Python или Smalltalk, но на платформе JVM и с использованием синтаксиса, который программист Java нашел бы естественным. Без этой искры вдохновения Groovy не существовало бы, но одно только это вдохновение не привело Groovy туда, где он находится сегодня. Ряд других факторов имеет решающее значение, и необходимо преодолеть различные препятствия. Давайте посмотрим на некоторые из этих факторов — различные столпы, если хотите, поддержка успешного проекта с открытым исходным кодом.
Строим лучшую лампочку, но стоим на плечах гигантов
Ключевым мотиватором многих ранних возможностей Groovy были вещи, которые участники проекта считали необходимыми, но отсутствующими в Java. Тем не менее, команда Groovy была намного меньше, чем команда разработчиков Java. Таким образом, была разработана базовая стратегия, позволяющая Java делать то, что она делает хорошо, и Groovy сосредоточился на пробелах: не делайте все, а делайте то, что делаете хорошо .
Интеграция между ними будет более тесной, чем другие альтернативные языки JVM. Когда вышли новые версии Java, иногда с функциями, вдохновленными тем, что Groovy добавил годами ранее, Groovy просто попытался продвинуть цели дальше с помощью следующего раунда отсутствующих функций.
Сказав это, стоит отметить, что добавление Groovy статической проверки типов и статической компиляции для лучшего устранения ошибок во время компиляции и значительного улучшения производительности несколько перекрывает Java. Несмотря на то, что Groovy позволяет беспрепятственно взаимодействовать между смешанными кодами Java и Groovy, многие пользователи просто не хотели покидать Groovy и вынуждены возвращаться обратно к Java, но хотели получить некоторые из преимуществ статической типизации и проверки типов в Java. Конечно, Groovy, всегда желавший еще больше поднять планку, сделал средство проверки типов расширяемым, чтобы вы могли добавлять свои собственные собственные средства проверки для более строгой проверки, чем Java, если хотите.
Наряду с созданием Java многие ранние функции Groovy были в значительной степени вдохновлены функциями, обнаруженными в Python, Ruby, Smalltalk и других языках — нет необходимости заново изобретать концепцию, просто предоставьте версию, дружественную к JVM и интуитивно понятную для кого-то, имеющего Java-разработчика. склад ума. Примеры таких функций включают в себя:
- Возможности метапрограммирования Groovy и диапазон типов данных заимствовали идеи из Ruby
- нотация списка и литерала карты и синтаксис для параметров по умолчанию были вдохновлены Python
- методы обработки коллекции,
collectиinject, следуя схеме именования Smalltalk - замыкания пришли из мира функционального программирования
В последние годы приятно отметить, что функции Groovy нашли свое отражение в таких языках, как C #, Swift, Scala, Kotlin, Frege и даже Java. Вот некоторые примеры:
- Лямбда-выражения Java можно рассматривать как ограниченную версию замыканий Groovy
- как часть проекта Coin, Java добавил строки для операторов switch (Groovy допускает строки, выражения регулярных выражений, выражения классов и замыкания в качестве возможных целей для оператора case)
- синтаксис для оператора Элвиса
?:теперь используется в PHP, Fantom и Kotlin, хотя они проверяют ноль, а не применяют Groovy правду; многочисленные языки вместо этого добавили оператор для объединения нулей, включая C # и Swift - оператор безопасной навигации
?.сейчас в C #, Swift, Kotlin, Fantom и Ruby (как&.) - оператор космического корабля
<=>теперь на PHP, Ceylon и Ruby - многочисленные динамические языки искали способы добавления статической проверки типов
Тот факт, что Groovy является открытым исходным кодом, а его дизайн и реализация открыты, делает возможным такой обмен идеями; поощрение инноваций и повышение планки для всех языков с открытым исходным кодом .
Профессиональная передовая разработка
Общей характеристикой многих (но не всех) проектов с открытым исходным кодом является высококачественная кодовая база и зачастую новаторское использование передовых методов разработки. Люди, заинтересованные в передовых методах, также часто ищут новейшие технологии, которые могут облегчить некоторые из их болевых точек. Groovy, безусловно, повезло, что такие люди были вовлечены в его сообщество в различных точках. Многочисленные методы и подходы были включены на пути к поддержанию высокого качества кода, улучшению охвата тестами, поддержанию соответствующей совместимости и внедрению лучших в своем классе практических разработок, чтобы снизить барьер входа для потенциальных новых участников и минимизировать рабочую нагрузку для существующих участников проекта. , Два примера, чтобы проиллюстрировать это:
- каждый представленный PR автоматически проверяется на сервере CI; Коммиттеры Groovy знают, будет ли отправка нарушать тесты без необходимости вручную применять и запускать тесты самостоятельно
- Checkstyle был важной дополнительной проверкой источников кода Java, но не работает с кодом Groovy, поэтому проект Codenarc был создан для обеспечения аналогичной среды проверки для кода Groovy.
Может показаться, что у проекта есть сложный набор политик и процедур, которым должны следовать разработчики, но это не так. Действительно, управление проектом, то есть то, как он выполняется, очень легкое. Передовые практики заложены в артефакты проекта, и при необходимости поощряются и усиливаются. По мере того, как новые участники присоединяются к команде, существующие коммиттеры дают рекомендации относительно того, почему что-то было сделано определенным образом в прошлом. Мы скоро вернемся, чтобы немного рассказать об управлении.
Одна из обычно звучащих гибких мантр — выпускать рано, часто выпускать . Конечно, исторически очень медленный цикл выпуска Java и медленное принятие новых функций является одной из причин существования Groovy. Groovy попытался значительно улучшить это, предоставляя новые функции намного раньше и значительно улучшенными темпами. Сказав это, иногда технические проблемы даже замедляют выпуск Groovy, но над этим работают. Конечно, будучи языком, мы не хотим заставлять наших пользователей обновляться каждую неделю, поэтому мы не должны быть такими агрессивными, как некоторые другие проекты.
Держать это весело
Стремясь к профессионализму и качеству, команда проекта также заняла позицию прагматики над теоретической чистотой. Пользователи Groovy хотят делать что-то и получать удовольствие от этого; язык не должен мешать . Имея это в виду, Groovy занял несколько агностическую позицию относительно того, как должен использоваться язык. Он поддерживает объектно-ориентированные и функциональные стили, императивные и декларативные. Это настоятельно поощряет довольно много хороших методов, но не мешает определенному стилю, который может выбрать программист. У этого есть несколько зрелый подход к тому, как следует обращаться с разработчиками . Постарайтесь не позволить разработчикам выстрелить себе в ногу, но не запрещайте им делать это, если они действительно стараются изо всех сил, чтобы сделать это.
Другим аспектом управления проектами, который может ослабить энтузиазм участников, является тяжелый процесс утверждения. Как упоминалось ранее, проект Groovy старается максимально облегчить работу. У этого нет сложного процесса для развития языка как процесс JCP Java . Могут быть предложены, обсуждены и утверждены незначительные, не вызывающие споров, улучшения в языке, путем консенсуса по списку рассылки, подкрепленному предложенным запросом на Github. Для более крупных изменений в языке в Groovy есть процесс предложения по улучшению Groovy (GEP), позволяющий проводить более сложные обсуждения. Хотя не все так просто. Одна из самых сложных частей при запуске проекта с открытым исходным кодом часто заключается не в том, чтобы выяснить, какие новые функции вы могли бы добавить, а в том, чтобы решить, что упустить, или сопротивляться желанию добавить функцию слишком рано, прежде чем ее последствия будут полностью поняты.
При необходимости Groovy имеет формальную структуру управления, к которой можно прибегнуть, поэтому мы можем, например, провести формальное голосование о том, следует ли добавить конкретную функцию или нет. Проект следует типичной модели управления Apache с комитетом по управлению проектом (PMC), ответственным за управление проектом. Таким образом, в итоге, мы стремимся к консенсусу сначала в более широком сообществе, затем в коммиттерах и, наконец, в случае необходимости, КУП.
Наконец, Groovy поддерживает дружескую атмосферу во всем сообществе . Бывают жаркие дебаты, и люди соглашаются не соглашаться, но в целом участники сообщества полагаются на большее благо сообщества. В общем, все работает достаточно хорошо; Пользователи Groovy не хотят бесконечно спорить об академических положениях теории, они хотят делать вещи, развлекаясь . Именно сочетание этих факторов побудило людей начать и продолжать вносить вклад в Groovy или в другие проекты в экосистеме Groovy.
Долголетие за пределами одного человека
Люди участвуют в проектах с открытым исходным кодом по разным причинам. Некоторые могут быть полностью или частично спонсированы их компаниями, другие могут быть волонтерами, которым просто нравится работать с мировым сообществом единомышленников. Учитывая разную мотивацию этих участников, проект с открытым исходным кодом имеет гораздо меньший контроль над тем, когда какой-либо отдельный участник может приходить или уходить по мере изменения их индивидуальных обстоятельств. За прошедшие годы в Groovy приходили и уходили некоторые крупные люди, а также другие, чьи обстоятельства изменили способ, которым они могут внести свой вклад — но проект адаптировался при необходимости и продолжал процветать.
В Groovy было более 300 коммиттеров кода в течение срока его службы, и в среднем за последние 5 лет в среднем насчитывалось более 50 активных разработчиков кода — больше, чем когда-либо ранее. Для тех, кто интересуется десятилетней историей лучших 100 участников, доступны онлайн через графики Github . Многочисленные другие вклады происходят и за пределами кода, в том числе в списках рассылки, форумах и блогах.
Вероятно, наиболее спорным человеком, который проиграл от языка, является один из его основателей, и действительно, большая популярность была поднята, когда основатель Groovy, Джеймс Стрэчэн, плодовитый участник открытого исходного кода, перешел из проекта, чтобы сосредоточить свое время на более приоритетных действиях. Известно, что в 2009 году Джеймс сказал: «Я могу честно сказать, показал ли кто-нибудь мне книгу« Программирование в Scala », написанную Odersky et. и др. в 2003 году я бы, наверное, никогда не создавал Groovy ». Многие в сообществе Scala годами цитировали и неправильно цитировали эти слова. Далее Джеймс пояснил, что никогда не сожалел о создании Groovy, и после глубокого погружения в Scala он несколько изменил свою любовь к языку и перешел на другие языки. В более поздних твитах он хвалил Groovy и демонстрирует слайды, демонстрирующие Groovy в некоторых его недавних беседах. Он особенно любит возможности DSL в Groovy в таких ситуациях, как конвейеры Jenkins в конвейере непрерывной доставки. Возможно, этот твит отражает его нынешнее мышление:
Пики и впадины спонсорства
Организации спонсируют разработку открытого исходного кода по разным причинам. Это может дать им конкурентное преимущество, повысить безопасность, стимулировать инновации, мотивировать персонал, увеличить размер прибыли и время выхода на рынок. Легко понять, почему многие организации так или иначе связаны с открытым исходным кодом. Но чаще всего возможности монетизации приходят как можно выше от «пищевой цепочки программного обеспечения».
Иногда связь между полученными доходами и языком программирования общего назначения, таким как Groovy, может включать несколько уровней. Деньги могут быть получены из приложения, веб-службы или облачного предложения, созданного с использованием инфраструктуры, написанной на Groovy, созданной с использованием Groovy или протестированной в Groovy. Именно по этой причине мы должны приветствовать инвестиции ряда организаций, которые спонсируют людей для работы в Groovy, включая G2One, Canoo, ASERT, SpringSource, VMWare, Pivotal и OCI.
Вероятно, самой известной из этих компаний в сообществе Java в последние годы является Pivotal. Это был дополнительный продукт от VMWare, которая ранее приобрела SpringSource. Groovy (и веб-фреймворк Grails) сформировали часть своего портфеля продуктов. В рамках этой спонсируемой работы был сделан очень ценный вклад, и во многих случаях она была сосредоточена на особенностях, представляющих особую ценность для пользователей Groovy в рамках спонсирующей организации. Но, к чести вовлеченных компаний, никакого жесткого влияния не оказывалось на общее управление языком, что позволяло ему оставаться языком общего назначения, привлекательным для многих людей.
В течение периода спонсорства Pivotal, который длился около 2 лет, вклады сторонних компаний продолжались, а интерес к Groovy продолжал расти. Позже, когда направления Pivotal изменились и их инвестиции в штатных сотрудников Groovy (и веб-каркас Grails) прекратились , проект Groovy снова адаптировался, и вклады из других источников снова стали первостепенными.
Самый простой способ увидеть влияние вывода Pivotal — это посмотреть на цифры. В течение примерно 2 лет спонсорства Pivotal было 6 авторов кода Pivotal и 111 других. В течение 18 месяцев с тех пор было 114 активных участников. В это число входят некоторые из первоначальных сотрудников Pivotal, которые теперь работают под новые должности в другой организации или на добровольной основе. Так что с очень поверхностным анализом может показаться, что цифры не сильно изменились — на самом деле, можно утверждать, что они улучшились, так как второй исследуемый период короче. Но это не будет точным отражением реальности. Некоторые из 6 разработчиков кода Pivotal почти полностью работали над Groovy (некоторые в основном работали над Grails), тогда как некоторые из 111 других, возможно, представили только несколько коммитов за весь двухлетний период.
Немного лучший подход к анализу вкладов — посмотреть количество коммитов. В течение двухлетнего периода спонсорства было в среднем 359 коммитов в квартал, 158 в квартал от сотрудников Pivotal и 201 в квартал от других. С тех пор было в среднем 188 коммитов за квартал. Таким образом, произошло заметное сокращение взносов, так как спонсорство Pivotal прекратилось, но текущий уровень коммитов остается здоровым, и число снова растет.
Следует отметить, что число коммитов отнюдь не является идеальной метрикой. Действительно, фиксация для исправления небольшой опечатки приводит к тому же весу, что и сложная фиксация, добавляя новую функцию, такую как черты или статическая проверка типов — хотя ни одна из них не была (или не должна быть) добавлена с помощью одной фиксации. Возможно, реальное беспокойство по поводу вывода Pivotal заключается в том, что сложные функции (которые лучше всего решать командам) могут быть трудны для развития с большим количеством участников, каждый из которых имеет только небольшое количество времени. Это действительно то, что нужно отслеживать с течением времени. Все, что мы можем сказать, это то, что знаки обнадеживают. Количество участников увеличивается, и некоторые из достигнутых успехов (например, новый анализатор на основе « Parrot » Antlr-4) превосходят прогресс, достигнутый в любой предыдущий раз.
Там нет места, как дома
В первые годы работы Groovy его дом был частью портфеля проектов с открытым исходным кодом Codehaus. Codehaus сыграл важную роль в обеспечении необходимой инфраструктуры для первых дней Groovy. Он предоставил нам полный набор лучших в своем классе инструментов: контроль исходного кода, списки рассылки, отслеживание проблем, загрузки, веб-сайты / вики, непрерывные сборки и чат — все это еще до того, как Github или облачные CI-сервисы, такие как Travis CI, даже существовали. То, что Codehaus взял на себя бремя хостинга и поддержание всей необходимой инфраструктуры для запуска успешного проекта с открытым исходным кодом, позволило команде проекта сосредоточиться только на создании лучшего Groovy, который они могли. Codehaus были довольно хороши в внедрении полезных новых технологий, поэтому Groovy довольно рано применил распределенный контроль версий, что открыло лучший рабочий процесс для развития кодовой базы. Вскоре проект также начал использовать Github. В дополнение к репозиторию git, предоставленному Codehaus, веб-процесс Github для клонирования репозиториев и создания запросов извлечения значительно снизил барьер входа для потенциальных новых участников, и в то же время минимизировал накладные расходы для команды проекта при проверке, обсуждении и принятии. новые вклады.
Примерно в то же время, когда заканчивалось спонсорство Pivotal, организация Codehaus свернула свою службу хостинга с открытым исходным кодом. С приближением закрытия Codehaus Groovy необходимо было найти альтернативный «хостинг» для своих инфраструктурных потребностей — только один Github не воспринимал все, что нам нужно. При обсуждении вариантов в сообществе был поднят вопрос управления проектом. У Codehaus было де-факто управление, под которым работал Groovy. Сообщество хотело быть уверенным в том, что где бы ни находился Groovy, не только технические артефакты проекта (кодовая база, архив рассылки, архив выпусков и т. Д.) Благополучно пережили этот шаг, но управление проектом в будущем оставалось дружественным к нашему существующему. пользователи и партнерские проекты в экосистеме Groovy.
Именно после многочисленных обсуждений с этими мыслями Apache Software Foundation стал основным претендентом на место назначения для Groovy. Он предоставил свою собственную инфраструктуру, аналогичную Codehaus, позволил нам поддерживать рабочий процесс с участием Github, который удобен для наших пользователей, и, что наиболее важно, он обеспечил надежную модель управления и сильный акцент на сообществе. Мало того, что мы уже знакомы с многочисленными коллегами-разработчиками из сообщества Apache, но и степень, в которой он охватывает сообщество, показалась подходящей для Groovy. К нашему большому удовольствию, переход на Apache пролил свет на Groovy, и пользовательские вклады и загрузки никогда не были выше, а языковой рейтинг использования увеличился; мы нашли наш новый дом .
Groovy экосистема и сообщество
Обсуждение Groovy было бы неполным без упоминания нашего основного класса пользователей. Наши аналогичные проекты в экосистеме Groovy, включая, помимо прочего, Grails, Spock, Ratpack, Gradle, GPars, Griffon и Jenkins. Эти и многие другие подобные проекты предоставляют высокоуровневые сервисы или платформы, основанные на Groovy. Многие пользователи этих проектов в конечном итоге используют Groovy, а некоторые даже не осознают этого факта. Без обратной связи и поддержки этих проектов Groovy не был бы таким полезным языком.
Наконец, было бы упущением не упомянуть многих пользователей Groovy за эти годы, многие из которых предоставили обратную связь и привели к многочисленным изменениям в языке. Groovy сегодня — это огромное улучшение по сравнению с тем, что было когда-то. Есть еще множество улучшений, которые мы хотели бы сделать, и огромный набор функций и идей, которые ждут своего часа. Участники и сообщество — это то, что поможет сделать эти изменения реальностью. Надеюсь, вам понравилось узнавать о некоторых опорах, которые поддерживали развитие Groovy. Почему бы не попробовать язык или прийти к нам в гости .