Помогает ли Open Source найти работу?
Open source-разработчик Михаил Грачев:
«Считаю, что open source-проекты могут помочь в поиске работы. Как и активный профиль на GitHub, кстати. Многие HR-специалисты уже давно используют GitHub, как площадку для поиска новых разработчиков. Готовые open source-проекты часто помогают избежать выполнения тестовых заданий при устройстве на работу, так как по ним можно также определить уровень разработчика.
Есть немало компаний с развитой open source-культурой. Они выделяют силы и время на создание собственных open source-решений, дополнительно оплачивают время, которое разработчики тратят на работу в open source-проектах. Примеры таких компаний: Evrone и Evil Martians».
Open source-разработчик Никита Соболев:
«На мой взгляд, лучше подготовиться к собеседованию, чем рассчитывать на свои Open source-проекты.
Имеет ли смысл показывать эти проекты на собеседовании? Скорее всего, никакого влияния на работодателя такая презентация не окажет. У HR есть четкие протоколы и процессы, в которых Open source не фигурирует. Иногда упоминание ваших Open source-проектов может даже навредить – некоторые работодатели подумают, что «будет вместо работы своим опенсорсом заниматься».
Open source-разработчик Михаил Грачев:
«Считаю, что open source-проекты могут помочь в поиске работы. Как и активный профиль на GitHub, кстати. Многие HR-специалисты уже давно используют GitHub, как площадку для поиска новых разработчиков. Готовые open source-проекты часто помогают избежать выполнения тестовых заданий при устройстве на работу, так как по ним можно также определить уровень разработчика.
Есть немало компаний с развитой open source-культурой. Они выделяют силы и время на создание собственных open source-решений, дополнительно оплачивают время, которое разработчики тратят на работу в open source-проектах. Примеры таких компаний: Evrone и Evil Martians».
Open source-разработчик Никита Соболев:
«На мой взгляд, лучше подготовиться к собеседованию, чем рассчитывать на свои Open source-проекты.
Имеет ли смысл показывать эти проекты на собеседовании? Скорее всего, никакого влияния на работодателя такая презентация не окажет. У HR есть четкие протоколы и процессы, в которых Open source не фигурирует. Иногда упоминание ваших Open source-проектов может даже навредить – некоторые работодатели подумают, что «будет вместо работы своим опенсорсом заниматься».
🔥2👍1
Собираем merge за выходные и сегодня, 27.06
Добро пожаловать в комментарии со ссылкой :)
Пока наши инженеры оценивают новые issue, завтра появится новый пак, stay tuned.
Добро пожаловать в комментарии со ссылкой :)
Пока наши инженеры оценивают новые issue, завтра появится новый пак, stay tuned.
Как давать обратную связь?
Open source-разработчик Никита Соболев:
«Обычно обратная связь на GitHub – про баги или новые возможности.
Про баги: пишите по классическому шаблону – что происходит, чего ожидаете, какие шаги. Создаете баг и отправляете.
Про возможности. Здесь сложнее, нужно описать мотивацию: зачем это нужно, какие есть возможности сделать по-другому, какие это несет ограничения и риски. Общая мысль – хочу такую новую фичу. А можно еще звездочку поставить.
Если давать обратную связь по-другому – ее абсолютно точно воспримут как неконструктивную. Например, если написать человеку на почту, что его приложение – отстой, это так себе обратная связь.Такая манера общения многое говорит о человеке. В том числе и то, что прислушиваться к нему не стоит. Периодически такое происходит почти со всеми, но большинство мейнтейнеров такой фидбэк просто игнорируют.
Обратную связь нужно давать по этикету. Он обычно описан в файлах CONTRIBUTING.md или readme, в шаблонах GitHub: как создавать issues, как их оформлять, что писать, что не писать. Помните, что люди делают это бесплатно, в свое свободное время, не надо тратить это время на пустые разговоры».
Open source-разработчик Никита Соболев:
«Обычно обратная связь на GitHub – про баги или новые возможности.
Про баги: пишите по классическому шаблону – что происходит, чего ожидаете, какие шаги. Создаете баг и отправляете.
Про возможности. Здесь сложнее, нужно описать мотивацию: зачем это нужно, какие есть возможности сделать по-другому, какие это несет ограничения и риски. Общая мысль – хочу такую новую фичу. А можно еще звездочку поставить.
Если давать обратную связь по-другому – ее абсолютно точно воспримут как неконструктивную. Например, если написать человеку на почту, что его приложение – отстой, это так себе обратная связь.Такая манера общения многое говорит о человеке. В том числе и то, что прислушиваться к нему не стоит. Периодически такое происходит почти со всеми, но большинство мейнтейнеров такой фидбэк просто игнорируют.
Обратную связь нужно давать по этикету. Он обычно описан в файлах CONTRIBUTING.md или readme, в шаблонах GitHub: как создавать issues, как их оформлять, что писать, что не писать. Помните, что люди делают это бесплатно, в свое свободное время, не надо тратить это время на пустые разговоры».
Как отличить полумертвый проект?
Open source-разработчик Никита Соболев:
«Проекты бывают разные и состояние их зависит от кучи факторов.
Есть проекты, в которых все готово. Их как раз можно назвать мертвыми – это законченные проекты, у меня таких штук пять есть. Если мне напишут про их доработку – я, скорее всего, это проигнорирую. И не потому, что проект мертвый. А потому, что проект закончен и я не считаю нужным в него что-то добавлять. Если какой-то баг – другое дело. Но обычно в таких проектах нет багов, все давно отлажено, ими активно пользуются, и они решают свои задачи.
Нужно уметь отличать полумертвые проекты и тупиковые ветки. А есть проекты, которые сейчас никто не развивает, но они актуальны и сообщество хочет, чтобы они были активнее.
Есть, например, какой-то компонент для React, которым активно пользуются. Но автор больше не занимается Open Source, а рыбачит на природе. Жмете кнопочку Project pulse на GitHub, смотрите на активность. Здесь можно понять, что мейнтейнер забросил проект.
Можно написать этому человеку письмо. Мол, спасибо за шикарный проект, я хочу его развивать, вот моя ветка, в которой я много всего сделал, назначьте меня соавтором и я буду вносить эти изменения. Часто люди говорят «да, давай, мне нравится направление развития». или они говорят «да мне уже пофиг, я этим сто лет не занимаюсь, забирай». Смена главного мейнтейнера – нормальная ситуация.
Если человек не ответит, а вам очень хочется его заполучить – можно форкнуть проект, назвать «Мой проект v2» и заниматься развитием форка. Желательно, конечно, развивать старый проект, но если совсем никак – то только форк».
Open source-разработчик Никита Соболев:
«Проекты бывают разные и состояние их зависит от кучи факторов.
Есть проекты, в которых все готово. Их как раз можно назвать мертвыми – это законченные проекты, у меня таких штук пять есть. Если мне напишут про их доработку – я, скорее всего, это проигнорирую. И не потому, что проект мертвый. А потому, что проект закончен и я не считаю нужным в него что-то добавлять. Если какой-то баг – другое дело. Но обычно в таких проектах нет багов, все давно отлажено, ими активно пользуются, и они решают свои задачи.
Нужно уметь отличать полумертвые проекты и тупиковые ветки. А есть проекты, которые сейчас никто не развивает, но они актуальны и сообщество хочет, чтобы они были активнее.
Есть, например, какой-то компонент для React, которым активно пользуются. Но автор больше не занимается Open Source, а рыбачит на природе. Жмете кнопочку Project pulse на GitHub, смотрите на активность. Здесь можно понять, что мейнтейнер забросил проект.
Можно написать этому человеку письмо. Мол, спасибо за шикарный проект, я хочу его развивать, вот моя ветка, в которой я много всего сделал, назначьте меня соавтором и я буду вносить эти изменения. Часто люди говорят «да, давай, мне нравится направление развития». или они говорят «да мне уже пофиг, я этим сто лет не занимаюсь, забирай». Смена главного мейнтейнера – нормальная ситуация.
Если человек не ответит, а вам очень хочется его заполучить – можно форкнуть проект, назвать «Мой проект v2» и заниматься развитием форка. Желательно, конечно, развивать старый проект, но если совсем никак – то только форк».
Собираем merge за последние дни
Добро пожаловать в комментарии со ссылкой :)
Добро пожаловать в комментарии со ссылкой :)
Как привлечь внимание мейнтейнера?
Open source-разработчик Михаил Грачев:
«Чтобы понять, посмотрит ли мейнтейнер ваш pull request, нужно проверить метрики проекта на GitHub.
В первую очередь – дату и время последних коммитов. Если коммитов не было давно – есть шанс, что проект забросили. В таком случае, лучше сначала создать issue и проверить, ответит ли мейнтейнер на него.
Если в последнее время коммиты были – важно проверить, не были ли это обновления зависимостей. Часто бывает, что мейнтейнер забросил проект, но периодически обновляет зависимости.
Еще одна метрика – количество открытых issues и pull requests на GitHub. Если их много и основные мейнтейнеры там не появляются – это еще один тревожный звоночек.
Если ваш pull request висит открытым уже несколько дней – можно попросить мейнтейнера обратить на него внимание. Для этого достаточно оставить комментарий к PR с упоминанием основного мейнтейнера (gentle ping)».
Open source-разработчик Михаил Грачев:
«Чтобы понять, посмотрит ли мейнтейнер ваш pull request, нужно проверить метрики проекта на GitHub.
В первую очередь – дату и время последних коммитов. Если коммитов не было давно – есть шанс, что проект забросили. В таком случае, лучше сначала создать issue и проверить, ответит ли мейнтейнер на него.
Если в последнее время коммиты были – важно проверить, не были ли это обновления зависимостей. Часто бывает, что мейнтейнер забросил проект, но периодически обновляет зависимости.
Еще одна метрика – количество открытых issues и pull requests на GitHub. Если их много и основные мейнтейнеры там не появляются – это еще один тревожный звоночек.
Если ваш pull request висит открытым уже несколько дней – можно попросить мейнтейнера обратить на него внимание. Для этого достаточно оставить комментарий к PR с упоминанием основного мейнтейнера (gentle ping)».
🔥2
Собираем merge за выходные и сегодня, 4.07
Добро пожаловать в комментарии со ссылкой :)
Добро пожаловать в комментарии со ссылкой :)
👍3
Как кастомизировать свой проект?
Open source-разработчик Никита Соболев:
«Главная вещь, которую многие разработчики не понимают – что нужно в readme-файле писать не «что это?», а «зачем это?».
Вот у нас, например, транскомпилятор из одного байт-кода в другой. А зачем он? В описании сказано: «с ним ваше приложение будет работать в 15 раз быстрее». И все понятно.
Очень многие мейнтейнеры не уделяют внимания именно пользовательской документации, ответам на базовые вопросы. Написание документации – отдельный навык, которым программисты не очень владеют. Это надо по-другому мыслить, ставить себя на место пользователя, а не владельца знаний. Последнему ответы очевидны, а вот пользователю – нет.
Что нужно, кроме описаний? Вот мой чек-лист.
👍 Покрытие кода тестами в процентах
👍 Как открыть баг и предложить фичу
👍 Что делать, если нужна коммерческая поддержка
👍 Скриншоты – как работает, как использовать, этакий quick start guide.
Форма может быть разной, главное, чтобы это было хоть в каком-то виде».
Open source-разработчик Никита Соболев:
«Главная вещь, которую многие разработчики не понимают – что нужно в readme-файле писать не «что это?», а «зачем это?».
Вот у нас, например, транскомпилятор из одного байт-кода в другой. А зачем он? В описании сказано: «с ним ваше приложение будет работать в 15 раз быстрее». И все понятно.
Очень многие мейнтейнеры не уделяют внимания именно пользовательской документации, ответам на базовые вопросы. Написание документации – отдельный навык, которым программисты не очень владеют. Это надо по-другому мыслить, ставить себя на место пользователя, а не владельца знаний. Последнему ответы очевидны, а вот пользователю – нет.
Что нужно, кроме описаний? Вот мой чек-лист.
👍 Покрытие кода тестами в процентах
👍 Как открыть баг и предложить фичу
👍 Что делать, если нужна коммерческая поддержка
👍 Скриншоты – как работает, как использовать, этакий quick start guide.
Форма может быть разной, главное, чтобы это было хоть в каком-то виде».
👍3
В чем отличие Enterprise-решений от открытых решений в одном проекте?
Open source-разработчик Никита Соболев:
«Отличие в том, что Enterprise-решение предлагает поддержку, это и ценится в софте. А открытый софт предлагает, по сути, непонятно что. Поэтому он нежизнеспособен и неконкурентоспособен.
Открытая технология может соревноваться с Enterprise только если вокруг нее появляется компания. А как только это происходит – способ дистрибуции становится не важен. Тут уже можно получить апгрейд или поддержку за деньги, какие-то люди будут не спать по ночам, чтобы все работало.
Поэтому закрытому софту было проще занять свою нишу. Сейчас в Open source появляются компании, которые делают ровно то же и уже нет никакой разницы».
Open source-разработчик Никита Соболев:
«Отличие в том, что Enterprise-решение предлагает поддержку, это и ценится в софте. А открытый софт предлагает, по сути, непонятно что. Поэтому он нежизнеспособен и неконкурентоспособен.
Открытая технология может соревноваться с Enterprise только если вокруг нее появляется компания. А как только это происходит – способ дистрибуции становится не важен. Тут уже можно получить апгрейд или поддержку за деньги, какие-то люди будут не спать по ночам, чтобы все работало.
Поэтому закрытому софту было проще занять свою нишу. Сейчас в Open source появляются компании, которые делают ровно то же и уже нет никакой разницы».
Собираем merge за сегодня, 9.07
Напоминаем, что окончание приёма pr уже во вторник, не затягивайте.
Добро пожаловать в комментарии со ссылкой :)
Напоминаем, что окончание приёма pr уже во вторник, не затягивайте.
Добро пожаловать в комментарии со ссылкой :)
Собираем merge за сегодня, 10.07
Напоминаем, что окончание приёма pr уже во вторник, не затягивайте.
Добро пожаловать в комментарии со ссылкой :)
Напоминаем, что окончание приёма pr уже во вторник, не затягивайте.
Добро пожаловать в комментарии со ссылкой :)
А что там по пересмотру? А у меня подвисла задача, а скоро уже конец приема.
Пересмотры:
https://github.com/testcontainers/testcontainers-go/issues/332
2 балла остаются, наши инженеры посчитали объём самой задачи на 2 балла, а большая часть — тесты
https://github.com/testcontainers/testcontainers-go/issues/439
2 балла остаются, там больше описания и тестов, чем функционала
https://github.com/uptrace/bun/issues/258
3 балла, согласны, большой объем работ
Подвисшие задачи:
https://github.com/testcontainers/testcontainers-go/issues/285
https://github.com/ClickHouse/clickhouse-go/issues/574
https://github.com/deepmap/oapi-codegen/issues/458
https://github.com/golang-jwt/jwt/issues/67
https://github.com/openfaas/faas-cli/issues/907
https://github.com/labstack/echo/issues/2201
Тут мы пингуем мейнтейнеров, но держим в голове, что с опенсорсом бывает так, что задачка не закрывается в срок.
Если что-то еще стоит прокомментировать -- можно написать в комментарии, мы посмотрим.
Пересмотры:
https://github.com/testcontainers/testcontainers-go/issues/332
2 балла остаются, наши инженеры посчитали объём самой задачи на 2 балла, а большая часть — тесты
https://github.com/testcontainers/testcontainers-go/issues/439
2 балла остаются, там больше описания и тестов, чем функционала
https://github.com/uptrace/bun/issues/258
3 балла, согласны, большой объем работ
Подвисшие задачи:
https://github.com/testcontainers/testcontainers-go/issues/285
https://github.com/ClickHouse/clickhouse-go/issues/574
https://github.com/deepmap/oapi-codegen/issues/458
https://github.com/golang-jwt/jwt/issues/67
https://github.com/openfaas/faas-cli/issues/907
https://github.com/labstack/echo/issues/2201
Тут мы пингуем мейнтейнеров, но держим в голове, что с опенсорсом бывает так, что задачка не закрывается в срок.
Если что-то еще стоит прокомментировать -- можно написать в комментарии, мы посмотрим.
GitHub
Start multiple containers at the same time · Issue #332 · testcontainers/testcontainers-go
I propose a function like tc.GenericContainer but that would accept many container requests, and start them in parallel and return an array with the responses or a combined error. Suggested signatu...
👍2
Собираем merge за сегодня, 11.07
Напоминаем, что окончание приёма pr уже завтра, не затягивайте.
Добро пожаловать в комментарии со ссылкой :)
Напоминаем, что окончание приёма pr уже завтра, не затягивайте.
Добро пожаловать в комментарии со ссылкой :)
Последний в этом кемпе сбор PR
Принимаем сегодня до 23:59 по Москве, потом — уходим считать все баллы.
Принимаем сегодня до 23:59 по Москве, потом — уходим считать все баллы.
Пока мы подводим итоги с мейнтейнерами, они дают очень приятную обратную связь.
Это от библиотеки https://github.com/ClickHouse/clickhouse-go
Это от библиотеки https://github.com/ClickHouse/clickhouse-go
👍8❤1
PR остались незамердженными, а issue -- открытыми. Мы даем владельцам еще 2 недели
Не все, но многие. Сегодня мы с командой организаторов посчитали, как бы распределились призовые места, если бы все PR замерджили. Пришли к выводу, что нужно дать время мейнтейнерам, чтобы конкурс был честнее.
Поэтому, сдвигаем сроки подведения итогов конкурса на 2 недели.
Задачи отправлять на PR больше нельзя, это время только для владельцев библиотек, чтобы принять или не принять решения.
Мы поторопим всех мейнтейнеров, но понимаем, что даже этих 2 недель может не хватить -- какие-то pr все еще могут остаться без ответа.
Надеемся, вы тоже считаете, что так будет справедливее по отношению к тем, кто вложил в эти библиотеки свои силы.
Новая дата объявления результатов конкурса: 29 июля 2022
Не все, но многие. Сегодня мы с командой организаторов посчитали, как бы распределились призовые места, если бы все PR замерджили. Пришли к выводу, что нужно дать время мейнтейнерам, чтобы конкурс был честнее.
Поэтому, сдвигаем сроки подведения итогов конкурса на 2 недели.
Задачи отправлять на PR больше нельзя, это время только для владельцев библиотек, чтобы принять или не принять решения.
Мы поторопим всех мейнтейнеров, но понимаем, что даже этих 2 недель может не хватить -- какие-то pr все еще могут остаться без ответа.
Надеемся, вы тоже считаете, что так будет справедливее по отношению к тем, кто вложил в эти библиотеки свои силы.
Новая дата объявления результатов конкурса: 29 июля 2022
👍5👎4
Open source camp продолжается!
Поэтому мы продолжаем постить разные интересности про open source.
Сегодня – первая «сцена после титров», ее герой – CEO @codescoring Алексей Смирнов.
Какие риски связаны с применением Open Source, на что важно обратить внимание?
При всей нашей любви к OpenSource, он не всегда бывает безопасным. И безопасность здесь подразумевается в общем смысле: от наличия уязвимостей и вредоносного кода до фактора автобуса для коллектива авторов, качества кода и лицензионной чистоты компонентной базы.
При выборе проекта для использования, важно проверить его на устойчивость. Вот простой чеклист, который вы можете скорректировать под свои условия:
- качество кода;
- наличие автотестов;
- актуальность последних изменений;
- актуальность и полнота документации;
- время реакции на изменения (и адекватность этой реакции);
- актуальность зависимостей;
- наличие достаточного количества регулярных контрибьюторов.
Это минимальный набор проверок, которыми вы себя застрахуете от основных рисков применения сторонних компонентов в своей разработке. О том, как и чем это всё смотреть и проверять, мы поговорим в следующих постах, оставайтесь на связи!
Поэтому мы продолжаем постить разные интересности про open source.
Сегодня – первая «сцена после титров», ее герой – CEO @codescoring Алексей Смирнов.
Какие риски связаны с применением Open Source, на что важно обратить внимание?
При всей нашей любви к OpenSource, он не всегда бывает безопасным. И безопасность здесь подразумевается в общем смысле: от наличия уязвимостей и вредоносного кода до фактора автобуса для коллектива авторов, качества кода и лицензионной чистоты компонентной базы.
При выборе проекта для использования, важно проверить его на устойчивость. Вот простой чеклист, который вы можете скорректировать под свои условия:
- качество кода;
- наличие автотестов;
- актуальность последних изменений;
- актуальность и полнота документации;
- время реакции на изменения (и адекватность этой реакции);
- актуальность зависимостей;
- наличие достаточного количества регулярных контрибьюторов.
Это минимальный набор проверок, которыми вы себя застрахуете от основных рисков применения сторонних компонентов в своей разработке. О том, как и чем это всё смотреть и проверять, мы поговорим в следующих постах, оставайтесь на связи!
👍3