행복한디벨로퍼

스프링부트 사용하면서부터 RestTemplate을 많이 사용하여 API개발을 해왔었다.

하지만 최근에 알게된 사실은 블로킹 API로 리액티브 기반의 애플리케이션에서의 성능을 떨어트리는 원인이 될 수 있다는 걸 알게 되었다. 또한 Spring5.0버전부터는 RestTemplate은 유지모드로 변경되고 향우 deprecated될 예정이라고 한다.

따라서 대안으로 Spring에서는 WebClient사용을 권고하고 있으며 다음과 같은 장점이 있다.

• Non-blocking I/O
• Reactive Streams back pressure
• High concurrency with fewer hardware resources
• Functional-style, fluent API that takes advantage of Java 8 lambdas
• Synchronous and asynchronous interactions
• Streaming up to or streaming down from a server

WebClient에 대한 자세한 사용법에 대해서 알고 싶다면 아래의 블로그 글을 참고하자.

medium.com/@odysseymoon/spring-webclient-%EC%82%AC%EC%9A%A9%EB%B2%95-5f92d295edc0

스프링공식문서

www.baeldung.com/spring-webclient-resttemplate

최근 읽고 있는 '자바 최적화'라는 책을 보다가 몰랐었던 내용이 있어 기록할겸 남겨본다. 

자바7 이전 리소스 사용후 닫는 것은 온전히 개발자의 몫

    public void readFirstLineOld(File file) throws IOException {
        BufferedReader reader = null;
        try {
            reader = new BufferedReader(new FileReader(file));
            String FirstLine = reader.readLine();
        } finally {
            if (reader != null) {
                reader.close();
            }
        }
    }

자바7 부터 언어 자체에 추가된 try-with-resources 생성자를 이용하면 try키워드 다음의 괄호 안에 리소스(AutoCloseable 인터페이스를 구현한 객체만 가능)를 지정해서 생성할 수 있다. 이로써 try 블록이 끝나는 지점에 개발자가 close() 메서드 호출을 깜빡 잊고 빠뜨려도 자동으로 호출된다. close() 메서드는 방금 전 예제와 똑같이 호출되고 비지니스 로직의 예외 발생 여부와 상관없이 무조건 실행된다.

    public void readFirstLineOld(File file) throws IOException {
        try( BufferedReader reader = new BufferedReader(new FileReader(file))) {
            String FirstLine = reader.readLine();
        }
    }

코드가 훨씬 심플해졌다. 하지만 try-with-resources 생성자 사용시 자동으로 close() 를 호출해주는 것을 몰랐다면 finally 코드를 생성해 그 안에서 또 close를 호출하려고 하였을거다...

위의 예에서는 catch(IOException exception) {} 과 같이 별도로 에러처리를 안해주고 그냥 상위로 exception을 그냥 던져버리는데 사실 좋지 않다. 항상 에러 발생시 catch 내부에서 잡고 로깅해주고 처리해주는 것이 좋다.

이번 포스팅을 하며 느낀점은 기본에 좀 더 충실한 공부가 필요할 것 같다.

자바 스트림 Skip 사용시 java.lang.IllegalArgumentException: -number 형태의 에러가 나는 이유는

skip 메서드의 인자로 0보다 작은 값이 들어 갔기 때문이다.

따라서 어떤 수치를 계산해서 skip에 인자를 전달하고 있다면 해당 값이 0보다 작지 않은 지 확인해보자.

Upper of POI 3.x Version, cell fill color is set as follows

setFillBackgroundColor (x)

setFillForegroundColor (0)

자바 엑셀 파일 배경색이 계속 검정색이거나 안바뀔 때는 setFillForeGroundColor대신 setFillForeGroundColor를 사용하자. POI 3.x윗 버전부터는 ForegroundColor를 써야 바뀌는듯....

        CellStyle styleBlueColor = workbook.createCellStyle();
        styleBlueColor.setFillForegroundColor(IndexedColors.CORNFLOWER_BLUE.getIndex());
        styleBlueColor.setFillPattern(FillPatternType.SOLID_FOREGROUND);

        cell = row.createCell(0);
        cell.setCellStyle(styleLimeColor);
        cell.setCellValue("인보이스번호");

프론트쪽을 개발하다가 최근에 버그를 발견하고 포스팅 남겨본다.

            var endDate = new Date(date).getTime();
            var now = new Date().getTime();
            var diff = parseInt((endDate-now)/(24*3600*1000));

            //if ((!Object.is(diff, -0)) && (diff <= 7)) {  => 이게 맞는방식
            if ((diff >= 0) && (diff <= 7)) {   => 버그 생성 방식
                return true;
            } else {
                return false;
            }

위의 코드는 두 날짜를 비교하는 코드이다.

diff는 두 날짜의 차이를 숫자로 나타내 주는데 현재 날짜가 endDate보다 크다면 -0을 반환하게 된다.

만약 위와 같이 diff가 0보다 클 경우라고 조건을 주게 되면 -0일 경우 포함이 안될거라고 생각하지만....그렇게 생각한다면 경기도 오산이다.

자바스크립트에서는 다음과 같이 0과 -0이 같다고 생각한다.

따라서 값을 비교할 때는 위의 코드에서 주석처리된 것과 같이 처리해주어야 한다.

자세한 설명은 아래의 stackoverflow의 글을 참고하도록 하자

stackoverflow.com/questions/7223359/are-0-and-0-the-same

객체를 복사 할 때 단순하게 '=' 연산자로 값을 주입하게 되면 얕은복사(Shallow Clone)가 이루어진다.

예를 들어, a객체가 있고 b 객체가 있을 때 b=a라고 주입하고 a 값을 변경하여도 우리는 b는 기존 a값을 가지고 있을거라 생각한다.

하지만 b도 변경된 a값과 동일하게 변경되게 된다.

따라서 자바스크립트에서 객체의 값을 복사할 때는 깊은 복사(Deep Clone)이 되도록 해주어야 한다.

b = JSON.parse(JSON.stringify(a))

와 같이 JSON 객체의 메소드를 이용하여 깊은 복사가 되게끔 해주자.

JSON.stringify는 자바스크립트 객체를 먼저 JSON문자열로 변환시키고 JSON.parse는 JSON문자열을 자바스크립트 객체로 변환시킨다.

JSON문자열로 변환했다가 다시 객체로 변환하기에 기존 객체에 대한 참조가 사라져 깊은 복사가 이루어지게 된다.

text 타입으로 되어 있는 컬럼에 데이터를 insert하려고 하자 다음과 같은 에러가 발생하였다.

Data truncation: Data too long for column

보통 텍스트형태의 데이터를 넣어봤자 500자 이내였기 때문에 이런 경우를 접해보지 못했는데 이번에 경험해보고 MYSQL의 text타입이 몇 글자 제한인지 알게 되었다.

TINYTEXT
- 범위 : 최대 255 글자

TEXT
- 범위 : 최대 65535 글자

MEDIUMTEXT
- 범위 : 최대 16777215 글자

LONGTEXT
- 범위 : 최대 4294967295 글자

65535글자면 왠만한 텍스트 데이터는 다 커버칠 것 같다.....LONGTEXT로 컬럼 type을 변경하여 처리하였다.

Solution => column type : TEXT -> LONGTEXT

쿼리 수행시 다음과 같은 에러 발생

ERROR: Memory limit exceeded Instance 5240c598fffb12fd:813807e3a953de95 of plan fragment F00 of query 5240c598fffb12fd:813807e3a953de91 could not start because the backend Impala daemon is over its memory limit

문제해결

클라우데라 IMPALA -> 구성 -> 단일 풀 메모리 제한(default_pool_mem_limit) 변경

클러스터의 메모리에 맞게 설정해주면 된다.

오늘은 정말 인상 깊게 읽었던 포스팅 하나를 소개할까 합니다.

글의 제목은 '적당히 잘하는 개발자' 입니다.

한 번 쯤은 방문해 보셨을 법한 '자바캔'의 블로그를 운영하시는 최범균 님이 쓰신 포스팅입니다.

javacan.tistory.com/514#comment12490475

이 글을 읽으면서 정말 많은 부분 공감하였습니다.

물론 저는 처음부터 '굉장한 개발자', '기술적으로 엄청 뛰어난' 개발자가 되고 싶지 않았음에도 많은 부분이 와닿았습니다.

개발자로 살아간다는 건 끊임 없이 나오는 IT기술들과 지식들을 습득하며 살아감을 의미합니다.

이렇다보니 어느 순간 '개발자로써 뒤쳐지면 어쩌지'라는 압박감을 가지고 살아가는 것 같습니다.

그리고 어느 순간 실력이 늘어나는 시점이 왔을 때 '와 나정도 실력이면 괜찮지'라는 생각이 들었다가 좀 더 다양한 경험들을 하며 공부를 하다보면 그런 생각을 했던 제 자신이 부끄럽게 여겨지는 시기도 오는 것 같습니다.

벼는 익을수록 고개를 숙인다는 말이 있듯이 IT분야에서도 통용되는 것 같습니다. 공부를 하면 할 수록 경력이 쌓이면 쌓일 수록 어느 한 편에 나도 모르는 불안감에 '모르는게 너무 많다'라는 생각이 듭니다.

하지만 제 생각엔 그렇습니다.

IT분야는 정말 광범위합니다. 한 사람이 그 모든 것을 잘 할 수 없습니다. 우리의 삶은 한정적이기에 굳이 지금 당장 필요하지 않은 것들을 습득하기 위해, IT 다양한 분야에서 뛰어난 개발자가 되기 위해 여가시간 모두를 사용하는 것은 어쩌면 즐거운 삶은 아닐 것 같습니다. 

너무 많은 부담감을 조금은 내려 놓고 지금 내가 하는 일을 잘하기 위해 시간을 보내다 보면 어느 순간 '적당히 잘하는 개발자'가 될 수 있을 거라는 생각이 듭니다. 적당히 잘하는 것도 쉬운 일은 아닙니다.

물론 뛰어난 개발자, 기술력으로 손꼽히는 개발자가 되는 것이 좋지 않다고, 나쁘다고 말하는 것이 절대 아닙니다.

어떤 개발자가 되고 싶은지는 본인이 선택하는 것이라고 생각합니다. 적당히 잘하는 개발자로 삶의 다양한 부분들에도 관심을 가지며 살아갈 것인지 많은 개인 시간과 노력을 투자해 정말 한 분야의 인정받는 뛰어난 개발자로 살아갈 것인지는 각자의 선택의 몫이라고 생각합니다.

또 정말 공감이 갔던 문구는 '꽤 많은 프로젝트가 기술 난이도가 아닌 다른 이유로 실패하는 것을 경험했다'입니다.

저 또한 다양한 프로젝트들도 경험하고 개인적인 토이프로젝트도 함에 있어서 해당 서비스들이 실패하거나 운영이 중단되는 이유는 결코 기술적인 부분의 결핍이 아니였습니다. 기술은 정말 중요하지만 서비스가 잘 돌아가기 위해 필요한 요소 중 하나라는 사실입니다. 높은 기술력 보다는 어쩌면 홍보나 마켓팅, 기획, 운영 등이 더 중요할지도 모릅니다.

어떤 개발자가 될 것인지? 이번 기회에 한 번 생각해보시면 좋을 것 같습니다.

youtu.be/GtJZTzJ2sxQ

긴 글 읽어 주셔서 감사합니다🙏