Hello, Freakin world!

아 ... 목표했던 바는 이뤘지만 사람의 욕심이란... 목표는 2문제를 맞추는 거였는데, 백준에서 꽤 많이 풀다보니 여기까진 쉬웠다.(나도 놀람 ㅋㅋㅋㅋ 다 풀 수 있을 것 같은 느낌이었다) 1번은 간단한 구현, 2번은 간단한 분할 정복 알고리즘을 짤 수 있느면 풀 수 있는 문제. 3,4 문제가 어려웠다. 3번은 아이디어가 떠오르질 않아 패스했고 4번을 집중적으로 공략했지만 실패. 효율성 무시하고 점수를 긁으면 각 문제당 50점 정도 긁어지는 것 같았다. (4번은 그렇게해도 52점 주더라) 근데 뭐 별 의미가 있나 싶다. 3문제를 100점으로 풀어야 프로그래머스에서 코딩 테스트때 프리패스권을 주기 때문. 아 아쉽다... 3,4번을 두 시간 넘게 팠지만 아쉽게도 fail. (최종 성적은 252점) 일단 풀..

아직 입문자인 나로선 너무 불편하게 느껴진다. 아마존 웹서비스 EC2에서 문서 편집 하기 위해 어느 정도 필요성을 느끼고 있긴 하지만... GUI 환경이 갖춰진 환경이라면 아직까진 IDE같은 편집기가 편하다. VI를 쓰면서 내게 불편함으로 다가왔던 장벽은 1. 여러 편집 커맨드를 외워야 한다는 점. 2. 자동 완성 기능이 없어, 타이핑이 잘되고 있는지 확신이 안든다는 점 1번은 생각보다 자주 사용하는 커맨드가 정해져 있는것 같아서 의외로 금방 적응할 수 있을 것 같지만 2번은 글쎄... 일단 불평은 접어두고, 학습해보자.

정말 간단하게 끝내리라 마음먹었던 프로젝트였는데, 너무나 엄청나게 복잡해졌습니다. 현재 채팅룸 서버, 채팅메세지 서버, 클라이언트 앱. 이렇게 세개의 모듈로 나눠서 작업하고 있습니다만, 공통적으로 사용되는 DTO, 헬퍼 메서드 등의 중복이 엄청나게 많습니다. 정말 자바9 모듈 프로그래밍의 필요성이 절실합니다. 그리고 또 메서드의 추상화를 극한으로 끌어올려야 한다는 것도 절실하게 느껴지네요. 지금도 리팩토링이 가능한 중복 코드들이 많이 보입니다. 애초에 람다나 제네릭을 적절하게 사용했다면 예방할 수 있었을텐데 라는 생각이 많이 듭니다.

저렇게 글을 써야되겠구나 싶었습니다. 이제부터 모든 글들은 경어체로 쓰고, 좀 더 겸손하게 정성들여 써야겠다는 생각이 드네요. 그리고 대단하다는 분들이 참 많다는 걸 다시 느끼면서.. 더 노력해야겠다는 생각입니다 ㅠㅠ

채팅앱의 UI 관련 코딩을 하다보니 자연스레 UI의 관련 기능들을 담을 하나의 컨테이너가 필요해졌습니다. 그리고 그 컨테이너가 안드로이드에서 제공하는 Activity라는 개념은 아닐까? 라는 생각이 들더군요. UI 코딩 이전에는 채팅방 정보를 제공하는 서버를 프레임워크화 하는 과정에서 모든 의존성을 담당하는 하나의 클래스를 두었었습니다. 이 역시 스프링의 ioc 개념에서 들고 왔습니다. 다시 말해, 하나의 클래스에 모든 의존성 정보를 몰빵하고, 그 클래스에서 모든 의존성을 setXXX와 같은 메서드를 통해 주입합니다. 이 방법은 애너테이션을 이용한 스프링의 방식처럼 세련되진 않지만, 그래도 클래스마다 필요로 하는 컴포넌트 객체들의 생존주기를 관리하는 코드를 넣지 않아 편리했습니다. Activity라는 개..

코딩 일기 카테고리 신설! 이 부분은 코딩하면서 주로 깨달은 점과 같은 다소 주관적인 내용을 담을 카테고리입니다.