Project
-
Hexagonal Architecture Practice 프로젝트 회고
Hexagonal Architecture Practice Project 현재 서비스를 운영하고 있는 let's Git it 토이 프로젝트는 controller, service, repository로 이루어진 3 tier layered architecture로 개발하고 있다. 초기 개발 이후 지속적으로 서비스를 개선하고자 리펙토링이나 기능들을 추가는 과정에서 유지보수에 불편함을 겪었는데 그 원인이 무엇일까 생각해보았다. 문제가 무엇인가? 레이어 간 side effect 서비스 초기라서 service와 repository의 영역에서 리펙토링 되는 부분이 많았다. 그 과정에서 repository의 변경이 service의 변경을 낳다보니, 유지보수 비용이 많이 들었다. 뿐만 아니라, 각 레이어에서 앞단으로 던지..
-
let's Git it 프로젝트 회고
let's Git it 프로젝트 회고 let's Git it은 현재(2023년 4월 기준) 운영 중이며, 실제 사용자의 피드백(버그, 의견 등)를 받아 서비스를 개선하였습니다. 서비스 운영을 시작하며, 서비스 개발 이전에 학습한 내용과 운영 과정에서 들었던 고민들을 정리해둘 필요를 느껴 회고를 작성합니다. 자세한 내용은 게시물로 정리해두었으며 각 항목에 링크를 걸어두었습니다. 링크가 있는 항목은 밑줄이 그어져 있습니다. 클릭하시면 자세한 회고를 확인하실 수 있습니다. 아직 추가되지 않은 회고는 내용이 정리 되는 대로 수시로 업데이트 될 예정입니다. 📌 기획의도 유저의 피드백을 받고, 서비스를 개선해보는 경험을 하고 싶었기 때문에, 사용자가 가볍고 재미있게 이용해볼 수 있는 서비스를 기획하고자 했습니다. ..
-
Kgeul - 기업협업 회고
다비수디지탈이라는 회사에서 했던 4주간의 기업 협업(인턴십)에 대한 회고이다. 다비수디지탈은 2018년에 설립된 회사이고 그 이전에는 다른 회사명으로 교육 사업을 진행해왔다. 주로 유아, 초등학생 대상의 교육 콘텐츠 사업을 주력으로 삼고있는데 그동안 축적된 교육 노하우를 활용, 에듀 테크 사업으로 확장을 도모하고 있는 상태였다. 에듀테크 전환의 일환으로 ‘외국인을 위한 한국어 학습 app 제작’ 프로젝트를 진행하고 있었고 제품 출시에 앞서 좋은 아이디어를 얻기 위해 우리에게 프로젝트의 일부를 맡겼다. 1. 프로젝트 소개 외국인을 위한 한국어 회화 학습 하이브리드 앱 제작 기간 : 2022.12.12 ~ 2023. 1. 5 (4주) 인원 : FE 1명, BE 4명 Stack 공통 : Node.js, npm..
-
Stawefolio - 2차 프로젝트 전체 회고
위코드에서의 두 번째 프로젝트가 끝났다. 두 번째 프로젝트는 여행지에서 머물고 싶은 좋은 스테이 큐레이팅 서비스, stayfolio를 모티브로, 여행지에서 감성을 더해줄 음악 section(time to vives)을 추가한 감성숙소 추천 서비스 stawefolio를 만들어보았다. - 기간 : 2022년 11월 28일 ~ 12월 9일 - 팀원 : FE 3명, BE 2명 1. 프로덕트 기획 및 스케쥴링 1.1 기획 프로덕트, 고객 관점으로 서비스를 생각하기 위해 노력 팀원들과 사이트를 살펴보며 어떤 것을 제안하면 고객의 경험에 도움이 될까 생각했다. 어쩌면 여행은 여행을 계획하는 순간부터 시작되는 것은 아닐까, 여행지에서 머무를 곳을 정하는 것도 여행의 여정이라면 그 여정을 즐겁게 해주자! 라는 기획 포인..
Hot Posts
-
github 원격 브랜치를 로컬로 가져오기Git&Github 2023.01.30 16:50
원격(origin) 저장소를 clone 받은 후 git branch로 확인해보면 원격저장소의 branch는 받아지지 않고 main 브랜치만 있는 것을 확인할 수 있다. 이 때, 원격 저장소에 존재하는 branch를 확인하고 해당 브랜치를 로컬로 가져오려면 아래와 같은 git 명령어를 사용하면 된다. git branch -r // 원격 저장소 branch 리스트 확인 git branch -a // 로컬과 원격 저장소 branch 리스트 확인 git checkout -t origin/develop // 원격의 develop 브랜치 가져오기 git checkout -t origin/feature/user // 원격의 feature/user 브랜치 가져오기 git checkout -t 옵션은 체크아웃 시 로컬에..
-
[MAC] 캡스락 대문자 기능 끄기 by. Karabiner-Elements, BTT기타 2022.10.05 01:13
맥북에서 영문 타이핑 하다가 한글 타이핑하려고 캡스락을 눌렀는데, 대문자를 계속 입력하는 상태로 되면 정말 짜증이 납니다. 이 모드를 풀려면 캡스락을 2초 정도 계속 눌러주거나 ctrl + space를 눌러줘야 하거든요. 이게 귀찮고 타이핑 시간을 잡아먹습니다. (코딩할 때는 주로 영문을 사용하기 때문에 불편하지 않을 수 있겠지만) 어쨌든, 이 문제를 해결하고 싶어서 여기저기 찾아보다가 이런 글을 보았습니다. 출처 : https://cafe.naver.com/inmacbook/2328279 이 글은 우측 커맨드 키에 한영키 기능을 추가하는 방법이었는데요. 윈도우 키보드에 익숙하신 분들은 위의 셋팅들을 참고하시면 바꾸실 수 있겠지만 저는 이미 맥에 익숙해져서 이 방식이 불편했습니다. 그리고 캡스락을 길게 ..
-
MySQL 제약조건 확인, 추가, 수정, 삭제 방법MySQL 2022.11.07 16:47
CRUD API 기능 구현 중에 DB table에 column에 unique 키 제약조건을 잘못 설정했었다. 예를들어, 로그인을 위한 정보를 받아오는데 이름에 unique값이 들어간다던지..하는 말도 안되는 실수가 있었는데, 연습이니까 테이블을 지우고 갈아 엎어도 됐지만, 현업에서 그렇게 문제를 해결하는 것은 절대 불가능할 것이기 때문에 테이블 컬럼의 제약조건을 수정하는 방법을 찾아서 해결했었다. 물론 처음 테이블을 만들 때 부터 제약조건을 잘 걸어뒀으면 문제없겠지만! 나중에 프로젝트 할 때 ERD를 세세하게 잘 만들어 둬서 수정하는 일을 없게 해야겠다! // 제약조건 확인하기 select * from information_schema.table_constraints // 이건 내 db 전체 select..
-
[Nest.js] 로컬에서 https 서버 구동하고 postman으로 테스트 하기Nest.js 2023.04.04 17:27
[Nest.js] 로컬에서 https 서버 구동하고 postman으로 테스트 하기 진행하고 있는 프로젝트에서 refresh token을 secure, httpOnly 옵션으로 쿠키에 담아 전송해주기로 했다. 그런데 프로덕트 api 서버가 https 서버로 세팅되어 있기 때문에 로컬에서 쿠키가 전송되는지 테스트를 하기 위해서는 로컬 서버도 https로 구동해야 했다. 그래서 mkcert라는 라이브러리를 사용하여 postman으로 쿠키를 확인할 수 있도록 세팅했다. 1. mkcert로 인증서 만들기 1-1. 설치 npm install -g mkcert 1-2. CA 만들기 mkcert -install mkcert -CAROOT #CA 저장 위치 확인 1-3. 인증서 만들기 mkcert -cert-file [..
-
Binary / Base64 / Blob / ArrayBuffer / FileJavaScript 2022.12.22 23:20
1. Binary Binary란 이진 데이터를 의미하며 1과 0만을 사용하여 2개의 수를 나타내는 진법을 뜻하는, 컴퓨터를 다루는데 있어 가장 근본이 되는 체계라고 한다. 2. Base64 컴퓨터는 모든 데이터를 0과 1로 저장한다. 그렇다면 컴퓨터 안에 저장된 바이너리 데이터를 꺼내 쓸 수 있을까? 메모리에 저장된 바이너리 데이터를 변수에 적재해놓고, 필요하면 변수를 호출해 바이너리 데이터를 다룬다. 그렇다면 숫자, 스트링이 아닌 이미지 비디오 같은 멀티미디어 파일들은? 이때 Base64 인코딩을 활용하는데, Bas64는 0과 1로 이루어진 바이너리 데이터를 인코딩하여 텍스트 형식으로 변환하는 것을 말한다. 변수에 이미지 url(웹 url이든 로컬의 file path든)을 저장하는 건 링크라는 징검다리..
New Posts
-
OSI 7 Layer - 3계층 : IPv4Network 2023.05.22 17:24
OSI 7 Layer - 3계층 : IPv4 IPv4가 하는 일 네트워크 상에서 데이터를 교환하기 위한 프로토콜로 단순히 다른 네트워크 대역과 통신하기 위해 네트워크 대역을 찾아가는 프로토콜이다. 20 바이트 데이터가 정확하게 전달될 것을 보장하지 않는다. 중복된 패킷을 전달하거나 패킷의 순서를 잘못 전달할 가능성도 있다. (악의적으로 이용하면 Dos 공격이 됨) 데이터의 정확하고 순차적인 전달은 그보다 상위 프로토콜인 TCP에서 보장한다. IPv4 프로토콜의 구조 ✅ Version : IP프로토콜의 버전, 일반적으로 4만 온다. IPv6 프로토콜은 따로 있다. ✅ IHL : IP Header Length, 일반적으로 옵션을 제외한 20바이트, 이를 4로 나눠서 표기 표현할 수 있는 수가 4bit이기 때..
-
SQL Query - SELECTDatabase 2023.05.17 01:53
SQL Query - SELECT IT 회사 관련 RDB 만들기 부서, 사원, 프로젝트 관련 정보들을 저장할 수 있는 RDB 만들기 RDBMS는 MySQL(Inno DB)을 사용 SELECT Query Statement 예제 ID가 9인 임직원의 이름을 알고 싶다. SELECT name, position FROM employee where id = 9; SELECT를 수행하면 selection condition을 통해 선택된 튜플의 값들 중에서 projection attributes에 의해 지정된 attribute에 대응하는 값만 가져오게 된다. 따라서 최종적으로 위의 쿼리를 수행하게 되면 다음과 같은 결과를 얻을 수 있다. project 2002를 리딩(leading)하고 있는 임직원의 ID와 이름과 ..
-
OSI 7 Layer - 3계층 : ARP 프로토콜Network 2023.05.12 20:26
OSI 7 Layer - 3계층 : ARP 프로토콜 ARP 프로토콜 ARP가 하는 일 IP주소를 MAC주소로 변환해준다. ARP 프로토콜은 같은 네트워크 대역에서 통신을 하기 위해 필요한 MAC주소를 IP주소를 이용해서 알아오는 프로토콜이다. 같은 네트워크 대역에서 통신을 한다고 하더라도 데이터를 보내기 위해서는 7계층부터 캡슐화를 통해 데이터를 보내기 때문에 IP주소와 MAC주소가 모두 필요하다. 이 때 IP주소는 알고 MAC주소는 모르더라도 ARP를 통해 통신이 가능하다. ARP 프로토콜의 구조 ✅ 하드웨어 타입 : 2계층 주소의 타입 보통 이더넷 프로토콜이 오므로 0x0001이다. ✅ 프로토콜 타입 : 3계층 주소의 타입 IPv4 프로토콜이 오므로 0x0800이다. ✅ 하드웨어 주소 길이 : 2계층..
-
OSI 7 Layer - 3계층 : IP 주소Network 2023.05.12 17:53
OSI 7 Layer - 3계층 - IP 주소 3계층이 하는 일 3계층은 다른 네트워크 대역 즉, 멀리 떨어진 곳에 존재하는 네트워크까지 어떻게 데이터를 전달할 지 제어하는 일을 담당한다. LAN과 LAN을 연결, WAN 대역에서 통신할 때 필요. 발신에서 착신까지의 패킷의 경로를 제어한다. INTRO : 3계층에서 쓰는 주소 1. IPv4 : 현재 PC에 할당된 IP 주소 IPv4 프로토콜로 통신하기 위해서는 IP주소, 서브넷마스크, 게이트웨이가 필요하다. 이러한 3계층 주소는 다음과 같은 리눅스 명령어로 확인할 수 있다. # 활성화된 전체 인터페이스 정보 확인 ifconfig # 사용하지 않는 것을 포함한 전체 인터페이스 정보 확인 ifconfig -a # 특정 인터페이스 정보만 보기 ifconfig..
-
Hexagonal Architecture Practice 프로젝트 회고Project 2023.05.12 03:44
Hexagonal Architecture Practice Project 현재 서비스를 운영하고 있는 let's Git it 토이 프로젝트는 controller, service, repository로 이루어진 3 tier layered architecture로 개발하고 있다. 초기 개발 이후 지속적으로 서비스를 개선하고자 리펙토링이나 기능들을 추가는 과정에서 유지보수에 불편함을 겪었는데 그 원인이 무엇일까 생각해보았다. 문제가 무엇인가? 레이어 간 side effect 서비스 초기라서 service와 repository의 영역에서 리펙토링 되는 부분이 많았다. 그 과정에서 repository의 변경이 service의 변경을 낳다보니, 유지보수 비용이 많이 들었다. 뿐만 아니라, 각 레이어에서 앞단으로 던지..