core team
1 core team
костяк команды
Так обычно называют немногочисленную основную группу, которая возглавляет работу над определенным проектом или же управляет оперативной деятельностью.
[ Департамент лингвистических услуг Оргкомитета «Сочи 2014». Глоссарий терминов ]
core team
Usually refers to a small central group of people who either manage a specific project or are key managers for an operation.
[ Департамент лингвистических услуг Оргкомитета «Сочи 2014». Глоссарий терминов ]
Тематики
2 core team
3 core team
См. также в других словарях:
Core-Team — Als Kernteam (englisch core team) bezeichnet man die Personengruppe in einem Unternehmen oder Projekt, die die Hauptarbeit am Fortschritt trägt und koordiniert. Für Softwareprojekte gilt: Im Gegensatz zu der meistens viel größeren Zahl an… … Deutsch Wikipedia
CORE — ist das englische Wort für Kern und bezeichnet: den hydrophoben Kernbereich eines Proteins, siehe Core (Protein) den Reaktorkern eines Kernkraftwerks den früheren Namen der Band Core22 einen Film: The Core – Der innere Kern die deutsche Kitefirma … Deutsch Wikipedia
Core — ist das englische Wort für Kern und bezeichnet: den hydrophoben Kernbereich eines Proteins, siehe Core (Protein) eine innere Proteinstruktur bei Viren, siehe Kapsid Core = Fondsmanagementstil im Bond Bereich den Reaktorkern eines Kernkraftwerks… … Deutsch Wikipedia
team roles — Modeling is a team effort. Each USPS BPR team member must be assigned one or more roles to ensure that the team meets its objectives. Some of the roles require a full time effort; they are called the core team roles. Other roles require part time … Glossary of postal terms
core — [[t]kɔ͟ː(r)[/t]] ♦♦♦ cores, coring, cored 1) N COUNT: oft n N The core of a fruit is the central part of it. It contains seeds or pips. Someone threw an apple core. Peel the pears and remove the cores. 2) VERB If you core a fruit, you remove… … English dictionary
Core self-evaluations — (CSE) represent a stable personality trait which encompasses an individual’s subconscious, fundamental evaluations about themselves, their own abilities and their own control. People who have high core self evaluations will think positively of… … Wikipedia
Core Design — Former type Defunct Industry Computer and video game industry Fate Acquired by Eidos Successor … Wikipedia
Core Security Technologies — Core Security Type Private Industry Computer Security Vulnerability Management Security Consulting Services Founded 1996 Headquarters … Wikipedia
Core — may refer to: Contents 1 Science and Academics 2 Computers and Technology 3 Media … Wikipedia
Core Design — Limited Rechtsform Limited Gründung 1988 (aus Gremlin Derby) Auflösung … Deutsch Wikipedia
Интервью с Александром Макаровым, Yii core team
Один из ключевых разработчиков Yii, Александр Макаров(SamDark), выступит на DevConf с докладом про пакетные метрики и я воспользовался возможностью задать несколько интересующих меня вопросов про новую версию Yii, новую ORM, сбор денег на OpenCollective, фулл-тайм open source разработку и немного про конференции.
Начну с вопроса, который тебе задают постоянно. Что с Yii? Когда Yii 3? Я довольно долгое время наблюдаю активное создание новых пакетов в github.com/yiisoft
С Yii всё нормально. Ну почти. Чтобы объяснить, нужно немного посмотреть назад.
Когда мы делали версию 2.0 мы несколько переоценили свои силы. Оно и понятно, Qiang Xue сворачивал горы каждый день и казалось нам по силам всё и сразу.
Потом, к сожалению, времени на OpenSource у него не хватило, и поддержка сделанного скушало всё время остальной команды. Ну а так как фуллтайм фреймворком никто не занимался, это выливалось в то, что релизы были не частыми и большими. Вдобавок, при проектировании тогда мы наделали ошибок. Сейчас мне они кажутся очевидными, но тогда мы думали, что так хорошо. Их, к счастью, не так много. Они не делают Yii 2.0 плохим, фреймворк вышел хороший. Но они вылились со временем в то, что обещание обратной совместимости, множество фич и дефицит времени дали нам проблемы с развитием фреймворка: внедрением PSR, ухода от закрытости к общим для всего PHP пакетам и библиотекам, улучшением по части применения более сложных подходов к разработке, лучшей тестируемости.
Была попытка отделаться эволюцией. Я в это какое-то время верил и говорил про версию 2.1. Но, технический долг был уже слишком большим. Получился бы не очень хороший фреймворк в котором не было бы смысла. И вот, в какой-то момент пришло осознание, что придётся рефакторить всё и много, а многие части даже выкидывать и переписывать. Но перед тем, как бросать в бой, я хорошо посидел и порефлексировал. Обозначил для себя то, что хочется исправить, принципы построения 3.0 и ценности Yii как организации. Это вылилось в несколько документов:
Далее началась работа по выделению отдельных пакетов и в процессе перечитаны и переосмыслены принципы построения пакетов Роберта Мартина. Пакеты на самом деле не совсем новые. Это части Yii2, которые, по большей части, можно использовать отдельно.
Но есть и новые, такие как:
Процесс ещё не завершён, поэтому рост количества пакетов будет продолжаться. С ними сейчас не просто, но впоследствии будет всё это намного легче поддерживать.
Помню у вас было в планах использование некоего нового ORM, о котором мало кто знает. github.com/cycle/orm Я пока не удосужился с ним ознакомиться подробно, расскажешь, чем он отличается от других и чем привлек тебя?
Да, это действительно Cycle. Реализовал её Антон Титов, автор roadrunner.dev. Документация там пока не вполне актуальна, так что, если не готовы читать исходник, лезть внутрь рановато.
Мы с Антоном долгое время общаемся. У него был тогда in-house фреймворк и он задавал вопросы на тему как и что устроено в Yii, что мне нравится и не нравится в Active Record. Обсуждали и плюсы-минусы Doctrine. Иногда созванивались и Антон показывал, как и что там у него сделано и я много раз говорил, что мол в Yii это удобнее.
В какой-то момент говорить так я начал меньше и понял, что из Cycle может получиться что-то глобально интересное. В то время там уже был похожий на Yii query builder синтаксис, концепт relations и много чего ещё. Особенно подкупало то, что в production у Антона RoadRunner и ему критично было то, чтобы Cycle не тёк, не кушал лишней памяти и не разваливался при ошибках в пакетной обработке данных.
На самом деле, я последний раз детально смотрел Cycle ещё весной и решение взять его по умолчанию для Yii не принято. Это пока только вариант. Но одно понятно: мы не будем завязываться на Active Record для валидации, форм и так далее. Это всё должно работать с чем угодно: с DTO, с Doctrine entity, с Cycle.
Да, мы действительно стартанули кампанию по сбору средств потому как времени на Yii 3 требуется больше, чем раньше только на поддержку Yii 2. Focused core developer не означает что это будет full-time (сумма всё-таки не сопоставима с коммерческим фуллтаймом), но означает что практически каждый день один разработчик будет уделять значительное время фреймворку не отвлекаясь на горящий продакшн, дедлайны, проблемы команды и вот это всё. То есть это не только больше времени, но и хороший фокус мыслей без сильно отвлекающих факторов.
Первым таким разработчиком буду я. По достижении цели попробуем поднять планку и расширить это на ещё одного члена core team.
Вся эта возросшая активность скорее всего связана с тем, что у тебя наконец появилось время. Ты работал в Skyeng, ушел оттуда(о причинах и подробностях можно почитать здесь — rmcreative.ru/blog/post/poka—skyeng ). Продолжаешь заниматься только open source? Как ощущения? Семейный бюджет?
Да, всё так: появилось время и Yii сильно поднялся в приоритетах целей. Занимаюсь я почти только OpenSource. Сейчас OpenCollective позволяет платить почти по всем счетам. Иногда беру какие-то небольшие подработки вроде ревью кода, процессов или безопасности, оформления OpenSource библиотек, поиска людей для компаний (знакомые хорошие разработчики, бывает, тоже ищут), но не много, чтобы не вредить разработке фреймворка.
Ощущения… всякие. Это действительно то, что мне нравится делать. Радует, что получается отличный инструмент. Радуют люди, которым Yii не безразличен и которые помогают. Нравится выступать на конференциях.
Иногда груз ответственности давит. Хочется отдохнуть, но «надо» заставляет что-то делать. Чаще всего в таком настроении ничего дельного не выходит, так что пытаюсь всё-таки убедить себя, что отдых заслуженный.
Ну и понимание что впереди ещё очень много работы тоже ощущается не очень. Хотя, если каждую неделю посматривать на сделанное, становится понятно, что сделать это всё реально и что мы это сделаем.
С нетерпением жду того момента, когда можно будет объявить альфу и получить первые гневные отзывы 🙂
Я еще помню ты открывал что-то вроде кофейни, и может даже не одну. Бизнес для души? Много времени отнимает?
В мае ты был одним из организаторов конференции PhpRussia. Как она прошла?
Для чего рядовому разработчику посещать такие конференции?
Ну и наконец про твой доклад. «Теория программирования: пакетные принципы и метрики». Ты упомянул Роберта Мартина и его мысли про пакеты. Насколько это применимо в мире PHP? В мире компилируемых языков делить один проект на несколько пакетов, которые компилируются в отдельные сборки — вполне нормальная практика и там действительно нужны некие правила. В PHP же мы обычно говорим о composer-пакетах, которые немного другое, и эти принципы с метриками нужны разве лишь для проектов уровня Yii3. Нет?
Это вполне применимо к PHP. Конечно, прежде всего это нужно для проектов уровня Yii, Symfony или Laravel, но и для коммерческих проектов это также имеет смысл. Пакетные метрики можно применять не только к пакетам Composer, но и к модулям кода, микросервисам и так далее.
DevConf пройдет 21-22 июня и до него осталось всего 2 недели. Крепкие доклады, возможность обсудить кучу вопросов в кулуарах или на кофебрейках и получить хороший позитивный заряд на долгое время — регистрируйтесь.
Postgresso 26
Жизнь продолжается. А мы продолжаем знакомить вас с самыми интересными новостями PostgreSQL.
Напоминаем о неписанном правиле сообщества: в Core Team не должно быть большинство из одной компании. После слияния-поглощения EDB 2ndQuadrant 3 из 5 участников Основной Команды оказались коллегами по EDB. К счастью, никого не сократили, а добавили двух достойных: Андреса Фройнда (Andres Freund, Microsoft, Citus) и Джонатана Каца (Jonathan Katz, Crunchy Data).
Любимые области Андреса Фройнда: репликация, производительность и масштабируемость (смотрите три недавние статьи на эту тему, ссылки в нашем разделе Статьи. Производительность), хранение.
Джонатан Кац (Jonathan Katz, Crunchy Data) занимался патчами и ревью, но больше концентрировался на разработке и поддержке сайта, выпуске релизов и прочей сопутствующей, но необходимой деятельности. Он вообще важный человек: председатель совета директоров Ассоциации PostgreSQL в США (United States PostgreSQL Association) и директор Ассоциации PostgreSQL-сообщества Канады (PostgreSQL Community Association of Canada), которая выступает как юридическое лицо сообщества.
Прекрасное, взвешенное решение. Впрочем, не все с этим согласны: Альваро Эрнандес (Álvaro Hernández Tortosa — если полностью) поздравил новоизбранных (непонятно кем и непонятно как — по его мнению) и предложил задуматься над следующими 10 проблемами управления сообществом:
Я опустил детали в обращении Альваро. Ещё одна из упомянутых им проблем (существующих с точки зрения Альваро): Core Team это «центральный орган» проекта. А юридически проект представляет Postgres Association of Canada, определяя в том числе интеллектуальную собственность: доменные имена, торговые марки и прочее. Как бы чего не вышло.
Анастасия Лубенникова из Postgres Professional стала распорядителем текущего коммитфеста. В этом ей помогает Георгиос Коколатос (Georgios Kokolatos).
А ещё Анастасия входит в Комитет по этике (Code of Conduct Committee) сообщества (а Илья Космодемьянский вышел из комитета).
Кстати, благодаря то ли Альваро, то ли общему настроению, Комитет по этике объявил вакансии: нужны люди из разных стран и разных народов, чтобы отразить многообразие PostgreSQL-сообщества. Пишите на coc@postgresql.org
Документация к PostgreSQL 13.0
The PostgreSQL Global Development Group объявила о доступности русской документации к версии 13. Перевод на русский язык — компания Postgres Professional. Официальная страница русскоязычной документации.
Обучение
Статьи
Масштабируемость и производительность
Андрес Фройнд (тот самый, кто только что обосновался в PostgreSQL Core Team) опубликовал серию из 3 статей о производительности PostgreSQL при большом числе соединений. Они дублируются в блоге Citus и в блоге Microsoft (пока 20 лайков, 2 подписчика).
В статье об издержках памяти начинается с популярного мотива — а если бы треды, а не процессы? Спойлер Андреса: если аккуратно померить, то издержки меньше 2 мебибайта. А неаккуратно — это при помощи top и ps.
Андрес исследует узкие места с тем, чтобы далее предложить путь их решения, и аргументирует не только из общих соображений, а с примерами и листингами. Раздувание кеша (cache bloat) тоже (как и оверхед при форке) не критично. Управление work_mem тоже удовлетворительно. А собака зарыта в куче снэпшотов: функция GetSnapshotData() дорогая и вызывается часто. Вывод: надо менять саму модель соединений (connection model), а может и модель исполнения запросов (query execution model). А от себя добавим: эта тема более, чем активно обсуждалась в рассылке hackers. Более того: в Postgres Professional давно ведутся разработки в этом направлении. Начиная с 12-й версии в Postgre Pro Enterprise Edition есть встроенный пул соединений. Это не совсем то, что сделал Андрес, но это тоже в тему масштабируемости клиентских соединений.
За диагностической 2-й статьёй следует 3-я — конструктивная: предложения Андреса уже в форме патчей, которые должны войти в версию PostgreSQL 14:
Другую серию — из 3 статей в жанре от 8.3 и до 13 — опубликовал Томаш Вондра (Tomas Vondra, 2ndQuadrant — то есть EDB).
В этой статье Томаш сначала объясняет замысел серии: почему начал с 8.3, почему именно эти тесты, зачем ему тестировать полнотекстовый поиск, на какой машине тестировать. Он не ставит цели сверхкорректного сравнения, это скорее упражнение для лучшего понимания PostgreSQL. До 8.3 он уж слишком отличался от нынешнего, охват и так недурен: 12 лет. А машина — обычный офисный компьютер.
Графики с NVMe SSD ведут себя прилично: производительность в основном монотонно растёт с номером версии. А вот с SATA творятся чудеса: c SATA RAID в режиме чтения некоторые флюктуации и, похоже, регресс в версии 9.6. А вот на записи-чтении грандиозное ускорение с версии 9.1 — в 6 раз!
Томаш уверен, что постгрессистам придут в голову блестящие идеи, как эффективней использовать ресурсы железа. Патчи по улучшению масштабирования соединений или патч по неволатильным буферам WAL тому пример. Можно ждать радикальных улучшений в хранении (более эффективный формат файлов на диске, использование прямого ввода-вывода, например), более эффективные индексы.
Для измерения производительности на аналитических нагрузках Томаш запускал бенчмарк TPC-H (его ещё называют бенчмарком принятия решений — decision support), получал результаты, которые можно анализировать ещё очень долго, нарисовал красивые графики, и сделал свои выводы — в меру отпущенного на это времени.
В TPC-H 22 запроса на 3 наборах данных: малом, среднем и большом. Томаш гоняет их на версиях от 8.3 до 13, да ещё и то включает, то отключает параллелизм. Коэффициенты масштабирования (scale factor) он выбирает такие: 1 (цель — поместиться в shared-buffers), 10 (в память) и 75 (не поместиться в память). Комбинаций — море, для анализа — простор. Иногда автор действительно «опускается» до отдельных запросов и анализирует причины странного поведения. Кривая производительности немонотонно меняется с версией, а по отдельным запросам скачет совсем неожиданно. Причина простая: планировщик и оптимизатор умнеют с новыми версиями за счёт новых планов и/или за счет новых способов использования статистики, но оборотная сторона — промахи: неверный выбор плана из-за плохой статистики, оценок стоимостей или других ошибок. Примерно то же и с параллелизмом: появляются новые планы, но если стоимости и оценки расходятся с реальностью, выбираются планы, хуже старых, последовательных.
Диаграмма из статьи TPC-H performance since PostgreSQL 8.3. Можно было поместить в наш раздел Прекрасное.
В преамбуле Томаш рассказывает историю FTS в PostgreSQL, которая началась с Олега Бартунова и Фёдора Сигаева лет за 20 до основания Postgres Professional. Далее Томаш сетует на отсутствие индустриальных стандартов тестирования полнотекстового поиска и обращается к собственным ресурсам ПО: в незапамятные времена он сочинил утилиту archie – парочку питоновых скриптов, которые загружают архивы переписки PostgreSQL, превращая их в базу, которую можно индексировать, в которой можно искать тексты. Сейчас в таких архивах около миллиона строк — 9.5 ГБ не считая индексов. В качестве тестовых запросов он взял 33 тыс. реальных поисковых запросов к архиву на сайте PostgreSQL.org.
Фёдор Сигаев и Олег Бартунов. Фотография из статьи Full-text search since PostgreSQL 8.3
Кроме того Томаш тестировал влияние индексов GIN и GiST. Оба запроса с использованием GIN дают огромный скачок в производительности — в 4 с лишним раза! Томаш благодарит за это Александра Короткова и Хейкки Линнакангас (Heikki Linnakangas), придумавших патч Improve speed of multi-key GIN lookups. А вот если использовать GiST, то ничего хорошего вообще не будет. А будет плавная деградация. Почему ж никто не жаловался? — вопрошает автор и предполагает, что вместе с апгрейдом версий многие апгрейдили и железо, и это маскировало эффект. Или просто не использовали GiST для текстового поиска.
Олег, Теодор [Фёдор] и их коллеги — напоминает Томаш — работали над более мощными вариантами GIN-индексов — VODKA и RUM [примечание редакции: об индексах RUM, о том, чем они лучше GIN, о расширении rum можно почитать здесь. Про водку не будем :)]. Это как минимум поможет некоторым типам запросов. Особенно автор надеется на улучшение поддержки новых типов полнотекстовых запросов, так как новые типы индексов спроектированы для того, чтобы ускорить фразовый поиск (см. там же).
Кстати, о текстовых файлах и поиске в них. Вот 196640 книг (файлов) в текстовом формате. Их, скорее всего, будут использовать для обучения больших сетей, но можно их, скажем, использовать и в каких-нибудь тестах производительности текстового поиска или ещё каких-то манипуляций текстом. Собирали тексты энтузиасты с the-eye.eu (почему-то недоступного честному пользователю из РФ).
Эта статья Павла Лузанова из отдела образования Postgres Professional и о производительности тоже: постольку, поскольку патчи, принятые на этом коммитфесте, имели отношение к производительности (о патчах Андреса, которые он упоминал, там тоже есть). Это, как и Часть 1 (Коммитфест 2020-07), MUST READ для тех, кто следит за технологическими новшествами PostgreSQL — без IMHO.
Жизнь в PostgreSQL
Открывает эту мемориальную подборку ссылок недавняя статья Егора Рогова: «Жизнь» на PostgreSQL
Некто Сергей aka ildarovich делает это на языке запросов 1С, а точнее одним запросом: Игра «Жизнь» в одном запросе
На JS, огромная статья, очень красивая визуализация: Эволюционирующие клеточные автоматы
Кстати, о Конвее: Джо (Joe), однофамилец классика клеточных автоматов (в прошлом выпуске мы ссылались на статью 2007-го года про то, как использовать PL/R для GIS) теперь, в начале ноября 2020, пишет на тему сверх-актуальную:
Он использует пакеты mvtnorm (3 алгоритма нормального распределения), politicaldata (специальные тулзы для сбора и анализа политических данных) и tidyverse (разные средства анализа данных). Для развлечения Джо предлагает разобраться в немалом количестве строк кода, создаёт свой тип данных и ещё предлагает придумать SQL-запросы в качестве упражнения.
Релизы
А также 12.5, 11.10, 10.15, 9.6.20 и 9.5.24. В новых версиях исправлены обнаруженные баги, в том числе связанные с безопасностью. Сейчас мы не будем на них останавливаться. Они описаны на этой странице.
Николай Самохвалов и Артём Картасов из Postgres.ai (Артём делал бОльшую часть кода) на Постгрес-вторнике 3 ноября рассказали (за полтора часа) о Database Lab 2.0 — новой, сильно отличающейся версии своей среды для тестирования и разработки с «тонкими клонами» (при клонировании копируются только измененные блоки).
pg_statement_rollback — это расширение Жиля Дароля (Gilles Darold), Жульена Руо (Julien Rouhaud) и Дэйва Шарпа (Dave Sharpe), которое реализует в PostgreSQL откат транзакции на уровне оператора (server side rollback at statement level for PostgreSQL) как в Oracle или DB2. Это значит, что при ошибке в выполнении оператора его результаты не видны — как будто оператора и не было. При этом результаты операторов, выполненных в транзакции до этого, не теряются. В PostgreSQL это можно было сделать только на клиенте, в psql, например:
Теперь всё будет работать на сервере таким образом, как будто для каждого оператора серверу посылаются
— а такая роскошь раньше могла сказаться на производительности. Авторы дают результаты тестов TPS-B и честно рассказывают о проблемах.
Бета-релиз расширения pgbitmap, доступно на pgxn и github.
Это расширение Марка Манро (Marc Munro) создаёт тип pgbitmap с полным набором функций, операторов и агрегатов. Он отличается от стандартных типов Postgres bit и bit varying тем, что строка не начинается с нулевого бита и тем, что набор операций намного богаче. Этот тип разрабатывался под Virtual Private Database для управления привилегиями. В этом релизе исправлены ошибки, он считается релизом-кандидатом. Сейчас открытых багов не осталось — присылайте, если найдёте.
Документация здесь.
Зависимостей теперь мало. Работает на Python 2.6+. Исходники здесь.
Появилась поддержка PostgreSQL 13. Загружать отсюда. Чейнджлог недоступен, за информацией велено обращаться к info@2ndQuadrant.com.
Есть и другие изменения, о которых можно узнать здесь. Сорсы находятся здесь, а инструкции по инсталляции здесь.
Прекрасное
Скриншоты не передадут гипнотической мощи этой динамической инфографики от DB weekly. Это кино увлекательно, познавательно воодушевляюще и даже чуть-чуть отрезвляюще в то же время.
а через 14 лет популярность PostgreSQL выросла более, чем в 2 раза:
Интерактивный шедевр наглядности & информативности (этот скриншот в подмётки не годится). Автор Алексей Лесовский из DataEgret.
Конференции
Внимание: переносится! Новые даты конференции 17 и 18 февраля 2021 года!
Одна из самых любимых PG-народом конференций — Postgres Ibiza 2020 — должна состояться в 2021 году 23-25-го июня (дата предварительная). Следите за новостями на pgibz.io или на сайте FUNDACIÓN POSTGRESQL — сообщества с испаноязычным уклоном. Про Бали пока не слышно.
Виртуальная европейская конференция по PostgreSQL, посещение бесплатное. Фокус на кейсы реальных клиентов. Пройдёт 8-9 декабря 2020 он-лайн. Twitter и LinkedIn: #postgresbuild.
