아장아장거리면서 주책부리는 블로그

지금까지 있었던 일들을 정리해보자면, 1. 모니터가 수명을 다했다 2. 구글 코딩테스트를 보았다. 문제를 정확하게 이야기 할 순 없어서 솔직하게 모든 것을 이야기할 순 없다. 1번의 경우, 문자열 관련해서 구현하는 문제였다. 구글은 생각보다 케이스가 많이 나왔다. 그래서 그런지 이런 저런 경우들을 다 생각해 볼 기회가 있었다. 모든 경우에 맞게 코드를 만들어내긴 한 것 같다. 2번의 경우, 경우의 수들을 고려해서, 가능한 최소값의 경우를 구해야 한다. 사실 모든 테스트케이스에 대해서 구현하진 못했다. 이걸 어떻게 처리하는게 좋을까 곰곰히 생각해보았지만 당시에는 이렇다할 최적의 방식을 찾지 못했다. 백트래킹으로 경우들을 만들어낸 후, 이 경우에 대한 값을 만들고 이 값중에 최소값을 구하는 방식인데, 경우를..

소스코드 : https://github.com/JangAJang/the-orient-of-Object-Orientation/tree/main/chapter2 딱 한줄로 2장의 소감을 말하자면, 1장에서 던진 추상적인 질문에 대해서 하나씩 자세한 예시를 들어주는 느낌이었다. 1장은 하나의 큰 화두를 던져준다면, 2장에서는 자세한 썰을 푸는 느낌이다. (진짜 고급진 단어만으로 글을 쓰고싶지만, 내 블로그는 그런 곳이 아니라고 생각된다 하핳) 일단 앨리스부터는, 조금 더 실제 실행시킬 수 있는 모양새의 프로젝트를 만들어보려고 노력했다. 객체지향 생활 체조?도 해보면서 객체지향적인, 클린한 코드 만들기를 습관화를 하려고 노력을 하는 중이다. 로마는 하루에 안만들어지니까, 일단은 뭐다? 앨리스라는 객체가 있다. ..

소스 코드 : https://github.com/JangAJang/the-orient-of-Object-Orientation/tree/feat/Chapter2 객체지향에서는 모든 객체를 위주로 일이 돌아간다는 이야기는 자주 들었다. 그러면 그 일이 어떻게 돌아가는지, 그리고 내가 만든 코드에서 어떻게 이루어져야 조금 더 객체지향적인 결과가 이루어질지 생각해보았다. 일단, 책에 적힌 이론들을 이해해보자. 객체지향 프로그래밍에서는 객체가 스스로 생각하고 결정하게하는, '캡슐화'가 이루어진다. 이를 통해 객체에 자율성이 부여된다. 이렇게 자율성이 있는 객체들이 협력하는 관계를 가지고, 이 관계 안에서 메시지로 소통을 한다. 객체 ---(협력이라는 관계)--- 객체 이 관계에서 각 객체는 메시지를 통해 소통한다..

어제부터 '객체지향의 사실과 오해' 에 관해 동기들끼리 스터디를 하기로 했다. 그 전에 잡담을 하면서 서로의 코드를 리뷰해보고 있었는데( 이거 말고도 보통의 남자들끼리 모이면 하는 그런 이야기도 많이 한다.) 로그인을 위한 validate로직을 보면서, 왜 이렇게 만들었으며 더 나아가 getter를 지양하는게 어떤 방향인지 이야기하게 되어 정리해보려고 한다. 물론 내 코드도 정답은 아니고, 어쩌면 오답에 더 가까운 코드일 수 있다. 하지만, 그런 부분을 짚어주면서 보는 사람이 있다면 나는 이 글을 통해 더 공부하는 거니까 정확한 당시 동기의 코드를 가져오진 않았지만, 당시에 기억나는 대로 똑같이 작성해보았다. 이 부분에 대해서 더 많은 예시와 설명을 위해 대략 20~30분 정도를 사용했던 것 같다. 사실..

2023년 1학기 캡스톤 디자인 프로젝트를 하면서, 다른 동기가 있는 조에서 dto마다 인스턴스들을 초기화시키는 생성자가 있어야 하는 이유는 너무 당연한데, 도대체 인스턴스 없이 만드는, NoArgsConstructor가 왜 존재해야 하는가를 궁금해했던 적이 있었다. 우리 조원들에게도 그 부분에 대해 알까 싶어 물어봤지만, 모른다는 이야기를 들었다. 그래서 이에 대해 정리를 해보려고 한다. 일단, JPA의 특성중에 프록시와 지연로딩에 대해서 먼저 알고오면 쉽다. 프록시는 엔티티를 상속받아 정의된다. 프록시에서는 실제 엔티티와 같은 인스턴스들이 초기화되지 않고 만들어지게 된다. 인스턴스 없는 생성자가 무엇일까? 그게 NoArgsConstructor이다!!!(이렇게 블로그 내용 돌려막다 보면 언젠가는 링크만..

캡스톤을 하다가, 한 동기가 질문했던 부분을 블로그에 남겨보기로 했다. 일단 받은 질문을 간단하게 요약하자면, 스프링은 자바로 동작한다. 자바에서는 에러가 발생하면, RuntimeException(이놈 말고도, IllegalArgumentException처럼 extends RuntimeException을 받는 녀석들이 있다)으로 발생하는 예외들은 분명 러닝과정에서 빨갛게 예외가 발생했다고 뜬다. 근데 이렇게, Response를 이용해 Exception에 대해 뭐시기를 해주는게 의미가 있는가? 였다. 일단, 이러한 유튭..아니 블로그각을 만들어준 동기에게 감사하고 정리를 조금 해봐야겠다. 테스트를 위해 하나의 예외를 집어넣어 실행을 시켜보았다. 이 상태에서, 실행을 시키고 해당 컨트롤러 uri를 요청하면,..

일단 3줄 요약으로 지금까지의 일들을 정리해보자. 우테코(프리코스 후 탈락), 소마(2차코테에서 탈락)를 떨어졌다. 구글인턴십은 코테를 보았지만 이후의 일정은 들은게 없다 게시판 백엔드를 만들고있었다. 기본적인 CRUD를 위한 더 많은 기능들을 공부했지만, 이후에는 이를 반복하게 되는 것 같았다. 개강을 했다 이젠 학교의 공부를 하면서, 다른 것들을 더 공부해야겠다는 생각이 들었다. 이번 학기에 캡스톤디자인? (쉽게말하면 졸업작품) 을 해야하는데, 이걸 웹서비스로 만들어봐야겠다는 생각이 들었다. 그렇다면, 서비스를 만들기 위해 필요한 것이 무엇일까? 프론트엔드를 할 줄 모른다. 물론 현업에 나가서는 백엔드 취업을 하기 위해 노력해야겠지만, 그렇다고 프론트를 하나도 모르고, 혹은 좋코딩처럼 "html은 할..

http.exceptionHandling() .authenticationEntryPoint(jwtAuthenticationEntryPoint) .accessDeniedHandler(jwtAccessDenialHandler) .and() .authorizeRequests() .antMatchers("/api/auth/sign_in", "/api/auth/join").permitAll() .antMatchers("/api/auth/reissue").access("hasAuthority('USER') or hasAuthority('MANAGER') or hasAuthority('ADMIN')") .antMatchers("/api/members/**").access("hasAuthority('USER') or ..

일단, 다듬는 이유부터 말하자면, 실제 웹사이트에서 회원 정보 수정을 할 때를 생각해보았을 때, 이게 이상하다고 느꼈기 때문이다. 보통 회원정보를 수정하면, 한 페이지에서 이메일, 닉네임, 비밀번호 수정등을 모두 하는데, 지금 만든 프로젝트에서는 각 정보마다 수정을 따로 해주어야 하기 때문이다. 이걸 동적으로 하면 되겠다는 생각이 들었다. 기존의 코드를 조금 인용해서, @Transactional public void editMember(EditMemberRequestDto editMemberRequestDto, Member member){ if(editMemberRequestDto.getNickname() == null && editMemberRequestDto.getEmail() == null && e..

토큰을 재발행하기 위해서는 어떤 과정이 필요할까를 생각해보았다. 필터체인에서 권한 검증을 받는다(여기서 토큰이 검증되지 않을 경우 예외처리된다) HttpServletRequest에서 토큰을 가져온다. 가져온 토큰을 AuthService.reissue에 집어넣는다. 서비스에서 나오는 TokenResponseDto을 HttpServletResponse에 담아준다. 응답을 준다. 정도로 생각했다. 저번과 마찬가지로, 성공과 실패 경우를 생각해보려고 했다. 하지만, 생각해보니, 이에 대한 문제를 생각하지 않아도 될 것 같은 이유가, 모든 경우에 대한 예외를 Spring Security를 만들 때 적용시켜두었다. 그래서 간단하게, 토큰이 정상적으로 있을 때, 토큰이 없을 때, 토큰이 정상적이지 않을 때를 테스트해..