경험의 연장선

ozh 테마 적용 안될 시 설정 방법

검프 — Thu, 27 Feb 2025 09:52:56 +0900

터미널에서 테마가 적용안되는 이슈 확인.

vim /Users/livenow/.oh-my-zsh/themes/agnoster.zsh-theme

를 보면 뭔가 git conflict가 났다.
아래 레포에서 테마 설정 이슈가 났을 때, 어떻게 처리할 수 있는지 논의 되었던 것을 알 수 있다.
https://github.com/agnoster/agnoster-zsh-theme/issues/155

cd $ZSH
git config core.autocrlf input
git rm --cached -r .
git reset --hard

후 다시 실행하면 잘된다

변수명 검색 사이트. 전세계 Github repo에서 검색하기

검프 — Wed, 21 Feb 2024 16:26:22 +0900

개요

변수명이 고민될 때는 깃헙 사용자들은 어떻게 변수를 사용하고있는지 찾아봐요.

https://grep.app/

[Git] macOS에서 Github 계정과 GitLab 계정을 폴더(Directory)별로 사용하자

검프 — Tue, 11 Jan 2022 23:58:42 +0900

git을 설치한 바로 직후라 가정하고 진행해요.

계정을 하나만 썼을 때는 global 설정으로 username과 email을 설정했는데, 관리해야 할 계정이 추가되니 매번 바꿔 줘야하는 불편함이 있었어요.
여러 블로그를 참고했는데, SSH로 설정하는 방법이 많더라구요. 근데 “원래도 안썼는데 굳이 써야할까?” 라는 의문점이 있었어요.

결론적으로 gitconfig 설정과 GitHub과 GitLab에서 제공하는 Access Tokens으로도 충분히 설정 가능하다는 것을 알고 포스팅을 작성하게 됐어요 :)

GitConfig 설정

먼저 Git 설정을 할게요! iterm이나, 터미널을 열어 실행해주세요.

vim ~/.gitconfig

위의 파일에서, global 설정을 한다고 생각하면 될듯해요 :) 명령어로도 가능하지만, vim을 사용해서 설정해봐요.

파일 수정

[user]
  email = "깃허브 이메일"
  name = "깃허브 사용자이름"
[includeIf "gitdir: "깃랩 계정으로 접근할 디렉터리""]
  path = "설정파일 위치"
[core]
  eol = lf                // OS 별로 CRLF 처리 차이로 인한 문제의 
  autocrlf = input        // 해결을 위한 설정

파일 수정 예시

[user]
  email = asdsd@naver.com
  name = livenow14
[includeIf "gitdir:/Users/livenow14/Desktop/woowa/"]
  path = .gitconfig-woowa
[core]
  eol = lf
  autocrlf = input

개인(Github) 계정을 global로 설정했어요 (실수로 회사 계정으로 push 해버리는 불상사 방지)
includeIf는 git 과 관련된 명령어를 실행할 때, gitdir의 하위 repository라면 path에 있는 설정파일을 포함하는 옵션이에요. path는 식별가능하게 작성 해주시면 돼요.
여기서 중요하게 체크 해야할게, woowa폴더내의 그냥 폴더에서는 설정이 적용이 안되고 ,git이 포함된 곳에만 적용이 된다는 점이에요
ex) /woowa/work/repo1, /woowa/work/repo2가 있을 때, /woowa, /woowa/work 폴더에는 적용이 안되고, repo1, repo2 폴더에만 적용이 된다.

저는 회사에서 사용할 레포지토리들을 바탕화면(Desktop)의 woowa 폴더에서 관리하고 싶어서 gitdir 위와 같이 설정했어요.

깃의 설정파일 우선순위가 Local(직접 설정한 것) > Global인 것을 참고하면 좋을 것 같아요.

이제 회사(GitLab) 계정 또한 설정해주죠.

.gitconfig-woowa 파일 수정

vim ~/.gitconfig-woowa

[user]
  email = "깃랩 이메일"
  name = "깃랩 사용자이름"

.gitconfig-woowa 파일 수정 예시

[user]
  email = livenow@woowa.com
  name = 검프

깃허브와 마찬가지로 이메일과 GitLab의 사용자이름을 설정해주면 돼요!

Access Token 발급

이제 Access Token을 발급 받아보죠!

GitHub Access Token 발급

먼저 메인 화면에서 맨 오른쪽 위 사진을 클릭하고 Settings에 들어가요

그다음 Developer settings를 클릭해요

그 뒤, Personal access tokens을 클릭해요

Generate new token으로 token 생성페이지로 가요

token생성 페이지에서, 필요한 권한을 주고 이름을 설정해요 (저는 업무 노트북에서 사용할 것이기 때문에 repository삭제 권한 빼고 다 설정했어요.)

Generate token을 클릭하면 token이 생성돼요. 여기서 나오는 token값은 페이지를 벗어나면 발급할 수 없으니, 따로 어딘가 저장해놓아요. 잊어버리면 무조건 재발급 해야해요.

% 토큰값 저장 필수 %

이후 예시에는 발급받은 깃허브 token이라 말할게요

GitLab Access Token 발급

Github랑 마찬가지로 Edit profile를 클릭해요

Github랑 마찬가지로 토큰이름이랑 Expiration date, 필요한 권한을 설정해요.

Expiration date는 따로 설정하지 않으면 영구적으로 사용할 수 있게 설정해요.

여기서 나오는 token값은 Github와 마찬가지로 페이지를 벗어나면 발급할 수 없으니, 따로 어딘가 저장해놓아요.

이후 예시에는 발급받은 깃랩 token이라 말할게요

% 토큰값 저장 필수 %

위의 토큰값들은 사진찍고 바로 삭제했어요 ㅎㅎ

자 이제 발급받은 Access Token들을 mac에 저장해줘야해요.
저장된 Access Token들은 비밀번호의 역할을 할거에요.

Mac에 Credential 등록

credential-osxkeychain 확인

credential-osxkeychain이 존재하는지 확인해요.

git credential-osxkeychain

있으면 아래와 같은 결과가 떠요.

git credential-osxkeychain
Usage: git credential-osxkeychain <get|store|erase>

없으면 아래와 같은 결과가 떠요.

git credential-osxkeychain
xcode-select: note: no developer tools were found at '/Applications/Xcode.app',
requesting install. Choose an option in the dialog to download the command line developer tools.

없을 경우, git을 다시 설치해주세요.

keychain 등록

이제, global 설정으로 keychain을 설정할 것을 예약해둬요.

git config --global credential.helper osxkeychain

자 이제 설정이 끝났어요!

helper가 잘 등록됐나 보려면

vim ~/.gitconfig

를 실행해보면 돼요 ㅎㅎ

[user]
  email = asdsd@naver.com
  name = livenow14
[includeIf "gitdir:/Users/livenow14/Desktop/woowa/"]
  path = .gitconfig-woowa
[core]
  eol = lf
  autocrlf = input
[credential]            //추가됨!
  helper = osxkeychain  //추가됨!

앞서 직접 설정했던 것 뒤에 추가로 설정된것이 보이시죠?! 이렇게까지 확인해봤다면 설정 완료!

이제 git 작업시 딱 1번 닉네임과 토큰값을 입력 해주면, 이후 mac의 키체인에 자동적으로 저장될거에요.

직접해보기

woowa 폴더내의 레포지토리

앞서 woowa폴더에 Gitlab을 사용하도록 설정했어요.

작업을 할 woowa폴더 내의 레포지토리에 들어가서

git config user.name

과

git config user.email

를 실행해보면 설정한 값이 잘 들어가는것을 알 수 있어요

실제로 커밋이 어떻게 찍히는지 보고싶다면 아래와 같이 간단하게 커밋을 날려봐도 돼요!

touch test.txt
git add .
git commit -m "test"
git push origin main

첫 push를 할 때 username과 password를 입력하라 할거에요.

여기는 회사용으로 사용할 거니, 깃랩의 name과 토큰값(발급받은 깃랩 token)을 입력하면 돼요 (아까 저장한 토큰값 안까먹으셨죠?!)

woowa 폴더에 포함되지 않는 레포지토리

woowa폴더 안이 아닌 레포지토리는 일반적인 전역설정이 들어가겠죠?

예시에선 study 폴더내의 레포에 접근했어요.

처음에 설정한 값이 잘들어있네요!

첫커밋을 찍을때 깃허브의 name과 토큰값(발급받은 깃허브 token)을 입력해야겠죠?! ㅎㅎㅎ

끝!

2021년의 기억

검프 — Sun, 9 Jan 2022 09:48:32 +0900

작년 이맘때 우아한테크코스를 합격하며 회고를 남겼던 적이 있어요.
[우아한 테크코스 3기] 최종 테스트 및 합격 후기
위의 포스팅으로 1년 회고를 마무리했다 생각했는데, 지금 와서 보니 우테코 합격 얘기뿐이라 작년에 무엇을 했는지가 보이지 않네요.

이번 포스팅에선 기억하고 싶은 부분들을 남겨보려 해요.

기억하고 싶은 것

적당히 유지한 커밋

무엇을 배웠는지에 집중하고, 그 과정에 커밋을 녹여내기로 했어요. 만약 커밋을 못 남긴다면, 어쩔 수 없다고 생각했고요!

1일1커밋을 유지하려다 보니, 어느 순간 커밋에 목표를 두고 있다는걸 알게 됐어요.
”커밋하기 좋은 공부인가?”라는 생각이 “이 공부를 통해 무엇을 얻을 수 있을까?”라는 생각보다 앞섯기에, 커밋을 남기기 전까지의 지식만을 공부했던 거였죠. 실제로 남는 것이 많이 없었어요.

현재 상황에 필요하거나, 하고 싶은 공부를 하기로 했고 이 과정에 자연스럽게 커밋에 남겨지는 것을 깨달았어요. 조금 듬성듬성 하지만, 오히려 지식이 채워짐을 느꼈어요.
제가 중요하게 생각해야 할 것은 지식이지, 출석 체크가 아니었기 때문이에요.

~~이날 이후 회사 적응하느라 커밋을 찍지 못했다는 슬픈 전설이...~~

블로그 포스팅 70개

지식을 혼자 가지고 있지 말고, 공유하자 마음먹었어요. 커밋은 혼자만의 만족이라면, 공유하는 만족은 모두의 만족임을 느꼈기 때문이에요. 또한 어려운 지식을 알기 쉽게 풀어서 글로 남겨주신 선배 개발자분들의 고마움에 대한 제 나름의 보답이라 생각했어요.

언젠가 정리한 지식을 까먹더라도, 블로그 한 번만 보면 바로 이해할 수 있게끔 노력했어요.
정리하며, 알고 있는 부분과 모르는 부분을 정확히 파악할 수 있어서 좋았어요. 항상 “이거 블로그에 올려도 괜찮은가?”라는 질문에서 수정과 추가 작업을 많이 했어요. 또한 처음 글을 남길 땐 단순 문제 해결법을 작성했는데, 제가 쓴 글이 아니라는 느낌이 들어 저만의 언어로 만들어 작성하는 것으로 점점 발전 시켜 나갔어요.
이러한 과정은 가진 지식을 유지할 수 있는 가장 좋은 방법이었어요.

블로그 포스팅은 2022년에도 유지할 예정이에요.

우아한테크코스 과정

과정요약

2020년 10월 지원부터 2021년 11월 수료까지 약 13개월의 시간을 몰입했어요.
”함께 자라기”라는 책에서는 일하는 순간에 부담감을 느끼는지 지루함을 느끼는지 항상 인식하며 난이도나 실력을 조정해야 한다고 말해요.

책을 교육 기간이 끝날 때 쯤 읽었지만, 못해서 아쉬움이 남는 것이 아닌, 이미 그렇게 해왔다는 검증을 할 수 있었어요. 우테코 기간에서 지루함 혹은 부담감을 느낄 때 코치분들이나 주의 크루들에게 조언을 많이 구했기 때문이에요. 이러한 과정을 통해 몰입을 자연스럽게 경험할 수 있었다 믿어 의심치 않아요. 혼자만 고민하고 해결하려 했다면, 절대 경험할 수 없었을 거에요.

함께한 모든 코치, 크루분들 고마워요 :)

거창에서의 사이드 프로젝트

레벨2 방학 기간에 크루원인 라이언, 유조, 동동과 함께 거창 시골집에서 사이드 프로젝트를 진행했어요(~~검라유동이라는 팀이었어요 ㅎㅎ~~).
4박 5일 동안 코딩, 음주, 수면의 사이클로 진행했는데 웃음이 끊이질 않아서 “개발을 이렇게 재밌게 할 수 있구나”라는 걸 느끼게 됐어요. 이때의 추억이 이후에 많은 힘이 됐어요.
프로젝트 완성을 하진 못했지만, 프로젝트 설계부터 요구사항 정리, 컨벤션 정의 등의 협업 경험을 많이 할 수 있었어요.

추가 테코톡

의무적으로 해야 하는 테코톡외에 도커 관련 테코톡을 추가 진행했어요.

도커를 깊게 공부해보고 싶기도 했었고, 도커 관련해서 테코톡 진행했으면 좋겠다는 의견? 도 있어서 진행한다 했는데, 생각보다 준비 시간이 많이 들었어요. 쉽게 생각했는데, 발표하려 하니 내용이 너무 넓었거든요.

처음 영상을 촬영하니 3시간 정도의 분량이 나왔어요(~~10분 테코톡 맞습니다~~). 돌려보니 쓸데없는 말도 많고, 뭘 말하려는지도 이해하기 힘들었어요. 하지만 내용을 줄인다면 연관성이 무너졌어요.

이때 지식을 처음 접하는 입장에서 쉽게 이해 가능한지, 전달받는 내용에 납득이 가능한지 등을 고려했어요. “테코톡을 보는 사람이 모든 걸 알고 있다면 굳이 이 영상을 볼까?”라는 생각으로 처음 보는 사람의 입장에서 큰 그림을 볼 수 있게 하자는 생각으로 다시 촬영했어요(~~그래도 1시간 30분이 나왔네요~~).

이 과정을 통해 지식을 전달받는 입장에 대해 고민할 수 있었어요. 또한 정말 알고 있는지, 모르는지에 대해 스스로 증명할 수 있게 됐어요. 어려운 걸 어렵게 말하는 건 쉽지만, 쉽게 말하는 건 정말 어렵거든요.

https://www.youtube.com/watch?v=IiNI6XAYtrs

스터디

크루원들과 많은 스터디를 진행했어요.
송파구에서 일을 더 잘하는 11가지 방법에는 ”이끌거나, 따르거나, 떠나거나!”가 있어요. 스터디를 진행할 때 이 문구를 항상 생각했어요. 무언가 시작할 때, 이 3가지를 생각하지 않으면 항상 우선순위에서 밀리게 돼서 흐지부지되는 경우가 많았거든요.
애매하거나 모르는 부분을 스터디원들과 함께 알아갈 때, 많은 것을 배울 수 있었어요.
이 또한, 이후에도 의식적으로 유지해야 한다 생각해요.

우아한형제들 입사

인생에 첫 직장인데 정말 좋은 회사인 우아한형제들에 입사하게 됐어요.
강렬하게 가고 싶었던 회사였고, 실제로 입사를 하게 되니 믿기지 않아요. 입사하기까지 도움을 주셨던 모든 분들에게 감사해요 :)

입사 이후 누군가 제게 이런 말을 해주셨어요.

이제 시작이네?

제가 지금까지 성장하기 위해 노력해왔던 것들을 계속 유지해야 한다는 다짐과 목표를 주게 해 줬던 말이라, 항상 명심할 거에요.
또, 회사에서 필요한 개발자가 되기 위해 더욱 수련할 예정이에요(~~내년 회고 때 검증할 수 있겠죠? ㅎㅎㅎㅎ~~).

아쉬웠던 기억

개발하며 어려운 부분들을 키워드로 정리해놨는데, 그중 50%만 글로 정리했어요.
오늘은 바쁘니까 내일, 내일, 이렇게 미루다 보니 새해를 맞이하게 됐어요.
오늘 하지 않으면 내일도 못 한다라는 걸 알게 된 한해였어요.

그래서 목표는?

이번 2022년도에는 아쉬웠던 부분들을 최소화하는 게 목표에요.
업무를 하며 어려운 부분, 애매한 부분들을 내일로 넘기지 말고, 그날그날 늦어도 그 주에 정리할 거예요 :)

‍ 급하게 결론을 내리자면

행복은 적금처럼 저장해서 꺼내쓸 수 있는 것이 아니다. 오늘 행복해야 내일도 행복할 수 있다.

정말 좋아하는 문장인데요. 저는 개발을 하고, 새로운 지식을 알아갈 때 행복을 느끼더라구요(물론 맛있는 거 먹었을 때도 마찬가지긴 하지만 ㅎㅎ). 이 행복을 놓치지 않으려고요!

여러분은 어떤 것을 할 때 오늘 행복하다고 말할 것 같나요?!

[Java] Java8과 Java11의 특징

검프 — Sun, 14 Nov 2021 20:28:39 +0900

정리

java8의 특징은 이전 포스트에 다뤘어요. 이번엔 java 11을 다뤄보려 해요.

Java 10은 라이선스 없이 상업적으로 사용할 수 있는 마지막 무료 Oracle JDK 였어요.
JAva 11부터는 Open JDK를 무료로 사용할 수 있어요.

Java 11에서 추가된 내용들을 기능, 성능 관점에서 보도록 해요.

기능 추가

1. String 클래스, 메서드 추가

isBlank, lines, strip, stripLeading, stripTrailing, and repeat가 추가됐어요.

String multilineString = "My name \n \n is \n Gump.";
List<String> lines = multilineString.lines()
  .filter(line -> !line.isBlank())
  .map(String::strip)
  .collect(Collectors.toList());

assertThat(lines).containsExactly("My name", "is", "Gump");

2. File 클래스, 메서드 추가

readString, writeString이 추가됐어요.

파일에서 문자열을 더 게 읽고 쓸 수 있게 됐어요.

Path filePath = Files.writeString(Files.createTempFile(tempDir, "demo", ".txt"), "Sample text");
String fileContent = Files.readString(filePath);
assertThat(fileContent).isEqualTo("Sample text");

3. 컬랙션 인터페이스, 메서드 추가

컬랙션의 toArray() 메서드를 오버로딩하는 메서드가 추가됐어요.

원하는 타입의 배열을 선택할 수 있게 됐어요.

List sampleList = Arrays.asList("Java", "Kotlin");
String[] sampleArray = sampleList.toArray(String[]::new);
assertThat(sampleArray).containsExactly("Java", "Kotlin");

4. Predicate 인터페이스, static not 메서드 추가

Predicate 인터페이스에 부정을 나타내는 not 메서드가 추가됐어요.

#Predicate.java
static <T> Predicate<T> not(Predicate<? super T> target) {
    Objects.requireNonNull(target);
    return (Predicate<T>)target.negate();
}

예시

List<String> sampleList = Arrays.asList("Java", "\n \n", "Kotlin", " ");
List withoutBlanks = sampleList.stream()
  .filter(Predicate.not(String::isBlank))
  .collect(Collectors.toList());
assertThat(withoutBlanks).containsExactly("Java", "Kotlin");

5. 람다에서 로컬 변수 Var 사용

람다식에서 var을 사용할 수 있게 됐어요.

List<String> sampleList = Arrays.asList("Java", "Kotlin");
String resultString = sampleList.stream()
  .map((@Nonnull var x) -> x.toUpperCase())
  .collect(Collectors.joining(", "));
assertThat(resultString).isEqualTo("JAVA, KOTLIN");

6. HTTP Client

Java 9에 도입된 HTTP 클라이언트가 표준 기능이 됐어요. (HTTP/1.1 과 HTTP/2을 지원헤요)전반적인 HTTP API의 성능이 향상댔어요.

HttpClient httpClient = HttpClient.newBuilder()
  .version(HttpClient.Version.HTTP_2)
  .connectTimeout(Duration.ofSeconds(20))
  .build();
HttpRequest httpRequest = HttpRequest.newBuilder()
  .GET()
  .uri(URI.create("http://localhost:" + port))
  .build();
HttpResponse httpResponse = httpClient.send(httpRequest, HttpResponse.BodyHandlers.ofString());
assertThat(httpResponse.body()).isEqualTo("Hello from the server!");

7. Nest-Based Access Control

중첩클래스들이 접근지정자에 상관없이 서로의 필드에 접근이 가능해졌어요.

class Test {  
    static class One {  
        private int one; 
     } 
     static class Two {  
        private int two;  
    }
 }

8. 자바 파일 실행

javac를 통해 컴파일 하지 않고도, 바로 실행할 수 있게 됐어요.

# before

$ javac HelloWorld.java
$ java HelloWorld 
Hello Java 8!

# after

$ java HelloWorld.java
Hello Java 11!

성능향상

1. 동적 클래스 파일 상수

CONSTANT_Dynamic이라는 새로운 상수 풀 형식을 지원해요.

2. 개선된 Aarch64

기존 문자열 및 배열 내장 함수가 최적화 됐어요.
java.lang.Math 의 sin, cos, log 메서드에 대한 새로운 내장 함수를 구현해요.

3. 새로운 GC

Epsilon이라는 새로운 GC가 실험적으로 나왔어요.
기본은 Z GC

4. JFR

애플리케이션에서 진단 및 프로파일링 데이터를 수집하는 데 사용할 수 있는 프로파일링 도구가 나왔어요.

Removed

1. Java EE and CORBA

앞으로 EE 나 CORBA 모듈이 필요한 경우 명시적으로 의존을 추가해야 해요.

2. JMC and JavaFX

FX 라이브러리가 OpenJFX 프로젝트로 옮겨가면서 코어에서 삭제됐어요.

Deprecated

1. Nashorn JavaScript engine

2. Pack200 compression scheme for JAR files

Java8의 사용이유

저는 최근까지도 Java 8을 사용했는데요. "Java 11이 있는데 Java 8을 왜 사용했나?"라는 질문이 자주 들어와서 이유를 정리해볼해요.

1. 외부 개발 툴과의 연동성

웹서비스를 구동할 때, 자바 애플리케이션 외에 툴들이 필요한 경우가 있는데요. 이런 툴과의 연동성 문제에서 가장 안정적이라 생각해요. Java 11 부터 요금 정책이 바뀌었기 때문에, Oracle JDK가 아닌 Open JDK를 사용해야 하면서 생기는 이슈들이 꽤 있었어요.

2. Java 11에서의 변경사항이 크게 없음

메서드, 기능들이 어느정도 추가됐지만, Java8에서와 크게 차이가 나지 않기 때문에, Java 11을 사용해야하는 큰 이유를 찾지 못햇어요.
또한, Java 8 → Java 11에서의 문제가 크게 없기 때문에. 이후 릴리즈가 지원을 하지 않을 때, 버전 업그레이드를 한다 해도 괜찮다 생각해요.

[Java] Java API 생성자 구현 및 검증 방식 (String, BigDecimal)

검프 — Tue, 9 Nov 2021 16:36:30 +0900

우테코 초기, 객체 검증, 할당 및 방어적 복사에 관련된 논의를 했던 적이 있어요. 논의에 대한 결과와 원문을 블로그에 남겨보려해요.

원문 : https://silly-elderberry-dd6.notion.site/Java-Java-API-8f4dceee5c84440288a5424a6326e457

생성자 코드 구현시, 검증로직을 어떤 순서로 진행하는게 좋을지에 대한 질문의 제이슨의 답변이었습니다.

왜이리 멀리보고 있었지?

답변을 듣고, 들었던 생각이었습니다.

선배 자바 개발자분들이 멀리 있는 것이 아니라, 자바 코드 내에 살아 숨 쉰다는 사실을 까맣게 잊고 있었습니다.

(질문을 한 제가 부끄러워지는 듯한 느낌이었습니다.. ㅠㅠ)

그냥 쓰는 것이 아닌, 알고 쓰자.

String, BigDecimal은 어떻게 생성자 코드가 구현되고 또 검증의 순서는 어떻게 되는지 코드를 읽어보며 이해해보려 했습니다.

자바 버전

jdk 1.8.0_275

String은 어떻게 검증되어 생성될까?

java.lang 패키지의 String 클래스를 먼저 살펴 보기로 했습니다.

클래스 선언 및 인스턴스 변수 확인

여기서 저는 3가지를 알 수 있었는데요. (밑에 두개는 아직 잘 모르겠어요..ㅎㅎ)

첫번째, String class는 상속할 수 없다.

final Class로 선언되어 있기때문에 다른곳에서 extends로 상속 할 수 없습니다.

두 번째, 문자 저장시 불변 char 배열을 쓴다.

String은 결국 클래스이기 때문에 프리미티브 타입인 char을 통해 데이터를 저장한다는 것을 알 수 있습니다. 또한 불변을 위해 final을 쓴 것을 확인할 수 있습니다.

마지막, hash는 불변이 아니다.

hashCode는 고유한 값이지 주솟 값은 아니기 때문에 불변이 아닙니다.

무한정 생성되는 String과 달리 int는 한정적이기 때문에 value 값이 달라도 hash 값이 중복될 수 있습니다.

생성자 확인

String을 인스턴스화 하기위해 2가지의 생성 방법이 있는데요

String pobi = "포비";
String brown = "포비";
String jason = new String ("포비");
String cu = new String ("포비");

위의 생성 방식의 차이는 무엇일까요? 제이슨의 수업에서 확인할 수 있었습니다.

리터럴로 생성할 경우, String constant pool에
new String()으로 생성 할 경우 Heap에 새로운 주소 할당

와닿지 않을 것 같아 그림으로 그려보았습니다.

리터럴로 생성될 경우 String Constant Poll에 저장되기 때문에 같은 값일 시 같은 주소를 공유하고,

new String()으로 생성될 시 Heap에 새로운 공간이 할당되는 것을 확인할 수 있습니다.

그렇기 때문에 아래 두개의 테스트가 통과 할 수 있습니다.

@DisplayName("같은 이름의 문자열이 저장될 때 두 변수는 같다")
    @Test
    void literalSameTest() {
        //given
        String pobi = "포비";
        String brown = "포비";

        //then
        assertThat(pobi).isEqualTo(brown);
        assertThat(pobi).isSameAs(brown);
    }

@DisplayName("같은 이름의 문자열로 String객체가 생성될 때, 두 변수가 같은지 비교한다")
    @Test
    void objectSameTest() {
        //given
        String pobi = new String ("포비");
        String brown = new String ("포비");

        //then
        assertThat(pobi).isEqualTo(brown);
        assertThat(pobi).isNotSameAs(brown);
    }

그럼 Heap의 할당된 걸 String Constant Poll로 옮기지 못하나?

intern()메소드를 활용하면 옮길수 있습니다.

테스트도 정상 작동하는 것을 볼 수 있습니다.

@DisplayName("intern() 정상 작동한다")
    @Test
    void internTest() {
        //given
        String pobi = "포비";
        String jason = new String ("포비").intern();

        //then
        assertThat(pobi).isEqualTo(jason);
        assertThat(pobi).isSameAs(jason);
    }

생성자 구현 로직 확인

드디어 구현 로직을 살펴보는 과정까지 왔습니다. ( 자바 버전에 따라 조금 차이가 날 수 있으니, 위에서 명시한 버전을 꼭 확인해주세요! )

String pobi = "포비" 는 어떻게 동작하는거지?

String Class 문서에 따르면

String str = "abc"; 는

char data[] = {'a','b','c'};

String str = new String(data); 와 같다고 합니다.

검증은 어떻게?

String 클래스에선 값을 복사하고, System에서 필요한 검증을 한 후, 할당을 하는 것을 볼 수 있네요

제이슨의 질문에 대한 첫번째 답이 나왔습니다.

String 클래스의 String(char value[]) 생성자는 복사 -> 검증(System에서 필요한) -> 할당 한다.

BigDecimal은 어떻게 검증되어 생성될까?

클래스 선언 확인

인스턴스 변수는 이후 BigDecimal을 따로 정리할때 하기로 하고, 클래스 선언만 간단히 확인해보겠습니다.

여기서 알수 있는 2가지는

첫 번째, Number 클래스를 상속받았다.

두 번째, 순서 비교를 위해 Comparable를 구현했다.

생성자 확인

저는 BigDecimal을 생성할 때 주로 String으로 인자를 넘겨주는데요, 테스트 먼저 확인하겠습니다.

@DisplayName("BigDeciaml 저장 및 더하기 확인")
    @Test
    void bigDeciamlSaveTest() {
        //given
        String five = "5";
        String ten = "10";

        //when
        BigDecimal fiveBigDecimal = new BigDecimal(five);
        BigDecimal tenBigDecimal = new BigDecimal(ten);
        BigDecimal sum = fiveBigDecimal.add(tenBigDecimal);

        //then
        assertThat(sum.intValue()).isEqualTo(15);
    }

문자열이 숫자로만 이루어져있다면, 정상적으로 생성 되는 것을 확인할 수 있습니다.

그렇다면, String이 비어있거나, 숫자 값이 아닌경우 에러가 발생해야 할 것입니다.

@DisplayName("문자열이 숫자가 아니라면 에러가 발생한다.")
    @Test
    void bigDeciamlSaveErrorTest() {
        //given
        String five = "five";
        String empty = "";

        //then
        assertThatThrownBy(() -> new BigDecimal(empty))
                .isInstanceOf(NumberFormatException.class);

        assertThatThrownBy(() -> new BigDecimal(five))
                .isInstanceOf(NumberFormatException.class);
    }

생성자 구현 로직 확인

위의 검증은 어떻게 진행될까요, BigDecimal 클래스에서 확인해보겠습니다.

베이스 생성자의 toCharArray에서, 방어본을 만든 후 → 검증(System에서 필요한) → 반환을 하는 과정을 볼 수 있습니다.

결국, BigDecimal(String)에서 넘어온 복사가 끝난 값이 인자(char[] in)로 들어오기 때문에 방어적 복사가 이루어졌다고 볼 수 잇습니다. 복사된 값으로 BigDecimal에서 필요한 검증을 하는 모습을 볼 수 있습니다.

그렇다면 public BigDecimal(char[] in, int offset, int len, MathContext mc)으로 생성하는 것이랑 BigDecimal(String)의 차이점은 복사를 하는것 뿐인데, 뭐가 다른걸까요?

문서에 따르면, BigDeicmal(String)보다 조금더 나은 성능을 기대할 수 있다고 합니다. (아무래도 값 복사를 하지 않기 때문이겠죠 → 더 넓게 볼 수 있는 관점을 주신 제이, 감사합니다.)

여기서는 CU의 질문의 답이 조금이나마 될 수 있을 듯 합니다.

결론적으로, 제이슨의 질문에 대한 두번째 답이 나왔습니다.

BigDecimal(String) 생성자는 값을 할당 하기 전 복사본을 만들고, 검증을 한다.
또한 BigDecimal은 상황에 따라 값 복사 → 검증 → 할당 혹은 복사없이 검증 → 할당 한다.

논의해볼 부분

완태가 검증 먼저 vs 항당 후 검증에 대한 질문을 남겨주셨는데요, 이부분은 저도 이렇다 할 정답이 떠오르지 않아 논의할 부분으로 남겨두려 합니다.

7개월 후의 늦은 결론

"이후에 결론을 내자!", 했던게 벌써 7개월 가량이 지나버렸네요((저때는 글의 어투도 달랐네요 ㅎㅎ). "검증 후 할당 vs 할당 후 검증"을 논의해보는 것이었는데요.

저의 결론은, "검증 후 할당"을 하자 입니다.
할당을 먼저 하게 되면, 할당을 위해 준비되어야 할 객체 생성 비용과 할당된 객체의 검증 과정의 비용이 커질거라 생각하기 때문이에요. 또한, 실패했을 때, 쓸모없는 객체가 힙 영역에 추가 추가 되어 GC에 의해 해제되겠네요 :)

지금 저의 결론이 정답이라고는 생각하지 않지만, 위와 같은 이유가 나름 명확하다 생각하기에.. 당분간은 유지될거라 생각해요!

여러분들의 생각은 어떤가요?

[SpringBoot] 멀티모듈 구조에서, 다른 모듈의 테스트 클래스 사용하기

검프 — Tue, 2 Nov 2021 21:53:36 +0900

Gradle Test Fixture 사용해서 테스트 중복코드를 줄일 수 있어요.

멀티모듈 구조에서 다른 모듈의 Test 폴더를 사용할 수 없으니, 중복되는 클래스가 각각의 모듈의 Test 폴더에 포함되었어요.

저는, Gralde 멀티모듈 구조에서, 의존을 하는 모듈의 Test 폴더까지 사용하고 싶었어요.
이때 사용할 수 있는 것이 Gradle Test Fixture입니다 ㅎㅎ

TestFixutre 적용

먼저 test fixture를 사용할 모듈에서 testfixture 의존성을 넣어요. (domain-cvi/build.gradle)

plugins{
    id 'java-library'    //**new**!!
    id 'java-test-fixtures' //**new**!!
    id 'maven-publish' //**new**!!
}

bootJar { enabled = false }
jar { enabled = true }

dependencies {
    implementation project(path:':common-cvi', configuration: 'default')
    implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
    runtimeOnly 'com.h2database:h2'
    runtimeOnly 'mysql:mysql-connector-java'
    implementation 'org.hibernate.validator:hibernate-validator:6.2.0.Final'

    //migration
    implementation 'org.flywaydb:flyway-core:7.11.2'

    //testFixture
    testFixturesImplementation 'org.springframework.boot:spring-boot-starter-test'  //new!!
}
...

testFixturesImplementation에 의존성이 추가된 것을 유의해주세요 (testFixture에서 사용할 라이브러리를 지정해줘야 합니다. )

testfixtures 폴더를 생성한 후, 멀티모듈 구조에 맞게 클래스를 생성해요.
(com/cvi/CustomParameterizeTest)

이제 이를 사용할 모듈에서 아래와 같이 의존성을 추가해주면 끝! (app-cvi/build.gradle)

version = '0.0.1-SNAPSHOT'

dependencies {
    implementation project(path:':common-cvi', configuration: 'default')
    implementation project(path:':domain-cvi', configuration: 'default')
    testImplementation(testFixtures(project(":domain-cvi")))    **//new!!
...**

일줄 알았더니...

Could not determine the dependencies of task ':app-cvi-api:test'.
> Could not resolve all task dependencies for configuration ':app-cvi-api:testRuntimeClasspath'.
   > Could not resolve project :domain-cvi.
     Required by:
         project :app-cvi-api
         project :app-cvi-api > project :domain-cvi-oauth-service
         project :app-cvi-api > project :domain-cvi-publicdata-service
         project :app-cvi-api > project :domain-cvi
      > Module 'com.backjoongwon:domain-cvi' has been rejected:
           Cannot select module with conflict on capability 'com.backjoongwon:domain-cvi:0.0.1-SNAPSHOT' also provided by [com.backjoongwon:domain-cvi:0.0.1-SNAPSHOT(default), com.backjoongwon:domain-cvi:0.0.1-SNAPSHOT(runtimeElements)]
   > Could not resolve project :domain-cvi.
     Required by:
         project :app-cvi-api
      > Module 'com.backjoongwon:domain-cvi' has been rejected:
           Cannot select module with conflict on capability 'com.backjoongwon:domain-cvi:0.0.1-SNAPSHOT' also provided by [com.backjoongwon:domain-cvi:0.0.1-SNAPSHOT(default), com.backjoongwon:domain-cvi:0.0.1-SNAPSHOT(runtimeElements)]

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

위와 같은 예외가 발생하네요...

예외의 이유

멀티모듈 구조를 완전히 잘못잡고 있었어요.
이전까지는

implementation project(path:':domain-cvi', configuration: 'default')

이렇게 다른 멀티모듈의 의존성을 끌어오고 있었는데, 이는 하위 의존성을 모두 다 가져오게 돼요.
즉, app-cvi-api 에서 많은 모듈을 의존하고 있는데,

여기서, app-cvi-api가 의존하고 있는 모듈들 또한 domain-cvi를 의존하며, 의존성이 엄청나게 겹쳤던 것이에요!!!

전체 모듈의 모듈 관련 의존성을

# app-api-cvi
dependencies {
    implementation(project(":common-cvi"))
    implementation(project(":domain-cvi"))
    implementation(project(":domain-cvi-oauth-service"))
    implementation(project(":domain-cvi-publicdata-service"))
    implementation(project(":domain-cvi-scheduler"))
    implementation(project(":domain-cvi-aws-s3-service"))

혹은

# domain-cvi
dependencies {
    compile(project(":common-cvi"))
    compile 'org.springframework.boot:spring-boot-starter-data-jpa'
    runtimeOnly 'com.h2database:h2'
    runtimeOnly 'mysql:mysql-connector-java'
    implementation 'org.hibernate.validator:hibernate-validator:6.2.0.Final'

이렇게 바꿨어요.

정리

그렇다면, 차이점이 뭘까요?
클라이언트 모듈 A(app-api-cvi), 의존 모듈 B(domain-cvi)라 정할게요.
A 모듈에서 B 모듈을 implementation으로 의존했다 가정하면(implementation(project(":domain-cvi"))),B 모듈만 의존한다는 것이에요.
만약 C라는 모듈이 A를 의존하려 하려 한다면, B 모듈을 가져오지 못해요.
즉, implementation이라 선언된 것은, 모듈 내에서만 의존해서 쓰고, 자신을 의존하려는 모듈에는 제공하지 않아요.

B 모듈 내의 의존성 (jpa)은 comile이라 선언되어 있어요. 이는, A 모듈이 B 모듈을 의존할 때, B 모듈은 jpa의존성도 제공해주겠다는 말이에요. (A 모듈은 B 모듈을 의존하며 JPA의존성도 사용할 수 있다. )

정말 어려웠어요... 지금까지 대충 의존성을 주입하려 했었어요(반성합니다 ㅠㅠ)
compile과 implementation의 차이를 알아가게 된 계기라 생각해요.
testFixure의 자세한 내용은 꼭 공식문서를 통해 확인해주세요 :)

Refer

https://docs.gradle.org/6.8.3/userguide/java_testing.html#sec:java_test_fixtures

https://bottom-to-top.tistory.com/58

[HTTPS] 클라이언트와 서버가 HTTPS 프로토콜에서 통신할 때 CA 동작과정

검프 — Wed, 20 Oct 2021 16:19:04 +0900

인증 기관(Certificate Authority, CA)은 디지털 인증서를 발행하는 주체예요.

사용자가 접속한 사이트가 유효한 사이트인지 확인하는 역할을 해요.

동작과정 (그림 위주)

인증기관(CA)에 사이트 정보, 공개키 전달

먼저 사이트는, 사이트 인증서(인증기관이 사이트에게 발급해주는 문서)가 필요해요.
이를 발급받기 위해 인증기관에게 사이트 정보와, 사이트 공개키를 전달해요.

데이터 검증

인증기관은 전달받은 데이터를 검증해요.

서명(암호화)

성공적으로 검증을 완료하면. 사이트 인증서 발급을 위해 인증기관의 비공개키로 서명(암호화)해요.

인증서 전달

서명이 완료되면, 사이트 인증서가 생성이 되고, 생성한 인증서를 사이트에게 전달해요

인증된 사이트

인증된 사이트가 되었네요!

인증기관 공개키 요청

클라이언트의 웹 브라우저에는 인증기관에서 발급한 인증서가 신뢰할 수 있는지를 확인하기 위해 '신뢰할 수 있는 인증서'(공개키)가 미리 등록되어 있어요.
여기까지는, 아직 클라이언트가 사이트에 접속 요청을 보내기 전이에요.

사이트 접속요청

사용자가 사이트에게 접속 요청을 보내면, 사이트는 자신이 신뢰있는 사이트임을 증명하기 위해 사용자에게 사이트 인증서를 전달해요.

인증서 복호화

사용자는 브라우저에 내장되어 있는 인증기관 공개키로, 사이트 인증서를 복호화 해서 검증해요.
사이트 인증서를 해독하면, 사이트 정보와 사이트 공개키를 얻을 수 있어요.

대칭키 생성 (g^A mod p)

사용자는 자신의 비공개키 A로 대칭키(g^A mod p)를 생성해요. 이때 사용하는 알고리즘은 디피-헬만 알고리즘이에요.
생성한 대칭키와 자신의 공개키를 사이트 공개키로 감싸요.

대칭키, 공개키 전달

이렇게 사용자가 사이트 공개키로 감싸진 정보를 사이트로 보내면, 사이트는 자신의 비공개키 B로 사용자에게서 받은 정보를 복호화해요.
사이트는 사용자의 대칭키, 사용자 공개키를 얻어요.

대칭키 생성 (g^B mod p)

사이트도 사용자와 마찬가지로, 자신의 비공개키 B를 이용해서 대칭키(g^B mod p)를 만들어요.
생성한 대칭키와 자신의 공개키를 사용자 공개키로 감싸요.

대칭키, 공개키 전달

사이트는 사용자 공개키로 감싸진 대칭키와 자신의 공개키를 사용자에게 전달해요.

대칭키 할당

이제 사용자, 사이트는 각각 사이트의 대칭키(g^B mod p), 사용자의 대칭키(g^A mod p)를 가지게 되었네요!

새로운 대칭키 생성(g^AB mod p)

사용자는 개인키 A를 사용해서 대칭키 g^AB mod p를 생성하고, 사이트는 개인키 B를 사용해서 대칭키 g^AB mod p를 생성합니다.
A와 B는 새로 생성한 이 대칭키로(g^AB mod p)를 정보를 교환해요.

새로운 대칭키에 의한 정보 전달

각각의 비공개키로 만들어진 대칭키라, 안전한 정보 교환이 가능하겠네요!

질문 - 대칭키가 해커에 의해 해킹 당할 확률은?

이는 우테코 3기 크루, 다니가 설명해준 것으로 마무리 할게요. 현재 제 안목에서 가장 명확하다 생각이 드네요 :)

Refer

[JUnit5] @ParameterizedTest 애노테이션(반복 테스트) 커스텀 하기

검프 — Wed, 20 Oct 2021 01:28:45 +0900

반복 테스트(ParameterizedTest)에 대한 출력을 통일성 있게 하고싶어 아래와 같은 옵션들을 지정했어요.

@ParameterizedTest(name = "{displayName} {index}, args = {arguments}")

@DisplayName("사용자 생성 - 성공")
@ParameterizedTest(name = "{displayName} {index}, args = {arguments}")
@ValueSource(strings = {"ㅁㅇㄹㅁㅇㄹ", "ㅓㅓㅓㅓ", "adfdf", "검프", "검프23213"})
void save(String name) {
...
}

테스트 출력시

위와 같이 나오며, "반복 테스트의 이름, 실행 번호, 파라미터"와 같은 형식으로 나오게 했어요.
정말 좋은데, 이러한 형식을 사용하기 위해 @ParameterizedTest를 사용하는 모든 곳에 위와 같은 옵션을 줘야해요.

귀찮지 않나?

맞아요. 테스트가 한 두개면 모르겠는데, 100개 이상인 반복 테스트에서 일일이 위와 같은 형식으로 작성하는 것은 문제가 있어요.

애노테이션 선언 (테스트 폴더에서)

#test/java/com/cvi 
package com.cvi;

import org.junit.jupiter.params.ParameterizedTest;

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Target({ ElementType.ANNOTATION_TYPE, ElementType.METHOD })
@Retention(RetentionPolicy.RUNTIME)
@ParameterizedTest(name = "{displayName} {index}, args = {arguments}")
public @interface CustomParameterizedTest {
}

커스텀한 ParameterizeTest를 만들었어요.

자세히 보면, 선언 위치는 애노테이션 타입과, 메소드에서, 실행시점은 런타임 시간에 작동하기로 선언하고, @ParameterizedTest와 옵션을 함께 정의했어요.

이게 되는 이유는 JUnit5에서 애노테이션을 조합하여 커스텀한 애노테이션을 만들 수 있게 지원하기 때문이에요.
여튼 이제, 반복 테스트 즉, @ParameterizedTest를 사용하는 곳에서는 동일한 출력을 보장할 수 있게 됐어요

@DisplayName("사용자 생성 - 성공")
@CustomParameterizedTest
@ValueSource(strings = {"ㅁㅇㄹㅁㅇㄹ", "ㅓㅓㅓㅓ", "adfdf", "검프", "검프23213"})
void save(String name) {
...
}

[MYSQL] 한글 별칭(aslias) 예외

검프 — Fri, 8 Oct 2021 14:12:01 +0900

문제상황

https://www.w3schools.com/sql/trymysql.asp?filename=trysql_func_mysql_concat 에서 쿼리를 조작하여, 그림과 같은 결과를 얻고 싶었어요.

쿼리를 아래와 같이 짰을 때

SELECT p.ProductID as '상품 아이디', p.ProductName as '상품이름', sum(od.Quantity) as sum
FROM Products as p
JOIN OrderDetails as od on p.ProductID = od.ProductID
GROUP BY od.ProductID HAVING sum >= 200
ORDER BY sum desc;

아래의 결과가 나오게 돼요.

"sum" 부분을 "총수량"으로 바꾸고 싶어서 아래와 같이 작성을 했는데,

SELECT p.ProductID as '상품 아이디', p.ProductName as '상품이름', sum(od.Quantity) as '총수량'
FROM Products as p
JOIN OrderDetails as od on p.ProductID = od.ProductID
GROUP BY od.ProductID HAVING '총수량' >= 200
ORDER BY '총수량' desc;

동일해 보이는 로직처럼 보이지만 결과는 처참해요. ㅠㅠ

해결법

https://dev.mysql.com/doc/refman/8.0/en/problems-with-alias.html MYSQL의 공식 문서를 살펴보니, 별칭을 지정하는 곳에서는 작은 따옴표(')를 이를 이용하여 로직을 사용하는 곳에선 백틱(`)를 사용해야 한다고 하네요.
그렇지 않으면 문자열 리터럴로 파악을 한다고 합니다!

즉, 아래와 같이 작성을 해야

SELECT p.ProductID as '상품 아이디', p.ProductName as '상품이름', sum(od.Quantity) as '총수량'
FROM Products as p
JOIN OrderDetails as od on p.ProductID = od.ProductID
GROUP BY od.ProductID HAVING `총수량` >= 200
ORDER BY `총수량` desc;

아래와 같이 제대로 된 로직이 실행이 돼요!

결론

MYSQL 공식문서에 에러에 대한 부분이 잘 정리되어있네요 ㅎㅎ
역시 공식문서가 최고..!

경험의 연장선

ozh 테마 적용 안될 시 설정 방법

변수명 검색 사이트. 전세계 Github repo에서 검색하기

개요

[Git] macOS에서 Github 계정과 GitLab 계정을 폴더(Directory)별로 사용하자

GitConfig 설정

파일 수정

파일 수정 예시

.gitconfig-woowa 파일 수정

.gitconfig-woowa 파일 수정 예시

Access Token 발급

GitHub Access Token 발급

GitLab Access Token 발급

Mac에 Credential 등록

credential-osxkeychain 확인

keychain 등록

직접해보기

woowa 폴더내의 레포지토리

woowa 폴더에 포함되지 않는 레포지토리

끝!

2021년의 기억

기억하고 싶은 것

적당히 유지한 커밋

블로그 포스팅 70개

우아한테크코스 과정

우아한형제들 입사

아쉬웠던 기억

‍ 급하게 결론을 내리자면

[Java] Java8과 Java11의 특징

정리

기능 추가

1. String 클래스, 메서드 추가

2. File 클래스, 메서드 추가

3. 컬랙션 인터페이스, 메서드 추가

4. Predicate 인터페이스, static not 메서드 추가

5. 람다에서 로컬 변수 Var 사용

6. HTTP Client

7. Nest-Based Access Control

8. 자바 파일 실행

성능향상

1. 동적 클래스 파일 상수

2. 개선된 Aarch64

3. 새로운 GC

4. JFR

Removed

1. Java EE and CORBA

2. JMC and JavaFX

Deprecated

1. Nashorn JavaScript engine

2. Pack200 compression scheme for JAR files

Java8의 사용이유

1. 외부 개발 툴과의 연동성

2. Java 11에서의 변경사항이 크게 없음

[Java] Java API 생성자 구현 및 검증 방식 (String, BigDecimal)

그냥 쓰는 것이 아닌, 알고 쓰자.

자바 버전

목차

String은 어떻게 검증되어 생성될까?

클래스 선언 및 인스턴스 변수 확인

생성자 확인

생성자 구현 로직 확인

String pobi = "포비" 는 어떻게 동작하는거지?

검증은 어떻게?

BigDecimal은 어떻게 검증되어 생성될까?

클래스 선언 확인

생성자 확인

생성자 구현 로직 확인

논의해볼 부분

7개월 후의 늦은 결론

[SpringBoot] 멀티모듈 구조에서, 다른 모듈의 테스트 클래스 사용하기

TestFixutre 적용

예외의 이유

정리

Refer

[HTTPS] 클라이언트와 서버가 HTTPS 프로토콜에서 통신할 때 CA 동작과정

동작과정 (그림 위주)

인증기관(CA)에 사이트 정보, 공개키 전달

데이터 검증

서명(암호화)

인증서 전달