18 open source проектов для практики программирования


Содержание

Как участвовать в open source проектах

Я написал это руководство, чтобы помочь любому присоединяться или выкладывать свои (contributing) open source проекты на GitHub. Одна из причин крутости open source — в желании людей помогать друг другу.

Не важно — программируете ли вы много лет или только начали, есть несколько моментов, которые вам нужно знать, чтобы продуктивно использовать GitHub. Гайдов «как» сделать что-то с технической точки зрения на GitHub множество: на какую кнопку нажать, какие команды запустить и подобное.

В начале публикация своей работы на GitHub пугает. Существует мало руководств, посвященных этикету, практическим приёмам и ожиданиям. Этот гайд направлен заполнить пробелы.

Читая этот гайд, помните, что нормально (и даже ожидаемо!) делать ошибки. Не нужно запоминать каждую мелочь. Делайте всё возможное и учитесь в процессе.

Гайд предполагает, что вы работаете с JavaScript-модулем, установленным через npm или bower , который размещён на GitHub. Кроме команд, предназначенных для npm или bower , большая часть этого гайда применима к другим платформам и языкам.

Как задавать вопрос

Перед тем, как спрашивать, поищите и почитайте существующие записи. Загляните в документы, Google, GitHub, и StackOverflow. Если на ваш вопрос уже отвечали раньше много раз, то разработчики, ответственные за проект, возможно, устали повторять ответ.

Если проект маленький, обычно принято задавать вопросы через отправку issue (см. ниже). Если большой — у них скорее всего есть рассылка или IRC-канал, через которые лучше всего обращаться с вопросами. StackOverflow — также очень хороший ресурс. Когда есть возможность, задавайте вопросы на публичном форуме. Таким образом ответить на вопрос сможет кто угодно, а ответ будет доступен любому человеку с таким же вопросом. Если ничего не работает, можно написать в твиттер или на почту поддержки проекта.

Отправка уведомления о баге (issue)

На GitHub уведомления о багах или улучшениях называются «issues».

Об этом спрашивали раньше?

Перед тем как отправить уведомление, нужно поискать существующие issues. Не забывайте проверять и открытые issues и закрытые. Если вы найдёте issue, который подобен вашему, прочтите всё о нём.

Если issue такой же как у вас, вы можете прокомментировать с дополнениями, чтобы помочь ответственным за проект разработчикам (maintainers) сделать отладку. Добавление комментария автоматически подпишет вас на уведомления по почте, что может быть полезным, когда будут появляться обновления, касающиеся этого issue. Если вам нечего добавить, но вы хотите получать уведомления об обновлениях на почту, вы можете нажать кнопку «watch», которая находится под комментариями.

Нет, никто не спрашивал

Если вы не можете ничего найти в существующих issues, не стесняйтесь отправить свой.

Нужно проверить, что указана версия проекта, так же как и версии связанных с ним приложений. Например, удостоверьтесь, что включили номера версий, выводимые командами node —version и npm list . Если вы заметите, что у вас установлена не последняя версия, используйте npm update и подтвердите, что issue всё ещё присутствует.

Разработчики проекта очень приветствуют тщательные разъяснения. Обычно это помогает им быстрее справиться с проблемой и всем это на руку.

Улучшаем код

Лучший способ — сделать «Fork» (копию) репозитория на GitHub. Это создаст экземпляр-клон репозитория в вашем GitHub аккаунте.

Перед тем как улучшать код, стоит сфокусироваться на том, что вы хотите конкретно сделать.

Каждый коммит должен выполнять что-то одно, а на каждый PR (см. ниже) должно быть одно специфическое улучшение.

Forking

  1. Нажмите на Fork в репозитории
  2. Перейдите в ваш форк внутри вашего аккаунта
  3. Сделайте git clone

Исправление и тестирование

Ок, теперь вы готовы к исправлению кода? Не совсем! Перед тем, как начать редактировать, вам нужно создать ветку (branch). Branch — как альтернативная временная линия. Можете почитать о git ветках тут.

Делаем ветку: git checkout -b something

Если вы пытаетесь починить баг, возможно вам стоит назвать ветку «fix-short-description». Если вы добавляете функциональность, «feat-short-description» — хорошее название. Когда вы меняете что-то в коде, возможно, вам захочется испытать его внутри какого-нибудь приложения или более крупного проекта.

В отношении стиля кода — просто пытайтесь имитировать стиль существующего. Не пыхтите над ним слишком сильно. Если владельцам не понравится внешний вид вашего кода, они предложат изменения.

Большая часть проектов пользуется наборами тестов, для уверенности в том, что имеющаяся функциональность кода не меняется из-за вносимых изменений. Это помогает поддерживать софт в стабильном состоянии.

Коммиты и пуш

Использование собственных изменений

Хоть это и не очевидно, вы можете начать использовать код в своих проектах сразу же.

Отправка ваших изменений обратно в проект

Вы сделали изменения, протестировали их с git commit и хотите отправить обратно в проект, чтобы они были включены в следующие версии.

На GitHub это делается с помощью отправки «pull request» (PR).

Отправка pull request

Золотое правило отправки pull request — всё выполнять так, как задумали владельцы проекта. Вы не можете читать мысли ответственных за проект, но можете посмотреть, что они делали в прошлом. Оценка этих действий заранее может повысить вероятность принятия ваших изменений.

Проще выражаясь: попытайтесь сымитировать стиль существующего кода. Обращайте внимание на отступы и стиль фигурных скобок в коде. Содержит стиль ранние инструкции return или там их избегают?

Код — не единственное, на что стоит обращать внимание. Заметьте какое время и формат имеют коммиты сообщений. Некоторые проекты используют настоящее время: «fixes the bug». А некоторые прошедшее: «fixed the bug».

Хороший способ проверить это — использовать git log и прочитать последние коммиты.

Что ещё стоит помнить:

Не меняйте номер версии софта (в package.json или bower.json ). Владельцы проекта сами позаботятся об этом, когда будут выпускать новую версию.

Если проект поддерживается корпорацией, возможно у них есть Contributor License Agreement (CLA) для избежания проблем с законом.


Владельцы проекта могут быть заняты, так что дайте им немного времени. Разработчики, вовлечённые в open source, часто участвуют во множестве проектов. Нередко разработчик получает десятки нотификаций о неисправностях в день, так что будьте терпеливым.

Если они не отвечают в течение 2 недель, вы можете прокомментировать это, чтобы вынести тему наверх. Чего-нибудь, вроде, «ping @ProjectMaintainer» обычно достаточно. Если даже после этого от них ничего не слышно, электронная почта — хороший способ выйти на контакт.

Команда может ответить тремя возможными способами:

  1. Всё сливается (merge). Ура!
  2. Ответственный за проект просит вас исправить что-то в PR перед тем, как принять вас. Мы обсудим это ниже.
  3. PR закрывается, а ваши изменения не добавлены. Обычно ответственные за проект дают небольшое разъяснение. Если от вас была новая фича, возможно, уже существует способ заставить код делать то, что вы хотите, вы просто этого не заметили. Если исправление бага, возможно, они хотят решить проблему иначе. Не позволяйте трудностям отбить у вас желание продолжать.
Исправление issues в pull request

Когда команда просит внести изменения в PR, новички ошибочно закрывают существующий и создают новый. Не стоит так делать! Существующий PR легко обновляется.

Во-первых, внесите изменения в соответствующие файлы. Добавьте файл с помощью git add , как вы уже делали:

git add some-file

Затем можете изменить свой предыдущий коммит вот так:

git commit —amend

Эта команда помещает ваши поэтапные изменения в предыдущий коммит.

Чтобы обновить коммит в вашем PR, вам нужно выполнить force push:

Команда —force сообщает git , что вы хотите перезаписать предыдущий коммит.

Другая распространенная ошибка — создание нескольких коммитов, вместо внесения изменений в один.

Мой PR был закрыт, но я хочу использовать свои изменения!

Хорошие новости: даже если ваше изменение не будет принято в репозиторий контрибьютора, вы в любом случае сможете его использовать. npm позволяет установить из репозитория GitHub

А ещё вы можете использовать свои изменения и одновременно видеть изменения исходного кода репозитория. Обычно это называется «maintaining a fork» (поддержка копии) проекта. Для этого потребуется добавить ещё один remote.

Создание своего проекта

Перед тем как начинать свой проект, пожалуйста хорошо изучите существующие — нет ли сильно похожего на ваш.

Поиск по существующим проектам

Иногда вы находите старый проект, который больше не поддерживается, но он решает ваши проблемы. Как делать форк смотрите выше.

Бонус: Составляйте список заметок по ходу работы. Если найдете понравившийся модуль, можете использовать заметки, чтобы улучшить секцию «See Also» в тех модулях, которые вам встретились, пока вы вели поиск, отправив им PR. Если не найдёте нужный модуль и не создадите свой собственный, можете превратить эти заметки в секцию «See Also» для своего модуля!

Начало проекта

Начало нового open source проекта должно быть крайней мерой. Почему?

Практический опыт: Не публикуйте ничего в npm пока у проекта не будет обоснованной минимальной функциональности.

Помните: вы всегда можете использовать npm link или npm install user/repo

Название проекта

Если ваш модуль — это плагин, обычно лучший способ — сделать для него префикс, в зависимости от того для чего этот плагин. В некоторых проектах есть гайды или соглашения как это делать. Например компоненты AngularJS обычно называются «angular-something», плагины Gulp —»gulp-something», а плагины Karma — «karma-something».

Пишем Readme

Хороший readme должен состоять из следующих частей:

  • Объяснение, которое умещается в одно предложение.
  • Установка (Install)
  • Смотрите так же (See Also)

Это правда важно. Если существуют другие модули с аналогичной функциональностью, ваш модуль должен объяснять, чем он отличается от других. Эта секция должна быть связана с другими модулями. Это поможет другим решить когда использовать ваш.

Пишем тесты

Есть много способов писать тесты. Их важность в том, что если они провалятся, процесс будет существовать с кодом ошибки. Вы можете использовать для этого assert или if (condition) < process.exit(1) >.

Бонус: вы используете инструмент CI вроде TravisCI.

Публикация в npm

  1. Вы написали README.md , который объясняет что делает модуль. Он должен включать секцию See Also , которая ведёт на другие подобные пакеты.
  2. Вы написали тесты. Тесты должны запускаться с помощью npm test , и они должны проходить.

Бонус: Найдите кого-нибудь, кто будет содействовать в поддержке проекта. Отлично, если кто-то может помочь делать ревью issues и мёрджить PR. Невозможно угадать, как много свободного времени у вас будет в будущем. Обидно иметь непочиненные баги или несмёрженные PR в полезном проекте.

Этикет

Обычно люди покидают сообщества, которые кажутся им недоброжелательными. Чтобы быть уверенным, что все ощущают гостеприимство, важно относиться ко всем мягко и с уважением.

Чаще всего — это не проблема. Но иногда у разработчиков случаются срывы, эмоции зашкаливают, они оскорбляются.

Дальше я выделил несколько тенденций, которые наблюдал сам и способы смягчить подобные ситуации.

Предполагать, что все делают всё возможное

эта задача должна быть очевидной для решения! почему её никто не решил?


Возможно у владельца проекта есть другие важные дела в жизни, которыми ему нужно заниматься. Ставить в приоритет жизненные задачи — не значит быть лентяем. Здоровье, счастье и благополучие реального человека на другом конце интернета намного более важны, чем любой баг.

Одна из мощных сторон open source как раз в том, что вы всегда можете сделать копию и отладить ошибки сами.

вы очевидно не понимаете, о чём я говорю!

Такой тип комментария особенно отталкивает новичков. Совершать ошибки должно быть абсолютно приемлемым.

Это проблематично ещё и потому, что на окружающих участников тоже распространяется чувство вины. Возможно, вы могли бы объяснить недочёт понятнее.

Абсолютно нормально злиться из-за бессилия. Программирование — это одна из самых сложных деятельностей человека. Но, несмотря на это, нужно не упускать точки зрения других людей. Сообщество намного более ценный компонент, чем код, а быть уважительным важнее, чем быть правым.

Заключение

Спасибо за то, что прочитали. Надеюсь этот гайд поможет вам получить то, чего вы хотели от open source. А применить полученные знания помогут open source проекты «Хекслета»:

  • Hexlet Резюме. Сервис для соискателей и эйчаров, работает на Ruby on Rails.
  • Hexlet Interview. Проект на Node.js для специалистов, которые хотят пройти публичное собеседование или попрактиковаться в проведении собеседований.
  • Hexlet СИКП. Проект на Laravel. Это трекер прохождения курсов СИКП.
  • Hexlet Correction. Проект на Java. Сервис для отправки сообщений об ошибках и опечатках владельцам сайтов.
  • Codebattle. Площадка для поединков между программистами. Используются Clojure и Elixir, а также JS (React, Redux) на фронтенде.
  • Code Basics. Основы программирования для начинающих. Можно создавать обучающие курсы для новичков.

Фронтендерам на заметку: для вас найдутся задачи в каждом из проектов.

Opensource проекты для получения опыта [закрыт]

Просматривая вакансии на Java программиста в интернете, можно заметить, что даже для джуниура почти везде нужно 1-2 года опыта работы.

Много раз читал, что для получения реального опыта программирования на Java можно принять участие в разработке какого-нибудь опенсорс проекта(забесплатно :D). Скажите пожалуйста, как найти такие проекты и предложить себя в качестве кандидатуры :)

В теории я уже достаточно хорошо разобрался : в Java SE и основах Java EE(Servlets, JSP, JSF), знаю основы SQL, HTML, CSS, JavaScript.

Закрыт по причине того, что необходимо переформулировать вопрос так, чтобы можно было дать объективно верный ответ участником Nicolas Chabanovsky ♦ 29 мар ’16 в 6:26 .

Вопрос порождает бесконечные прения и дискуссии, основанные не на знаниях, а на мнениях. Для получения ответа перефразируйте ваш вопрос так, чтобы на него можно было дать однозначно правильный ответ, либо удалите вопрос вовсе. Если вопрос можно переформулировать согласно правилам, изложенным в справке, отредактируйте его.

1 ответ 1

даже для джуниура почти везде нужно 1-2 года опыта работы.

Это еще что. Мне попадались вакансии Senior Ruby Developer с 6+ годами опыта, хайлоадом и всем таким, не старше 23 лет. )

По сабжу. Если немного покурите Spring MVC, Hibernate и JQuery, то можете попробоваться на один из проектов JTalks. Ребята разрабатывают набор компонент для развертывания форумов/блогов/ всего такого с тесной взаимной интеграцией. Первый релиз уже состоялся и можно посмотреть что получилось, но работы еще много. Опыт командной разработки для новичка (да и не только) будет отличный.

Open-source системы управления проектами

2020. В системе Руководитель появилась автоматизация бизнес процессов, методы оплаты и API

Вышла новая версия 2.0 open-source системы управления проектами Руководитель. Добавлена автоматизация бизнес процессов. Теперь повторяющиеся и однотипные действия выполняются в один клик. CRM Руководитель научился взаимодействию с клиентами. К примеру, с помощью публичных форм вы можете принимать заявки с сайта и автоматически заносить информацию в базу «Руководителя». Добавлены методы оплаты, которые позволят клиентам оплачивать счета в приложении! С помощью API интегрируйте программу «Руководитель» с вашим сайтом или другим сервисом.

2020. В системе управления проектами Руководителей появился онлайн чат

Вышла новая версия 1.9 open-source системы управления проектами на PHP/MySQL Руководитель. В ней добавлены три новых типа полей: карта, штрих-код и QR-код. Также появились новые опций для существующих типов полей и ряд новых настроек для приложения, комментариев и т.п. Самым интересным обновлением является онлайн чат, который даст возможность отправлять персональные сообщения и создавать групповые диалоги. Появился новый отчет “Временная шкала”. С помощью данного отчета можно отобразить задачи, проекты или любые другие записи в виде временной шкалы.

2015. В php-системе управления преоктами Руководитель появились связанные записи

Вышло обновление PHP-системы для управления проектами Руководитель 1.5. В версии 1.5 добавлены следующие возможности: новый тип поля «Связанные записи», с помощью которого можно связывать между собой записи из разных сущностей, кнопка «Добавить» в отчетах, с помощью которой можно добавить новую запись. В отчетах добавилась возможность фильтрации записей по родительской сущности. Также, появилась возможность отображать под-сущности в меню.

2015. Вышла серверная версия ONLYOFFICE для Linux

Появилась серверная версия виртуального офиса для коллективной работы ONLYOFFICE для платформы GNU/Linux. Для портирования приложения на Linux авторы использовали свободную реализацию платформы Microsoft .NET — Mono. Результатом стал Linux-релиз продукта ONLYOFFICE Common Server v.8.1, который включает в себя такие возможности, как управление документами, CRM, почтовый агрегатор и проекты. Онлайн-редакторы документов не входят в состав Common, их появление в версии для Linux ожидается позже. Система поставляется как бесплатное open-source решение. Исходные коды и инсталляционные пакеты ONLYOFFICE доступны в репозиториях SourceForge и GitHub.

2015. Руководитель — бесплатная система управления проектами с встроенным конструктором

Open-source система управления проектами Руководитель предназначена для установки на собственный (локальный или интернет) сервер с поддержкой PHP/MySQL. Особенность системы не только в том, что она бесплатна, но и в том, что она позволяет сконструировать приложение, максимально подходящее для конкретных целей. Вы можете добавлять новые поля и сущности, настраивать взаимосвязи между ними. Можно настраивать отображение списков и формы сущностей, добавлять к сущностям комментарии. Так же хотелось бы отметить широкие возможности импорта/экспорта данных и настройки прав доступа в системе. В Руководителе пользователи разделены на группы и для каждой группы есть возможность настраивать доступ к сущностным и их полям.

2012. Teamlab делает SaaS-версию платной. 3 хорошие новости

Популярный сервис для совместной работы и управления проектами Teamlab запустил на бета-тестирование новую версию (v.7) и объявил о новой ценовой политике. Ранее практически полностью бесплатная SaaS версия Teamlab теперь станет полностью платной. Через 6 месяцев всем бесплатным пользователям будет предложено начать платить. И конечно, это нельзя назвать хорошей новостью, но в ней есть 3 позитивных момента. Первый — это то, что Teamlab держит обещания. Мы изучили историю сервиса, и действительно, Teamlab никогда не давал стандартных обещаний, что «базовые функции останутся навсегда бесплатными». Они обещали, что «open-source версия останется навсегда бесплатной» — и так оно и будет. Эту версию можно установить на собственный сервер и перенести в нее свои проекты. ***

2011. TeamLab: история одного стартапа

Разработчики перспективного сервиса для управления проектами TeamLab рассказали об истории его создания: 7-е число 7-го месяца 2010 года, 7 часов вечера. Именно на эту магическую дату был назначен выпуск новой версии проекта TeamLab. TeamLab — это система для управления проектами и общения внутри компании. Первостепенная задача любого стартапа – создать нечто значимое. И пусть даже идея не нова, её всегда можно усовершенствовать, тем самым сделав мир чуточку лучше. Так и мы загорелись желанием внести что-то новое, представить свое видение современных систем совместной работы.Удалось ли нам внести свою изюминку? — Решать вам. ***

Цукерберг рекомендует:  4 аспекта современного сайта

2010. Google Wave продолжит развитие в качестве проекта Apache

Apache Software Foundation, организация, которая занимается развитием open-source проектов, приняла Google Wave в свой инкубатор. Таким образом, дальнейшим развития Google Wave (а точнее Wave in a Box) будет заниматься open-source сообщество Apache. Как известно, многие модули Google Wave имеют открытый код, который размещен на code.google.com. Теперь код будет перенесен на инфраструктуру Apache и любой, кто заинтересован в использовании или развитии Google Wave и протокола Wave Federation protocol, сможет поучаствовать в проекте.

2010. TeamLab — бесплатная альтернатива Basecamp теперь на русском

Латвийский сервис Teamlab, запущенный этим летом, стал доступен на русском языке. Это очень интересное решение для организации совместной работы и управления проектами, которое чаще всего сравнивают с Basecamp. Teamlab предоставляется либо как бесплатный SaaS сервис (практически без ограничений), либо как (опять же бесплатная) инсталлируемая open-source система. Принимая во внимание то, что Teamlab — это действительно качественное решение, которое по функциональности не уступает Basecamp, возникает вопрос: откуда такая щедрость? По заявлению представителей компании-разработчика, система Teamlab была создана для собственных нужд и она им так понравилась, что они решили поделиться своей радостью с другими. Компания надеется привлечь сторонних разработчиков к развитию продукта и завоевать популярность за счет бесплатных пользователей, чтобы реально конкурировать с Basecamp на глобальном рынке. А уже затем они планируют вводить платные фичи (при этом обещается, что open-source версия останется бесплатной навсегда). ***

2007. OpenProj выходит под свободной лицензией

Компания Projity решила выпустить под открытой лицензией версию своей системы для управления проектами, которая до сегодняшнего дня была доступна в виде веб-сервиса Project-On-Demand. По мнению специалистов, новая программа OpenProj — это очень серьёзная заявка на то, чтобы потеснить позиции нынешнего лидера на этом рынке Microsoft Project. Программа OpenProj будет интегрирована в крупнейшие дистрибутивы Linux, включая Mandriva, Mint и Sabayon. Кроме того, сейчас идут переговоры с OpenOffice.org и компанией Sun Microsystems, разработчиком StarOffice, чтобы интегрировать OpenProj и в эти офисные пакеты. ***

2007. OpenProj — Open Source-аналог MS Project

Компания Projity, занимающаяся продажами программного обеспечения для управления проектами собирается на конференции LinuxWorld, которая пройдет в августе, представить свой Open Source-продукт OpenProj. По словам исполнительного директора Projity, Марка О»Брайана (Marc O»Brien), проект OpenProj призван стать достойной альтернативой Microsoft Project, которая «действительно откроет дорогу всему программному обеспечению с открытым кодом». Сообщается, что уже ведутся переговоры с OpenOffice.org по вопросам интеграции с этим открытым офисным пакетом, а на данный момент OpenProj поддерживает чтение файлов в формате Microsoft Project. Кроме того, О»Брайан надеется на помощь Open Source-сообщества по интеграции OpenProj с популярными системами CRM (управление взаимоотношениями с клиентами) и ERP (управление предприятием) с открытым кодом, а также по созданию локализаций. ***

2006. Сервис Google Code: преимущества и недостатки

Новые Open Source проекты

Открытое программное обеспечение стало двигателем инноваций. И в этой статье вы убедитесь в этом. Мы рассмотрим лучшие проекты OpenSource по версии премии Black Duck Open Source Rookies.


Это восьмой выпуск Black Duck Open Source Rookies. Каждый год, Black Duck рассматривает мир свободного программного обеспечения и находит лучшие новые Open Source проекты, которые были реализованы в этом году.

Большая часть проектов, получивших награду Black Duck разработана или финансирована коммерческими компаниями. Некоторые проекты — это дополнения к основной продукции спонсоров или внутренние ответвления, в то время как другие становятся поводом для развития этих основных проектов.

Как правило, у лауреатов премии наблюдается три тенденции в отрасли:

  • Использование контейнеров Docker — в предыдущем году, Blcak Duck выбрала технологию Docker в качестве лучшего решения для виртуализации серверов. Экосистема Docker продолжает расширяться, вместе с несколькими проектами, в том числе спонсируемыми Red Hat и Capital One.
  • Рост открытого сотрудничества — Учитывая успех Facebook и Skype для личного обмена сообщениями, было реализовано много подобных решений для офиса. Таких как GoToMeeting или Slack. Теперь запатентованные решения сталкиваются с серьезной конкуренцией со стороны программ с открытым исходным кодом, которые предоставляют те же функции, но полностью открыты.
  • Использование искусственного интеллекта — мы можем быть очень далеко от действительно умных машин, но за глубокими методами обучения, с помощью которых компьютер может научиться путем обработки данных и моделирования нейронных систем, наше будущее.

Rocket.Chat

Это веб-платформа с открытым исходным кодом для создания чатов. Ориентирована на сообщества и компании, которые хотят создать свой внутренний чат. Команда разработчиков Rocket выбрала модульный, пакетный подход, а это позволяет Rocket.Chat предложить впечатляющий набор функций, для реализации удобной работы и связи в реальном времени, от простого обмена текстовыми сообщениями с поддержкой смайлов, до видеосвязи, многопользовательских аудиоконференций, совместного использования экрана и многое другое.

У RocketChat есть собственные приложения для Linux, Windows, MacOS, а также мобильные приложения для Android и iOS. Здесь даже есть собственное приложения для FirefoxOS, для настольных и мобильных устройств. А поскольку это Open Source проект, то это отличный выбор для разработчиков, жалеющих строить и развивать собственную платформу чата.

Mattermost

Другой отличной альтернативой для Slack есть Mattermost, ее история началась с компании — разработчика игр для HTML 5. Изначально это был игровой портал и приложение для обмена сообщениями, цель которого была найти геймеров за пределами Facebook. В итоге программа была переделана в решение для совместной работы в пределах компании, для таких случаев, когда компания не хочет, чтобы ее данные были получены провайдером. На данный момент — это отличная альтернатива Slack с открытым исходным кодом написанная на React и Go.

Mattermost объединяет все задачи коммуникации в одном месте, через удобный и интуитивно понятный интерфейс, удобный для поиска и доступный везде. Пользователи могут обмениваться сообщениями и файлами с помощью своих компьютеров и смартфонов, сохраняя всю важную информацию внутри ИТ инфраструктуры. Интерфейс Mattermost совместим с Slack и обеспечивает работу программного обеспечения разработанного для Slack. Есть две версии программы — одна рассчитана на работу с командами до 50 человек, а другая позволяет организовывать коммуникации между сотнями и тысячами пользователей.

Hubl.in

Решения для видеоконференций WebEx и GoToMeeting стали стандартными инструментами во многих офисах. Эти решения опирались не только на собственные приложения для компьютеров, но и на новые возможности веб-браузеров.

Hubl.in — свободное решение с открытым исходным кодом, для организации видеоконференций от компании Linagora, создателя платформы для совместной работы — OpenPaaS. Hubl.in поднимает связь в реальном времени на новый уровень, позволяя использовать браузер для организации видеоконференций, даже без каких либо плагинов.

Если вы читаете эту страницу, то вы можете попробовать Hubl.in прямо сейчас. Он основан на WebRTC, что позволяет реализовать децентрализованную связь между браузерами. Это значит, что ваша конференция не передается на Hubl.in никаким способом, это повышает безопасность и обеспечивает еще один уровень секретности.

MXNet

Глубинные методы обучения направлены на то, чтобы научить компьютеры самообучению, с помощью моделирования нейронной сети человеческого мозга, а затем передачи этой сети огромного количества данных, для обучения.

MXNet — это легкая библиотека машинного обучения, созданная DMLC разработчиками CXXNet, Minerva, и Purine2. Здесь применен опыт, полученный в этих проектах, а также смешан императивный и символический стиль программирования. MXNet использует планировщик динамических зависимостей, который автоматически паралеллизует как символические, так и императивные операции на лету. Уклон в сторону оптимизации делает MXNet быстрым и потребляющим немного памяти. Библиотека портативная и легкая, она легко масштабируется даже для нескольких машин. Можно даже использовать для таких задач, как распознавание образов на смартфоне. Группа DMLC хочет сделать открытое программное обеспечение широкодоступным. Проект MXNet тоже содержит набор руководств и схем для построения систем машинного обучения.

Bazel

Всем предприятиям любых размеров известно, что они должны разрабатывать программное обеспечение быстро и эффективно, чтобы оставаться конкурентоспособными. Google особенно хороша в этом, и чтобы поделиться этим с другими они выпустили внутреннюю подсистему для сборки программного обеспечения — Bazel.

Bazel стремится ускорить процесс сборки и повысить надежность за счет общего хранилища кода, в котором все программное обеспечение находится в состоянии открытого исходного кода. Здесь автоматизировано тестирование и релизы, используется как параллельность, так и кеширование, чтобы ускорить обработку. Особенно подходит для проектов с крупными базами кода, на основе нескольких языков программирования или для различных платформ. Основная особенность Bazel — тщательное тестирование в сложных условиях работы в Google. Текущая версия поддерживает Linux, OS X, но не Windows.

React Native

Разработчики мобильных приложений сталкиваются с трудным выбором: разрабатывать приложения для iOS или Android с помощью собственных инструментов, или воспользоваться кроссплатформенными. С одной стороны, родные приложения быстрее и предлагают лучший пользовательский интерфейс. Однако разработка такого приложения, означает — написать его, по крайней мере, два раза на самых разных языках программирования. Кроссплатформенные инструменты, такие как JavaScript позволяют им писать программу только раз, но эти приложения часто работают плохо и выглядят не очень красиво.

React Native — это OpenSource проект с открытым исходным кодом, поддерживаемый Facebook. Он позволяет двигаться сразу в двух направлениях. Создавая свои приложения с помощью библиотеки JavaScript React вы сохраняете логику работы приложений JavaScript, а также пользовательский интерфейс полностью нативный для обоих оболочек iOS и Android. Для разработчиков React Native представляет собой новый подход к написанию мобильных приложений — учиться раз, писать везде.

Kontena

Docker-контейнеры — революционный способ для развертывания приложений. Но многие организации все еще борются за решение для управления контейнерами.

Kontera — проект с открытым исходным кодом, для управления контейнерами. Kontera имеет много новых технологий и возможностей для ускорения развертывания. Здесь есть поддержка нескольких хостов, мульти-AZ контейнеры, сетевая технология Weave, VPN доступ к контейнерам, а также интуитивно понятный мастер развертывания. У Kontera есть все что компании может понадобиться для разработки, развертывания и контроля контейнерных систем. Она может быть установлена в любой облачной инфраструктуре. Поскольку это открытый исходный код, она скоро выйдет за рамки Docker и будет поддерживать контейнеры Windows, CoreOS PKT и другие контейнерные технологии.

Nulecule

Инициатива открытых контейнеров Docker предоставляет отличную оболочку для приложений. Но он все еще не может управлять зависимостями активов и отношениями между экземплярами в многоконтейнерных приложениях.

Nulecule — это спецификация, для упаковки сложных многоконтейнерных приложений, обеспечивающая правильное развертывание. Nulecule при поддержке Red Hat предлагает целостную систему для управления отношениями между контейнерами. Большинство систем управления контейнерами рассматривают мультиконтейнерные приложения как отдельные объекты, а не как что-то целое. Такой подход ограничивает гибкость и портативность всего приложения. В отличие от этого решение на основе Nulecule создает стандартизированный способ описания приложения, в том числе всех ссылок на зависимости и метаданные коммуникаций внутри каждого образа контейнера.

InSpec

Рабочий процесс DevOps часто завален соблюдением сложных спецификаций и медленным развитием. InSpec обеспечивает путь, ускоряющий работу за счет автоматизации процесса проверки соответствия. Если соблюдение правил является неотделимой частью процесса разработки — это одно из лучших решений.

Как решение с открытым исходным кодом для определения соответствия, безопасности, а также требований относительно политики Inspec предлагает множество сложных функций. В том числе тестов на проверку соблюдения метаданных для периодизации, а также интерфейс командной строки, для удобного выполнения тестов. Пользователи могут контролировать процесс с помощью специального разработанного языка программирования. Поскольку Inspec работает в локальной системе, он может изучить любой узел инфраструктуры.

Hygieia

Технологические гиганты не одиноки в инвестировании в свободное программное обеспечение. В этом году Capital One попытались найти панель инструментов для разработчиков, и небыли обнаружены ни коммерческие решения ни OpenSource проекты. Поэтому компания создала собственную — Hygieia. Панель выпущена в прошлом году и ее исходный код опубликован на GitHub.

Capital One использует Hygieia в процессе разработки программного обеспечения, чтобы дать командам и лидерам простой, доступный и быстрый способ получить представление о текущем состоянии процесса разработки. Вместо того чтобы показывать только часть процесса развития, как это делают другие панели, Hygieia предлагает полный обзор в двух вариантах: видежет и ползунок.

Вариант виджет показывает более подробную информацию: особенности текущего этапа, вклад в код, интеграцию, анализ кода, анализ безопасности, функциональные ресурсы тестирования и развертывания и т д. Ползунок показывает степень прогресса каждого элемента, на этапах разработки, тестирования и развертывания.

Glucosio

Когда программисту Бенджамину Кернеса был поставлен диагноз диабет второго типа в мае 2015 он понял, что нет инструментов с открытым исходным кодом для отслеживания уровня глюкозы или других показателей, для людей подобных ему. В сентябре 2015, он и небольшая команда выпустили Glucosio, первое приложение с открытым исходным кодом для мониторинга уровня глюкозы.

Пользователи Glucosio могут отслеживать уровень глюкозы в крови и получить полезные советы, через приложение помощник. Пользователи также могут внести свой вклад в исследование диабета, оставив анонимную демографическую или личную информацию. Glucosio на данный момент доступно на 20 языках и было загружено на каждом континенте. Разработчики также планируют предложить бесплатный API для исследователей, чтобы они могли получить доступ к данным, которые пользователи оставляют в программе.

Vault

Компания из Сан-Франциско HashiCorp известна своим инструментом для создания и настройки легкой, портативной среды разработки — Vagrant. Новый проект с открытым исходным кодом этой компании — Vault, инструмент для безопасного управления секретами. Здесь могут находиться ключи, API, пароли, сертификаты, учетные данные сотрудников, и другая секретная информация. У HashiCorp отличные Open Source проекты, можно сказать — так держать.

Vault шифрует и расшифровывает данные без их сохранения, а также позволяет командам безопасности определить параметры шифрования, а разработчикам — возможность хранить зашифрованные данные без разработки своих алгоритмов шифрования. Vault даже может генерировать секретные ключи по запросу AWS или баз данных SQL, а затем автоматически их отменять, когда они уже использованы. Поддерживается единый интерфейс для доступа, с жестким контролем, а также подробные журналы аудита, так что пользователи могут быть уверенны, что их секреты в безопасности.

Rancheros

Rancher Labs разработала высокоэффективную технологию запуска контейнеров — операционную систему в миниатюре, со всем необходимым для запуска контейнеров, но ничего больше. RancherOS — это дистрибутив Linux, размером 20 Мб, специально разработанный для простого способа запуска и управления контейнерами Docker. Идея заключается в том, что он похож на CoreOS, Но с одной особенностью — все здесь работает через Docker контейнеры, даже сама операционная система.

В RancherOS Docker работает непосредственно поверх ядра Linux и распределяет все сервисы пользовательского пространства как контейнеры Docker. Экземпляр системы Docker инициализирует все системные службы (Udev, DHCP, TTY) каждая из которых работает в отдельном контейнере. Экземпляр пользователя Docker создает отдельные контейнеры для всех пользователей, в пределах основного контейнера пользователя. RancherOS также обеспечивает обновление через контейнеры и может использовать различные системы управления контейнерами.

OWASP Security Knowledge Framework


OWASP Foundation (Проект Open Web Application Security) — это некоммерческое сообщество, которое предоставляет ресурсы и средства для обеспечения безопасности веб-приложений, которые разрабатывают OpenSource проекты. Многие разработчики не знают о рисках безопасности уязвимостей, с которыми они сталкиваются. С этой целью OWASP SKF (Security Knowledge Framework) обеспечивает свободный инструмент с открытым исходным кодом для обеспечения безопасности веб-приложений. Он также может служить учебным пособием, которое научит основам безопасности в веб-приложениях.

SKF поддерживает разработчиков программного обеспечения на протяжении всего жизненного цикла их продукта, обеспечивая его безопасность. Анализируются методы обработки, которые используют разработчики для редактирования своих данных, а затем перебираются шаблоны для известных уязвимостей. После завершения предлагаются решения для исправления проблем с безопасностью.

Выводы

Это были все новые Open Source проекты, отмеченные премией Black Duck. Награждение происходит каждый год, поэтому новые Open Source проекты за 2020 год мы увидим только в 2020.

Лучшие Open Source проекты по машинному обучению. Часть 1

С каждым годом искусственного интеллекта становится всё больше. Это связано с тем, что машинное обучение открыло новые возможности и перспективы для самых разных областей: от распознавания лиц и голоса до обработки языка, изображений, кинофильмов и т. д. Итак, предлагаем вашему вниманию 20 наиболее известных опенсорсных проектов по Machine Learning.

TensorFlow

TensorFlow — открытая библиотека для создания и тренировки нейронных сетей. Предоставляет API для облачной, мобильной, десктопной и веб-разработки. Поначалу создавалась командой Google Brain для внутреннего использования. Имеет интерфейсы для Swift и Javascript. Последняя версия поддерживает высокоуровневый API Keras, который написан на Python и работает поверх CNTK, TensorFlow и Theano.

Scikit-learn

Эту библиотеку разработали во время реализации проекта Google Summer of Code. Она предоставляет пользователям простые, но достаточно эффективные инструменты, предназначенные для глубокого анализа данных. А за счёт простоты и удобства Scikit-learn не уступает по популярности TensorFlow.

MXNet

Фреймворк Deep learning от Apache. Создавался с упором на гибкость и продуктивность, поэтому позволяет комбинировать императивное и символическое программирование.

PyTorch

Очень популярная библиотека среди фанатов Machine Learning. Создана на базе Torch, развивается в стенах Facebook. По сути, это пакет Python, поддерживающий тензорные вычисления с GPU-ускорением и работу с нейросетями через систему autograd.

Magenta

Исследовательский проект, который демонстрирует мощный потенциал машинного обучения при создании музыки и произведений искусства. Позволяет генерировать музыку и изображения. Расширяет творческие возможности музыкантов и художников. Основной репозиторий предназначен для применения с Python, однако есть версия и для JavaScript.

Style2Paints

Это алгоритм, который служит для раскрашивания чёрно-белых штриховых скетчей. Также ИИ может создавать собственное цветовое оформление и переносить стиль рисования и цветовую гамму с одних изображений на другие.

Image-to-image translation in PyTorch

Данный проект сделан на основе нейронных сетей pix2pix и CycleGAN. Он содержит PyTorch-реализации, позволяющие преобразовывать одни изображения в другие. Например, вы легко сделаете из лошади зебру. Нейросеть работает очень быстро, поэтому можно обрабатывать даже видеофайлы.

Deep voice conversion

Работает по аналогии с предыдущим инструментом, но преобразует не изображения, а звук. В частности, можно синтезировать в целях имитации голос нужного человека, сохранив все его индивидуальные особенности. Для этого потребуется датасет в виде реальных записей голоса.

StarGAN in PyTorch

Проект объединённой генеративно-состязательной сети, предназначенной для трансформации изображений с помощью PyTorch. Позволяет менять цвет кожи, пол, возраст, причёски и даже настроение людей на фотографиях.

Face detection

Библиотека используется не только для распознавания лиц, но и для определения пола и эмоций изображённых людей, делая это в реальном времени. Для работы применяются датасеты fer2013/IMDB, библиотека компьютерного зрения OpenCV, сверхточная нейросесть Keras.

Продолжение здесь! Также ждём ваших комментариев!

К чему приводит внедрение хакеров в Open Source-проекты

Совместные Open Source-проекты насчитывают миллионы строк кода, отдельные части которого переплетаются с кодом других открытых проектов. Древовидная структура зависимостей кода может поставить под угрозу небольшие открытые проекты, если их сумеют заразить вредоносным кодом киберпреступники, пишет портал DARKReading.

В последние годы популярность Open Source достигла той стадии, когда подавляющее большинство организаций начало включать его в свою критически важную инфраструктуру. Тем не менее, следует знать, что открытый код может представлять легкую добычу для злонамеренных действий со стороны разработчиков, принимающих участие в его создании. Основатель Zero Day Consulting Брэд Коузи считает, что вездесущность кода, которая проистекает от самой природы проектов с открытым исходным кодом, представляет реальную угрозу для предприятий. Подключившись к целевому Open Source-проекту, перед преступником открывается широкий выбор возможностей, правда, в рамках узкого коридора: «Чтобы раздобыть ценную информацию, но при этом не раскрыть себя, хакерам нужно действовать быстро. Для осуществления этой цели они могут прибегнуть к встроенному кейлоггеру или какому-то другому трояну».

Цукерберг рекомендует:  Рекурсия вычисления значения символьного математического выражения

Открытость, свободный доступ к коду, прозрачные политики управления — все это делает Open Source желанной добычей для хакеров. «Это довольно известный вектор атаки. Предполагаю, что мы осведомлены о сравнительно небольшом количестве атак, на самом деле их проводится гораздо больше», — считает директор по исследованиям Veracode Крис Энг.

К этим мнениям присоединяется голос еще одного эксперта. «Это происходит вокруг нас. В истории ИБ бывали случаи, когда хакеры атаковали открытый код и нет никаких оснований полагать, что они на этом остановились», — полагает руководитель департамента по исследованию проблем безопасности Checkmarx Эран Ялон. Прежде, чем код будет принят в тот или иной Open Source-проект проект, практически все его участники должны пройти проверку, которая проводится другими участниками, напоминает он. Тщательность проверки зависит от репутации человека — чем большим доверием к нему проникаются, тем меньше потребность в его проверке или она становится символической.

Однако в основном проверку участников проводят известные проекты, такие, к примеру, как сообщества крупных дистрибутивов Linux. У них процедуры проверки четко налажены, поскольку в крупных проектах задействовано большое количество участников, что позволяет проводить их на постоянной основе. «Небольшие проекты лишены таких ресурсов, поэтому не могут обеспечить сравнимый с крупными проектами уровень безопасности. Таким образом, эти проекты становятся все более уязвимыми», — говорит Коузи.

Маленький проект, большое влияние

В качестве основной цели для злоумышленников эксперты называют небольшие проекты Open Source. Способ проникновения в них — инфицирование при помощи вредоносного кода. «Большой пакет может состоять в зависимости даже с самым крохотным пакетом. В некоторых случаях количество уровней, на которые могут уходить зависимости, не поддается исчислению. Когда вы приступаете к созданию проекта и вам кажется, что у него будет лишь одна или две зависимости, на самом деле их может быть несколько сотен. Проверить их все — нереально», — говорит Ялон. Осенью прошлого года стало известно, что в Open Source-проект Event-stream, который поддерживался одним разработчиком, был встроен вредоносный код. Его внедрили в библиотеку кода, распространяемую через NPM — популярный менеджер пакетов для разработчиков Javascript.

«Event-stream — это небольшой проект, который зависел от доброй воли одного участника, у которого к тому же не было достаточно времени для его поддержки, — объясняет Ялон. — В итоге хакеру удалось убедить его в том, что он может взять управление проектом на себя». Далее, чтобы не вызывать подозрений, хакер решил пойти по проторенной тропе, какое-то время поддерживая код проекта в рабочем состоянии, однако после он посчитал, что пора перейти ко второй фазе атаки. Ею собственно стала модификация кода в пакете с зависимостями — в него был вставлен код, который предназначался для взлома некоторых биткоин-кошельков. О масштабах атаки красноречиво говорят цифры. В среднем код Event-stream за неделю скачивается почти 1,5 млн. раз, он задействуется в более чем 1600 других пакетах, счет загрузок которых идет на миллионы.

Следующий пример показывает, к каким последствиям могут привести проблемы с компоновкой одного небольшого пакета, которые даже не связаны с злонамеренными действиями. 23 марта 2020 г. разработчик Азер Кочулу удалил 250 написанных им модулей, которые распространялись по каналу NPM. Один из этих модулей (left-pad) был очень маленьким фрагментом кода — он состоял из 11 строк и добавлял пробелы в левой части строк текста, чтобы он вписывался в определение переменной. В тот же день разработчики со всего мира заметили, что с их программами на JavaScript что-то не так. Одно из предупреждений гласило: «npm ERR! 404 ’left-pad’ is not in the npm registry». Это означает, что для запуска проекта требуется пакет под названием left-pad, но получить его не удается. Многие разработчики не могли понять, что случилось: они никогда не использовали такой модуль. Однако его могли использовать другие модули, о чем можно было просто не догадываться.

Как позже выяснилось, left-pad применяется в тысячах корпоративных и коммерческих программ по всему миру, в том числе созданных с помощью компилятора Babel для Javascript и программной платформы Node. После того, как код left-pad исчез из репозиториев, тысячи программ перестали работать. На первый взгляд кажущаяся пустяковой проблема (разработчики могли легко воссоздать функциональность left-pad в своих пакетах) оказала огромное влияние на мир разработки.

Универсальная угроза

«Считаю нужным подчеркнуть, насколько распространен открытый код. По данным Gartner, его применяют для своих внутренних проектов 95% предприятий», — говорит Энг. Учитывая, что современная разработка все больше тяготеет к методикам ускоренного программирования типа Agile и DevOps, считает он, для обеспечения наилучшей защиты предприятиям нужно идти одним единственно верным путем — создания внутренней команды разработчиков, которые пишут для проекта свои собственные функции и библиотеки.

Так каким же образом эта внутренняя команда разработчиков может повысить безопасность кода? «На первом этапе нужно определиться с выбором библиотек и проектов с открытым кодом, которые дополнят технологический стек предприятия. Отталкиваться следует от надежности и репутации проектов», — говорит Коузи. На втором этапе следует убедиться, насколько этот проект активен и снабжается ли он регулярными обновлениями. «Активность почти всегда означает качество. Чем больше в проекте задействовано активных людей, тем больше вероятность того, что они устранят уязвимости», — объясняет он.

Третий этап — установка патчей безопасности. По словам Энга, в настоящее время многие организации беспокоятся по поводу так называемых уязвимостей нулевого дня, выражая свое недовольство, что государственные субъекты не в состоянии провести «базовую гигиену кода». «У этой проблемы есть одно базовое решение — обновление и базовое сканирование открытого кода», — сказал он.

В свою очередь Ялон считает, что наилучшая гарантия безопасности — доверие к Open Source-проекту и внутреннему разработчику, который его применяет. «Вредоносные пакеты с открытым кодом — это не повод для беспокойства, если их никто не использует, — говорит он. — Задействуя ПО с открытым кодом, каждая организации должна установить четкие правила для тех, кто может обновлять или изменять программные пакеты».

18 open source проектов для практики программирования

где имеются задачи для начинающих программеров.

Вопрос: где ещё в Open Source есть здачи для начинающих которые можно преобразовать к лабораторным работам?

1. HECTEPOB , 20.06.2005 19:58
V.M.Kotov
Интересная идея! Вот бы я када учился у нас такой препод был! Огромный респект!


2. dozen , 20.06.2005 20:47
V.M.Kotov

цитата: Вопрос: где ещё в Open Source есть здачи для начинающих которые можно преобразовать к лабораторным работам?

Багфиксинг любого проекта. Залезаешь на ихнюю Bugzilla/JIRA/whatever, выбираешь баги (на глазок по сложности), раздаешь студентам, шлешь патчи (опционально). Баги хороши тем, что задача небольшая, но в то же время — реальная.

цитата: V.M.Kotov:
Есть такая мысль вместо типичных лабораторных работ заставить студентов ковырять OpenSource проекты****
Вопрос: где ещё в Open Source есть здачи для начинающих которые можно преобразовать к лабораторным работам?

3. nenin , 20.06.2005 23:51

цитата: V.M.Kotov:
Есть такая мысль вместо типичных лабораторных работ заставить студентов ковырять OpenSource проекты.

Боюсь, это будет медвежья услуга движению OpenSource. Во первых, «начинающий программист» это чаще всего слон в посудной лавке — после него замучаешься переделывать. Более того, «начинающий программист», которого загнали на работу из под палки (да еще и бесплатно) к тому же слон злонамеренный: в общем сломает больше, чем починит.

Хотите своих студентов чему-нибудь научить — оставьте их в покое (захотят — сами научатся). Если Вам преподавательская сознательность не позволяет — тогда уж давайте им реальные деньги за хорошую работу. Простейший пример — что-нибудь типа eLance: и задачи обычно не большие, и деньги платят, и реальный (а не абстрактный) опыт, и, самое главное, ответственности практически никакой.

4. Диктатор , 21.06.2005 02:37
5. Scrudge , 21.06.2005 10:25
Диктатор

Во первых, «начинающий программист» это чаще всего слон в посудной лавке — после него замучаешься переделывать. — ну, ну а на что тестирование? Если изменение, не стабильно или работает неправильно — его никто не включит в рабочий проект. Open Source тем и хорош, что твой код может посмотреть любой и, при надобности подправить.
V.M.Kotov
Вопрос: где ещё в Open Source есть здачи для начинающих которые можно преобразовать к лабораторным работам? — лабораторная работа, обычно предпологает быстрый конкретный результат в конце работы, который должен быть соответствующим образом оценен. Для этого требуется типичная задача. Вряд ли это возможно в рамках конкретного open source проекта. А вот заставить студентов ковырять код в течении семестра, со сдачей зачета/проекта — это более возможно. ИМХО.

6. Chippy2003 , 21.06.2005 10:38
V.M.Kotov
http://code.google.com/summerofcode.html

Диктатор
медвежья услуга движению OpenSource
Коммитить изменения в проект будет вовсе не обязательно.

7. hydrolizer , 21.06.2005 10:46
Scrudge
ну, ну а на что тестирование?
здесь, я думаю, речь шла не о работоспособности, а о структуре кода, и возможности дальнейшей его поддержки
8. bobah_ly , 21.06.2005 10:50
V.M.Kotov

В штатах как я понял поступают немного по-другому. Организовывают Open Source проект в рамках университета. Обычно получаются очень наукоемкие проекты, на которых многие защищаются.
В качестве лабораторок для начинающих можно устроить изучением алгоритмов, написанных более продвинутыми товарищами (ну или просто STL . Более продвинутые занимаются разработкой/доработкой проекта.

9. Dilon , 21.06.2005 10:53
Chippy2003 там уже началась работа и сроки до конца лета
10. V.M.Kotov , 21.06.2005 11:04
dozen
Принято. Но вопрос несколько шире — кого стоит поддержать, например нет желания поддерживать пентагон даже опосредовано т.е. лучше вообще что-нибудь с отечественными корнями. Конкретизируйте
nenin
Правила в т.ч кодирования для gcc я прочитал там объём материала — на среднюю методичку, перевести и заставить выполнять — дело техники

цитата: Боюсь, это будет медвежья услуга движению OpenSource. Во первых, «начинающий программист» это чаще всего слон в посудной лавке — после него замучаешься переделывать. Более того, «начинающий программист», которого загнали на работу из под палки (да еще и бесплатно) к тому же слон злонамеренный: в общем сломает больше, чем починит.

Во первых c OpenSource ничего страшного не случится — защита от дураков там имеется. Во вторых стимул у студента и так есть — лабораторка->зачёт->экзамен иначе армия

Scrudge
Пофиксить 5-7 багов за семестр — по-моему реально.

Добавление от 21.06.2005 11:07:

bobah_ly
Понятно что надо идти к своему проекту — но для этого надо фактически менять 90% преподавательского сотава — а откуда его взять — надо вырастить, а как выростить если нет своих проектов — учиться на чужих.

11. Scrudge , 21.06.2005 11:36
V.M.Kotov

кого стоит поддержать — например, у OpenSource сообщества есть проблемы с издательскими системами (настольными), реальной альтернативы InDesign и Quark Xpress нет (Scribus не всчет, он еще слишком слаб). Имеется куча просмотрщиков, но нет ни одного сопоставимого по возможностям с IrfanView или ACDSee. Аналога HyperSnapDX, нормального, тоже нет. Нет ни одного файлового менеджера сопоставимого по мощности с Total Commander или Frigate. Конкурента (подчеркну, нормального) ABBYY Lingvo тоже нет. Вообщем — вариантов море!

например нет желания поддерживать пентагон — а какая разница если это GPL, например? Все равно все смогут использовать и пентагон в том числе.

лучше вообще что-нибудь с отечественными корнями — а вот этого не так много, к сожалению. Из крупных проектов, лично я, на вскидку могу припомнить только Quanta+ (редактор языков разметки и скриптовых использующихся в Web аналог Macromedia Dreamweaver), да и то ребята ее разрабатывающие перешли к разработке коммерческой версии, а Open Source версию поддерживают буржуи.

Пофиксить 5-7 багов за семестр — по-моему реально. — maybe, maybe.

12. Chippy2003 , 21.06.2005 11:45
Dilon
Как список дружественных к студентам проектов все равно сойдет
13. wolf69 , 21.06.2005 15:23
V.M.Kotov

Ну вот есть например такой проект
http://prawda.newmail.ru

Ни строчки кода внести не позволю, но наиграетесь вволю.
Начиная от простейших вещей типа подсчета частотности слов в «Войне и мире»,
кончая такими вещами как составление переводных и семантических словарей с помощью нейронных сетей.
А еще можно все это добро перенести в ПалмОС

14. Scrudge , 21.06.2005 15:33
wolf69

Ни строчки кода внести не позволю — интересно, что это за Open Source такой тогда?

15. wolf69 , 21.06.2005 15:57
Ну ты посмотри на страницу.
Там С-кода 1 мегабайт, грамматик тоже где-то 1 мег и 30 мегабайт словарей.
Так вот переводящая программа остается за тем человеком, кто ее сейчас пишет.
А вот всякие вещи, которые вокруг — лингвистические исследования можно отдать студентам.
Программы их использоваться. ну может быть и будут, но не пользователем а разработчиками.
Просто их главный выход — лингвистическое знание, оно вообще не в виде программ.
Программы — это просто инструмент, «усилитель интеллекта».

Ну и вообще — кому сейчас нужны программы 10 летней давности? А вот словари не теряют актуальности
по сто лет. А еще есть такие грамматики Хомского, которые первый раз были открыты (держись за стул)
аж в 5 веке до нашей эры.

16. V.M.Kotov , 21.06.2005 17:28
wolf69
Спасиб за ссылку, но инересуют проекты с более развитой инфраструктурой, чтобы студенты привыкали к тому как надо работать в большом проекте с CVS и т.п.

А про словари и грамматики Хомского удалите плз — к теме отношения — ноль

17. Scrudge , 21.06.2005 17:32
V.M.Kotov

А про словари и грамматики Хомского удалите плз — к теме отношения — ноль — Да, нет. Товарищ — таким образом решил рабочей силой бесплатной обзавестись.

18. dozen , 21.06.2005 17:50
V.M.Kotov

цитата:
Принято. Но вопрос несколько шире — кого стоит поддержать, например нет желания поддерживать пентагон даже опосредовано т.е. лучше вообще что-нибудь с отечественными корнями.

Ну, меня поддержите. а, звиняйте — тут какой-то департмент в вооруженных силах мой код юзает, а вы же пламенные патриоты, неутомимо сражающиеся с потенциальным противником. тогда. тогда. вот ведь, блин, а тогда некого! DOD — крупнейший заказчик всего и вся, и почти любой OS-проект где-нибудь в DOD да используется.

Может, отделите котлеты от мух? Хотите студентов программить научить — учите. Хотите пушечным мясом сделать — делайте. Но определитесь наконец.

цитата: V.M.Kotov:
*** но инересуют проекты с более развитой инфраструктурой, чтобы студенты привыкали к тому как надо работать в большом проекте с CVS и т.п. ****

Я бы на большой проект (по настоящему) сразу не замахивался. Там ресурсы нужны, однако. Попробуйте что-нибудь типа Мозиллы стащить и помотреть. А вот с инфраструктурой- то это да.
ИМХО:
1. Можно попробовать поработать с Parynya ( http://www.parinyasoft.com/ ) Но я про OpSrc что-то у него не заметил. Кроме того, не исключено что багов там не очень-то много.
2. Visual-MinGW 0.56 http://visual-mingw.sourceforge.net/ — багов много, альфа версия, и sourceforge- т.е. развитая система обратной связи.


Свой проект бодяжить не стоит. Но может стоит попробовать «перехватить» что-нибудь умирающее- такое на sf бывает.

цитата: например нет желания поддерживать пентагон

а он что- домагается? Вот противный.

19. nenin , 21.06.2005 18:25

цитата:
Попробуйте что-нибудь типа Мозиллы стащить и помотреть.

200мб исходников? Мозилла далеко не «простенький» проект

20. Dilon , 21.06.2005 21:23

цитата:
Попробуйте что-нибудь типа Мозиллы стащить и помотреть.

200мб исходников? Мозилла далеко не «простенький» проект

Я может неясно выразился- Мозилла как раз пример большого проекта (там некоторые предлагали). Как распакешь- сразу ясно, что по чём.

21. nenin , 21.06.2005 21:40
22. scorpi , 21.06.2005 21:48
Я думаю Mozilla не самый подходящий проект для обучения. Лучше взять проект, в котором не изобретается велосипед для каждой ерунды, и не вводятся контрапродуктивные ограничения на используемые фичи.
23. ViRUS_1 , 22.06.2005 07:07
V.M.Kotov
1)iXBT Forum DB (Delphi). Только он маленький, без CVS (все никак не могу на sf загнать). Можно взять на моем сайте. В перспективе планировал сделать плагины для разных сайтов. Студентам можно поручить их написание.
2)RSDN@Home (C#). www.rsdn.ru

цитата: V.M.Kotov:
Есть такая мысль вместо типичных лабораторных работ заставить студентов ковырять OpenSource проекты, понятное дело что студенты — программисты в основном нулёвые, но в gcc напрмер есть специальный раздел

где имеются задачи для начинающих программеров.

Вопрос: где ещё в Open Source есть здачи для начинающих которые можно преобразовать к лабораторным работам?

Вот ещё кстати, напомнили мне: http://www.codeblocks.org/

24. nenin , 22.06.2005 21:46
25. VBKesha , 23.06.2005 00:45
Да вообще идея хорошая, а то надоело решать задачи не имеюие никакой ценности.
26. rGlory , 23.06.2005 00:58
Кстати есть вот что http://www.topcoder.com, при этом очень удобно, Вам даже оценки ставить не придется, они за Вас все сделают
27. denixa , 23.06.2005 09:56
Идея хорошая. Может имеет смысл попробывать свой проект организовать по правилам и схемам opensours, следующие покаления студентов будут приходить и дорабатывать функциональность. Только надо выбрать востребованную область, автоматизировать какуенибудь задачу для Учебного заведения. Попробуйте начать с разработки сетевой системы тестов или посложнее (пока нигде до конца не рещенной задачи) составление расписания, или разработайте(доработайте базу деконата) и т.д. Главное чтоб этим ктото пользовался. Можно еще попробывать создовать аналоги не очень сложных прорамм.
28. softland , 23.06.2005 10:05
Посмотри GeoBlock (https://sourceforge.net/projects/geoblock) он правда на Delphi, но там и OpenGL и базы данных и перспективы внедрения.
29. V.M.Kotov , 23.06.2005 14:15
all
softland
Речь идёт, естественно, о С/С++.
30. ViRUS_1 , 25.06.2005 10:34
V.M.Kotov
http://wackowiki.com/RussianOpenSource
31. psg , 26.06.2005 17:03
V.M.Kotov
А где Вы аж пару десятков студентов набрали, которые понимают, что такое указатели?

Добавление от 26.06.2005 17:06:

V.M.Kotov
Кстати, IMHO Ваша идея редкостный бред. Если студенту это будет интересно, он поддержит какой-то нибудь проект. Самостоятельно. Тот, который будет интересен именно ему, а не Вам. А всем остальным проще массивчик отсортировать и после зачета забыть о программировании как о страшном сне.

psg
А как мне видится, редкостный бред это отучиться 5 лет по специальности «Программное обеспечение вычислительной техники и автоматизированных систем.» после чего идти работать продавцом консультантом, забыв о программировании как о страшном сне. А вот сделать так чтобы студенту был интересен именно тот проект который ему ДОЛЖЕН быть интересен вот это не просто — тут где то и есть отличие преподавателя института от преподавателя ГПТУ.
А что такое указатели — объясняют на первом курсе — дисциплина ЯВУ (язык высокго уровня).
Да и если Вам нечего ответить на вопрос данной ветки то просьба — не засоряйте эфир.

32. V.M.Kotov , 27.06.2005 09:21
33. vvd-2007 , 20.02.2007 22:17
http://fat.hut1.ru/
Эту программу я писал года три назад. Это графический редактор для флэш-анимации на linux. Можете взять его и делать с ним всё что вашей душе будет угодно. Ссылка на исходники в самой нижней строчке страницы. Если будут вопросы — отвечу что знаю.
А по теме — это лучше курсовые и дипломные задания давать, а не лабораторные.
И ещё — сходите на http://www.sisyphus.ru/ Там вроде авторы все русские.
34. Lamn , 21.02.2007 21:39
Можно еще посмотреть, кто сам просит о помощи: http://sourceforge.net/people/

Добавление от 21.02.2007 21:48:

Вспоминаю эмоции, когда заработали мои первые правки в чужом серьезном софте. Как раз в студенческие годы, как же это было здорово! Идея вплотную показать студентам реальные программы определенно хороша!

Записки программиста

Как стать контрибьютором в open source проект — идеи для первого патча и прочие рекомендации

26 декабря 2020

Я нередко наблюдаю, как люди приходят в мейлинг лист какого-нибудь открытого проекта и спрашивают, мол, с чего проще всего начать контрибьютить в этот проект. Видимо, этот вопрос беспокоит многих, поэтому я решил приготовить пост с некоторыми идеями по этому поводу. По моему опыту, от специфики проекта тут мало что зависит, так что идеи довольно универсальны.

Между прочим, интересный вопрос — а зачем это вообще кому-то может быть нужно? Для большинства людей работа над открытыми проектами — это в первую очередь возможность получить колоссальный опыт разработки, а также сделать нечто, чем будут пользоваться миллионы людей по всему миру (возможно, даже не зная об этом) ну как минимум еще ближайшие лет 10. Не стоит также списывать со счетов желание понять, как внутри устроены, скажем, операционные системы или компиляторы. Я пишу здесь об этом по той причине, что без достаточно сильной мотивации вы вряд ли найдете лишнее время для работы над каким-то там опенсорсом. Поэтому первым делом поймите для себя, что именно привлекает вас в данном конкретном проекте.

Примечание: Также вас может заинтересовать статья Как я прокачиваю владение английским языком. В мире open source, как правило, все разработчики общаются между собой на английском языке.

Далее предполагается, что вы определились с проектом, а также разобрались, как он компилируется, как прогоняются тесты, как происходит установка, а также нашли описание процесса разработки и место, куда нужно посылать патчи. Это не сложно. Примеры см в заметках Сборка LLVM-стека из исходников и чем она так интересна, PostgreSQL: сборка из исходников и настройка под Linux, Основы написания декодеров для Sigrok на языке Python и Памятка по сборке ядра Linux из исходного кода. Также не повредит разобраться, как отлаживать проект. Тут все сильно зависит, помимо прочего, от используемого в проекте языка программирования, а также используемой вами ОС. Если проект написан на C или C++, то обратите внимание на мои заметки, посвященные GDB, LLDB и WinDbg. В любой непонятной ситуации не стесняйтесь обратиться за помощью в мейлинг лист или IRC-канал проекта.

Итак, с чего же можно начать:

  • Опечатки. Начните с малого. В любом достаточно крупном проекте полно опечаток, как в документации, так и в комментариях к коду. Патчу, который их исправляет, гарантированно все будут очень рады, а шансы сломать что-то таким патчем равны нулю. А значит его почти наверняка быстро примут. В процессе у вас сложится хорошее понимание, как в данном конкретном проекте нужно оформлять патчи, куда их нужно слать, и так далее.
  • Code review. Большинство программистов обожают писать код, но не очень любят читать или тестировать его. Поэтому многие проекты испытывают нехватку в ревьюверах. Будучи новичком в проекте, вы совершенно бесценны, как ревьювер! Ведь вещи, которые другим разработчикам могут казаться «очевидными», для вас таковыми не являются. При этом делать code review сравнительно просто. Как минимум, нужно проверить, что код действительно делает то, что нужно, ничего не ломает, проходит все тесты и сам покрыт тестами, не сыпет ворнингами при компиляции, хорошо документирован, оформлен в соответствии с принятым в проекте code style, не ломает обратную совместимость, и не содержит явных ошибок (например, утечки ресурсов). Что интересно, читая чужой код, вы быстро разберетесь во внутреннем устройстве проекта. Не бойтесь пропустить какие-то ошибки. Коммиттер, а также другие ревьюверы, прекрасно понимают, что вы работаете над проектом недавно, и в любом случае перепроверят за вами.
  • Исправление багов. На какие-то баги вы можете налететь сами. Особенно, если проект, над которым вы работаете — это библиотека. Но куда большие багов обычно репортят другие пользователи проекта. Проверьте багтрекер. Найдите первый понравившийся баг и попытайтесь его воспроизвести. Если не получается, постарайтесь выяснить у багрепортера детали. Может оказаться, что баг не воспроизводится или даже уже был исправлен. Закрыв тикет без какого-либо исправления, вы тоже окажете помощь проекту. Еще в поиске багов вам могут помочь санитайзеры и статические анализаторы кода.
  • Оптимизация. Обычно это халява, так как в сущности от вас требуется переписать код, чтобы он делал то же самое, только быстрее. Правда, чтобы найти настоящее «бутылочное горлышко», нужно не просто придумать синтетический бенчмарк, а иметь какую-то реальную и достаточно большую нагрузку. Само собой разумеется, выполнение оптимизации потребует от вас хорошего владения средствами профилирования кода.
  • Тесты. Печально, но факт — тесты программисты писать тоже не любят. Определите степень покрытия кода тестами, найдите непокрытые участки кода, напишите для них тесты. Удивительно, но многие программисты не понимают разницу между модульными и интеграционными тестами и никогда не слышали про property-based тесты. Если в проекте нет одного из этих видов тестов, предложите патч, который его добавляет.
  • Документация. А еще программисты часто не любят писать документацию. Проверьте, нет ли белых пятен в официальной документации или man-страницах проекта. Бывает еще так, что в документации есть несостыковки, устаревшая информация, или просто битые ссылки. Возможно, документацию можно улучшить, добавив в нее наглядных примеров.
  • Рефакторинг. В любом достаточно старом проекте есть места, которые можно переписать чуть лучше, чем они написаны сейчас. Большой файл с исходным кодом можно разбить на несколько, десяток параметров, передаваемых процедуре, можно объединить в одну структуру, и так далее. Важно, чтобы код не только решал стоящую перед ним задачу, но и был при этом читаемым!

Если позволите, хотелось бы дать еще пару советов. (1) Чем меньше ваш патч, чем больше шансов, что его примут. В частности, «заодно» подправлять отступы в не связанных с вашим патчем местах — очень плохая идея. (2) На первых порах любая прихоть коммиттера для вас — закон. Если коммиттер просит вас что-то исправить в патче, просто сделайте это, даже если ваши предпочтения не совпадают с предпочтениями коммиттера. Спор с ним попросту ни к чему не приведет. (3) Будьте предельно вежливы, используйте как можно больше слов please, thank you, и так далее. Любая грубость, троллинг, сарказм и так далее совершенно недопустимы!

Также не забывайте, что контрибьютить можно не только в виде патчей. Отвечать на вопросы в IRC и пользовательском списке рассылки, дополнять и исправлять wiki-сайт проекта, освещать новости проекта в своем блоге (можно создать рассылку ProjectName Weekly, если ее еще нет), писать обучающие статьи или, возможно, даже книги, посвященные проекту, организовать локальные юзергруппы, и так далее — все это тоже очень важные вклады в развитие проекта!

А контрибьютите ли вы в open source проекты и если да, то в какие, и каким образом?

18 open source проектов для практики программирования

14 Способов сделать вклад в открытое программное обеспечение, не будучи Гениальным Программистом или Рок-Звездой


Множество людей хотят влиться в open source, но не знают с чего начать. Вот несколько способов, которые помогут, даже если вам недостаёт технических знаний и способностей.

Открытое программное обеспечение изменило мир, и многие хотят внести свой вклад. К сожалению, люди ужасаются от барьера на вступление в open source проект. Я часто слышу от людей, которые хотят помочь, но не могут:

«Я не очень хороший программист.»
«Я не смогу выделять достаточно времени.»
«Я не знаю к какому проекту подключится.»

Существует 3 основных принципа, которые следует помнить, если вы ищете возможность внести свой вклад:

Проектам нужны люди с любым уровнем знаний и опыта.
Маленький вклад лучше, чем никакой.
Если не знаешь с чего начать — начни с того, что используешь!

Среди новичков самая разрушительная мысль которую я наблюдал — мнение что для вклада в open source ты должен быть гениальным разработчиком. Это не так! Конечно, есть некоторые «рок-звёзды» в open source и они даже могут быть гениальными программистами. Тем не менее, подавляющее большинство таковыми не являются! Мы просто люди которые делают своё дело. Иногда мало, иногда много. Иногда это программирование, а иногда и нет.

Большинство из того, что делает open source это работа и время потраченное на проект. Большинство таких вещей не требуют интеллекта или взгляда как у Ларри Уолла, создателя Perl’а, или Давида Ханссона, создателя Rails. Для разработки нового языка программирования или web-фреймворка вдохновение надо, но остальное, что делает проекты уровня Perl и Rails успешными — тяжкий труд. За это вы, возможно, и не получите славу, но всё равно необходимо и через какое-то время ваш вклад будет замечен.

Прислушайтесь к другим

Всё в open source включает себя других людей. Желание присоединиться к команде значит, что ты понимаешь сообщество проекта и как в нём всё крутится. Прогулка в проект со словами «Привет! Я думаю что делать следует вот так.», как правило, не расценивается хорошим тоном. Некоторые проекты может и приветствуют такого рода подход, но если проект уже устоявшийся, такой подход имеет мало шансов на успех. Слушать — это лучший способ узнать в чём проект нуждается.

Списки рассылок: Для многих проектов, списки рассылок являются основным каналом связи по разработке проекта. У больших проектов есть много рассылок и есть из чего выбрать. К примеру, для PostgreSQL существует не менее 12 рассылок для пользователей и 6 для разработчиков. Я предлагаю подключится к основной рассылке как для пользователей, так и для разработчиков, чтобы начать слушать.

Подпишитесь на блог: Блоги которые ведут основные разработчики часто полны информацией про будущие релизы. Существуют агрегаторы новостей и блогозаписей проекта. Если такой сайт есть, к примеру planet.gnome.org или planet.mysql.com, начните оттуда. Попробуйте поискать в Google «planet ».

Подключитесь к IRC каналу: Многие open source проекты имею IRC-каналы где разработчики и пользователи зависают для обсуждения разработки и решения проблем. Посмотрите на странице проекты как называется канал и в какой сети IRC он находится. (прим. перев. Как показывает практика самой популярной сетью есть Freenode, а потом — собственные серверы проектов. Не редки случаи запуска собственных серверов Jabber и конференций.)

Работа с ошибками

Код — сердце практически любого open source проекта, но не думайте что писать код это единственная возможность сделать вклад. Поддержкой кода и системы в целом часто пренебрегается в погоне за новыми возможностями и исправлениями ошибок. Осмотритесь, возможно это ваш путь вступления в проект.

Большинство проектов имеют публичные, видимые для всех, системы отслеживания ошибок, связанные со страницей проекта и документацией. Это второй важный канал связи между разработчиками и пользователями. Поддержание его в актуальном состояние это отличный способ помочь проекту. Возможно, вам понадобятся дополнительные полномочия, которые большинство руководителей будут рады вам дать, если вы изъявите желание помочь.

Диагностика ошибок: Ошибки часто имеют плохое описание. Диагностика и сортировка ошибок сильно помогут разработчикам (даже более того, сэкономят им время) в определении в чём же действительно проблема. Если пользователь сообщает, что «Приложение не работает когда я делаю X», потратьте немного время что бы уточнить что именно идёт не так. Ошибку можно воспроизвести? Можно сделать пошаговый мануал по проблеме? Можно ли сузить проблему: воспроизводится только в одном браузере, работает только в некоторых дистрибутивах? Если да, то в каких?

Даже если вы не знаете в чём именно проблема, затраченные усилия помогут кому-то уточнить или даже решить проблему. Заносите всё что вы нашли по проблеме в bug-трекер, что бы все имели доступ к актуальной информации.

Закрывайте исправленные тикеты: Часто в коде ошибки уже исправлены, но запись в bug-трекере ещё есть. Зачистка этого «хлама» может занять уйму времени, но принесёт неоценимый вклад для всего проекта.

Начните с поиска старых записей и посмотрите, действительно ли ошибка ещё присутствует. Проверьте, возможно в новых релизах ошибка уже исправлена и запись может быть закрыта. Если известно что исправлено — укажите версию и можете закрывать.

Если явных следов исправления нет — попробуйте воссоздать ошибку на новых версиях. Если не воспроизводится — откомментируйте тикет и закройте. При наличии ошибки отметьте это, но, оставьте открытым.

Программисты с любым уровнем знаний и опытом могут помочь проекту. Не думайте что надо быть настоящим гением для существенного вклада в проект.

Если ваша работа включает изменение кода, посмотрите в какой форме происходит передача кода в проект. У каждого проекта свой рабочий процесс, поэтому уточните как правильно делать прежде чем отправлять код.

К примеру для PostgreSQL процесс очень строгий: модификации кода, в виде заплатки, отправляются в список рассылок разработчикам, где они изучают каждый аспект изменений. С другой стороны, есть проекты, такие как Parrot, в которых очень просто получить привилегию делать commit в основную ветку кода. Если проект использует GitHub, вероятно рабочий процесс основан на системе pull-запросов. Нет двух одинаковых проектов!

Всякий раз когда вы изменяете код, следите что бы вы действовали как ответственный участник сообщества и ваш код соответствовал стилю всего остального проекта. Добавленный или изменённый вами код не должен отличаться от остального! Вам может и не нравится использование текущего стиля скобок или пробелов для создания отступов, но это грубо когда вы добавляете код, который не соответствует стандарту. Это тоже самое: «Мне не нравится ваш стиль, мой лучше, делайте как я.»

Тестируйте: Почти все проекты предназначенные для использования на нескольких платформах могут иметь проблемы переносимости. Когда релиз скоро и бета- или релиз-кандидат- версии готовы, руководитель проекта надеется что проект будет тестирован разными людьми в разных условиях. Вы можете быть именно таким человеком и проверить что на вашей платформе пакет работает правильно.

Как правило, нужно лишь скачать, собрать и начать использовать приложение. Но вклад может быть огромен если у вас непопулярная платформа или аппаратное обеспечение (прим. перев. К примеру помочь разработчикам nouveau сделать поддержку современной видеокарты, что переводчик и сделал летом.). Просто комментарий о том, что сборка и испытания прошли успешно, дают знать что предстоящий релиз проверен и может быть опубликован.

Исправляйте ошибки: Это, как правило, путь для людей которые хотят сразу влиться в код. Тут всё просто: ищем интересную ошибку в bug-трекере и исправляем её в коде. Документируем исправления в коде, если это принято.

Хорошая идея — это создание тестов для кода, который вы исправили; а некоторые проекты даже требуют исправление ошибок с тестами! Возьмите блокнот и ручку для записей при копании в незнакомом коде. Даже если вы не можете исправить ошибку, запись в bug-трекере это отметка что вы пытались сделать. Это поможет другим, кто придёт после вас.

Пишите тесты: Большинство проектов имеют наборы тестов, но сложно себе представить такой набор, в котором больше нечего тестировать. Используйте такие инструменты для исследования покрытия кода как gcov для C или Devel::Cover для Perl. А затем, добавьте тесты для улучшения покрытия.

Заставьте замолчать компилятор: Процесс сборки для проектом на C часто сопровождается странными предупреждениями компилятора. Эти предупреждения редко показывают на реальную проблему, но они могут так выглядеть! Да и слишком много предупреждений делает компилятор похожим на ноющего ребёнка.

Убедитесь что код действительно содержит ошибку. Если нет, исправьте код так что бы избавиться от ложного срабатывания (или, не совсем ложного).

Добавьте комментарии: Если вы копаетесь в чужом коде, вы часто находите места которые вас сбивают с толку. Если даже вас он сбивает, то какие чувства у остальных на этом месте? Сделайте полезный комментарий и отправьте заплатку.

Работа с документацией

Документация это важная часть любого проекта. Она может страдать от того, что была написана с точки зрения человека знакомого с проектом, а не глазами человека, который только хочет туда попасть. Если вы когда-то читали документацию с мыслью «Он что, думает что я знаю как это делать?» то вы понимаете о чём я говорю. Свежий взгляд всегда благотворно влияет на документацию и указывает на недостатки, которые остальные уже не замечают.

Создавайте примеры: Нет ни одного проекта в котором достаточно примеров. Web-API, библиотеки, графические приложения (такие как, GIMP) или командные утилиты, для всех них хороший пример лучше покажет использование, чем сухая документация.

Для API или библиотеки не лишним будет написать приложение которое её использует. Это могут быть даже куски ранее написанного кода с отсечением всего ненужного. Живой пример использования в повседневной жизни также будет не лишним! Если приложение графическое — рассмотрите создание скрин-каста разных процессов.

Работа с сообществом

Открытое программное обеспечение это только отчасти код. Сообщество, вот что движет им. Вот способы которым вы можете тут помочь.

Отвечайте на вопросы: Лучший способ построить сообщество — помогать друг-другу. Отвечать на вопросы, особенно новичков, это важный шаг в росте и процветание. Время затраченное на помощь «нубу», даже если его вопрос можно легко найти в документации (с ответом: «RTFM»), оплатится новым, активным участником. Каждый с чего-то начинал, а приток новых пользователей это жизненно важно для любого сообщества.

Пишете блогозаписи: Если у вас есть блог, поделитесь опытом. Расскажите о проблемах с которым вы столкнулись и как вы их решили. Этим вы сразу поможете в двух направлениях: продвижения проекта и помощь людям, которые столкнулись с такой же проблемой. Блог ваших технических похождений также очень неплохой способ показать опыт использования технологий и приложений и будет полезен при поиске новой работы.

Улучшите сайт проекта: Большинство программистов — дерьмовые дизайнеры и редкий проект которому не нужна помощь талантливого дизайнера. Помогите улучшить дизайн сайта, всё-таки это лицо проекта. Поверьте, затраченное время окупится с лихвой! Возможно проекту нужен капитально новый дизайн или логотип, а таких способностей может не хватать у сообщества. Я знаю это, потому-что сам хотел бы улучшить дизайн сайтов собственных проектов.

В конце-концов. Прежде всего, слушайте о чём люди говорят. Смотрите, возможно именно тут вы можете чем-то помочь. Например, недавно в рассылке проекта Parrot было решено использовать GitHub и их систему bug-трекера взамен старого Trac. Некоторые люди были против — не было способа перенести всю старую базу Trac на новую платформу. После целого дня споров, я влез и сказал: «А что если я напишу преобразователь?». Люди пришли в восторг от моей идеи! Я потратил время, чтобы написать программу для преобразования 450+ тикетов. Ведь в противном случае была б потеряна история. Это был успех! Я взялся за дело, а в это время основные разработчики оставались сосредоточены на развитии Parrot.

Существует так много способов внести свой вклад, особенно если мы посмотрим мимо очевидного — добавление нового функционала. Каждый, кто использует open source, может помочь своими талантами и способностями в развитии проекта и его сообщества.

FDroid — F-Droid сетевой репозиторий Open Source проектов, сам является открытым ПО, исходники сервер и клиент, и хвалебная ода на хабре.

AOpenSource — база данных Open Source проектов включает

Форум русскоязычного сообщества Ubuntu

Считаете, что Ubuntu недостаточно дружелюбна к новичкам?
Помогите создать новое Руководство для новичков!

Автор Тема: Open-source проекты (Прочитано 4049 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Страница сгенерирована за 0.069 секунд. Запросов: 24.

© 2012 Ubuntu-ru — Русскоязычное сообщество Ubuntu Linux.
© 2012 Canonical Ltd. Ubuntu и Canonical являются зарегистрированными торговыми знаками Canonical Ltd.

Цукерберг рекомендует:  Знай, когда Google индексирует твой сайт
Понравилась статья? Поделиться с друзьями:
Все языки программирования для начинающих