혹독한 겨울에 자라 배울수록 겸손한 보리 혹독한 겨울에 자라 배울수록 겸손한 보리

출처 - https://kimdubi.github.io/mysql/varchar/ 대량의 데이터가 적자될 것으로 예상되는 테이블에 컬럼 추가 필요성을 느껴 작업을 하게 되었다. 문제는 스펙에 사이즈가 나와있어, 해당 사이즈를 명확히 할 것인지. 스펙을 정의한 곳에 신뢰가 완전하지 않아 여유를 둘 것인지에 대한 고민이다. 물론 varchar형태가 가변형이기 때문에 크게 해도 성능상 이슈가 없으니 미리 크게 잡아두는게 편하지 않냐는 생각과 명확한 사이즈를 통해 해당 길이의 패턴이나 의미전달을 할 수 있지 않을까란 생각이 또 충돌하였다. 추후 사이즈를 변경하는것에 대한 부담감을 갖지 않도록 사이즈 변경은 db에 무리없이 작업할 수 있는지 알아봤다. 1. varchar size 256 bytes 이하구간에서 증..

1. 코드리뷰의 필요성 2. 목적 I'm not a greate programmer. I'm just a good programmer with great habits - Kent Beck 정리를 하다가보니 코드리뷰의 중요성과 목적에 대해선 어느정도는 모두가 다 알고 있을 것이라고 생각된다. 강의 내용에서도 특별한 내용은 없다. 강의를 통해 다시 상기하게 된 것은 코드리뷰는 상대방을 깎아내리는게 아닌 함께 더 좋은 품질의 코드를 만들어 가는 것이다. 때문에 상대방을 존중하는 자세로 수정이 필요할땐 권유하는 말로, 리뷰를 받았을때는 감사하는 마음으로 솔직하게 자신의 생각을 전하면 된다는 것이다. 어느 누군가가 불편함을 갖고 스스로의 생각을 아끼게된다면 앞으로의 리뷰는 실패한 것이라고 생각된다. 다행이도 현재..

자바 버전별 기능을 다시 찾아보던 중 java 10에서 병렬 처리 가비지 컬렉션 도입으로 성능 향상이라는 글을 보았다. https://www.skyer9.pe.kr/wordpress/?p=287 JAVA 버전별 특징 – 상구리의 기술 블로그 JAVA 버전별 특징 출처1 : https://thatisgood.tistory.com/entry/Java-10-버전-특징 출처2 : https://ggomi.github.io/jdk-version/ JDK 1.0 JDK1.1 1997년 JDBC, RMI, Reflection, JIT, Inner Class JDK 1.2 1998년 자바를 세가지 버전으로 나눴 www.skyer9.pe.kr 병렬처리 가비지 컬렉션 parallel GC는 이미 java 7,8에 기본으로..

최근 추천받은 책에서 안전 해시 설계에 대한 글을 보면서 전에 기술면접때 받은 한 질문이 떠올랐다. 질문은 무수히 긴 스트링 값이 있을때, 거기서 해당 단어가 있는지 없는지 확인하고자 한다면 어떻게 해야할까?였다. 분명 좋은 방법이 있을텐데 당시 난 아무런 방법을 떠올리지 못했고, 단순히 contains을 통해 포함 유무를 확인했을 것 같다고 했다. 면접이 끝날 때쯤 질문시간에서 난 해당 질문에 대해 해결 키워드를 질문을 했고, 해시 테이블을 사용해 보라는 답변을 받았다. 말을 듣고, 해시테이블에 해당 해시코드로부터 인덱스를 가져와 나눠져서 저장하는 그림이 연상되었다. 하지만 하나의 스트링을 나눠서 저장하는 로직에 대한 전처리에 대한 것은? 이런 의문은 들었지만 솔직히 해시 테이블이나 해시 맵을 떠올리지..

회사에서 작업하면서 단순히 데이터 목록을 findall을 통해 조회한 값을 리턴하는 메서드에 당연하단 생각으로 @Transactional(readOnly = true) 을 주었었다. 그리고 리뷰를 하는도중 동료가 @Transactional(readOnly = true)의 역할이 무엇인지 물었었고 나는 readOnly=true인 상태이면 영속성 컨텍스트에 관리를 받지않아, 스냅샷 저장. 변경감지 수행등을 하지 않아 성능적으로 나아 이 옵션을 달았다고 답변을 했다. 그리고 이어지는 질문은 그럼 해당 옵션이 아예 없으면 되는데, 왜 필요한가였다. 떠올린 생각과 한 얘기는 1. readonly true일때는 master가 아닌 reader DB로 호출되는 장점이 있지만 현재는 개발단계로 하나의 db만 사용하고 ..

dto 객체에서 비어있는지 여부를 판단하기 위해 empty 라는 변수를 추가했다. 그리고 boolean형을 가져올때 isEmpty 식으로 boolean 타입을 묻곤 하기 때문에 큰 생각없이 변수 명을 isEmpty와 같이 지정하고 값을 가져올때도 isEmpty() 로 isEmpty 값을 가져 오도록 했다. 하지만 이처럼 is가 붙은 경우 isEmpty 값이 true를 주고 다시 isEmpty() 메서드를 통해 가져올 때 메서드의 내용은 public boolean isEmpty() { return isEmpty; } 로 isEmpty의 값을 그대로 리턴하지만 isEmpty 의 값을 true로 줬기 때문에 false로 리턴한다. boolean 형의 변수명의 규칙과 주의할 점을 찾아봐야 하겠다. 발견 1 Lo..

약 20만개의 데이터가 들어 있는 테이블을 날짜로 조회하려고 하니, 평소와는 다르게 지연이 생겼다. 이를 찾다, 찾다 확인해보니 해당 쿼리의 응답이 늦는 것을 확인 할 수 있었다. 1. 지연이 생기는 코드 SELECT * FROM table WHERE date BETWEEN "2021-06-24" AND "2021-06-25" ORDER BY id desc LIMIT 100; index를 걸어둔 date를 해당 구간으로 조회를 한 후 100를 id 기준 내림차순으로 정렬하는 쿼리이다. 하지만 결과가 제한된 수인 100개 이상일 때는 문제가 없지만 이 이하가 되는 경우 응답이 늦었다.(정렬기준이 오름차순도 마찬가지였다. 즉 limit 수보다 근소하게 작을때, 오름차순이든, 내림차순이든 정렬을 함께 하게되면..

이번에 typecript + nestjs 환경으로 구성된 프로젝트를 보며 궁금한 점이 생겼다. javascript에서도 ORM 프레임 워크가 있으며 이는 jpa와 아주 유사했다. 눈에 익어 코드를 이해하는데 무리는 없었으나 큰 의문이 생겼다. 프로젝트 내 코드에서도, typeORM 공식 사이트 예제코드에서도 필드에 대한 접근제어자가 없는 것이다. 내가 알기론 javascript의 접근 제어자 default 값은 public이다. 따라서 entity의 필드값들의 타입은 public이란 것인데 높은 안정성이 필요한 개체 값이 변동 가능성이 높은 public인 것인지 의문이 든다. 많은 사람들이 변동가능성에 대해 생각을 했을 것인데 왜일까? 찾아보니 비슷한 내용이 https://stackoverflow.com..