안녕하세요
포기하지 않는 성장하는 서버 개발자 이미리입니다! 서로 성장하는 협업 기간이 되면 좋겠습니다! 맡은 일에 책임을 갖고 성실히 임하겠습니다!
Soongsil University. CSE 21 Server Developer Contact minhee020@naver.com Phone 010-6286-6023 GitHub간단 소개
UMC 2기 안드로이드 파트로 참여하여 앱 개발을 한 경험이 있습니다.
이러한 경험은 제가 서버 파트를 맡을 때 안드 분들의 개발 환경을 더 이해하기 쉽고, 각 기능을 어느 파트에서 구현하는게 더 효율적일지 판단하는데 도움이 될 것이라고 생각합니다!
가치관
<aside> 1. 소통
1. 소통개발 외에도 여러 팀프로젝트를 하면서, 팀원간 소통 과정에서 응답이 가장 중요함을 깨달았습니다. 읽었다고 확인 메세지를 보내는 것조차 상당히 중요한 부분이라고 생각합니다. 저는 자주 메세지 확인을 하며 답장을 빨리 하려 노력합니다. 또한, 소통이 되지 않는다면 혼자 해결 할 수 없는 문제가 발생하였을 때 해결하지 못하고 끙끙 앓다 시간만 뺏길 수 있습니다. 이럴 때 도움을 요청하는 것도 좋은 방법이라고 생각합니다.
1.
책임감 & 계획성
저 혼자 하는 프로젝트가 아닌 다른 사람과 같이 하는 프로젝트인 만큼, 시작한 이상 끝까지 책임을 져야한다고 생각합니다.
이전에 수업에서 창업을 기획 & 디벨롭을 1학기 동안 진행하고 마지막 주에 발표하는 활동있었는데, 기말고사 기간과 겹쳐 많은 팀원들이 시간을 내지 못하는 상황이었습니다. 때문에 저희 조는 다른 조들보다 일주일 먼저 만나 발표 기획과 피피티를 만들어 놓았고, 남은 일주일 동안은 서로가 맡은 파트의 보완점을 찾아가면서 더욱 치밀한 기획안을 만들 수 있었습니다. 시험기간이 겹치더라도 책임감을 갖고 끝까지 완성할 수 있었습니다.
</aside>
커리어
2021.08-09 씨아이 팀프로젝트_구글 공룡게임 만들기
2022.01-03 42서울 라피신 6기 2차 참여
2022.03-07 UMC android 파트 참여
2022.03-08 42서울 본과정 참여
2022.07- 헬퍼 어플 안드로이드 파트 참여
2022.10-11 Passrithm 앱 제작 - SW/DT 새싹 공모전 우수상 수상
포트폴리오
참여 경험 및 경력
토글에 상세 설명을 해두었습니다! “”을 클릭해주세요!
”을 클릭해주세요!•
2021.08-09 씨아이 팀프로젝트_구글 공룡게임 만들기
<aside> [2021.08 - 09] 씨아이 팀프로젝트_구글 공룡게임 만들기
[2021.08 - 09] 씨아이 팀프로젝트_구글 공룡게임 만들기 직책 : 팀장 (5명이서 한팀)◦
기존 배포 되어 있는 공룡코드에서 기능을 추가하여 만듦.
◦
추가된 기능
▪
장애물의 종류 다양화 (기존 코드 : 1개 —> 3개, 랜덤하게 생성)
▪
z, x키를 통해 점프의 높이를 달리 함. z-> 낮은 점프, x->높은 점프
▪
충돌 시 재시작 기능, 종료 기능 구분 ("1"을 누르면 재시작, "2"를 누르면 시작)
▪
공룡이 점프할 때마다 색이 바뀌도록 함
◦
플레이 영상
◦
코드(github 주소)
◦
프로젝트를 진행한 이유
학교에서 배운 c를 통해 여름방학이라는 기간 동안 간단한 미니게임을 만들고자 하는 목표가 있었습니다. 그러던 도중 학부 내의 씨아이라는 소모임에서 방학동안 c언어 스터디와 프로젝트가 진행된다는 이야기를 듣고 참여하게 되었습니다. (수정필요)
◦
협업하면서 어려웠던 점 & 이를 극복한 방법
코로나19라는 상황이 겹치면서 팀원간의 대면소통이 어려웠습니다. 때문에 줌과 카카오톡을 활용하여 소통했으나, 팀장의 개인 톡과 단체 톡방을 혼용하여 카톡을 통해 코드를 전달하고, 전달사항을 카톡으로 설명하다보니 가장 최신의 코드가 무엇인지 전달사항이 무엇인지 제대로 파악하지 못하게 되었습니다.
이로 인해 팀원 한명이 맵 사이즈의 크기를 혼동하여 작은 화면 버젼으로 코드를 짜는 일이 벌어졌었습니다. 다행히 간단한 부분이라 빠르게 수정할 수 있었으나 저희 팀은 상황의 심각성을 깨달았습니다.
따라서 팀장의 개인톡으로 전달하는 방식은 버리고 단체 톡방만을 활용하여 변경사항을 전달하는 방식으로 바꾸었습니다. 이후에는 변경사항을 잘 놓치지 않았고 개인 톡은 도움요청, 단체 톡방은 변경사항 전달로 기능이 분리되어 팀원간의 소통이 원활해졌습니다.
당시에는 github의 존재와 사용법을 몰라 git이라는 더 실용적인 방안이 있었음에도 카카오톡만을 활용하여 프로젝트를 했다는 점이 아쉬웠습니다. 그와 동시에, github 없이도 우리가 이렇게 소통했다는 성쾌감에 아주 뿌듯했던 프로젝트였습니다.
◦
협업 방식
▪
비대면 (카카오톡, ZOOM 활용)
◦
프로젝트 개발에서 맡은 부분
▪
팀장의 역할
•
팀원들 시간을 조율하여 회의 시간 정하기
•
보고서 써서 제출하기
•
중간점검, 최종발표 하기
•
회의 진행하기
•
코드 합쳐서 최종 결과물 만들기
▪
팀원의 역할
•
코드짜기 (선인장 모양 만들기, 선인장 속도 조절, 공룡이 내려오는 속도 조절, 충돌 부분 수정 등등) 전반적으로 다 참여함.
—> 어려워하는 팀원이 있어 도와주다보니
( 코드의 경우 github 링크로 첨부해두었습니다.)
•
보완할 점 얘기하기
•
어려움을 겪는 팀원 도와주기 </aside>
•
2022.01-02 42서울 라피신 6기 2차 참여
<aside> [2022.01 - 02] 42서울 라피신 6기 2차 참여 ( 100% 대면 진행 )
[2022.01 - 02] 42서울 라피신 6기 2차 참여 ( 100% 대면 진행 )◦
라피신 : 한달간 상대방의 코드와 나의 코드를 평가하고 평가 받는 과정
(비전공자와 전공자가 섞여 진행된다.)
◦
월 - 목 : 개인과제 및 코드리뷰
금 : 시험
주말 : 팀프로젝트 진행
▪
코드리뷰를 통해 얻은 것
개발자에게 “커뮤니케이션 능력”이라는 것이 매우 중요하다는 것은 익히 들어 알고 있었습니다. 저는 ‘나 정도면 커뮤니케이션이 잘 되는 편이지’하고 자만했습니다.
하지만 코드리뷰를 통해 제 소통능력이 얼마나 바닥인지 알게 되었습니다. 처음 코드리뷰를 할 때, 복잡하게 되어있는 코드를 보며 상대방에게 이해 시켜야할 때 어디부터 시작해야되는지 어디까지 설명해야 되는지 감이 오질 않았습니다. 코드리뷰를 하던 도중 제 스스로 설명이 꼬여 사과를 하고 처음부터 다시 설명하는 일도 종종 있었습니다.
한달 동안 코드리뷰를 받고, 하는 것을 반복하다보니 어느새 복잡한 코드는 지양하며 코드를 알아보기 쉽게 주석을 달아놓고 노션으로 따로 정리를 해놓는 제 자신을 발견할 수 있었습니다.
다른 사람이 이해하기 쉽도록 코드를 설명하기 위해 준비하는 과정에서 저스스로 이 코드를 왜 이런 로직을 짰는지 고민하며 사족을 날리고 더 깔끔한 코드를 완성할 수 있었습니다. 42서울 한달간 개발자의 “커뮤니케이션”에 대해 배울 수 있었습니다.
◦
팀프로젝트 _ 스카이 스크래퍼
▪
설명
네 방향에서 바라볼 때의 보이는 건물의 개수가 주어질 때 가능한 건물들의 형태를 구하는 문제
이러한 모양의 문제가 주어진 경우 argv를 통해 왼쪽 상단부터 시계방향 순으로 16개의 숫자를 입력 받는다.
—> 입력 : 1 2 2 3 3 2 3 1 2 2 3 1 1 3 2 2 (위쪽, 오른쪽, 아래쪽, 왼쪽)
입력을 토대로 4*4 배열의 내부를 채운 모습이다.
◦
협업하면서 어려웠던 점 & 이를 극복한 방법
42서울 라피신을 하면서 가장 난감했던 것은 부족한 시간에 대한 압박감이었습니다. 어려운 과제가 주어지더라도 주말 안에 해결해서 제출해야 했기 때문에 항상 무언가에 쫓기 듯 코드를 짰습니다. 또한 팀프로젝트를 하는 동시에 개인 과제의 진도도 동시에 빼야했기 때문에 진도가 느린 사람들은 두배로 힘들었습니다.
저희 팀 또한 이러한 시간 문제에 허덕였으며 제출 마감 1시간 30분 전까지도 코드를 완성하지 못했습니다. 결국 저희는 코드를 완성하지 못한 채 제출하게 되었고 이틀간 열심히 짠 코드는 무용지물이 되었습니다. 하지만 저희 팀원들은 절망보다는 개운하다는 마음이 들었습니다.
협업을 하면서 얻은 것이 너무나 많았기 때문입니다. 디버깅이라는 것을 몰랐던 저는 디버깅이라는 것을 얻었고, git을 통해 협업하는 경험을 얻었고, 결과보다 과정의 소중함을 알게 되었습니다.
이번 한달 라피신 기간을 보내면서 여러번의 실패를 했습니다. 여러번의 포기도 해보았습니다. 그 사이에 좌절도 행복도 느꼈습니다. 하지만 잃은 것은 없다고 생각합니다. 누군가 다시 팀프로젝트를 할 것이냐고 물을 때 당연하게 yes라고 외칠 것이라 단언합니다.
(+ 여담 :
같은 말을 하는데도 서로 표현하는 방식이 달라 충돌이 생긴 적 있었다. 서로 이해가 잘 되지 않을 땐 간단히 의사코드나 그림을 통해 설명하는 방식이 빠르다는 것을 깨달았다.)
◦
협업 방식
▪
github 활용
▪
slack을 통한 소통
▪
대면 소통
◦
프로젝트 개발에서 맡은 부분
▪
스카이 스크래퍼의 규칙을 찾아 구현하기
(규칙 1. 같은 줄의 양끝이 2 && 3 —> 2와 가까운 2번째 칸에는 4가 온다.
규칙 2. 숫자 4의 앞 —> 1234
규칙 3. 숫자 1의 앞 —> 1
규칙 4. 같은 줄의 양 끝이 1 && 2 —> 2 앞은 3이고 1 앞은 4이다. )
void fill_col(char *col, char tab[4][4])
{
int idx;
idx = 0;
while (idx<4)
{
if(col[idx] == '1' && col[idx+4] == '2')
tab[3][idx] = '3';
else if (col[idx] == '2' && col[idx + 4] == '3')
tab[1][idx] = '4';
if (col[idx] == '4')
{
tab[0][idx] = '1';
tab[1][idx] = '2';
tab[2][idx] = '3';
tab[3][idx] = '4';
}
else if (col[idx] == '1')
tab[0][idx] = '4';
idx++;
}
while (idx < 8)
{
if (col[idx] == '1' && col[idx - 4] == '2')
tab[1][idx - 4] = '3';
else if (col[idx] == '2' && col[idx - 4] == '3')
tab[2][idx - 4] = '4';
if (col[idx] == '4')
{
tab[3][idx - 4] = '1';
tab[2][idx - 4] = '2';
tab[1][idx - 4] = '3';
tab[0][idx - 4] = '4';
}
else if (col[idx] == '1')
tab[3][idx - 4] = '4';
idx++;
}
}
void fill_row(char *row, char tab[4][4])
{
int idx;
idx = 0;
while (idx < 4)
{
if (row[idx] == '1' && row[idx + 4] == '2')
tab[idx][3] = '3';
else if (row[idx] == '2' && row[idx + 4] == '3')
tab[idx][1] = '4';
if (row[idx] == '4')
{
tab[idx][0] = '1';
tab[idx][1] = '2';
tab[idx][2] = '3';
tab[idx][3] = '4';
}
else if (row[idx] == '1')
tab[idx][0] = '4';
idx++;
}
while (idx < 8)
{
if (row[idx] == '1' && row[idx - 4] == '2')
tab[idx - 4][0] = '3';
else if (row[idx] == '2' && row[idx - 4] == '3')
tab[idx - 4][2] = '4';
if (row[idx] == '4')
{
tab[idx - 4][3] = '1';
tab[idx - 4][2] = '2';
tab[idx - 4][1] = '3';
tab[idx - 4][0] = '4';
}
else if (row[idx] == '1')
tab[idx - 4][3] = '4';
idx++;
}
}
Plain Text
복사
</aside>
•
2022.03-07 UMC android 파트 (FLO 클론 코딩)
•
2022.07-12 헬퍼 어플 안드로이드 파트 참여
참여한 부분
→ 타이머 페이지
→ 차트 페이지
→ 커뮤니티 페이지
→ 사이드 바 구현
•
2022.10-11 Passrithm 앱 제작 - SW/DT 새싹 공모전 우수상 수상
파이어베이스, java (android) 사용
안드로이드 + 파이어베이스 참여
서버 실습
instagram ERD 간단 설계
N:M, 1:N의 관계를 신경써서 설계하였습니다. 때문에 모든 인스타그램의 기능을 구현하지는 못하였고, 필수적인 부분들을 추려서 그들의 관계를 설계해보았습니다.
1.
요구사항 분석하기
<aside> 요구사항 분석
요구사항 분석•
회원가입은 전화번호 or 이메일로 본인인증을 거친다.
•
본인인증 후 이름, 비밀번호를 입력한다. (비밀번호는 6자 이상, 숫자/영문/특수기호 포함)
•
생일을 추가하면 회원가입 완료 (만 14세 이상을 확인, 광고 개인화 등의 목적을 가짐)
•
(프로필사진, 이름, 닉네임, 웹사이트, 소개) 는 '오픈 프로필' 에 해당, (이메일, 전화번호, 성별, 생일) 은 '개인정보' 에 해당. 이 중 사용자 이름, 전화번호만 필수항목
•
회원끼리는 팔로워 - 팔로잉 관계가 존재한다.
•
마이페이지는 (닉네임, 프로필사진, 게시물 수, 팔로워 수, 팔로잉 수, 이름, 소개, 각 게시물의 첫 번째 이미지) 가 포함된다. ('스토리' 기능은 일단 배제)
•
프로필 편집에서는 (프로필사진, 이름, 닉네임, 웹사이트, 소개) 를 수정할 수 있다.
•
개인정보 설정에서는 (이메일, 전화번호, 성별, 생일) 을 수정할 수 있다.
•
게시물 작성에는 (본문, 회원태그, 위치, 이미지들) 이 포함된다. ('다른 미디어에도 게시', '고급 설정' 기능은 배제)
•
게시물 작성 - 사람 태그하기에서는 닉네임으로 검색하여 일치하는 회원을 보여주고, 선택할 수 있다. 태그는 여러 회원을 지정할 수 있다.
•
게시물 작성 - 위치 태그에서는 검색어와 일치하는 장소를 보여주고, 선택할 수 있다. (일단은 정확한 위치가 아니더라도 텍스트로 입력할 수 있게만 구현)
•
노출되는 게시물에는 (프로필사진, 닉네임, 게시물 첫 번째 이미지, 좋아요 수, 본문, 사람태그, 위치, 해시태그들) 이 포함된다.
•
게시물 본문을 클릭 시 본문과 댓글이 보인다.
•
댓글에는 (프로필사진, 닉네임, 댓글내용, 태그된 유저, 댓글 좋아요, 대댓글 여부) 가 포함된다.
•
좋아요에는 좋아요를 누른 회원들의 (프로필사진, 닉네임, 이름, 팔로우/팔로잉 여부) 가 포함된다. (팔로잉 중이라면 '팔로잉', 아니라면 '팔로우' 버튼으로 보임)
•
활동에서는 '좋아요' 활동만 구현. 좋아요의 생성일자를 기준으로 오늘, 이번 주, 이번 달에 해당하는 활동을 보여준다. ('회원님이 알 수도 있는', '~님이 사진 ~장을 공유했습니다' 등의 소식형 활동 일단 배제)
•
활동 노출 문구에는 (닉네임, 좋아요 수, 해당하는 게시물 첫 번째 사진, 업로드로부터 지난 시간) 이 포함된다. (지난 시간의 경우 분, 시간, 일, 주 단위로 표현)
→ 총 정리
•
마이페이지 - 홈, 프로필 편집, 개인정보 수정
•
메인 페이지 - 게시물 노출
•
게시물 작성
•
활동 </aside>
2.
Entity, Attribute 뽑아내기
Entity : 엔터티는 쉽게 말해 실체, 객체라고 생각할 수 있다.
Attribute : 데이터 모델의 관점에서 속성은, 인스턴스로 관리하고자 하는 의미상 더 이상 분리되지 않는 최소의 데이터 단위로 정의할 수 있다.
https://siyoon210.tistory.com/26 → N : M 설계 참고한 곳
구현한 API 문서
실습 영상 1. 정적 페이지를 통해 API 테스트를 하는 모습
실습 영상 2. 카카오 로그인을 통해 토큰을 발급
화면에는 보이지 않으나 intelliJ 콘솔에서 로그인을 할 때마다 새로운 토큰값이 출력되는 것을 확인할 수 있다!
특이사항
실습 도중 과금에 대처한 이력이 있습니다. 대략 25000원 정도 부과되었는데, 이때 어디서 나왔는지 원인을 파악하고 영어로 메일을 쓰면서 다시는 과금하지 않으라 다짐했습니다.
과금이후 그 계정은 버리고 새로운 AWS 계정을 만들어 관리를 하였는데 새로운 계정은 한번의 부과 없이 잘 사용하고 있습니다.
•
과금이 어느 부분에서 되는지 잘 알고 있습니다..!
•
그때 작성한 블로그 글입니다.