피드백 환영

우선 Project algo는 한국에서 '다빈치코드' 라고 불리는 보드게임 algo를 웹상에서 플레이할 수 있도록 구현하려는 프로젝트이다. 게임 서버쪽은 Spring(이하 스프링) 프레임워크로 작성하고, 게임 클라이언트쪽은 게임개발자 지망 시절에 다루어봤던 Unity3D(이하 유니티) 엔진으로 만들 예정이다. (유니티는 다양한 플랫폼에 대해 자동으로 포팅하는 기능으로 유명하며, 그 중 웹도 포함된다.) 이 과정에서 Unity3D 클라이언트와 스프링서버가 통신이 원할하게 이루어져야 하는데, 이 부분에 대하 http 프로토콜은 'UnityWebRequest' 라는 유니티의 고유 클래스로 쉽게 통신할 수 있다. 문제는 구상 과정에서 웹소켓 기술의 사용이 필요해보였고, 이 부분에 대해 파악이 덜되었기에 기술검토..

github : https://github.com/codestates-seb/seb42_main_024/tree/feat/chatWithMember/server/src/main/java/com/main/server/chat * 스프링 부트 2.7.9 버전과 Java 11 버전을 사용하고 있습니다. 제가 해당 기능을 만들기위해 코드를 짜며 파악한 정보를 바탕으로 작성되는 글이기 때문에 틀린 정보가 포함되있을 수도 있습니다. 뇌피셜로 작성된 정보는 확언을 피해서 작성하고있으며, 틀린 정보가 있다면 피드백을 부탁드립니다. 1. Config @Configuration @EnableWebSocketMessageBroker @RequiredArgsConstructor public class WebSocketConf..

CodeStates 더보기 해당 글은 CodeStates 부트캠프를 지내며 겪었던 일과 경험들을 개발지식에서 몇걸음 멀어진 상태에서 적는 스스로의 메타인지를 위한 글입니다. 대부분 혼잣말을 하는 형식으로 기술되며, 형식따위 지켜지지 않을 확률이 높기에 조금 이질적일 수 있습니다. 섹션 4에 대한 회고는 섹션 3 회고에서 언급했던 느낌이랑 크게 다를게 없었습니다. 섹션 4 초반 챕터에서 스프링 시큐리티를 배울때는 정말 많은 분량을 소화시켜야 했는데, 다행히도 후반는에 AWS 를 통한 클라우드 배포, Github Actions 를 통한 배포자동화, 나름 자신있는 기본적인 CRUD를 활용해 todo-app을 만드는 솔로프로젝트등 초반에 비해 여유가 있었습니다. 섹션 5 프리 프로젝트에서는 랜덤 구성된 팀원들로..

코드스테이츠 프리프로젝트가 끝난 이후, 제가 AWS를 사용하면서 겪은 예상치 못한 에러 하나와, 기간내에 해결하지 못한 에러 두개를 작성해보려 합니다. 1. AWS EC2 서버에서 스프링 프로젝트 빌드 무한로딩 에러 프로젝트를 완성 후, 기존에 사용하는 ngrok 이라는 프로그램으로 통신을 하면 get 메서드가 제대로 전달이 안되는 오류가 있어서, 개발중인 상태인 서버를 AWS EC2에 올려서 테스트를 해야하는 일이 있었습니다.EC2 인스턴스에 환경을 세팅하고, git으로 서버도 클론해오고, 빌드를 하려는 순간, 빌드 중 76%에서 시간만 증가하고 빌드가 이루어지지 않는 오류가 발생했습니다.여러가지를 찾아본 끝에 발견한 문제점은 메모리 문제였습니다. 제가 쓰는 인스턴스는 AWS freetier 에서 제공..

코드스테이츠 프리프로젝트 진행중 내가 새로배우거나 해결한 에러를 정리해보려 합니다. 1. CORS 에러 해결 포스트맨으로는 정상작동 되었으나, 로컬 환경에서 ngrok 이라는 도구를 통해 react 기반의 프론트 서버랑 통신하는데 있어서 cors 에러가 나왔었습니다. @Bean CorsConfigurationSource corsConfigurationSource() { CorsConfiguration config = new CorsConfiguration(); // 기존코드 // config.setAllowedOrigins(Arrays.asList("*")); // config.setAllowedMethods(Arrays.asList("GET", "POST", "PATCH", "DELETE")); // ..

CodeStates 더보기 해당 글은 CodeStates 부트캠프를 지내며 겪었던 일과 경험들을 개발지식에서 몇걸음 멀어진 상태에서 적는 스스로의 메타인지를 위한 글입니다. 대부분 혼잣말을 하는 형식으로 기술되며, 형식따위 지켜지지 않을 확률이 높기에 조금 이질적일 수 있습니다. 약 1~2주 정도 늦게 섹션3 회고글을 쓰게 되었다. 원래는 좀더 블로깅도 하고, 개인 학습도 하려고 했는데 생각보다 섹션3의 수업량이 꽤 많았다. 못따라갈 정도는 아니였는데, 코드스테이츠쪽에서 수업내용이랑 별개로 과제를 따로줘서 여유가 많지 않았다. 회고글도 섹션3를 끝냈으니 조금 쉬고 주말에 써야지 했던게, 섹션4의 시큐리티 내용을 들어가니까 선행학습을 아예 하지못했던 내용에 분량까지 많아서 주말에는 별개의 과제를 할 시간도..

// 기존 코드 Repository public List getIdFromPage(int page) { return em.createQuery("select b from Board b order by b.id desc", Board.class) .setFirstResult(limit * (page - 1)) .setMaxResults(limit) .getResultList(); } Board 엔티티에 Comment를 전부 꺼내서 리스트 객체로 담습니다. (양방향 연관관계 설정으로 쿼리문에서 join을 따로 붙히지 않았습니다.) Service public List getListFromPage(int page) { return boardRepository.getIdFromPage(page); } 단순 리턴이..

CodeStates 더보기 해당 글은 CodeStates 부트캠프를 지내며 겪었던 일과 경험들을 개발지식에서 몇걸음 멀어진 상태에서 적는 스스로의 메타인지를 위한 글입니다. 대부분 혼잣말을 하는 형식으로 기술되며, 형식따위 지켜지지 않을 확률이 높기에 조금 이질적일 수 있습니다. 오늘자로 코드스테이츠 백엔드 커리큘럼의 섹션2 가 끝났다. 체감상 섹션1 때보다 시간이 빠르게 흐른것 같은 느낌이다. 바쁘게 살아서 그런가. 아무튼, 섹션 2의 전체적인 여정은 성공적이라고 단언한다. 우선은 섹션1 에서 언급된 번아웃에 관한 것인데, 나란녀석은 단순해서 먼 곳의 목표가 아무리 크더라도 집중력을 잃고 가까운 곳의 목표만을 쫒게되는 사람이다. 다시말해 지속적인 자극( 여기선 성취감 )이 없으면 쉽게 질려버리거나 집중..

소요시간 : 1 ~ 2시간 사이 깃허브 : https://github.com/GoF9490/NodeToSpring-Board GitHub - GoF9490/NodeToSpring-Board Contribute to GoF9490/NodeToSpring-Board development by creating an account on GitHub. github.com 정말 타이밍이 좋다고 해야할지, 전에 했던 작업에서의 오류, 그 외 개선사항 등등이 현재 제가 듣고있는 강의에서 그대로 나와서 간단하고 빠르게 몇개만 적용시켜서 리팩토링 했습니다. 코드 자체는 크게 변하지 않았지만 범위가 넓어서 바꾼 코드들 하나하나 올리기는 좀 그렇고, 무엇을 바꾸었는지 정도만 언급하고 바뀐 코드는 직접 깃허브 링크에서 확인해주..

이전글에서 이어집니다 프로젝트 시간의 반정도를 잡아먹은 controller 구현 및 테스트 입니다. 여태까지는 spring 프로젝트에 html 템플릿을 담고서 controller에서 해당 템플릿으로 데이터를 넘겨주는 형식으로만 프로젝트를 만들어봤기에 http 통신을 spring 으로 제대로 해본건 처음이였습니다. 사실 지금도 각 어노테이션에 대해 완벽하게 이해하고 있지는 않고 느낌적으로 쓰는것이기에 추후에 update 기능을 추가하면서 시간을 들여 여러가지 시도하면서 학습할 계획입니다. // controller controller는 원래 계획대로라면 node.js 의 html 페이지와 통신을 해야하지만, node.js 코드를 다시 읽고 고치려니 꽤 시간이 많이 잡아먹힐 것 같아서 일단 postman 으로..