일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- 메이븐
- gradle
- IOC
- 빌드툴
- 컴퓨터시스템
- Kotlin for Java Developers
- springwebmvc
- 토비의스프링3.1
- 클린코드
- beanfactory
- hibernate
- FunctionalInterfaces
- 프록시
- springboot
- ORM
- DesignPattern
- 링커
- lambda
- 자바
- 토비의스프링
- java
- JPA
- Spring
- ApplicationContext
- exception
- AutoConfiguration
- Immutable
- String
- DispatcherServlet
- 링킹
- Today
- Total
목록private note (17)
엔지니어로 가는 길
재능 있는 사람이란 개발과 관련된 지식 또는 능력을 다른 사람보다 빨리 습득하는 사람이라고 하고, 뛰어난 개발자를 다섯 손가락 안에 꼽히는 회사에서 일하는 개발자라고 가정한다면 재능 없는 사람도 뛰어난 개발자가 될 수 있다고 생각한다. 개발은 시험이나 대회가 아니다 정량적으로 점수를 매길 수도 없고, 참여자들을 변별하기 위해 누군가 억지로 만든 변별력 있는 문제를 풀어야 하는 것도 아니며, 언제나 정답이 정해져있는 것도 아니다. 개발은 현실의 문제를 해결하는 것이고, 때로는 효과적이고 효율적인 방식보다 빠른 방식이 정답일 때도 있고, 빠른 방식보다 효과적이고 효율적인 방식이 정답일 때도 있다. 따라서 좋은 회사는 개발자를 뽑을 때 정량적으로 점수를 매기는 것이 아니라 자신들이 정한 일정한 기준을 넘는 개..
Spring boot 버전을 올려보자 Spring boot 2.0을 사용 중인 프로젝트의 버전을 최신 버전으로 올려보려고 한다. 간단한 일은 아니겠지만 불가능한 일도 아니다. 수많은 문제를 끊임없이 만나게 될 텐데, 문제를 만나서 해결하거 live-everyday.tistory.com 담당하고 있는 프로젝트의 Spring Boot 버전을 2.0.1에서 2.7.6까지 올렸다. 위 글에서 Spring Boot 버전을 올려보고 싶다고 말하기는 했으나 이렇게 생각보다 빠르게 마무리될 줄은 몰랐다. 이 글에서는 Spring Boot 버전업 과정에서 만난 이슈를 정리하려고 한다. (버전을 올림에 따라 발생할 수 있는 모든 이슈가 아닌, 회사 프로젝트에서 발생한 이슈만 정리하였다.) 2.1.18 -> 2.2.13 A..
커리어적으로 예리하고 긴장된 상태란 쉽게 말해서 언제든 이직할 수 있는 상태를 말한다. 언제나 가슴에 이직을 품고 있어야 한다는 뜻이 아니다. 지금 회사가 아주 마음에 들고, 가능하다면 지금 회사에서 커리어를 끝까지 보내고 싶다고 하더라도, 오히려 그럴수록 더욱 커리어적으로 예리하고 긴장된 상태를 유지하려고 노력해야 한다고 생각한다. 예리하고 긴장된 상태를 유지해야만 1. 끊임없이 성장할 수 있다 2. 이직하고 싶은/이직해야 하는 상황이 찾아왔을 때도 걱정이 없다 3. 회사와 나를 대등한 관계로 여기며 당당할 수 있다 무뎌지지 말자. 더 나의 상태를 더 예리하게 만들자. 긴장을 놓지말자. 나는 더 잘할 수 있고, 지금의 조건보다 더 좋은 조건, 지금의 회사보다 더 괜찮은 회사는 항상 존재하며, 나만 준비..
아플 때마다 하는 말이지만 역시 건강이 최고다. 3년 정도 잘 피해 다니다가 최근에 코로나에 걸렸는데 꽤 아팠다. 목이 화상 입은 것처럼 아파서 바나나도 삼키지 못했는데 지금은 많이 좋아졌다. 우리에게 건강은 일반적으로 아주 좋은 상태로 주어진다. 건강한 것을 당연하게 여기고, 앞으로도 계속 좋을 줄로만 알고 건강을 소홀히 여기기 시작하면 언젠가 반드시 대가를 치르게 되어있다. 건강을 소홀히 해서 코로나에 걸린 것은 아니지만, 코로나로 간만에 아파봤으니 건강의 중요성을 다시 한번 깨닫고, 경각심을 가지는 기회로 삼으려고 한다. 지금 건강한 건 절대 당연한 게 아니다. 감사해야 할 일이다. 앞으로의 건강 또한 그냥 보장되는 게 아니다. 노력해야만 건강할 확률을 높일 수 있을 뿐이다. 나중에 돌이킬 수 없을..
* 한 두 달 전쯤 진행했던 업무 빌드 타임 30분 담당하고 있는 서비스에서 의존성을 추가하거나 수정할 때마다 30분이 소요됐다. 처음엔 '원래 그런가 보다' 하고 넘어갔는데, 해당 서비스에 대해 알게 될수록 30분은 너무 과하다는 생각이 들었다. 의존성을 하나 추가하거나 수정하는 아주 간단한 수정이었고, 프로젝트도 그렇게 거대하고 복잡하지 않은 데 너무 오랜 시간이 걸린다고 생각했다. 그러던 차에 의존성을 수정할 일이 있는 업무를 맡게 되었고, 빌드 타임부터 개선해보기로 했다. 원인이 뭘까 해당 서비스는 gradle 멀티 모듈 프로젝트였고, gradle 버전은 4.X였다. 처음에는 build.gradle 파일을 보며 빌드 타임이 느린 원인을 몇 가지 추측해보았다. - deprecated 저장소 - 불필..
여유롭지 않으므로 의식의 흐름대로 작성하고 나중에 수정하기로 한다. 사용자에게 알려야 하는 특정 이벤트가 발생하면 문자, 알림톡, 앱 push 등의 수단을 이용하여 사용자에게 해당 이벤트가 발생했음을 비동기적으로 알린다. 사용자에게 알림을 보낼 때 관련 알림 서비스의 이슈로 인해 알림을 보내는 데 실패할 수 있다. 예를 들면, 특정 클라우드의 문자 발송 서비스를 이용하고 있을 경우 우리 서비스가 아닌 해당 클라우드와 관련한 이슈로 인해 알림을 발송하는 데 실패할 수 있다. 이러한 예외는 얼마든 발생할 수 있고, 재발송을 시도하면 되기 때문에 예외에 대한 처리도 명확하다. 또한 알림은 핵심 로직이 아니기 때문에 알림이 실패했다고 해서 이후에 있는 작업이 진행되지 않는 것도 적절하지 않다. 이러한 이유로 알..
클린 코드에서 하나의 함수는 하나의 행동만 해야한다고 했다. 글도 마찬가지인 것 같다. 하나의 글에서는 하나의 주제만을 다루어야 한다. 최근에 글쓰기가 어렵게 느껴진 이유가 바로 주제를 확실히 정하지 않고 무작정 글을 쓰려고 했기 때문인 것 같다. 주제를 정하지 않았으니 글을 쓰다가 '이걸 주제로 할까?', '아 이걸 주제로 할까?', 왔다갔다 하면서 엉망이 되는 것이다. 코딩테스트 문제를 풀 때 풀이를 떠올리지 않고 손이 가는대로 풀다보면 엉망진창이 되듯, 글도 먼저 생각하지 않고 마구잡이로 써가다보면 글이 아니라 그냥 낙서가 되는 것 같다. 앞으로 글을 쓸 때는 그 글에서 무슨 말을 하고 싶은지, 분명하고도 간결한 하나의 주제를 정하고 글을 써야겠다.
오늘 / 당장 중요한 것 / 변할 수 있는 것 / 실용적인 것 대세 프레임워크는 시간이 흐름에 따라 얼마든지 바뀔 수 있다. 프레임워크의 사용법에 매몰되어 검색 없이 원하는 것을 바로바로 머릿속에서 꺼내 구현할 수 있도록 익히기만 한다면 당장의 생산성은 올라가겠지만, 미래의 생산성까지 보장되지는 않는다. (예를 들어, 대세 프레임워크가 바뀌게 되면 새로운 프레임워크를 익히는 데 많은 시간이 필요할 것이다. 프레임워크의 원리와 구현에 대해 알아야 해결할 수 있는 복잡하고 어려운 문제를 만나면 해결하는데 많은 시간이 필요할 것이다.) 내일 / 당장 중요하지는 않은 것 / 변하지 않는 것 / 원론적인 것 프레임워크가 풀고자 하는 문제는 시간이 지난다고 사라지지는 않는다. 새로운 프레임워크가 자신만의 방식으로 ..
Spring boot 2.0을 사용 중인 프로젝트의 버전을 최신 버전으로 올려보려고 한다. 간단한 일은 아니겠지만 불가능한 일도 아니다. 수많은 문제를 끊임없이 만나게 될 텐데, 문제를 만나서 해결하거나 또는 해결하지 못했다면 왜 해결하지 못했는지, 어디서 막혔는지를 잘 정리할 것이다. 최신 버전의 Spring boot를 사용하게 된다는 것은 결과이다. 어쩔 수 없는 이유로 당장 최신 버전을 사용하지 못할 수도 있다. 결과는 어쩔 수 없는 영역인데, 결과에 너무 집중하면 원하는 결과가 나오지 않았을 때 실망하게 된다. 이 일을 할 때는 Spring boot의 버전별 차이와 빌드툴에 대해 배우는 것을 목적으로 접근하려고 한다. 최신 버전을 사용할 수 있게 된다면 좋은 일이고, 그렇게 되지 않더라도 어디서 ..
기존 프로젝트에서 사용하고 있던 라이브러리나 프레임워크의 버전을 바꾸는 것은 간단한 일이 아니다. 하지만 JUnit5로 마이그레이션 하는 것은 예외인 것 같다. JUnit 4와 JUnit 5는 함께일 수 있다 https://junit.org/junit5/docs/current/user-guide/#migrating-from-junit4 JUnit 5 User Guide Although the JUnit Jupiter programming model and extension model do not support JUnit 4 features such as Rules and Runners natively, it is not expected that source code maintainers will need..