사내 사이드 프로젝트를 하던 도중 한글명을 갖는 파일들의 이름의 자음 모음이 분리되는 현상이 일어났습니다. 맥북이나 리눅스 노트북으로 확인하였을 때는 이상이 없었으나, 윈도우로 확인하였을 때 증상이 나타났습니다.해당 문제는 한글의 입력 방식의 차이로 인해 발생하는 문제

직렬화는 객체를 바이트 스트림으로 변환하는 과정을 말합니다. 이러한 바이트 스트림은 파일로 저장하거나 네트워크를 통해 전송할 수 있습니다. 자바에서는 Serializable 인터페이스를 구현하여 객체를 직렬화할 수 있습니다.역직렬화는 직렬화된 바이트 스트림을 다시 객체

사이드 프로젝트 Yaksok을 진행하면서 처음으로 RESTAPI를 기반으로 프론트앤드와 백엔드의 업무가 완전히 분리된 개발 경험을 하고 있습니다.모두 열정은 가득하지만 경험은 많지 않아 삽질의 연속이었는데 여태까지의 여정을 요약하면 아래와 같습니다.열정 가득한 우리는

회사에서 운영 테스트 중 캐시에 대한 문제가 대두 되었습니다. 캐시가 클라이언트들의 브라우저에 저장 되어있어 최신 소스로 재배포 해도 좀 처럼 반영이 되지 않았고, 고객들에게 캐시 비우기 및 강력 새로고침을 방법을 알려주는 메뉴얼을 배포하여하는 해프닝이 벌어졌습니다.&

@RequestPart와 @RequestParam은 Spring Framework에서 파일 업로드를 처리하는 데 사용되는 두 가지 주요 어노테이션 입니다. @RequestParam이 파일 전송이 가능할 것이라는 생각은 처음에 하지 못했습니다. 왜냐하면, get방식 처럼

스프링 부트의 파일 자동 스캐닝 기능을 오해하여 헤매는 경험을 하였습니다. 설정에 따른 정확한 기능과 차이를 기록해주려고 합니다우선 잘못 알고 있었던 것은 자동 스캐닝은 .properties 파일을 자동으로 스캐닝 하는 것이 아닌 application.properti

우선, 애노테이션은 애노테이션 자체로서는 주석 그 이하도 이상도 아님을 알아야 합니다. 단, 일반적인 주석과 달리 그 대상이 컴퓨터가 읽는 주석이라고 생각하면 되는 부분입니다.애노테이션에서 @Retension은 애노테이션의 유효한 범위를 알려줍니다. 즉, 스코프 설정

git이라는 툴이 그냥 사용하다 보면 익혀지지 않을까라는 생각으로 몇차례 사용해보았습니다. 그러나 좀처럼 git이라는 툴에 대한 이해도는 올라오지 않았고, 사내 프로젝트는 SVN을 사용하다 보니 Git과는 더 멀어졌다는 위기감을 느끼게 되었습니다.해서 본격적으로 git

HTTP 메서드의 PUT과 DELETE를 Tomcat과 Apache 서버에서 차단해달라는 요청이 있었습니다.우선은 나름의 근거를 제시해왔고, 제작된 제품도 PUT, DELETE 메서드가 필수적인 RESTAPI방식이 아닌 SOAP 방식이었으므로 차단할 수 있는 설정을 추

회사에서는 SVN을 사용하다보니 git을 사용할 기회가 점차 적어졌습니다.그러다가 다음 프로젝트에서 사용할 표준을 만드는 과정에서 git을 적극적으로 도입하는하게 되었습니다.이전에 git을 사용한 적은 있지만 본격적으로 이해해서 사용하기보다는 야생적으로 그때그때 휘뚜루

물건을 찾을 때, 그 물건이 있을 수도 있고 없을 수도 있는 상황을 생각해보면 Optional<T>를 쉽게 이해 할 수 있습니다. 물건을 찾을 때, 해당 물건이 있으면 "여기 있어요"라고 말하고, 없다면 "죄송하지만 없네요"라고 말할 수 있습니다. Optional

특징:Spring Framework의 의존성 주입 방법 중 하나입니다.유연성이 높고 선택적인 의존성 처리가 가능합니다.객체 생성 후에도 의존성을 변경할 수 있습니다.예시:특징:Lombok 라이브러리의 기능으로 생성자를 자동으로 생성합니다.모든 필드를 파라미터로 받는 생

이 개념들은 여러 개의 함수/메서드가 있는 환경에서 각각의 함수/메서드를가 시행 될 때, 상호 간의 어떤 관계를 가질지에 대한 부분입니다.호출 되는 함수의 작업 완료 여부를 확인 합니다.작업이 완료 될 때까지 기다립니다메서드 A가 메서드 B를 호출 하였을 때, 메서드

DTO는 기본적으로 자료구조라고 하였습니다. 그렇다면 getter/setter를 사용하지 않고 각각의 필드 값에 직접적으로 접근하는 것이 더 맞는 방향성이 아닌가? 라는 질문이 생겼습니다.DTO에서 Getter/Setter를 사용하는 이유는 아래와 같습니다.getter

아래의 저장소들을 connectionless와 stateless를 지향하는 HTTPS 통신 프로토콜의 한계를 보완하기 위해 나온 것들입니다. 즉, 서버가 각각의 클라이언트들을 구별하고, 식별하기 위해 데이터를 저장하는 것입니다.서버에서 생성 후 클라이언트에서 관리허용

두 질문의 정확한 의미를 이해하고 해답을 찾기 위해서는 먼저 어떤 조건에서라는 전제가 매우 중요해 보입니다. 토비의 스프링 3.1 vol.1의 후반부에 아키텍처에 대해 설명하는 부분에서 저는 나름의 해답을 찾은 것 같습니다. 데이터 중심 아키텍처와 오브젝트 중심 아키텍

Mybatis에서 \\처음에는 DB 매니저 프로그램을 사용해서 값을 직접 입력해도 속도가 느리게 나와 문제의 원인을 발견하기 매우 어려웠습니다. ${} 사용하여 일부 쿼리가 생략되는 것 같은 이상 현상 때문에 소요시간이 줄어든 것으로 느껴졌기 때문입니다.그러다 혹시 몰

DI 다음으로 스프링에서 가장 강조하고 있는 개념은 테스트입니다. 테스트는 개발자로 하여 안정감을 갖을 수 있게 해줍니다. JUnit과 TDD 개념에서 언급 되듯이 코드를 수정했지만 발 뻗고 잘 수 있는 안정감 말입니다.하나의 프로그램 전체를 테스트하기란 사실상 불가

Robert C. MartinP.S. 클린코드 책에 대한 많은 사람들의 우려를 잘 알고 있습니다. 해서 맹신 하지 않고, 저자의 의도를 비판적으로 바라보려고 노력하고 있습니다.! 맹신하게 된다면 빠르게 변하는 개발 업계에서 잘못된 방식의 접근이 될 수도 있는 책인 것

프로젝트 내에 ServiceExecutor를 수정해보기로 했습니다.ServiceExecutor의 Outline은 다음과 같았습니다.필드 \- 로그인 정보 테이블에 대한 칼럼명 맵핑 \- RowType 초기값Autowired \- PasswordEncoder \-