rookie days.

production / development 로 배포 환경을 분리하면 브랜치를 merge 할 때 development의 배포 환경이 production으로 merge 되어 버리는 문제가 발생한다. 이때 .gitattributes라는 것을 이용해 특정 파일이 merge 되는 것을 막을 수 있다.

chat gpt에 따르면, .gitattributes 파일은 git의 동작을 지정하는 데 사용되는 파일이라고 한다. 이 파일을 사용하여 파일의 텍스트 인코딩, 줄 종료 스타일, 이진 파일 처리 등을 저장할 수 있다고 한다.

파일 패턴 다음에 병합 전략을 설정하여 해당 파일을 병합에서 제외한다. 가장 일반적인 전략은 “merge=ours”이다. 이 전략은 현재 브랜치의 변경 사항을 유지하고, 병합 대상 브랜치의 변경 사항을 무시한다.

.gitattributes

*.md merge=ours

요즘 사무실 리눅스 서버에 명령어를 입력 할 때 다음과 같은 명령어가 나왔다.

You have new mail in /var/spool/mail/~~~

여기로도 메일이 오는 건가 싶어서 찾아보니

mail 이라는 명령어를 입력하면 받은 메일을 확인할 수 있다고 했다.

들어가보니 무려 2만개가 넘는 메일이 쌓이고 있었다 ㅎㅎ( 2018년부터 )

"/var/spool/mail/~~~": 22933 messages 22933 new

d[메일번호] 로 메일을 지울 수 있다고 해서 메일을 지워줬다.

메일을 나가고 싶을 땐 q를 입력하면 된다 ㅎㅎ

node_modules/.cache/hard-source 폴더 삭제

아니면 그냥 node_modules 폴더 삭제하고 yarn install 다시 해주기

yum update를 하는데 아래와 같은 에러 발생 

The GPG keys listed for the "MySQL 5.7 Community Server" repository are already installed but they are not correct for this package.
Check that the correct key URLs are configured for this repository.

검색해보니 GPG key가 만료되어 해당 에러가 발생한다고 하더군요.

해결 방법은 아래의 명령어로 키 업데이트를 진행하면 된다고 합니다.

rpm --import https://repo.mysql.com/RPM-GPG-KEY-mysql-2022

참고

리눅스 서버에 레디스 설치 👉 yum install epel-release 명령어 입력 👉 아래 사진과 같은 에러 발생

검색해보니 참고한 블로그에서 CentOS 6 의 yum 지원이 종료 되었다고 하더군요.

해결 방법으로는 아래의 명령어를 사용하면 된다고 합니다.

# 32비트인 경우
echo "https://vault.centos.org/6.10/os/i386/" > /var/cache/yum/i386/6/base/mirrorlist.txt
echo "http://vault.centos.org/6.10/extras/i386/" > /var/cache/yum/i386/6/extras/mirrorlist.txt
echo "http://vault.centos.org/6.10/updates/i386/" > /var/cache/yum/i386/6/updates/mirrorlist.txt
yum update

# 64비트인 경우
echo "https://vault.centos.org/6.10/os/x86_64/" > /var/cache/yum/x86_64/6/base/mirrorlist.txt
echo "http://vault.centos.org/6.10/extras/x86_64/" > /var/cache/yum/x86_64/6/extras/mirrorlist.txt
echo "http://vault.centos.org/6.10/updates/x86_64/" > /var/cache/yum/x86_64/6/updates/mirrorlist.txt
yum update

++ 왜인지 모르겠으나,

echo 명령어 실행시, 그런 디렉토리가 없습니다 라는 에러가 나서

echo 명령어 한 번 yum update 한 번 이렇게 반복(?)하면서 명령어를 실행했습니다.

참고

노션에 미리 적어두고 블로그에 올리기까지 고민이 많았는데 올리기로 결정했다.
처음 적는 회고이다 보니 많지는 않지만! 간략하게라도 적어 보면 좋을 것 같아서 적어보았다.

오늘이 지나면 22년이 하루 남게 된다. 뭔가 다사다난 했던 한해를 보낸 것 같다.

2022년을 마무리는 회고를 해보면 좋을 것 같아서 회고를 적게 되었다.

살면서 쓰는 첫 회고록이다 보니 어떤 걸 담으면 좋을까? 라는 고민을 많이 했다.

우연히 다른 블로그에서 역할에 따른 구분으로 회고를 한 것을 보았는데

나의 올 한해도 역할에 따라 회고를 해보면 좋을 것 같아서 세가지의 ‘나’로 나누어 보았다.

1. 개발자

2. k-장녀

3. 인간

개발자

2년차 개발자가 되었다. 1년차일 때보다 더 많은 것을 맡았고, 해냈고, 달렸다.

사수의 퇴사로 사수 분께서 하시던 일의 많은 많은 부분이 내 것이 되었다.

회사가 소규모이다 보니, 역할의 구분이 명확하지 않아서 BE, FE, 인프라 구분 없이 열심히 달렸다.

2년동안 구분없이 맡은일을 하면서, BE 에 조금 더 관심이 갔다. FE 도 FE 만의 매력이 있지만, API 설계, 작성, 수정 작업들을 할 때 조금 더 흥미를 느꼈던 것 같다. 이 친구가 조금 더 궁금하다고 할까…? (사실 1년차 일 때는 FE 작업이 더 좋았다)

열정과 실력이 넘치는 많은 개발자 분들과 달리, 나는 내가 개발과는 인연이 없고 억지로 이 일을 하고 있다고 생각했었다. 이런 나에게 ‘궁금함’이라는 감정이 생겼다. 나.. 너 좋아하게 된 걸까?

그래서 올해는 나에게는 조금 특별한 해인 것 같다.

일에 생겨버린 이 감정에 오랫동안 식지않는 나의 성향이 올해의 나를 움직이게 했기 때문이다.

그 움직임으로 올해 한 것들을 간략하게 적어보았다. (다 적을 수는 없어서 적을 수 있는 것 위주로 적어보았다.)

1분기에 서비스 C의 리뉴얼 버전을 런칭하고 추가기능 개발 및 수정사항 대응을 하였다.

2분기에는 회사 홈페이지 개발을 맡아 진행하였고, 스크래핑이 필요한 부분 개발, 결제 시스템 기획을 맡아 진행하였다.

3분기에는 인프라 구축, 결제 시스템 개발을 진행하였다.

4분기에는 서비스 D의 리뉴얼 버전 BE 를 담당하여 작업을 진행하였다.

특별히 올해 8월에는 정말 좋은 기회로 좋은 곳에 다녀왔다. 바로 INFCON 2022에 다녀왔는데, 정말 좋은 경험이었다.

사이드 프로젝트

올해 6월부터 근무시간 외에 틈틈이 작업한 사이드프로젝트를 12월에 런칭했다.

기획부터 개발까지 모두가 열심히 참여해 작업한 결과물이 배포되는 날 모두가 기뻐했던 기억이 생생하다.

끝이 아닌 새로운 시작으로 계속 수정하고 개선할 예정이다.

k-장녀

본가에 자주 방문하기 힘든 환경이라는 핑계로 많이 찾아뵙지 못했던 지난 날의 나를 반성하며, 올해는 한달에 한번은 꼭 찾아 봬야지 다짐 했었다. 한달에 한번 본가에 방문해 가족들과 시간을 보내고 이야기도 많이 하면서 가족과의 유대관계도 깊어질 수 있어서 좋았다.

‘가족’이라는 공동체가 나는 꽤 중요하다 생각해서 내년에도 한달에 한번 이상은 꼭 볼 수 있도록 해야겠다는 생각을 했다.

인간

올해는 사내 독서토론 덕분에 23권의 책을 읽었다. 책을 읽으면서 생각하고 말하고 글로 표현하는 방법을 배웠다. 아직 뛰어나다 라고 할 수 없는 1학년의 느낌이지만, 무언가를 시작하고 그 과정 중에 있게 된 것만으로도 좋은 것 같다. 내년에는 성장을 위해 독서에 있어서도 다양한 변화를 줘야겠다는 생각이 들었다.

결론

2022년은 ‘성장’에 집중하고 싶었는데 나는 과연 ‘성장’했을까? 생각해보면 ‘아주 조금은’ 성장한 것 같다는 생각이 든다. 인간관계, 일, 가정에서 모두.

이렇게나 당당하게 아주 조금 성장했다 할 수 있는 이유는 아마도 지금 마음 상태가 굉장히 안온하기 때문 아닐까?

다가오는 2023년은 ‘밀도’를 키워드로 살아보고 싶다는 생각이 든다.

처음 써보는 회고록이다 보니 어색한데, 그래도 이렇게 한 해를 정리하면서 기록을 남겨 보니까 참 좋은 것 같다. 내년도 건강하게 잘 살아내야지🙂

[230102]

노드 버전이나 다른 버전들 볼 때 LTS라는 말을 들어보긴 했는데, Long Term Support의 줄임말이었다.

[230118]

mybatis의 parameterType에는 String 을 쓸 수 없다. => parameterType 안에 들어있는 클래스의 getter 메서드로 받아오는 방식인데 String은 getter 방식이 아니므로 에러발생

if 사용 할 때는 #{_parameter}라는 지정된 이름을 사용하면 알아서 변환이 된다고 한다.

우연히 히츠개발자 브이로그를 보다가 storybook이라는 걸 알게 되었다.

프론트엔드 개발에 storybook이라는 컴포넌트 명세 툴을 사용하고 있었다.

검색해보니, 컴포넌트 별로 기록을 남길 수 있어서 내가 아닌 다른 개발자가 합류할 때 공유가 쉬울 것 같다는 장점이 있을 것 같았다.

사이드 프로젝트 코드 리팩토링 한번 끝나면 적용해 보아야겠다.