![]()
파일 접근 권한 리눅스의 파일 접근 권한은 다음과 같은 구조를 가진다. rwx는 각 자리를 비트로 표현하여 2진수로 표현이 가능하며 이를 8진수로 변환해서 나타낸다. 즉, 아래 권한을 8진수로 나타낼 경우 644가 된다. 권한 변경 리눅스에서 파일 접근 권한 변경 방법은 chmod(change mode) 명령어를 이용하면 된다. chmod [옵션] [사용자][연산][권한] [파일 or 디렉토리] 옵션 -R: 하위 디렉토리의 접근 권한도 함께 변경 구분 기호 설명 접근 권한 r 읽기 w 쓰기 x 실행 수행 연산 + 권한 추가 - 권한 제거 = 권한 부여 사용자 u user의 약자, 소유자 g group의 약자, 그룹 o other의 약자, 일반 사용자 a all의 약자, 모든 사용자 문자가 없으면 'a'와..
![]()
여러 기술블로그 글을 통해서 페이징을 할 때에는 OOM을 방지하기 위해 fetch join을 삼가해야 한다는 것을 알고 있었다. 왜냐하면 JPA가 distinct를 고려하여 페이징 조건을 맞추기 위해 모든 데이터를 메모리에 불러오기 때문이다. 이는 OOM을 발생시킬 수 있기 때문에 굉장히 위험하며 @OneToMany 또는 @ManyToMany 관계에서 해당되는 이야기이다. 왜 @OneToMany 또는 @ManyToMany에서만 해당되는 이야기일까? OneToMany를 예로 들자면 1의 입장에서 fetch join을 수행할 때 1에 해당하는 데이터가 N개 만큼 쪼개지는 현상이 발생한다. 말로 설명하기 어려운데 다음 그림을 참고하면 좋을 것 같다. 위 그림처럼 쿼리의 결과로 group1이 두 번 나타나는 현..
0. N:1 환경설정 @Entity @Getter @Builder @AllArgsConstructor @NoArgsConstructor(access = AccessLevel.PROTECTED) public class Parent { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; } @Entity @Getter @Builder @AllArgsConstructor @NoArgsConstructor(access = AccessLevel.PROTECTED) public class Child { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private long id; @Ma..
못생긴 프롬프트를 꾸며주자 https://misc.flogisoft.com/bash/tip_colors_and_formatting bash:tip_colors_and_formatting - FLOZz' MISC Bash tips: Colors and formatting (ANSI/VT100 Control sequences) The ANSI/VT100 terminals and terminal emulators are not just able to display black and white text ; they can display colors and formatted texts thanks to escape sequences. Those sequences are misc.flogisoft.com
사용자 변경 su [사용자 명 (default: root)] 환경변수를 포함하여 사용자 변경 su - [사용자 명] 현재 사용자 확인 whoami 위치 찾기 whereis [파일 명] which [파일 명] 되돌아가기 exit 명령어 기록 history 우분투 계열 패키지 설치 : apt를 사용 rpm : 레드햇 계열, dev : 데비안 계열 apt - h : 설명을 출력 apt list [프로그램명] : 설치할 수 있는 프로그램의 버전을 출력 apt install [프로그램명] : 프로그램을 설치 apt search [프로그램명] : 프로그램 검색 apt update : 설치된 프로그램을 업데이트 apt update [프로그램명] : 설치된 프로그램을 업데이트. 사용하지 않는 패키지를 유지 apt up..
![]()
준비 - 실행 - 검증 given-when-then given-when-then 패턴은 테스트 코드를 준비-실행-검증 세 단계로 나누는 패턴을 말한다. 예시 코드는 다음과 같다. given에서 테스트를 준비하고, when에서 검증하고자 하는 메서드를 호출하고, then에서 호출 결과를 검증한다. 너무나 간단하기 때문에 더 설명할 것도 없다. 사실 테스트 코드를 작성하기 전에 더 중요한 것은 어떻게 테스트하기 좋은 메서드를 작성하느냐 인 것 같다. 엔터프라이즈급 서비스는 비즈니스 로직이 굉장히 복잡할 수 있고, 메서드의 복잡도가 증가할 확률이 높을 것이다. 그때 테스트하기 좋은 코드로 잘 짜는 능력이 필요할 것이라고 생각한다. 그럼 테스트하기 좋은 코드(메서드)는 뭔데? 조심스럽게 내(초짜) 생각을 말해보..
