home
HOME
home
오픈소스 컨트리뷰션 아카데미
참여 프로젝트
History
About </Code>
갤러리
동영상
참여 후기
home

2021 OSSCA

Gallery
rhashtable_init이라는 함수가 hashtable을 만드는데, hashtable 만드는게 실패할 수 있음에도 에러처리가 되어있지 않은 bug를 발견했습니다. 그래서 patch를 보냈는데 patch에 memory leak bug가 있어 다시 v2를 보냈습니다.
그런데 rhashtable_init이라는 함수가 ipv6, mac80211, mlx5에 모두 쓰이다보니 patch를 3개로 split하라는 comment가 왔습니다.... (patch를 split하려면 각각 commit 메시지를 적어주고 coverletter까지 쓰고, 메일이 patch 갯수만큼 보내짐 + 하나를 다시 빠꾸먹으면 모든 패치를 다시 다 보내야함)겨우겨우 patch를 split해서 보냈는데, 또 코드 cleanup comment가 있어서 다시 v3 패치 3개(+coverletter)를 보냈습니다.
그런데 이전에 보낸 v2는 mac80211 브랜치에 머지되고, v4는 net-next 브랜치에 머지되어(각각 메인테이너가 다른 사람이라)나중에 linux kernel net-next에 mac08211이 머지되면 충돌이 일어나게 되어 이거 어떻게 하냐고 메일을 보냈는데 메인테이너 둘 다에게 무시당했습니다. 아직까지도 답장을 받지 못한 슬픈 상태입니다.
[슬픈 코드] 사연1
Chromium / Blink 자체는 상당히 어려운 프로젝트였기에, 오픈소스 입문자인 저는 그 속에서 해볼 수 있는 적당한 난이도의 이슈를 찾는 일은 정말 쉽지 않았습니다. 열심히 골라봤던 첫 이슈는 공부하려고 보니 윈도우 환경에서는 테스트할 수 없는 상황이었고, 일주일이 넘도록 이슈를 결정하지 못하던 시기에 멘토님이 구세주처럼 나타나 이슈들을 공유해주셨습니다.
뭐라도 일단 시작해보고 싶어 간질간질했던 터라 냉큼 하나를 골라 댓글을 남겨놓고, 본격적인 첫 기여 활동을 시작했습니다.아무래도 처음이니 참고 커밋이 있어도 이해하고 적용하기 위해서는 부가적인 공부가 필요했습니다. 키워드 하나하나 생소해서 열심히 찾아보고 정리해가면서 제가 맡은 코드를 이해하기 위해 시간을 쏟다보니 시작하고 4일 뒤에야 코드 수정을 완료했고, 멘토님께 리뷰를 부탁드렸습니다.
첫 번째 피드백을 받고 수정한 뒤에 '리뷰어 추가해서 다음 단계로 가보자!' 라는 답변을 기다리던 어느날, 멘토님의 다급한 목소리가 들리는 듯한 댓글 알림이 울렸습니다. 딱 그날 이슈 작성자 본인이 코드를 수정하고 Merge까지 진행시켜버린거죠...ㅠ 이런 경우는 정말 흔치 않다고 하던데 아마도 급하게 진행해야하는 이슈가 아니었을까 싶었습니다(지금 생각해보니 이슈 진행하겠다는 댓글에 답변이 빨랐던 것도.....?!).
멘토님은 본인이 좀 더 빨리 리뷰했으면 Merge까지 갈 수 있었을 텐데라고 하시면서 매우 미안해하셨습니다. 하지만 제가 속도가 느린게 더 치명적이었을 겁니다. 결국 희망차게 시작했던 처의 첫 패치는 merge conflict과 함께 실패로 돌아갔습니다.
보통 새로운 이슈를 처리하기 위해서는 새로운 브랜치를 만들어 수정을 하는게 일반적 입니다. 저는 평소처럼 새로운 브랜치를 만들고 작업을 열심히 하였습니다. 한 이슈를 제가 뜻하던 대로 잘 작업하였다는 생각에 PR을 open 하였습니다. 하지만 문제는 이 부분에서 발생하였습니다. 바로 제가 로컬에서 브랜치를 만들었을때 base 브랜치가 main이 아닌 제가 다른 작업을 하고 있었던 branch가 base로 되어 다른 브랜치에서의 작업과 commit 기록이 합쳐져 PR이 open 되는 상황이었습니다. 따라서 제가 원치 않았던 여러 커밋들이 한 PR에 모두 잡혀 PR상의 커밋 로그가 매우 복잡해 졌습니다. 여러 방법을 시도하다가 제 main이 upstream의 메인보다 commit이 앞선 불상사까지 생겼었습니다.커밋이 꾜일때로 꼬여버려 맨토님께서 upstream main의 상태를 제 forked된 main으로 force push 하는 방식으로 우선 제 main 브랜치의 문제점을 해결하였으며 바로 다음에는 제가 PR을 하려고 하였던 branch의 commit을 rebase를 통하여 해결을 하였습니다. 또한 이번 일을 계기로 git GUI에 대해 부정적으로 생각하고 있었지만 GUI또한 git을 공부하는데에 있어서 매우 큰 도움이 된다는 것을 알게 되었습니다. 이제는 branch를 생성하기전 더욱이 신경써서 현제 제가 위치하고 있는 브랜치를 확인 후 생성하는 좋은 습관이 생겼습니다. 또한 이러한 실수를 계기로 git revert 와 git reset등 여러 git활용법을 더 사용하게 된 것 같아 뿌듯한 경험이었습니다.
[웃픈 코드] 사연 1
오픈스택팀은 컨트리뷰션 아카데미 활동 기간동안 활동했던 내용들을 문서화하기 위한 팀 블로그를 구축하여 활동했던 기록들을 정리하였었습니다. 하지만, 컨트리뷰션 활동 기간이 종료된 후에도 이대로 마무리 하기에는 아쉬움이 남아 저희가 활동하면서 우여곡절을 겪은 이야기들을 팀 블로그에 담아 다른 사람들에게 도움이 되었으면 하는 바람으로, 활동 기간이 종료된 이후에도 멘티들과 함께 오픈스택에 처음 기여하고자 하는 사용자들과 다음번 컨트리뷰션 아카데미 오픈스택팀에 참여하는 미래의 멘티분들을 위해서 오픈스택에 대해 잘 알지 못해도 쉽게 이해할 수 있는 친절한 가이드라인을 만들기로 하였습니다. 때문에 팀 블로그 대공사 작업을 진행하게 되었고, 영광스럽게도 팀 블로그 대공사 작업을 맡게 되었습니다.이후 대공사를 마치고 배포를 한 뒤, 기쁜 마음으로 오픈스택 메인 채널에 팀 블로그 링크를 공유하여 메신저를 확인해보니 뭔가 잘못되었습니다."로....컬....호.....스.....트.....??""뚫어보자, NG ~~~!""반려!!!!""자신과의 싸움""뚜시뚜시"....로컬호스트에 대한 말들이 대화방을 가득채우고 있어, 공유했던 링크를 다시 확인해보니 도메인이 'localhost'로 되어 있었습니다. 로컬 환경에서 작업했었던 경로를 그대로 전달했던 모양입니다.
[웃픈 코드] 사연 2
때는 8월 26일, Challenges 프로그램이 끝나갈 무렵이었습니다. 데브옵스 관련 PR을 끝내고 다음 이슈를 찾던 중, 멘토님께서 저에게 SQL의 CASE 구문을 구현하는 이슈를 주셨습니다. 당시 원래 진행하던 분이 계셨는데 잠시 중단한 상태였습니다. 나름 여러가지 PR을 1달동안 진행해본 터라 자신감 넘치는 타노스 짤을 쓰면서 그 이슈를 Get 해버렸습니다... 앞으로의 고단한 여정은 예상도 못한 채 말이죠. 9월 초 쯤에 간단한 문법들을 사용하여 기능 구현은 완료 했습니다. 그 때 당시에는 CASE 구문의 디테일을 잘 몰랐던 터라 간단한 테스트들은 통과했지만 결과값의 자료형 일치, 구문마다 evaluate 여부를 따지는 로직... 등등 더 신경 쓸게 많다는 것을 멘토님의 리뷰를 통해 알고 차차 코드를 고쳐나갔습니다. 또한 GlueSQL에서 아주아주 중요히 여기는 “no unwrap()”, “no clone()”, “no mutable” 의 엄격한 철칙들을 지키면서 코드를 고쳐나가다 보니 9월 말 즈음 정확히 기능은 같지만 코드는 크고 아름다운(?) 100줄 정도가 되어 있었습니다. 그 100 줄의 코드 속에는 Rust 언어의 다양한 함수형 프로그래밍 기법들, 소유권 개념을 잘 활용하여 deep copy 없이 쓰여진 구문들 등... 지금 다시보다 너무 감격스러운 코드였습니다. 그렇게 몇가지만 더 고치면 끝나가려던 찰나, Maintainer 이신 멘토님께서는 GlueSQL의 확장성을 위해 과감하게 다양한 API에서 Row 마다의 자료형 체크를 하지 않기로 결정하셨습니다. 그 말인 즉슨, 저에게는 다시 9월 초에 작성했던 코드(보다 심지어 덜 엄격하게)로 돌아가면 된다는 말이였습니다. 그렇게 기준을 맞춰서 다시 코드를 짜보니... 100줄이었던 것이 22줄이 되었습니다! 아까 제가 자랑했던 그 Rust의 다양한 아름다움을 보여주던 코드는 아쉽게도 다소 컴팩트하고 노멀하게 바뀌었죠. 이렇게 결국 Merge가 되기까지 약 1달 반이 걸렸습니다 ㅎㅎ 이슈: https://github.com/gluesql/gluesql/issues/140PR: https://github.com/gluesql/gluesql/pull/330
[웃픈 코드] 사연 4
# 멘토님 두 분과 함께 새벽까지 삽질한 사연을 소개합니다!
9월 말이었습니다. 저희 팀은 UTF-16 캐릭터셋 인코딩/디코딩 클래스 개발을 맡게 되었습니다. 라이브러리는 TDD로 개발되었기 때문에 클래스 구현에 앞서 유닛 테스트와 관련된 코드를 먼저 작성할 필요가 있었습니다. 그래서 저는 팀원 분들이 바로 클래스 개발을 시작할 수 있도록 먼저 유닛 테스트 관련 코드를 작성하고 빌드해두려고 했습니다.
그런데 열심히 테스트 코드를 만들고 UTF-16 클래스를 stub으로 둔 채 빌드를 해보니 유닛 테스트는 통과하는데 project build는 실패하는 것이었습니다. 출력된 에러 메시지를 구글링하고, 새로 추가된 코드를 다시 살펴봐도 도통 원인을 알 수 없었습니다. 이렇게 구글링하길 3시간이 지났을까요? 오후 5시가 되었고, github discussion에 시행착오 내역, 빌드 에러 메시지, 현재 환경, 코드 등을 자세히 적어 도움을 구했습니다.
업로드 후에 여러 멘티님이 관심을 보여주셨습니다. 오후 8시가 되자 멘토님 두 분이 discussion에 참전해주셨고 코드에서 특정 부분을 수정해보거나 build cache나 gradle cache를 제거해보는 등의 다양한 제안을 주셨습니다. 하지만 문제는 해결되지 않았습니다. 오후 10시에는 멘토님 환경에서도 문제를 재현하기 위해 코드가 이리저리 날아다녔고, 문제가 재현되지 않자 각자 브랜치를 만들어서 서로의 환경에서 테스트를 해보기도 하였습니다. 이렇게 계속 테스트를 하던 중, 밤 12시 30분에 드디어 한 멘토님이 문제 재현에 성공하셨고 해결의 실마리를 찾을 수 있었습니다.
문제 재현에 성공한 멘토님의 기기와 실패한 멘토님의 기기의 Android API 수준이 달랐던 겁니다. 그래서 API 버전을 의심하기 시작했고 이를 바꿔가며 테스트하기 시작했습니다. 그렇게 1시까지 열심히 테스트하였습니다. 하지만 테스트 결과 같은 API 버전인데 성공할 때도 있고 실패할 때도 있었습니다. 그렇게 또다시 테스트를 반복하였고... 결국, 새벽 2시에 정확한 조건을 알아냈습니다. 바로 API 28에서 gtest의 test case 수가 227개 이상일 때 기기에서 segmentation fault가 발생해서 build에 실패하던 것이었습니다. 아뿌
[삽질 코드] 사연1
그 해 여름이었다. 시원한 아메리카노와 함께 카페 의자에 앉아 깃헙 이슈를 확인했다.
‘버그 이슈라… 금방 해결하겠는걸?’
verify를 눌렀을 때 file count가 0이 된다는 버그 내용이었다. 명시된 테스트 환경을 구현하기 위해 코드를 확인해보았다. 우선 verificationServiceImpl로 들어갔는데 2000줄이 넘는 코드양에 벌써부터 불안감이 엄습해왔다. 아득해지는 정신을 간신히 붙잡고 로컬에서 돌려보았다. 분명 가이드에 명시된 대로 했는데 이슈 명세에 나온 부분에 채닿기 전에 벌써 에러가 났다.
‘로컬이라서 파일 업로드가 잘 안되나?’
그래서 우리 4조의 멘토, 대한민국 소프트웨어 산업의 미래 @박남규 namkyu1999 님이 세팅해주신 Lightsail 인스턴스에서 실행해보았는데 여기서는 또 Gradle 에러로 인해 빌드 과정에서 에러가 나 실행되지가 않았다. AWS 설정도 다시해보고, VSCode 자바 패키지를 다시 설치해보았지만 결과는 똑같았다.
‘후후훗 이 녀석 재밌군’
남규님에게 DM을 날렸다. 그 사이 SSH로 연결해서 gradlew 파일을 실행해서 테스트해보려고 온갖 별짓을 다했는데 자꾸 꼬여 답변이 올 때까지 기다렸다. 돌아온 답변은 친절했지만 자바는 친절하지 않았다. 결국 키보드를 집어던졌다.가을이 왔다. 같이 Task를 진행하던 @조효주 JoHyoju04 님과 카페에서 만나 이슈를 진행하기로 한 날이었다. 효주님 또한 비슷한 이슈를 처리하고 계셨기에 나는 그 간의 분노를 쏟아냈다. 그런데 효주님은 당황하지 않고 코드를 보시더니 로컬에서 테스트 환경을 구현했던 본인의 트러블 슈팅 경험을 차근차근 설명해주셨다. root.dir을 바꾸고, bin/bash 명령어를 일부 수정하면 된다고 말이다.
‘뭐…..뭐라고??????’
멍청하게도 나는 루트 디렉토리 설정값을 놓치고 있었다. 덕분에 나는 단번에 문제를 파악할 수 있었고, 쉘 스크립트의 로그를 확인해보면서 tree package에 문제가 있음을 알 수 있었다. 오랫동안 막혔던 이슈 진행이 함께 하니 단번에 뚫려버렸다. 이 날 이후로 나는 비대면 업무가 증가하는 환경 속에서 페어프로그래밍의 중요성을 다시 한 번 깨달았다. 지속적으로 팀원들과 커뮤니케이션하고, 이슈 진행 상황을 공유하는 것은 개발자에게 정말로 중요한 일이다. 일정이 얼마 남지 않았지만 앞으로 이를 실천하며 컨트리뷰션에 임해야겠다고 생각했다.
[삽질 코드] 사연2
dooboo-ui는 Context API를 통해 테마를 받아 사용하도록 되어있습니다. 그리고 이것은 ThemeProvider로 감싸져 있는 컴포넌트에서만 사용가능한데, 혹시 실수로 그렇게 하지않아 테마값을 받아오지 못하더라도 기본테마가 적용되도록 프로젝트 전반에 걸쳐 관련 코드가 존재했습니다.그런데 어느날 다른 멘티에게 도움을 주려고 간단한 예제를 Codesandbox로 만들었는데, 실수로 ThemeProvider를 사용하지 않았습니다. 이때 기본테마가 전달되지 않는다는 것을 발견했는데, 도저히 왜 그런지 이해할 수 없었습니다.결국 dooboo-ui가 사용하고 있는 emotion 라이브러리의 코드를 뜯어보기에 이르렀고, https://github.com/emotion-js/emotion/blob/d7d768e056e6cd7a10c2de6ecb2b564e6444dac3/packages/react/src/theming.js#L6이 부분 때문에 withTheme의 결과로 테마 기본값이 빈 객체 {} 가 들어갔고, 이것은 falsy한 값이 아니었기 때문에 default prop이 적용되지 않은 것이었습니다.
일반적으로 많은 사람이 이용하는 오픈소스들은 github에서clone 해오는 과정부터 빌드하기 위해 필요한 라이브러리 및 툴들을 다운받는 방법들이 자세하게 적혀있습니다. 하지만 kicad의 경우 컴퓨터 공학 전공 사람들이 주로 이용하는 프로그램이 아니어서 그런 건지 모르겠지만 소스코드를 빌드하기 위해 필요한 라이브러리 및 툴들이 무엇인지만 알려주고, 해당 툴을 다운받는 방법 및 해당 툴을 적용하여 make하는 방법이 나와 있지 않았습니다. 그렇기 때문에 소스코드 빌드를 위해 라이브러리와 툴들을 다운받는 작업을 진행하였습니다. 해당 라이브러리를 다운받는 작업이 순조롭게 진행되는 줄 알았지만 정작 cmake를 하여 makefile을 만들 때 라이브러리를 못찾는 일들이 발생하였습니다.
이 문제를 해결하기 위해 stackoverflow와 해당 라이브러리 메뉴얼을 찾아보기도 하고 매우 많은 시간을 투자하여 하나의 라이브러리를 해결하면 다시 또 다른 라이브러리를 인식하는 작업을 해야 하는 순간이 계속되었습니다. 14개 정도 되는 kicad라이브러리를 인식하는 작업을 통해 결국 빌드에 성공하였습니다. 이 과정이 굉장히 힘들었지만 결국 성공하여 매우 뿌듯하였습니다.
[삽질 코드] 사연4
이번 대회에서 파이썬의 async 기능 구현 도전을 해보기 위해 호기롭게 async for 기능 구현을 도전을 했습니다. 기존 cpython과 생성되는 bytecode가 달라서 같은 bytecode를 생성하도록 작성을 했습니다. 그런데 기존에 작성된 로직이 cpython과 달라서 panic이 bytecode 생성 로직을 수정하는데 시간이 걸렸습니다. bytecode 생성까지는 다시 맞췄는데 다시 실행해보니 cpython 동작과 다르게 동작하고 있어 수정하니 다시 panic이 발생하면서 시간이 너무 지체되었습니다 ㅠㅠ.. rust는 compile에 거의 다 잡아준다는 말을 들었는데 이번에 rustpython을 하면서 runtime에서 panic이 굉장히 많이 뜨면서 compile도 빡센데 런타임도 힘들다고 느꼈습니다;;
[삽질 코드] 사연5
지난 1학기에 학교에서 오픈소스 개론 수업을 들었어요. 선배님들이 이뤄놓은 오픈소스 생태계에 대해 배우니 선배님들의 공유 정신이 대단하다고 느껴지면서저런 대단한 사람들만이 오픈소스를 개발하고 기여한다고 생각했어요. 수업 막바지쯤 과제로 오픈소스를 사용해서 뭐든지 만들어 보라고 하셔서 유튜브에서 영화 리뷰 영상에 달린댓글을 수집하고 Keras를 이용하여 간단한 층을 쌓아 영화의 평점을 예측해보는 프록그램을 만들었어요. 정신없이 완성을 하고 나니 오픈소스에 관심이 조금 더 생겼어요.
그러던 중 학교 커뮤니티에서 오픈소스 컨트리뷰톤 모집 공고를 발견했어요! 관심있게 읽어 보았는데 마침 제가 오픈소스 수업에서 경험했던 NLP에 기여하는 팀이 있어서이건 나를 위한 거구나! 하고 바로 지원했죠. 합격하고 나서도 난 그냥 키보드만 투닥투닥 거릴 줄 아는 학부생에 불과한데 뭔가를 할 수 있을까 매일 고민했어요. 오픈소스 레포지토리에 이슈를 넣으면서 오픈소스에 적응하고 있는데 어느날 문득 뭔가 만들어보고싶다! 라는생각이 확 들었어요! 그러면서 제가 저번학기 수업에서 힘들게 Youtube에서 댓글을 크롤링했던게 생각났고제가 귀찮게 자료 찾아가면서 했던 작업을 다른 사람들은 좀 더 편하게 해줄 수 있으면 좋겠어서유튜브 텍스트 데이터 크롤링 라이브러리를 개발하기로 마음먹었습니다!
유튜브는 영상플랫폼 아니야? 라고 생각하시는 분들이 있을수도 있는데, 요즘 가장 많이 사용하는 플랫폼이니만큼 댓글, 제목, 자막, 더보기 등 정말 많은 정보들이 있고 위대한 유튜브 알고리즘 기반으로 관련된 영상을 모아서 가져올 수 있기 때문에 NLP를 연구하시는 분들에게 정말 좋은 소스가되더라고요. 만들겠다고 마음먹자 마자 댓글과 제목 밖에 크롤링 할 수 없던 코드를 자료를 찾아서 더보기란과 자막까지 가져올 수 있도록 추가했어요. 최대한 유튜브에 해가 되지 않는 방향으로 크롤링 하기위해 유튜브 공식 API를 사용하였는데 이 API가 할당량이 다 되면 멈추는 이슈가 있어서 사용자들이 좀 더 편하게 사용하도록 여러개의 API키를 입력하고 할당량이 끝나면 자동으로 바꿔주는 기능까지 추가했습니다. 가장 간단하고 간편하게를 모토로 라이브러리를 만드는데 문득 세부적인 부분까지 조정하길 원하는 사용자도 있을거라는 생각이 들었어요. 그래서 영상을 검색할때 영상의 관련 주제를 선택할 수 있는 파라미터를 추가하려 했는데이게 유튜브 공식 문서에 해당 파라미터는 있는데 예시를 제외하고는 없더라고요? 당황해서 미국, 영국 등 여러나라 공식 사이트에 들어가봐도 다 없었어서 만고의 구글링을 시작했고결국 러시아(잘 기억이 안나는데 러시아 같았어요..) 공식 유튜브 예전 버전에서 그 파라미터를 찾을 수 있었고 이때 뭔가 짜릿했습니다 ㅎㅎㅎ 크롤링 테스트를 완료하고 데이터 프레임의 형태로 변환해주었는데 이를 저장하는 과정에서 문제가 생겼어요. 전 최대한 코드 한줄로 모든걸 완성 시켜주고 싶어서 폴더 생성해서 파일을 저장까지 해주려고 했는데, 파일의 이름을 어떻게 해야할지 모르겠었어요. 본인이 검색했던 검색어로 파일을 만들면사 용자가 어떤 검색어로 검색했는지 몰라서 폴더명 제약에 걸려 오류가 뜰 수 있거든요.. 그렇다고 저장을 안하면 제가 처음에 생각했던(최대한 사용자가 편하게) 방향과는 조금 달라서 고민을 하다 결국 현재 시간을 기반으로 파일을 저장해주기로 했어요 ㅎㅎㅎ(혹시 이에대해 좋은 아이디어각 있으시면 이슈 남겨주세요!)
그렇게 많은 고민 끝에 코드를 완성하고 Pypi에 배포하여 pip install로 간편하게 설치까지 할 수있도록 설정하여 라이브러리 개발을 완료하였습니다. ㅎㅎㅎ 배포를 하고 pip ‌install로 잘 설치되는 저의 라이브러리를 보니 너무 뿌듯했어요. 불과 몇개월 전 까지만 해도 오픈소스는 대단한 사람들만 하는거야 라고 했던 제가 오픈소스를 개발하고 배포해서 사람들의 소중한 시간을 지켜주다니!! 며칠 뒤엔 제가 저희 팀 말고는 어디에 말한적도 없는데 어떻게 알고 많은 분들이 사용해주시고 깃허브 스타를눌러주고 가시더라고요. 정말 몇개 안되지만 이런게 처음인 저는 너무 신났고 내가 정말 도움이 되었구나를 느끼며 뿌듯해했습니다.
이 컨트리뷰션 아카데미가 아니었다면 절대로 누리지 못했을 거에요. 이런 프로그램 만들어 주셔서 감사합니다 ㅎㅎㅎ 그런데 저도 좀 사용하다보니 생각지 못한 오타, 오류가 발생하더라고요 지금 당장 학교 시험기간이라 신경을 못쓰고 있는데한번 사용해주시고 부족한 부분 지적 해주시고 이슈, PR 날려주시면 정말 감사하겠습니다 !!!(스타까지 남겨주시면 더욱 좋고요 ㅎㅎㅎㅎ) https://github.com/Mo0nl19ht/youtube_crawler 라이브러리 깃허브 주소입니다. 이 기회를 계기로 앞으로 더 멋진 오픈소스 컨트리뷰터가 되고 싶어요여러분 키보드만 투닥거리는 학부생인 저도 해봤어요 여러분도 가능합니다!아무것도 아닌 프로그램이라 생각해도 누군가에겐 도움이 돼요!오픈소스 화이팅!!!
[뿌듯한 코드] 사연1
인생 첫 기여라서 많이 긴장됐었는데 너무 친절하게 답변해주셔서 너무 뿌듯한 경험이었습니다! 이분들 덕분에 이후 기여들은 편한마음으로 진행할 수 있었어요
[뿌듯한 코드] 사연2
개발을 시작하고 나서 이렇게 많은 comment들이 달린 PR은 처음 경험해봤네요...
2주라는 시간동안 무진장 열심히 달려서 얻은 성과같습니다ㅎㅎ 사실 말이 2주지 3주정도가 걸렸는데, 중간에 노트북이 맛이 가서 OS를 다시 깔았던 기억이... (절반정도는 짠한 사연입니다) 이 사건 이후로는 중간중간 커밋을 꾸준히 해주는 중이에요! 중간 많은 사건들이 있었는데, 모두 해결하고 머지된 날 스스로 뿌듯해한 것이 기억납니다. 큰 프로젝트 안에 제가 작성한 코드들과 기록이 남는다는 것은, 어떠한 면에선 제가 다른 개발자분들께 인정받은 느낌인 것 같아요. 또한 코멘트들이 많은 것은 제가 많은 실수를 했다는 뜻이 아니라, 다른 분들과의 활발한 교류를 뜻하는 것이라 생각해요. 그러니 PR을 올리실 때 코멘트를 두려워하는 분이 계시다면, 겁내지 말고 자신을 가지시길 바랍니다! 우리 모두 오픈소스의 푸르른 생태계를 위하여 화이팅해요!
[뿌듯한 코드] 사연3
한 줄 짜리 PR 3개로 버그를 20개쯤 고쳤습니다. 비록 코드는 한 줄이지만 이 버그가 어디 숨어 있고 왜 버그인지 알아내는데는 한 줄 마다 몇날 며칠이 걸렸지만요. 보낼 땐 열심히 버그를 찾아서 고쳤을 뿐이지만, 지나고 보니 한 줄짜리 패치로 버그를 이렇게 많이 고치는 사람은 저 말고는 또 없더라고요.
[뿌듯한 코드] 사연4
회원가입 창에서 약관을 누르면 나오는 약관 창에서 x 버튼을 눌러서 닫으면 다시 오픈이 되지 않는 이슈를 해결하고 있었습니다. 열리는 과정부터 닫히는 과정을 꼼꼼하게 살펴보고 css가 잘못 설정된 부분이 있는지 살펴봤지만, 문제의 원인조차 찾지 못했습니다. 하지만 계속해서 약관창을 살펴보다 보니 다른 문제들이 보였습니다. 스크롤이 불필요하게 2개가 존재했는데 그러다보니 내릴 때 불편함이 있었습니다. 그래서 해당 문제에 대해 이슈를 만들고 해결한 후 PR을 올렸고 현재는 머지된 상태입니다. 약관창이 다시 열리지 않는 문제에 대해서는 아직까지 진행을 하고 있다는 슬픈 얘기이지만, 그래도 문제가 있는 부분을 찾고 해결할 수 있는 부분에 대해서 기여를 했다는 점에 뿌듯함을 느꼈습니다.
[뿌듯한 코드] 사연5
1.흑역사 및 삽질의 기록입니다.
저희는 논의했던 내용들이 슬랙에서 사라지기 시작하면서 놀래기도 하였고 디스코드로 이력을 남기기 시작했습니다. 코드의 오타가 있어 찾는것에 시간이 많이 걸렸고, 해결 이후 다시 실수 하지 않도록 방향성에 대해 정리하였습니다.
2.리눅스에서 입력되는 hanjp를 맥에서 동작하는 입력기를 만들기 위해 맥용 개발 언어와 맥에서 개발을 하려면 어떻게 해야하나 설계도 하였고, 그러다보니 기존에 잘 만들어둔 구름 입력기를 참고해서 처음부터 개발 하고 하다보니 너무 어려운 부분이 많았습니다. 구름 입력기 팀과 이야기를 하기 시작하였고, 최종적으로는 처음부터 만드는건 많은 리소스와 비용을 요구하는 삽질이며, 구름입력기에 익스터널 모듈로 입력방식을 추가하는것이 좋겠다는 방항을 얻었습니다.
[흑역사 코드] 사연1