본문 바로가기

Programming

 (18)
rust의 소유권 이해하기 러스트의 소유권 요약 1. 불변 참조는 얼마든지 가능하다. 2. 불변참조를 하는 동안에 가변참조를 해서는 안된다. 3. 가변참조는 한번에 하나만 가능 항상 입버릇처럼 했던 말이, "러스트 공부해야되는데" 였고, 기존에 설치만 하고 바로 접었었기에, 이번에는 진짜 해야지 하는 마인드로 다시 읽어보기 시작했다. 소유권은 The Rust Programming Language 한국어 번역본에 분명 자세히 설명되어있지만, 여전히 글만 보고는 막막함을 많이 느끼는 건 동일하다. 한국어로 쓰여져 있지만 이해하기 어렵긴하다. 직접 코드 짜면서 하나하나 이해 해보는게 좀 더 도움이 많이 되었긴 했다. 결국 소유권과 관련된 부분에 있어서는 나의 시야를 러스트가 보는 시야와 동일하게 맞춰야지만 이해할 수 있다. 러스트가 소..
프론트엔드의 관점에서 테스트란 들어가며 《구글 엔지니어는 이렇게 일한다》 중 테스트 관련한 장을 읽을 때, 테스트와 관련된 고민이 생겼었다. 가장 하고 싶으면서도 하지 못하는 것이 유닛 테스트를 비롯한 자동화 테스트였기 때문이었다. 그러던 중 테스트와 관련하여 다른 분과 이야기할 기회가 생겼었다. 이전에 테스트와 관련된 고민을 이야기했었던 것 때문이었다. 그분과 테스트에 관한 이야기를 하면서 테스트를 바라보는 내 시선이 바뀌었다. 아래에서는 주로 유닛 테스트와 관련된 부분이 주가 될 것이다. 프론트는 못 해 지금도 완전히 완치된 것은 아니었지만, 《클린 아키텍처》를 읽으면서부터 「프론트는 못 해」 병에 걸려 있었다. "프론트는 클린아키텍처 못 해", "프론트는 테스트 못 해" 와 같이 프론트는 못하는 것이 많다 생각했다. 《클린 아키..
1분만에 하는 터미널 실행 시 날씨 정보 보기 설정(wttr.in) 리눅스에서 백그라운드(&)를 Done 없이 깔끔하게 실행하기에서 wttr.in의 날씨정보를 터미널을 열때마다 뿌리고 있다고 했는데, 오늘은 그 방법에 대해 소개하고자 한다. 먼저, wttr.in은 wego의 래핑으로 시작한 프로젝트로 콘솔 지향 기상 예보 서비스다. 이미지 없이 Text만으로도 멋진 날씨 정보를 볼 수 있는 서비스다. 자세한 정보는 https://github.com/chubin/wttr.in를 참조하면 된다. 설정 방법 여기서는 curl을 사용하지만, 다른 http 클라이언트를 사용해도 무방하다. 1. .bashrc나 .zshrc 파일을 연다. (사용하는 쉘에 맞게) 2. 빈 줄에 다음 명령어을 추가한다. (도시를 생략하면 현 위치 기반으로 동작) `(curl -s "ko.wttr.in/..
리눅스에서 백그라운드(&)를 Done 없이 깔끔하게 실행하기 리눅스에서 '&' 명령어를 사용하여 작업을 백그라운드에서 시작하면, 아래와 같이 PID와 작업이 완료되었을 때의 + Done 메시지가 뿌려진다. 하지만 필요없는 경우도 있다. WSL2를 사용하면서, curl로 wttr.in의 날씨정보를 터미널에 뿌리고 있는데, 이를 백그라운드로 실행하자, 날씨정보 앞뒤로 저 메시지가 뜨게 됐었다. 처음에는 output을 /dev/null로 보내는 글만 있었는데, 당연하지만 날씨 정보만 보고 싶은거지, 모든 output을 버리고 싶었던건 아니었다. 서론이 길었다. 답은 명령을 괄호로 감싸는 것이다. 괄호로 감싸게 되면 subshell에서 실행되기 때문에 위 두 메시지가 보이지 않는다고 한다. 예) (curl wttr.in &) 참고자료 : https://stackoverf..
모바일 디바이스를 위한 웹 최적화가 필요한 이유 원래는 애플의 아이폰과, 최신 플래그십 안드로이드 스마트폰의 성능은 급속도록 증가하고 있다. 이에 맞춰 모바일 디바이스를 위한 웹 성능 최적화 전략이 수정될 가능성이 있다. 느린 핸드폰을 지원하기 위한 자바스크립트 성능 최적화보단, 120Hz 스크린을 위한 애니메이션 지원이 더 중요해질 수 있다. 물론 모바일 디바이스는 배터리라는 한계점을 안고 있기 때문에, 여전히 자바스크립트 성능 최적화는 중요하다. ―라고 생각했었다. 현실은 달랐다. 이 글에 따르면 모바일 성능 격차는 매우 크다. 특히 안드로이드와 iOS의 성능 격차는 크며, 플래그십 안드로이드와 중저가 안드로이드 스마트폰의 성능 격차는 충격적으로 크다. 원래 위와 같이 생각했던 이유는 구글에서는 평균적인 모바일 기기를(라이트하우스등) 2016년에 ..
뜯어 고치기 vs '2' 추가하기 이게 아닌데... 뭔가 잘못됐다. 높이가 40px인 공통 버튼 컴포넌트 를 만들었다. 하지만 알고 봤더니 높이가 40px이 아니라 28px이었다. 이미 수십 번 넘게 이곳저곳에서 쓰였던 상황이다. 당신은 어떤 선택을 해야 할까? A. 뜯어고치기 어차피 바뀌어야하는 것이다. 레이아웃이 깨지는 곳을 고치는 것은 매우 귀찮은 일이지만 어처피 해야 할 일을 하는 것일 뿐이다. 지금 고치지 않으면 점점 공수는 커져만 갈 것이다. 그래서 당신은 공통 버튼 컴포넌트를 수정하기로 결심했다. 선택의 결과 이제 당신에게 주어진 것은 버튼을 쓴 곳마다 레이아웃이 깨지는지 확인해야 하는 일이다. 아쉽게도 버튼은 주변 레이아웃에 많은 영향을 끼쳤다. 하단 푸터 버튼 영역의 height를 무심코 40px로 지정했었고, 15개의 ..
커밋을 잘게 쪼개자 - 커밋은 언제 하는 것이 가장 좋을까? "깃 커밋은 언제 하는 것이 가장 좋을까?" 들어가면서 커밋의 단위는 개발자들마다 생각이 각기 다를 것이다. 누구는 크게, 누구는 작게 말이다. 이 글에서는 커밋을 어느 단위로 할지에 대해 이야기한다. 다만 웹 프론트엔드 개발에 한정한다. 이는 웹 백엔드나 기타 다른 응용 프로그램 개발에서는 또 다른 원칙이 적용될 수도 있기 때문이다. 커밋의 기본 원칙 커밋의 기본 원칙은 '1 Action, 1 Commit'이라고 생각한다. 이는 추후에 혹시나 모를 revert 등을 통한 롤백을 쉽게 하기 위함이기도 하다. 하나의 액션, 하나의 커밋 하나의 액션은 커밋 메시지 한 줄이다. 예를 들면 "카드 컴포넌트 내부에 말 줄임표 처리", "font-size를 16px에서 14px로 조정", "Item이란 용어를 Ca..
개발자들이 꼭 알아야할 KJDD 방법론 KJDD 방법론은 KkulJaem Driven Development 의 약자다. 한국어로 꿀잼 주도 개발이다. KJDD 방법론은 재밌어야 개발이 잘 된다는 이론에 기반하고 있다. 물론 그 이론은 당연히도 내가 만든 것이다. 개발할 때 카페인만큼 중요한 건 꿀잼이라 생각한다. 물론 이 꿀잼의 강도는 매번 다르겠지만 어쨌든 꿀잼이기만 하면 된다. 토종꿀이든 서양 꿀이든 상관없이 꿀이면 된다는 것이다. '꿀잼 주도 개발'을 실천하는 간단한 예시가 있다. 예제를 재밌게 하면 된다. 예를 들어 쇼핑몰 사이트를 만든다고 생각해 본다. 보통이라면 상품 테스트 데이터로, 상품명을 '상품 1', '상품 2', '상품 3'으로, 상품 사진은 기본 이미지로 넣을 것이다. 하지만 KJDD 방법론은 다르다. 상품명은 '하품',..

티스토리툴바