14 начина да направите първата стъпка от отворен код
Софтуер с отворен код, или «отворен код», значително влияние върху развитието на информационните технологии, както и много фирми се интересуват. Често, обаче, експертите виждат редица пречки за участието си в отворен код-проектите. Ето основните от тях са:
- "Аз не съм много добър програмист."
- "Аз не съм достатъчно време да го направя."
- "Аз не знам какъв проект да се направи."
Но това не е много добър подход към проблема. Така че, има три основни принципи трябва да имате предвид, когато мислите за новите възможности в областта на развитие:
- Проектите трябва специалисти с различни нива на обучение, умения и опит
- Дори и експерт-новак - е по-добре от нито един експерт.
- Най-добър проект за начало - този, с който вече сте запознати с.
Най-често погрешно схващане за начинаещи е, че те вярват, че да участват в отворен код проекти трябва да бъде истински "програмиране гений." Но това не е така. Разбира се, в света на отворения код развитие има своя гуру, но не всички. Повечето от тях - обикновените програмисти, които са добри само в работата си, без значение колко малки или големи, те допринасят за проекта. И не винаги е тази работа е свързана с програмиране. Работата по проектите с отворен код-крие главно в рутина изпълнението на текущите задачи.
Повечето от задачите, които са разработчиците, не изисква гений на проблеми със зрението, като Wal Лари, Perl създател Дейвид или Heynemeyera Хансон, основателят на релсите.
Създаване на нов език за програмиране или рамка, разбира се, изисква вдъхновение, но останалата част от работата, което прави проекти като Perl или релси, успешна рутинна изисква постоянни усилия. Тези усилия едва ли може да ви донесе слава, но те със сигурност са необходими и важни, и рано или късно, дарението ще се види.
слушайте внимателно
Всички етапи на работата в отворен код проекти в един или друг начин свързани с хората, които са включени в тях. Вие се присъединят към екипа, което означава, че трябва да се разбере как процесите и взаимодействието между всички участници. За да се стигне до екипа с визията си за ситуацията и да налага всички свои гледни точки - не най-добрият вариант. За някои проекти, този подход може да е приемливо, но ако се работи върху продукта за повече от един месец, шансовете са, че вашите идеи ще приемат с ентусиазъм, много малки. Чуйте мнението на колегите си - това е може би най-добрият начин да се разбере какво е необходимо за проекта на този етап.
2. Следете блога. Блогове, които са водещи фирми, могат да бъдат много полезни, тъй като те ще ви информираме за промени и подобрения в предстоящото пускане.
Има специализирани портали с думата "планета" в заглавието, които се натрупват новини и публикации от блогове на различни ресурси, свързани с проекта. Намерете този ресурс чрез изпращане на заявка за търсене като "планета
3. Добавете в чата. В много отворен код проекти за обсъждане на актуални въпроси, използващи групови разговори. Така че бъдете сигурни, за да разбера как да общуват помежду си участници в проекта.
Работа с "билет"
Разбира се, кодът - това е в основата на всеки отворен код проект, но не вярвам, че код писане - това е единственият начин да участват в проекта. Техническа помощ често не обръщат достатъчно внимание на стремежа към създаване на нови функции и корекции на грешки. И всъщност това са областите, които позволяват на новодошлите да влязат в проекта.
Повечето проекти са на обща отворена система работи с "билет", който е свързан с интернет страницата на проекта и са включени в документацията. Такава система - е основният източник на комуникация между разработчици и потребители. Постоянна работа с текущата заявка - това е чудесна възможност да се допринесе за проекта. За да работи системата може да се наложи специални разрешения, които ви дават Тим капак, веднага след като сте решили да се придържате към настоящите изисквания на потребителите.
5. Затворете старите грешки. Това често се случва, че бъговете "фиксирани едно" но "билет" не е затворен. По този начин, системата е "запушена" старите грешки, които пречат на работата с реалните проблеми. "Почистване" на системата за проследяване на старите грешки - това е скучно и отнема много време процедура, но това е много важно за целия проект.
Работа с код
Ако работата ви е свързана с промяната на кода, да разгледа начини за промяна на кода, използван по проекта. За всеки проект се характеризира с нейните вътрешни технически процеси, така че да научите повече за тях, преди да предложи вашата версия на кода.
Така например, в проекта PostgreSQL строго регламентирани всички процеси: промени в кода се изпращат под формата на пластири за изпращане на всички големи разработчици, които внимателно да проучат всички промени. От друга страна, има и други видове проекти, като, например, Папагала, където програмистите да "ангажира" промените директно в базата данни. Ако вашият проект използва GitHub, вероятно процеси доставени чрез издърпване request'y, т.е. искания за включване на промените. Не забравяйте, че няма два проекта са едни и същи.
Всеки път, когато трябва да се пренапише кода, не забравяйте, че вие работите в екип и затова правим всичко възможно, за да съответства на вашия стил с обща база, използвана в проекта. част от код, които можете да добавяте или промяна, не трябва да се открояват от общата код. Може да се наложи на предпочитанията си в код дизайн, но кода си, трябва да отговарят на общите разпоредби, приложими към проекта. В противен случай това е едно и също нещо да казва: "Не ми харесва стила си, и мисля, че най-добрият ми, така че трябва да правиш това, което има."
6. Тест бета версията. Във всеки проект, който е проектиран да работи на множество платформи, могат да се проблеми, свързани с прехода към друга платформа. В навечерието на новата версия, когато има нова бета версия, мениджъри на проекти очакват, че те ще бъдат тествани на различни платформи. Можете да вземете участие в тестването и се уверете, че продуктът работи по една или друга платформа.
Като правило, което трябва да се изгради и инсталиране на нова "натрупване" и тестване на продукта, но е особено важно за проекта, ако използвате нестандартен хардуер. Ако се потвърди, че "Билд" работи при такива условия, това значително ще улесни задачата на мениджъри на проекти в определянето на текущото състояние на освобождаване.
7. коригират грешки. Обикновено това работа начинаещи с код започва. Тук всичко е просто: Намерете "билет", която описва някои бъг и да го коригираме в кода. Потвърдете промяната в документацията (ако е необходимо).
Приятно ми е да се добави на теста да се тества тази част от код, който имате фиксирани; Някои проекти изискват всички грешки са придружени от съответните тестове. Записвайте, тъй като капитанът на непознат код. Дори и да не могат да се справят с бъг, описва в билета, че сте успели да разберете за това. Това ще помогне на членовете на екипа, които ще работят с бъгове след вас.
8. Запис на тестове. Повечето проекти се използват тест-системи, предназначени за тестване на кода, но е трудно да си представим такъв комплекс, който няма да се предвиди възможност за добавяне на нов тест. Използвайте инструментите за изпитване, като например C или gcov за Devel :: Cover за Perl, да се определят областите на изходния код, който не може да бъде готов за тестване на тест комплекса. След това добавете подходящи изпитвания, за да може да се тества на изискваната функционалност.
9. Изключете предупреждението за компилатор. Често "Билд" проекти в C е придружен от многобройни сигнали компилатор. Това съобщение не винаги се говори за грешката, но предизвиква отвличане на вниманието.
Проверете дали кодът е скрита някаква грешка. Ако грешката не присъства, изключете фалшивата тревога.
Работа с документи
Архивиране - това е рутинна част от всеки проект, който често се пренебрегва. В допълнение, проблеми с документацията често могат да бъдат причинени от факта, че тя е написана от гледна точка на хората, които са запознати с проекта, а не тези, които са запознати само с него на. Ако четете документацията по проекта, която някога сте посетили идеята: "Изглежда, че това ръководство е написано така, сякаш аз вече знам как да се използва" Знаеш ли какво искам да кажа. Много често, нов поглед от разкрива слабости в настоящата документация, която не може да бъде видяно от участниците преките проекта.
11. Довежда примери. Все още няма такива проекти, които биха били налице твърде много примери. Независимо от това, което е заложено на карта: на API, електронна библиотека, графично приложение като Gimp, например, или на инструментите на командния ред - един добър пример с правилния описанието може бързо да се даде по-ясна представа за правилното използване на програмата, а не купчина документи.
За API, или по електронна библиотека, да създавате и примерна програма, която използва този инструмент. Тя може да бъде взето от кода, който сте написали, и адаптирани към нуждите на настоящия пример. Tool е най-добре да се въвеждат някои пример за това как можете да използвате в ежедневието. Ако сте визуален, добавете снимка на един процес, например, инсталирате приложението.
Работа в екип
Работа в отворен код проекти само отчасти свързано с кода. Това носи успеха на екипа на проекта. И вие може да спомогне за изграждането на сплотен колектив.
12. отговаря на въпроси. Най-добрият начин да се обедини екипа - това е, за да помагат на другите. За да се подпомогне успеха на проекта е особено важно да се отговори на въпросите, по-специално, по въпросите за начинаещ. Този път няма да се изразходва, дори и начинаещ пита въпрос, на който може да се намери отговор, след като прочетете необходимата документация. В допълнение, можете да получите нова благодарност и активен член на екипа си. Всички, за да се започне отнякъде, и всеки проект се нуждае от постоянен приток на персонала, за да продължи да се развива.
14. Обърнете внимание на сайта. Повечето програмисти, за съжаление, не са най-добрите дизайнери, така че едва ли има проект в процес на развитие, които не прибягват до допълнителна помощ дизайн. Ако си талантлив уеб дизайнер и може да помогне за подобряване на сайта и затова представянето на проекта за потребителите, това е, което трябва да бъде, и да насочи усилията си. Може би на сайта се нуждае от редизайн или обичай лого. Това е, може да бъде необходимо тези умения в екипа ви. Много ръководители на екипи по проекта липсва точно такива креативни дизайнери.
И най-важното, да слушат думите на колегите си. Може да бъде в състояние да им помогне в решаването на неотложните проблеми.
Така например, наскоро Parrot разработчиците в обсъждането на изпращане решили да използват GitHub като система работи с "билет", вместо старата система Trac. Някои от тях са срещу този ход, тъй като не е било възможно да мигрират съществуващите "билети" към новата система. След един ден на дискусия за всички "за" и "против" един от разработчиците предлагат да се напише програма конвертор, и това е привлякло вниманието. След известно време, програмата е готова, както и цялата история на повече от 450 "билет" беше запазена.
Във всеки проект, винаги има възможност да си намерят работа, както и с отворен код-проекти на много възможности. Само трябва да бъде в състояние да се намери правилното прилагане на неговите способности.
Добре известен активист отворен код почина в резултат на евтаназия
В допълнение към активната работа на белгийското програмист съм написал няколко книги, които отвориха технически и философски аспекти на свободния софтуер.
Система интегратор BelABM - преходът belobolgarskih банки на отворен код
Използването на софтуер с отворен код в банковата система - световната тенденция. Тъй като тази тенденция се отразява в Беларус, dev.by директорът на Департамента за системна интеграция BelABM Сергей Korzhenevich.
Колона главен изпълнителен директор. Тъй като ние се печелят с отворен код
CEO Percona Питър Зайцев каза dev.by за това как те са в състояние да печелят на софтуер с отворен код и корпоративни решения за MySQL и MongoDB.
Google е създала Гръмпи - Python transkompilyator в Go
проект с отворен код, която да ускори изпълнението на паралелни задачи на високо натоварване платформи
В този момент, преводът е куца малко. В оригинала, имаше един поглед, че е необходимо да се провери всички места в кода, които компилаторът се оплаква. Ако няма грешки, а след това се опитайте да промените кода, така че компилаторът не могат да издават предупреждения. Състав предупреждения често показват пропуски в кода, или дори грешки, така че за тях това не е необходимо да се отбележи с думите "това е глупаво компилатор, а аз Dartanyan!". Например, аз се изчисти всички предупреждения компилатора в своите програми, т.е. Аз съм с помощта на ССЗ знамена, които не са събрани код, ако намери поне един предупредителен: -Wall -Wextra -Werror. За съжаление, много фирми които се колят за предупреждения компилатора. Това се отнася не само за да отворите проекти източници, но също така и проекти с затворен код.
В статията има и друга грешка в превода:
> 5. Затворете старите грешки. Това често се случва, че бъговете "фиксирани едно" но "билет" не е затворен. По този начин, кодът за "запушване" на старите грешки, които пречат на работата с реалните проблеми. "Почистване" на кода от старите грешки - това е скучно и отнема много време процедура, но това е много важно за целия проект.
Очевидно е, че има думата "код" трябва да се заменят с "система за проследяване на грешки."