기록 그리고 기록

$ sudo service docker start  
Redirecting to /bin/systemctl start docker.service  
Job for docker.service failed because the control process exited with error code. See "systemctl status docker.service" and "journalctl -xe" for details.

실행하려니 실패.

$ systemctl status docker.service  
● docker.service - Docker Application Container Engine  
   Loaded: loaded (/usr/lib/systemd/system/docker.service; disabled; vendor preset: disabled)  
   Active: failed (Result: exit-code) since 화 2022-04-05 12:17:01 KST; 12s ago  
     Docs: [https://docs.docker.com](https://docs.docker.com)  
  Process: 25074 ExecStart=/usr/bin/dockerd (code=exited, status=1/FAILURE)  
 Main PID: 25074 (code=exited, status=1/FAILURE)

상세 사유 없어서 확인이 안됨.

이럴땐 도커 데몬을 직접 실행해본다.

$ sudo dockerd --debug  
Error starting daemon: Error initializing network controller: Error creating default "bridge" network: failed to allocate gateway (10.252.0.0): Address already in use

나의 경우 bridge ip 설정 떄문에 실패한 것.

흡입력이 세고, 잘 읽힌다. 가볍게 읽히는데, 가볍기만 한 건 아니었다.

각각의 사연의 주인공들이 가진 고민, 구구절절 내 고민들을 가져다 들춰놓은 듯 하다. 지금 내 상태가 만족스럽든 아니든 새벽감성이 생기면 불현듯 시작되는 고민들... 기억에 남는 문장이 많더라. 

최근에는 자기계발서만 읽어왔는데, 역시 문학은 문학이다. 흐름에 맡겨서 읽어내려가다 보면 이런 저런 생각이 들고, 자기 고백을 하는 느낌도 나고, 내가 쓴 글은 아니지만 나를 글로 적어놓은 듯 느끼며, 위로 받고, 힘을 얻기도 한다. 

윗 교정기 붙인지 3주, 아랫 교정기는 2주가 됐다.

통증이 어느 정도 잠잠해졌다고 생각했는데 오늘 다시 아프다 ㅠㅠ 하아아....

잠잠했던 윗 잇몸이 다시 씹을때마다 욱신욱신.. 잘 움직이고 있다고 좋아해야 하는거니, 아니면 염증이라도 있는거니?

가만히 있어도 새 이가 나려는 것 처럼 간질 간질하기 까지..

이럴때면 다른 분들 교정일기를 찾아보면서 그나마 좀 위로를 받는데, 나도 좀 써봐야겠다 싶었다.

점심에 먹은 삼겹살이 엄청 맛있었는데 이노무 교정의 불편함 때문에 그 맛이 반감되더라...

씹을 때마다 교정기철사 위에 차곡차곡 적립되는 음식물들이 참 거슬리지 않을 수 없다. 

아직 한 달도 안됐는데 이걸 24번이나 반복해야 한다니 ㅎ;

소마 1g 이면 근심 걱정이 사라지고 평화가 찾아온다. 소마를 취할 것인가, 아니면 고통을 인내하겠는가.

머리가 복잡한 날은 꽤나 자주 찾아온다. 누구는 이런 걸 한다더라. 나도 뭘 해야하지 않을까? 일하기 정말 싫다. 하지만 내일도 출근 해야지. 언제까지 다람쥐 쳇바퀴 돌 듯 살아야 할까? 등의 잡념이 침대까지 쫓아온다. 잡념에 휘둘리지 않고 평화롭게 살 수 없을까? 하는 생각이 들곤 한다. 

멋진 신세계에서는 이런 고민이 없다. 각자에게 주어진 삶은 너무나도 당연하다. 무언가를 갈망하지 않는다. 물질적으로나 정신적으로나 안정이 보장된 삶을 산다. 내가 바라는 게 그런 안정된 삶일 수도 있겠다. 

멋진 신세계의 시민들은 세뇌 당해 생각할 자유를 박탈당한 천치처럼 보이기도 한다. 하지만 현실을 살고 있는 내가, 쉽지만은 않은 삶을 살아내어 도달하고 싶은 상태가 그 시민들의 상태와 다르지 않다면, 그들은 천치일까? 아니면 선취자일까. 

이것 저것 찾아보던 중 제일 깔끔하게 잘 돌아가는 것 발견!

• https://www.npmjs.com/package/vue-masonry-css

1. data에 property를 선언한다.

• 컴포넌트마타 property를 선언해줘야하는 번거로움.
• 리액티브로 관리된는 오버헤드 (상수는 리액티브하지 않아도 되는데)

2. create 훅에서 property를 선언한다.

• create 훅은 이미 observation 단게가 끝난 후에 호출되는 것이므로, 여기서 property를 선언하면 리액티브 시스템에서 관리되지 않는다.
• 이것도 컴포넌트마다 property를 선언해줘야 하는 번거로움이 있다.

  3. 플러그인 만들어 사용하기

• 아래 링크 참조
• 컴포넌트마다 property 선언 안해줘도 된다.

https://coderethinked.com/3-different-ways-to-access-constants-in-a-vue-template/

enum 클래스를 활용하자.

String 상수로 정의한 경우 정해진 값 외에 값이 들어와도 정적 체크가 안된다.
enum을 활용하면 정적 체크가 가능하다.

에러 로그엔 컨텍스트가 담겨야한다.

에러가 어떤 인풋에서 기타 다른 조건은 어떠했는지등을 남겨야 한다.
띡하고 에러만 남기면 어디서 부터 디버깅을 시작해야 할지 알 수 없다.

INFO 레벨 로그 또한 컨텍스트가 담겨야 한다.

컨텍스트 없는 로그는 반쪽자리다.

로그는 시간이 지나고 봐도 의미를 알 수 있어야 한다.

개발 할때 대충 간략하게 로그 메시지를 작성하게 되면 시간이 지나거나 다른 사람이 보면 이해할 수 없게 된다.
누가봐도 이 로그가 어떤걸 의미하고, 그래서 어떤 영향이 있는지 등을 알 수 있게 작성하자.

catch를 아무데서나 하지 말자

그 에러에 대한 처리 방향을 결정할 수 있는 위치에서 catch 해줘야 한다.
어떤 인터페이스가 throw 한다고 해서 무조건 그 자리에서 catch 해버리는 것은 의미 없다.
또한 에러를 먹어버리거나 임의값을 리턴한다든지 하는 경우 2차 사고를 낳고 디버깅을 어렵게 한다.

if, else if의 연속...

status를 체크하고 싶어
상태전이가 A -> B -> C 로 된다고 할때

if(currentStatus.equals(A) && nextStatus.equals('B')) return true;
if(currentStatus.equals(B) && nextStatus.equals('C')) return true;
return false;

이렇게 작성하면 보기도 어렵고 상태가 추가될때 마다 코드가 늘어난다.
일때 enum 클래스 내부에 상태전이 사전조건에 대한 것을 한 단계 추상화하여

enum Status {
 Status condition;
}

if(currentStatus.equals(currentStatus.condition)) return true;
return false;

Status 클래스에만 추가하면 로직은 더 이상 건드리지 않아도 된다.

보통 레이어에 따라

controller
service
domain
mapper

등으로 패키지 구조를 잡았는데, 프로젝트가 커지다보면 각 피쳐 별로 클래스가 산재되어있어 유지보수가 어려워 어떤 것이 Best Practice인지 찾아보게 되었다.

from : https://stackoverflow.com/questions/3226282/are-there-best-practices-for-java-package-organization

One package per module/feature, possibly with sub-packages. Put closely related things together in the same package. Avoid circular dependencies between packages.

1. 피쳐/모듈 별로 패키지를 나눈다.
2. 각 피쳐/모듈 패키지는 서브 패키지를 가질 수 있다.
3. 각 패키지별 순환 참조가 생기지 않도록 한다.

이렇게 관리하면 연관된 클래스가 가까이 있어 유지보수가 쉬워지지 않을까 생각한다.

레이어별, 피쳐별 각각 장단점이 있겠지만, 프로젝트 구조가 커지면 피쳐별로 관리하고, 그 안에서 레이어를 나누는게 낮지 않을까하는 생각