글쓰며 돌아볼 시간이 생겨서 간단하게 과정을 진행하며 들었던 생각을 기록하고자 작성합니다.1~3주차는 전반적으로 쉬웠고, Private 레포였던 4주차는 어려웠습니다. 초반에는 시험기간과 겹쳤고, 중후반부턴 동아리 프로젝트와 2박3일 해커톤과 겹쳐 회고할 시간을 만들기엔 힘들었습니다.당장 리팩토링할 시간도 없을 정도로 빠듯했기에 최대한 처음 짤 때, 제대로 짜자 라는 생각으로 고민하며 코드를 작성했습니다. 객체지향 프로그래밍정확히 2학년 때 학교 수업과 일치하는 이름입니다. 당시에는 배우면서 궁극적인 목표가 뭘까 잘 모르겠었는데, 오히려 이 프리코스에 이 이름을 붙여도 될 것 같습니다.왜 SOLID 원칙에 맞춰서 프로그래밍하고, 객체지향 생활체조 9원칙이 탄생하게 됐는 지 그 배경을 직접 손으로 알 수..
전체 글
이전 블로그 https://velog.io/@go_high/posts기능 외 요구사항프리코스에선 미션의 요구 사항이 다음과 같다. 과제 진행 요구 사항, 기능 요구 사항, 프로그래밍 요구 사항우선 과제 진행 요구사항에서 원하는 건 1. 마구잡이로 진행하지 마라, 문제를 해결하기 위해선 기능 분리와 정리가 우선되어야 한다.2. 과제의 버전 관리와 커밋명에 신경써라 라고 느꼈다. 또한 프로그래밍 요구 사항에선 JDK21 버전 환경과 우테코의 자바 코드 컨벤션을 지키는 것을 요구했다. 기능 요구사항앞선 요구사항에 맞춰 README에 구현 기능을 정리했다. https://github.com/seogwoojin/java-calculator-7/tree/seogwoojin GitHub - seogwoojin/java-calculator-7: 석우진_프리코스 1주차 레포입니다석우..
이 글을 작성하기에 앞서 인프런의 실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화 강의 | 김영한 - 인프런김영한 | 스프링 부트와 JPA를 활용해서 API를 개발합니다. 그리고 JPA 극한의 성능 최적화 방법을 학습할 수 있습니다., 스프링 부트, 실무에서 잘 쓰고 싶다면? 복잡한 문제까지 해결하는 힘을 길www.inflearn.com다음 강의를 수강하고 작성하는 것임을 알려드립니다. 관계형 데이터베이스의 핵심 중 하나는 테이블 간의 관계를 어떻게 정의할지에 있습니다. 이러한 관계를 명확히 설계하는 것은 데이터 모델링의 중요한 부분인데요.스프링 JPA는 테이블 간의 관계를 객체 간의 관계로 자연스럽게 변환해주는 도구입니다. 이번 글에서는 1:N 관계를 중심으로 JPA에서 이를 다..
이번에 동아리에서 기존 Nest로 작성된 Account-Server를 Spring+Kotlin으로 변경하는 프로젝트(같은 스터디)를 진행하게 됐습니다. 저는 현재 이 중에서도 특히 인증과 인가 담당한 파트를 전반적으로 담당하고 있습니다. 왜 스프링인가? 시작에 앞서 간략하게 나마 스프링으로 전환하려는 이유를 서술하겠습니다. 1. 유지보수 가능한 개발자가 많다. 저희 동아리의 메인 서버가 스프링+코틀린으로 작성된 만큼 스프링을 다룰 개발자가 많으며, 동시에 구인하기에도 용이합니다. 2. Nest를 쓸만큼 다중 요청이 많지 않다. 싱글 쓰레드인 Nest는 비동기 I/O 모델은 분명 I/O bound 작업에서 강한 만큼, I/O 작업이 주를 이루는 어카운트 서버 (WAS내 복잡한 연산 X)라는 점에서 ..
본격적으로 스프링 세큐리티 라이브러리를 이용하기 전에 러프하지만, 간단하게 인터셉트와 JWT 라이브러리, Redis를 이용해 OTP Code를 생성 -> 검증 -> 임시 Token을 발급하고, 이를 인증한 회원에게는 접근 권한을 발급하는 로직을 구현해보겠습니다. 스프링 부트 생성까지는 스킵하고 의존성 설정 부터 시작하겠습니다 implementation("io.jsonwebtoken:jjwt:0.9.1") implementation("javax.xml.bind:jaxb-api:2.3.1") implementation("org.glassfish.jaxb:jaxb-runtime:2.3.1") implementation("org.springframework.boot:spring-boot-starter-dat..
오랜만에 알고리즘을 풀었습니다.이런 류의 Union-Find 문제가 종종 보이길래 빠르게 포스팅합니다. 문제 접근이번 문제의 경우 처음부터 알고리즘을 보고 풀었습니다.. 클래스 5의 문제들 중 비트마스킹이 너무 많습니다.이분탐색, 분리집합 스타트였다는 점 참고해주세요. 우선 풀면서 '공항' 문제와 매우 유사함을 느꼈습니다. 이진탐색인데 뭔가 체킹을 필요로 하는?(기존에 이 문제 못풀었습니다) 시간 단축의 핵심은 Target K 숫자보다 큰 수 중 가장 작은 수를 이진 탐색으로 간단히 찾고그 수가 아직 사용하지 않은 수면 좋겠으나만약 사용된 경우에는 그 수보다 큰 수들 중 사용되지 않은 가장 작은 수를 빠르게 찾는 것에'분리 집합' (Union Find) 알고리즘을 사용하는 것이라고 생각했습니다. 한칸씩..
Docker를 사용한 배포를 직접 해보면서 뭔가 이미지 파일들과 도커 허브를 잘 이용하면 자동화된 배포가 가능할 것 같았습니다. 기존에는 프로젝트를 진행하면서, 배포에 많은 시간을 사용했습니다. Main Branch에 Merge를 하면 WAS가 올려진 서버에 직접 SSH 접속해 이를 다시 받아오고, DB 변경 사항이나 배포용 환경설정에서의 Conflict 등을 직접 다룬다는 게, 프로젝트의 핵심이 되는 비지니스 로직에만 집중하지 못하고, 자꾸 밖으로 힘이 샌다는 느낌이 강하게 들었습니다. 변경 사항을 직접 테스트하고 빌드하고 이를 EC2 서버에 Deploy하는 과정을 한번에 해준다... 정말 멋진 자동화 프로세스입니다. 개발자는 항상 효율을 따지는 사람들 인 것 같습니다. 결과적으로 전부터 쭉 궁금했..
1. 마구잡이식 개발에서 벗어나자 기능 요구사항 분석 -> ERD 설계 -> ERD에 맞춰 Entity 설계 -> Repository, Service 구현 -> 구현 사항 테스트 -> 프론트엔드 연결 2. 영속성 컨텍스트 내부 객체는 한 트랜잭션이 커밋될 때, 더티 체킹을 통해 알아서 DB에 수정사항이 반영된다.(장고 orm에서는 가져온 객체를 수정하더라도 post.save()와 같이 반영을 해줘야 했는 데, JPA에는 Dirty Checking 기능이 있어서 그렇다!, 꽤나 똑똑한듯) +) 자체적으로 merge 하는 방법보다 이 JPA의 변경감지 기능을 사용하는 설계가 옳다. 처음부터 준영속 객체를 생성하지 말고, 영속 객체를 DB에서 꺼내오는 식으로 3. 엔티티 클래스에서 자체적으로 비지니스 로직을 ..