일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 | 29 | 30 | 31 |
- 유레카
- 주울
- 백트래킹
- 구현
- 스프링 시큐리티
- 다익스트라
- 트리
- ZuulFilter
- dp
- BFS
- 이분 매칭
- 서비스 디스커버리
- Logback
- 도커
- Java
- spring cloud
- 구간 트리
- Gradle
- 플로이드 와샬
- 비트마스킹
- docker-compose
- 메모이제이션
- Zuul
- 게이트웨이
- 달팽이
- spring boot
- 이분 탐색
- 완전 탐색
- Spring Cloud Config
- 스택
- Today
- Total
목록분류 전체보기 (387)
Hello, Freakin world!
사용자는 콘솔을 통해 - 채팅방 생성 - 채팅방 리스트 조회 - 채팅방 나가기 - 채팅방 참가 의 기능을 이용할 수 있다. https://github.com/johnna-endure/chatting-project-entire johnna-endure/chatting-project-entire Contribute to johnna-endure/chatting-project-entire development by creating an account on GitHub. github.com 전체 코드이다. 완벽하진 않지만 그래도 끝이 보인다!!!
채팅앱의 UI 관련 코딩을 하다보니 자연스레 UI의 관련 기능들을 담을 하나의 컨테이너가 필요해졌습니다. 그리고 그 컨테이너가 안드로이드에서 제공하는 Activity라는 개념은 아닐까? 라는 생각이 들더군요. UI 코딩 이전에는 채팅방 정보를 제공하는 서버를 프레임워크화 하는 과정에서 모든 의존성을 담당하는 하나의 클래스를 두었었습니다. 이 역시 스프링의 ioc 개념에서 들고 왔습니다. 다시 말해, 하나의 클래스에 모든 의존성 정보를 몰빵하고, 그 클래스에서 모든 의존성을 setXXX와 같은 메서드를 통해 주입합니다. 이 방법은 애너테이션을 이용한 스프링의 방식처럼 세련되진 않지만, 그래도 클래스마다 필요로 하는 컴포넌트 객체들의 생존주기를 관리하는 코드를 넣지 않아 편리했습니다. Activity라는 개..
코딩 일기 카테고리 신설! 이 부분은 코딩하면서 주로 깨달은 점과 같은 다소 주관적인 내용을 담을 카테고리입니다.
특히 DTO들의 중복이 아주 심하다. 지금 서버 간에 JSON 포맷의 데이터로 통신을 하고 있다. 그래서 그 데이터를 사용하기 위해 다시 DTO 객체에 바인딩한다. 그래서 서버, 클라이언트 모두 같은 DTO 클래스를 가지고 있어야 하는데, 프로젝트가 어느 정도 복잡해지니, 유지보수하기가 여간 귀찮은게 아니다. 그리고 유틸용으로 작성해놓은 메서드도 다른 모듈에서 사용하려면 코드를 복사해서 사용해야한다. 상황을 몸소 느껴보니, 자바9에서 모듈 시스템을 왜 도입했는지 알겠다. 대충 찾아보니 gradle에서 plugin을 이용하면 모듈 프로그래밍이 가능한 것처럼 보인다. 일단 킵해두고 반드시 학습해보자. 여기저기 수정하기 귀찮아죽겠다 ㄹㅇ로
안티프래질 국내도서 저자 : 나심 니콜라스 탈레브(Nassim Nicholas Taleb) / 안세민역 출판 : 와이즈베리 2013.10.01 상세보기 (글을 끄적이기에 앞서 아래의 내용은 초보 독서가가 읽고 느낀 미숙한 글임을 밝힙니다.) 안티프래질이란 주변의 가변적인 요인들의 변화로 인해 불안정해지는 것이 아닌, 오히려 이익이 되는 경우를 일컫는다. 어떻게 이런 시스템이 존재할 수가 있을까? 싶기도 하지만, 우리는 부지불식 간에 이런 시스템을 알고 있었다. 우리 안에 아무도 모르게 내재돼있던 이런 개념을 끄집어내 정리한 그의 통찰력에 찬사를 보낸다. 기본적으로 가변적인 요인들의 불안정성으로부터 이익을 얻기 위해서는 이런 요인들에 크게 의존하지 않아야 한다. 블랙 스완을 예측하고 대비하려면 이런 요인들..
if문은 코딩에서 분기를 처리하는 가장 기본적인 문법입니다. if문의 사용자체가 안티패턴을 유발하진 않습니다만, 하지만 특정 상황에 따라 if문의 사용은 코드를 어지럽힐 수 있습니다. 어떤 경우가 있을까요? 이런 경우들을 일반화시켜 하나의 문장으로 정리하면 다음과 같습니다. 1:N의 관계에서 N이 상당히 큰 경우거나 커질 가능성이 있는 경우. 특히 아키텍쳐 레벨에서 이런 식의 코드로 흐름을 제어할 경우, 정말 개발/유지하기 힘든 코드가 탄생할 수 있습니다. 상대적으로 개수가 고정적이고 확장의 폭이 좁은 '메뉴'의 핸들러 매핑과 같은 문제에 대해서는 개수가 꽤 되더라도 if문 분기를 이용해서 해결할 수도 있습니다. N이 그리 크지 않다면 if문이 더 편한 경우도 분명히 존재한다고 생각합니다. 그렇다면 대안..
ChatRoomServer의 단위테스트 및 통합테스트 추가(v1.1) 이제 채팅룸 서버는 에러가 없는 이상 완성됐다고 간주하고, 다음 작업으로 넘어가자. https://github.com/johnna-endure/chatroom-serverjohnna-endure/chatroom-serverContribute to johnna-endure/chatroom-server development by creating an account on GitHub.github.com 진행 상황 이제 다시 Selector를 이용한 논블로킹 방식의 서버부분과 이 두 가지 서버에게 요청을 보내는 콘솔 앱 부분 작성에 들어가면 된다. 참고로 이벤트 방식의 논블로킹과 동기 방식의 논블로킹은 서로 완전히 통신하는 방식이 다르다.이에..
간단하게 시작해서 여기까지 오게 되다니 ... 코드를 조금씩 생성하면서 그에 관한 글도 꾸준히 올리려했지만 워낙에 코드를 뒤집어 엎고대규모 수정하는 경우가 빈번해 글 사이 시간 간격이 상당히 길어졌다. 결국 CompletableFuture 를 이용한 논블로킹 동기 방식의 서버를 1차 완성했다.아직 단위테스트와 통합 테스트 몇 부분을 더 추가해야 되긴하지만. 내 기준에 정말 의미있는 성과다. 아직 다듬을 코드가 많긴 하지만, 그래도 나름 코드 품질을 어느 정도는 유지하려 애썼다. 아래는 전체코드다.(혹시 실행시켜보시려는 분은 .gradle, .idea, build, out 폴더는 삭제하고, 프로젝트는 gradle로 빌드하시면 됩니다. ) 이 프로젝트에 대해서도 할말이 많긴 한데,자세한 설명은 따로 프로젝트..
Thread api 중 destroy, stop, suspend 등이 안전 상의 이유로 폐기됐습니다. 스레드를 강제로 종료시키던 destroy()는 사전에 자원의 cleanup 작업을 하지 않습니다. 그래서 때때로 monitor가 락을 유지한 상태로 내버려두기도 해, 데드락 유발의 원인이었다고 하네요. https://docs.oracle.com/javase/1.5.0/docs/guide/misc/threadPrimitiveDeprecation.html Java Thread Primitive Deprecation Why Are Thread.stop, Thread.suspend, Thread.resume and Runtime.runFinalizersOnExit Deprecated? Why is Thread...
용도는? volatile의 용도는 다중 스레드 프로그래밍에서 변수 메모리의 위치를 스레드의 로컬(위의 Working Memory)이 아니라 Main Memory에 생성함으로서 일관성있는 데이터의 참조가 가능한 변수를 만들기 위함입니다. 하지만 과연 스레드 세이프할까요? 스레드 세이프 한가? 만약 volatile을 적용한 변수에 대해서 읽고 쓰기만 한다면 스레드 세이프합니다. 하지만 volatile변수의 연산 결과를 로컬 변수에 저장하고, 다시 이 로컬 변수를 volatile변수에 할당하는 경우에 데이터의 일관성이 깨질 수 있습니다. volatile int n = 1; public void modify() { int temp = n + 1; n = temp; } 위의 경우에서 n+1 연산을 하는 도중 다른..