LINUX.ORG.RU

Участие в опенсоурс проектах


0

0

Долго думал куда запостить эту тему, решил сюда.
Вот есть желание поучавствовать в опенсоурс проекте, интересует разработка на Qt + C++. Опыта мало.
Как найти проект, который еще не сильно матерый (чтобы не сильно много чужого кода разбирать, потому как с этим проблемы) ну и для начала попробовать написать некие патчи к данной софтине?
И вообще кто участвовал, какое важное св-во нужно иметь, помимо умения и опыта разработки на данном ЯП\технологии? Или если не особо силен в них, то лучше не соваться?

П.С, огромная просьба сильно не троллить.

Спасибо за ответы.

★★

OpenSource это не просто «обязанность». Смотри на софт и определяй что тебе не нравится, но ты хотел бы помочь проекту стать таким как ты хочешь.
Всё просто.
Какие скиллы? Знание английского, опыт кодинга, понимание кода, стиля, умение исследовать код чтобы не плодить велосипедов.

tia
()
Ответ на: комментарий от tia

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

DDR ★★
() автор топика

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

И вообще кто участвовал, какое важное св-во нужно иметь, помимо умения и опыта разработки


Не огорчаться, когда твои патчи не принимают из-за того, что у разработчика «своё видение направления развития проекта».

Biga
()
Ответ на: комментарий от DDR

Опыт лучше получать не в живых проектах. Сам придумай задачу и скооперируйся со знакомыми/найди с кем можно было бы это сделать, скажем, на том-же лоре.

tia
()
Ответ на: комментарий от tia

Да ничо хорошего от этого не выходит, как только задача почти готова, то улучшать ее уже не интересно ибо никому не нужна. И так получается, что пишешь УГ и опыта не особо добавляется.

DDR ★★
() автор топика
Ответ на: комментарий от DDR

>ибо никому не нужна
А ты найди то что нужно.
Допустим, есть тулза, которая тебе нравится, но она написана, допустим, на фрипаскале. Может стоит переписать её на CPP с Qt?
Тоже самое и с другими проектами.
Видишь что в проекте не хватает чего-то(допустим, считаешь что все IM ущербны) - делай своё.

tia
()

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

Milker ★★
()
Ответ на: комментарий от Milker

>Переписать какую-нибудь тулзу с одного языка на другой.

Это контрпродуктивно.

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

Лучше писать мелкие утилиты «для себя». Для этого надо временно разучиться пользоваться гуглом и начать клепать велосипеды. Чем больше, тем лучше. При этом не лениться читать документацию к библиотекам, info libc и время от времени смотреть на то, «как пишут люди».

Процесс весьма и весьма небыстрый. Может занять годы, так что подумай: надо ли оно тебе, т. к. программисты — одна из самых бесперспективных профессий.

linuxfan
()

> Как найти проект, который еще не сильно матерый (чтобы не сильно много чужого кода разбирать, потому как с этим проблемы) ну и для начала попробовать написать некие патчи к данной софтине?

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

Из мелких программ на C++ и Qt у меня стоит только http://symmetrica.net/cuneiform-linux/yagf-ru.html

question4 ★★★★★
()

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

mv ★★★★★
()
Ответ на: комментарий от question4

Посчитал пакеты с объёмом менее мегабайта и зависящие от Qt. Получил:

Модули Qt:
x11-libs/qt-test
x11-libs/qt-svg
x11-libs/qt-sql
x11-libs/qt-dbus
x11-libs/qt-opengl

Части KDE:
kde-base/kde-env
kde-base/automoc
kde-base/ktimezoned
kde-base/libknotificationitem
kde-base/qimageblitz
kde-base/kdebase-data

Графические интерфейсы к Cuneiform:
app-text/cuneiform-qt
app-text/yagf

Аналог Alcohol 120%:
app-cdr/acetoneiso

Словари:
app-dicts/qstardict
app-dicts/simpledict
app-dicts/goldendict

Насколько я могу судить, Cuneiform-Qt прекратил развиваться. Последние 5 пунктов — вполне живые проекты, развиваемые одиночками или небольшими коллективами, объём исходников — несколько сотен килобайт.

question4 ★★★★★
()

Приделай к qbittorrent какой-нить xml-rpc интерфейс или что-то подобное, чтобы его можно было в качестве демона запускать, а потом из гуя к нему подключаться.
Было бы очень полезно.

proDOOMman ★★
()
Ответ на: комментарий от ShTH

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

azure ★★
()

>> т. к. программисты — одна из самых бесперспективных профессий.

это кризис

kto_tama ★★★★★
()

Ну это же всё просто делается. Scratch your own itches. Что тебя раздражает в софтине, которой пользуешься? Ковырни, исправь, сунься в баг-трекер и предложи свой фикс.

Оно именно так и работает. Приходить с пустыми руками и говорить: «озадачьте меня чем-нибудь, я очень хочу поучаствовать», — не только глупо, но и бесполезно. Некоторые проекты публикуют свои TODO, у некоторых это надо собирать в багзилле, но лучше всего связываться именно с тем, с чем имеешь дело постоянно: так и мотивация будет, и тестирования достаточно.

rusty_angel
()

> не сильно много чужого кода разбирать, потому как с этим проблемы

ни! так дела не делают. это хорошее умение. приводит к тому, что скок-скок-скок по коду в нужную точку. не понятно - читать что вокруг и понимать как и что с чем связано.

а вообще - опыт, опыт, опыт. как правило большие проекты модульные (если хорошо были изначально проектированны). т.е. большой он или нет, но участок всё равно будет ограничен по размеру

gunja
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.