빅데이터란 무엇인가?
팀내 공유 했던것 가볍게 정리.
발표 자료 : http://prezi.com/k56wvgphtmix/big/?utm_campaign=share&utm_medium=copy
프레지 자료라.. 읽을 내용이 없습니다. OTL
"생각은 언어로 표현되는 순간 죽어 버린다" 라는 말이 있는데요.
팀 세미나를 말로 진행했었는데 글로 쓰려니 영 표현이 안되네요 ^^;
왜 이책을 읽게 되었나?
제가 처음 빅데이터 관련해서.. 읽었던 책이 지금은 3판까지 나온 한빛미디어 출간 Hadoop 완벽 가이드 입니다. 이 책이 처음 출간 되었을 때는 빅데이터에 대한 내용들이 국내에 서서히 알려지기 시작했고 점점 관심있는 사람들이 늘어나기 시작했었습니다. 아무튼 이 책을 한 반절 정도 읽다가 말았다가 작년에 다른 하둡책을 사서 vmware에 우분투를 설치해서 책에 있는 내용을 실습해 봤습니다. 워드카운팅이라던지 기타 등등...
그런데 한달 정도 지나니깐 다 잊어 버렸습니다. -_-;
배웠는데 써먹을 곳이 없으니까 잊어 버린거죠. 그래서 좀 생각을 해 보니.. 내가 너무 빅 데이터의 기술(하둡)에만 집착하고 있는 것이 아닌가.. 과연 빅데이터가 무엇이고 기술적인 관점이 아닌 비즈니스 적인 관점에서 보면 어떻게 될까, 써먹을 곳을 찾아 볼 수 있을까 하고 생각하다가 이 책을 읽게 되었습니다.
제가 생각하는 이 책에서 가장 큰 핵심은 "빅 데이터의 시작은 모델과 시나리오를 만드는 것" 입니다.
개발자의 마인드에서 빅데이터에 대한 공부를 할때 기술서적을 먼저 보면서 시작 하는 것도 좋지만 빅데이터가 과연 무엇이고 어떻게 써야 하는지 이것을 잘 생각해서 단순히 워드 카운팅이 아닌 진짜 쓸만한 모델과 시나리오를 만들어 보고 이것을 가지고 시작하면 좋을 것 같습니다.
WHY?
그럼 왜 빅데이터가 이렇게 관심을 끌게 되었는지 생각해보면 전체적인 시대의 흐름과 기술의 발전이 빅데이터 시대를 가속화 했다고 볼 수 있습니다.
가트너에 따르면 2020년에 스마트폰과 태블릿, PC 를 제외한 약 260억개의 디바이스가 인터넷에 연결되고 이것들을 포함하면 약 500억에서 750억개의 디바이스가 인터넷에 연결된다고 합니다. 이러한 디바이스들은 다양한 데이터들을 생산하게 되고 이렇게 생산된 데이터들이 빅 데이터가 됩니다.
그리고 이렇게 생성된 빅데이터들을 저장하고 처리하기 위한 시스템들의 가격도 많이 낮아져서 빅데이터가 관심을 끌 수 있는 한가지 원인이 됩니다.
CPU, STORAGE, NETWORK, BANDWIDTH 이 하드웨어들의 가격은 시간이 지날수록 성능은 향상되고 가격은 낮아지기 때문에 합리적인 가격으로 매우 많은 양의 데이터들을 처리 할 수 있게 됩니다.
이렇게 다양한 디바이스이 만들어낸 데이터들과 이를 처리할 수 있는 하드웨어들의 성능향상과 비용감소에 따라 데이터에서 새로운 가치를 뽑아 낼 수 있기때문에 빅데이터가 인기를 끌게 됩니다.
구글의 수석 과학자 이런 말을 했다고 하네요.
"우리는 남보다 더 나은 알고리즘을 가진것이 아니다. 단지 우리는 더 많은 데이터가 있을 뿐이다."
물론 더 나은 알고리즘도 가지고 있겠지만 -ㅁ-;; 데이터가 얼마나 중요한지 강조 하고 있습니다.
WHAT?
그럼 빅데이터는 무엇인가?
IT 시장 전문 리서치 업체인 IDC에서는 아래와 같이 정의 하고 있습니다.
"빅데이터는 클라우드 컴퓨팅과 대형 메모리 모델의 변화를 포함한 하드웨어 기능의 변화와 플랫폼 변경에 따른 데이터 처리 능력과 비용을 극대화하기 위한 기술 범위의 발현이다"
단순히 볼륨이 큰 데이터를 의미 하는것이 아니라 데이터 처리 속도, 데이터 관리 인프라등 여러가지 사항을 만족 해야 빅데이터라고 볼 수 있습니다.
최근에 IDC는 빅데이터를 분석 관점인 BI(Business Intelligence)측면에서 대규모의 데이터로부터 매우 빠르게 데이터를 추출, 발굴, 분석하여 가치를 경제적으로 찾아낼 수 있는 새로운 기술과 차세대 아키텍처라고 정의 하였습니다.
그럼 빅데이터의 특징을 정의 할 수 있는 4가지 V(보통 이 4가지를 충족하면 빅데이터로 볼 수 있습니다)에 대해서 알아 보도록 하겠습니다.
위 이미지에 설명이 잘 되어 있네요!
여기를 참조 하시면 됩니다. http://dashburst.com/infographic/big-data-volume-variety-velocity/
간략히 정리 해 보면
VOLUME : Big data is big. 말그대로 BIG 해야 겠죠. 2020년에는 40제타 바이트정도가 될꺼라고 예상한다고 합니다.(1제타 바이트 = 뉴욕 맨하탄의 20% 규모의 서버)
VELOCITY : 보통 한사람당 2.5정도의 네트워크 커넥션을 가지고 있고 엄청난 양의 데이터를 생산해 냅니다. 이것들을 신속하게 분석 해야 겠죠.
VARIETY : 다양한 형태의 데이터들. 지금 당장만 하더라도 YouTube에 40억 시간의 비디오가 올라와있고 페이스북을 통해 한달에 공유되는 내용만 해도 300억 건에 다랍니다.
VERACITY : 데이터의 불확실성. 데이터가 늘어난 만큼 쓸모있는 데이터를 뽑아내는 것도 중요합니다. 북미에서 매년 3조 천억 달러정도가 데이터를 검증하는데 소모 된다고 합니다. 이 때문에 데이터 분석학자들이 많이 필요 하다고 합니다.
HOW?
그럼 빅데이가 무엇인지 대충 감을 잠았으니..어떻게 활용할 것인지 생각해 보도록 하죠.
빅데이터의 주요 니즈와 활용에 대해 아래와 같이 간략히 정리 할 수 있습니다.
1. 대량 데이터 분석과 거래량 처리는 매우 복잡하고 광범위한 데이터베이스의 로직 및 도식을 필요로 함
2. 다량의 정형/비정형 데이터 수집 및 분석 필요
3. 동시에 수 천명의 웹 어플리케이션 사용에 따른 대용량 데이터 관리 필요.
4. 조직관련 데이터는 방대한 네트워크 및 엔티티 유형을 포괄함.
이러한 비즈니스 활용 시나리오로는 고객 행동분석을 통한 고객이탈 방지, 소셜 네트워크에는 감성 분석을 통해 상품, 서비스에 관한 긍정적인지 부정적인지 어떤 반응을 하는지에 관한 분석이 있습니다. 쇼핑몰에서는 비슷한 취향의 아이템을 추천하는 교차판매 엔진같은게 있을 수 있고, 인터넷의 클릭스트림을 분석하고 로그 데이터의 마이닝을 통해 악의적인 부정과 인터넷 범죄자들을 찾는데 도움이 될 수도 있습니다. 금융 업종 및 제조와 유통 업종에서도 네트워크상에서 발생한 로그와 다양한 센서 기반의 데이터를 통해서 다양한 문제를 파악하고 분석해서 해결하는데 도움이 될 수도 있습니다.
(책을 읽어 보시면 더 다양한 사례를 볼 수 있습니다.)
그럼 어떤 기술을 써야 할까요?
오픈 소스로 다음과 같이 정리할 수도 있습니다.
허허허.. 이것들 언제 다 배우나요. ㅠㅠ
아래 링크에 위 이미지에 대한 설명이 있습니다.
http://datakulfi.wordpress.com/2013/03/27/big-data-open-source-technology-landscape/
여기까지 빅데이터에 대해서 간략하게 정리해 보았습니다.
위 견해는 저의 관점에서 바라본 빅데이터구요. 더 많은 관심이 있으신분은 책을 보시는것을 추천 드립니다.
마무리로 간단히 말씀 드리면
개발자로서 빅데이터의 기술 부터 공부하기 보다는 빅데이터가 무엇이고 비즈니스적인 관점에 미리 생각해보고 공부를 하면 빅데이터에 대해서 좀 더 효과적으로 접근할 수 있고 생각의 범위가 넓어질 수 있습니다.
"데이터가 있다면 데이터를 살펴보고, 우리가 가지고 있는 모든 정보를 마이닝 하자"
- 구글 수석 과학자 -
Big brother
http://ebs.daum.net/knowledge/episode/7513?t__nil_issue=uptxt&nil_id=4
하루에 생산되는 데이터. 250경 바이트
지난 2년간 생산된 데이터량 > 인류가 그동안 쌓아온 데이터.
권련이 빅 데이터를 악용할 경우, 데이터를 활용해 통제할 수 있는 빅 브라더가 탄생할 수 있다.
다음주에는 꼭..
집단지성 프로그래밍 책을 좀 읽고 챕터 별로 정리를 해야겠다.
이전에 읽다가.... 음 좋긴 한데 지금 하는일에선 쓸모가 없겠어.. 라고 했는데..
다시 생각해보니 그래도 다 읽어 두면 좋을 것 같다.
하지만.. 책이 좀 두껍지 -ㅅ-;;
화..화이팅!!
select insert는 쓰지 말자....
어 티스토리 글쓰는 폼이 바뀌었네.. ㅋㅋ
요즘 모니터도 커지고 그래서, 설정 바가 왼쪽이나 오른쪽에 있는것도 꽤 괜찮은 듯.
좋은 개선이다!!
아무튼...
요즘 인수인계 받아서 유지보수 하는 시스템이 있는데..
여기에 개선할 내용이 있어서 개발 하던중...
insert를 하는 부분에서 select insert를 하는 부분이 있어서..돌아 버리는줄.. -,.-..
나는 DB는 되도록 데이터를 담는 역할을 하고, 쿼리도 데이터를 담거나 불러오는 역할로만 쓰도록 주로 코딩 하는데..
이전 소스를 살펴보면 쓸대없이 복잡하게 쿼리를 꼬아놓은 로직들을 볼 수가 있다.
이게 개발 할때는 좀더 간편하고 소스를 줄일 수 있기 때문에 쉬울지는 몰라도..
나중에 유지보수 하는 사람의 입장에서 보면 상당한 고역이다.
Service에 비즈니스 로직이 다 들어가 있어야 하는데..
ibatis를 사용하는 경우, .sql 파일에다가 로직까지 포함 되어 있으면 디버깅이 너무 어려워 진다.
으흐..
되도록 쓰지 말자.. ㅠㅠ
리눅스 명령어 모음
| http://manpage.co.kr/senario/viedit.htm ftp 명령어 : http://ttongfly.net/zbxe/?document_srl=45527 tar - GNU 버전 tar 저장 도우미 이 설명서는 tarfile 이라고 알려진 저장 파일을 묶거나 풀 수 있도록 만들어 진 GNU 버전 tar 저장 프로그램에 대한 설명이다. tarfile 은 테이프 드라이브에 저장할 수도 있고, tarfile 을 일반적인 보통 파일로 쓸 수도 있다. tar 의 첫번째 인수로는 반드시 Acdrtux 중 하나의 옵션이 들어가야 하고, 다른 선택적인 기능이 덧붙여진다. tar 의 마지막 인수로는 압축될 파일이나 디렉토리의 이름이 오게 된다. 디렉토리 이름이 사용될 경우 언제나 하위 디렉토리가 함께 저장된다. 가장 많이 사용하는 일반적인 옵션 [압축할 때] tar cvzf 파일명.tar.gz <디렉토리> 또는 파일 [압축 해제] tar xvzf 파일명.tar.gz [예제] tar -xvvf foo.tar : foo.tar 파일을 푼다. tar -xvvzf foo.tar.gz : gzip으로 압축된 foo.tar.gz 파일을 푼다. tar -cvvf foo.tar foo/ : foo 디렉토리에 있는 내용물을 foo.tar 파일로 묶는다. 기능 옵션 반드시 아래 옵션들 중 하나가 들어가야 한다. -A, --catenate, --concatenate : 저장 파일에 tar 파일을 추가한다. -c, --create : 새 저장 파일을 만든다. -d, --diff, --compare : 저장 파일 혹은 파일 시스템 간의 다른 점을 찾는다. --delete : 저장 파일에서 지운다. (자기 테이프에는 쓰면 안됨!) -r, --append : 저장 파일의 끝에 파일을 덧붙인다. -t, --list : 저장 파일의 내용 목록을 보여준다. -u, --update : 저장 파일에 저장된 사본보다 새로운 파일만을 덧붙인다. -x, --extract, --get : 저장된 것에서 풀어낸다. 부가적인 옵션 --atime-preserve : 덤프된 파일의 접근 시간을 바꾸지 않는다. -b, --block-size N : 블럭 크기를 N x 512 바이트로 정한다. (기본값 N = 20) -B, --read-full-blocks : 읽은 만큼 블럭을 재지정한다. (4.2BSD 파이프를 읽기 위함) -C, --directory DIR : DIR 디렉토리로 바꾸고 작업을 한다. --checkpoint : 저장 파일을 읽는 동안 디렉토리 이름을 출력한다. -f, --file [HOSTNAME:]F : 저장 파일 혹은 장치 파일 F에 저장한다. (기본 "-", 표준입/출력을 나타낸다.) --force-local : colon 문자가 있더라도 저장 파일을 지역 파일로 처리한다. -F, --info-script F --new-volume-script F : run script at end of each tape (implies -M) 테이프의 끝에 도달하면 스크립트를 실행한다. (-M 이 포함된다.) -G, --incremental : 이전 GNU 형식으로 incremental 백업을 만들거나 목록을 보거나 풀어낸다. -g, --listed-incremental F : 새로운 GNU 형식으로 incremental 백업을 만들거나 목록을 보거나 풀어낸다. -h, --dereference : 심볼릭 링크를 묶지 않는다. 그것이 가리키는 파일을 묶는다. -i, --ignore-zeros : 크기가 0인 것은 무시한다. (보통 EOF를 의미한다.) -j, --bzip2 : bzip2 필터를 사용하여 .bz2 파일을 푼다. --ignore-failed-read : 읽을 수 없는 파일이 있더라도 종료 코드 0을 출력하지 않는다. -k, --keep-old-files : 기존에 있는 파일을 유지한다. 파일이 있으면 덮어쓰지 않는다. -K, --starting-file F : 저장 파일에 있는 파일 F에서부터 시작한다. -l, --one-file-system : 저장 파일을 만들 때 로컬 파일 시스템 안의 놓는다. -L, --tape-length N : N * 1024 바이트를 쓴 다음 테이프를 바꾼다. -m, --modification-time : 파일의 변경 시간 정보를 유지하지 않는다. -M, --multi-volume : 여러 개로 나눠진 저장 파일로 만들거나 목록을 보거나 풀어낸다. -N, --after-date DATE, --newer DATE : 주어진 DATE 보다 새로운 파일만 저장한다. -o, --old-archive, --portability : ANSI 형식 대신 V7 형식으로 저장한다. -O, --to-stdout : 표준 출력으로 파일들을 풀어낸다. -p, --same-permissions, --preserve-permissions : 모든 퍼미션 정보를 유지한다. -P, --absolute-paths : 파일 이름의 맨 앞 `/' 문자를 버리지 않는다. --preserve : -p 옵션과 -s 옵션을 함께 사용한 것과 같다. -R, --record-number : 저장 파일의 레코드 번호를 각각의 메시지로 보여준다. --remove-files : 파일을 저장 파일에 덧붙인 다음 파일을 지운다. -s, --same-order, --preserve-order : 저장 파일 목록과 똑같은 순서로 풀어낸다. --same-owner : 같은 사용자 소유권으로 파일들을 풀어낸다. --numeric-owner : user/group 이름으로 항상 숫자를 사용한다. -S, --sparse : 듬성한 파일을 효율적으로 다룬다. -T, --files-from F : 파일 F에서 목록을 읽어 추출하거나 만든다. --null : -T reads null-terminated names, disable -C -C를 비활성화하고, -T로 읽을 때 null로 끝나는 이름을 읽는다. --totals : --create로 만들어진 바이트 총합을 출력한다. -v, --verbose : 처리중인 파일을 자세하게 보여준다. -V, --label NAME : 저장 파일의 볼륨 이름을 NAME으로 한다. --version : tar 프로그램의 버전 정보를 출력한다. -w, --interactive, --confirmation : 각각을 처리할 때 마다 물어본다. -W, --verify : attempt to verify the archive after writing it 저장 파일을 쓴 후에 저장 파일을 점검한다. --exclude=FILE : FILE을 제외한다. -X, --exclude-from FILE : FILE 목록에 있는 것을 제외한다. -Z, --compress, --uncompress compress로 압축하거나 푼다. -z, --gzip, --ungzip : gzip으로 압축하거나 푼다. --use-compress-program PROG : PROG로 저장 파일을 다시 처리한다. (PROG은 반드시 -d를 처리해야 한다.) --block-compress : 테이프에 저장할 때 압축 프로그램의 출력을 막는다. --rsh-command=CMD : `rsh' 대신 원격 COMMAND를 사용한다. 이 옵션은 표준 `rsh' 대신 원격 장치에 접근할 수 있는 다른 것(예를 들어, Kerberized `rsh')을 사용하는 사람들을 위해 필요하다. -[0-7][lmh] : 드라이브와 밀도를 지정한다. http://sinsungcampus.wo.to 담당자 : 유명홍 대표전화 :0505-555-1334, 02-6403-1334 E-mail : myunghong72@empal.com |
사용자 경험 스케치 에서..
읽는 중 @_@.
아래 반문은 기억해 뒀다가 나중에 말도 안되는 일정을 요구할 경우에 써먹어야겠다.
디자인 단계 뿐만 아니라 개발 단계에서도 적용할 수 있으니...
개발하다보면 일단 개발 부터 진행 할려고 하는데.. 나도 그렇고..
이를 지양 하고 디자인 프로세스를 잘 마무리 하고, 그 기간에 개발을 하고 싶으면 다양한 프로토타이핑으로 개발 단계를 준비하는 것으로 대체해야지.
start.
실무에서 프로젝트를 진행할 때 자주 접할 수 있는 상황이 있다. 이런 상황에서 오가는 말을 살펴보는 것으로 이 장을 마무리 할려고 한다.
이 제안은 무척 훌륭합니다. 이상적인 세계에서는 아주 좋은 방법이에요. 하지만 현실에서는 그렇지 않죠. 마감일도 맞춰야 하고 비용도 제한돼 있으니까요. 이런 프로세스를 일일이 거치기에는 일단 시간과 비용이 허락하질 않아요. 현실에서는 이상적인 것만 추구하는 건 불가능 합니다. '적당히 good enouth' 괜찮은 방법을 차용할 수밖에 없어요.
이 말을 들으면 나는 거의 항상 아래와 같은 두 가지 반문으로 응답한다.
제대로 된 기획과 디자인 방법을 적용할 만한 비용이 없다는 건 이해할 수 없어요. 제품 출시가 늦어지는 데 들어가는 비용은 항상 충당하고 있잖아요? 엉터리 기획과 디자인, 점검 방법 덕분에 쏟아지는 수많은 오류를 수정하는 데 들어가는 비용은 어디서 나오는 거죠?
제대로 된 기획과 디자인 프로세스를 적용하는데 필요한 비용은 오류가 가득한 엉터리 제품을 시장에 늦게 출시하는 데 들어가는 비용에 비하면 아무것도 아니에요. 그런데 어째서 비용이 허락하지 않는다는 거죠?
프로젝트 초기에는 디자인하려는 제품이 어떤 것인지 확실히 알 수 없다. 이런 사실을 인정하고 프로젝트를 관리해 나가기란 무척 어렵다. 따라서 프로젝트의 초기부터 제품을 결정해 버리고 개발 단계로 곧장 넘어가려는 경우가 많다. 하지만 현실은 그렇지 않다. 행운이 따르는 아주 극 소수의 경우를 제외하면 제대로 된 디자인 단계를 거치는 쪽이 훨씬 효과적이다. 시간과 비용을 절약하면서 훌륭한 제품을 제작하는 지름길이다.
바로 결련으로 넘어가버리는 지금의 방식보다는 명확한 디자인 단계를 프로세스에 도입하는 것이 훨씬 바람직 하다.
요즘은..
사실 한 1년 반전에.. 그때쯤 나왔나? 책 나왔을 때 다 읽었었는데..
기억이 안났다.. ㄱ-...
하여 기억을 되새겨 볼 겸 해서 다시 읽어 보는중...
특히나 컬렉션 프레임워크 부분은...(면접보는데 질문이었다. 대답을 잘 못했음)
충격 먹고 다시 살펴 보았다. 웁스 -_-;;
잘 좀 하자 ㅋ.
어제 오늘 면접 본 후기.
오랜만에 보는 면접이라 떨리기도 했고, 또 면접관이 4분씩 계셔서 힘들기도 했다.
면접을 잘 보지는 않았다. 100%중에 한 60~70%정도 마음에 들었을것 같다.
SM 면접은 아무래도 내가 조금 가볍게 생각했었다.
이력서를 작성할 때도 별 생각없이 기존에 이력서 작성하던데로 기술 위주로 작성을 했었는데,
사실 SM 이력서 작성할때는 운영에 대한 생각과 이력을 중심으로 기술해야 하는데 이를 인지 하지 못했다.
면접을 보고나서, 면접자리에 같이 있었던 퇴사 하시는 분(아마 이분 대신 일하게 될)이 지적을 해 주셨다.
나는 모르고 있는 내용이라서 대단히 감사 했다. ^^;
솔루션 기업 면접은 그 분야를 선도하는 기업이라서, 나름대로 준비도 하고 해서 면접을 진행했다.
기술 질문의 경우에는 딱히 꼭 집어서 특정 분야에 집중적으로 물어보시지 않고, 이력서에 있는 내용으로 질문을 하셨는데, 잘 대답 하지는 못했다. 조금 더 생각해보고 대답을 했어야 하는데. 약간 아쉽긴 했다.
인사 담당자의 질문은 사전에 양해를 구하고 다양한 질문을 하였다.
이직 사유에 관해서 질문을 했을때.
내가 이력서를 작성하고, 면접에 대답을 할 때도 약간 개인적인 욕구가 강하다고 보이는 것 같다.
이 것에 대해서는 어느정도 맞는 말이고 부정을 할 수는 없지만, 사실 이번 경우에는 아는 분의 아는분의 추천으로 지원을 하게 됬는데, 면접보는 회사에서도 개인적인 욕구에 맞지 않는 일을 시키면 퇴사할 것이냐 라고 질문을 하였다.
어느 회사가 개인적인 욕구에 100% 맞추어 일을 주고 하겠느냐, 그 받은 일을 최대한 열심히 하고, 그 곳에서 자기 계발의 기회를 찾아서 최대한 회사에 기여 하겠다. 이런 뉘앙스로 대답을 하였으나..
아마도 개인중심 적인 사람 이런 식으로 인식하신것 같다.
물론 인사담당자 입장에서는 사람 뽑을때 최대한 회사에 기여하고 오래있을 수 있는 사람을 뽑아야 겠지만, 구직자의 입장에서도 회사에 입사 하였을 때 자신의 업무에 정말로 맞지 않는 다면 이직하는게 당연하지 않을까 라는 생각이 들었다.
특히나 일반 업무도 아니고 개발자(지식노동자)라는 입장에서 자신의 지식을 활용할 수 있는 그런 포지션에서 최대한 일 할 수 있도록 해야지 최대한의 효율이 나올 수 있고, 업무에 맞지 않는 일을 시키면 소프트웨어의 품질이 잘 나올 수 있느냐 이런 생각이 든다. 물론 내 입장에서.. -_-;;;
인사 담당자의 생각도 맞다. 하지만 내 생각도 틀리지는 않는다고 생각한다.
아 그리고 블로그에 올려논 글들도 확인 했던데.
지금 다니고 있는 회사가 마음에 안든다는 내용이었다.
사람이 회사를 다니면서 비판도 못하나. -_-;;
사실 그 포스팅은 비공개 포스팅이 었는데 꿀릴.. 머 잘못말한것도 아니고. 회사 담당자가 봐도 그렇게 틀릴 말은 아닌..
그런 내용 이었다고 생각한다.
뭐 할말은 다 하고 살아야지.
-_-;;
토스 3책을 분권했다.
집중해서 책 읽기
퇴근해서 라디오 들으면서 책 많이 읽었었는데..
(탱구의 친친, 타블로의.. 머였더라 )
이사 오면서 묘하게 책 읽는 리듬이 어긋나서 생각보다 좀 많이 못 읽었다.
사놓고 못 보고 있는 책이..
하둡(재미있다! 하지만 당장 필요한 기술이 아니다.), 멀티코어 프로그래밍(이놈은 그냥 훑어 봐야겠다)
기선형이 빌려준 자바 병렬 프로그래밍(어렵다! 책이 지루하다!)
뷰티풀 아키텍처(음?? -_-;;)
옆에 보니깐 대략 이정도??
지금까지 산 책이 헉 벌써 80권 정도내..
비율을 보면 API 레퍼런스 류가 약 40% 방법론 책이 30%(잼있어. 하드 코드나 실용주의 사고와 하급, 소프트웨어 컨플릭트
기타 디자인 및 패턴 책들
처음으로 책 사서 볼 때도 API에 너무 치중하지 말고 방법론 및 디자인 책도 사서 보자는 주의 였는데
나름 잘 지켜 지고 있다. 하하하핫.
아무튼.
목적은 집중해서 책 읽기!!!
하여, 복층에 있던 오디오를 1층으로 내렸다. 여름엔 1층에서 생활.
겨울 되면 다시 올라가지만 -ㅅ-;;;
요즘 7시 30분 퇴근이라 집에 오면 9시 가까이 되는데...(젝일 책 읽을 시간이 모잘라)
적어도 10시 전에 책 읽어서 11시(11시 예능은 본방 사수 -_-;;) 까지 읽는 습관을 다시 들여야겠다.
일단 책 읽을것들을 다 읽고(또 책 샀다, 자바 퍼포먼스 파운데이션, 이놈은 10월에나 보겠다.)
코딩은 잠시 급한것만 하고, 아니면 일 하면서 지루할때 짬짬이 하던가 해야겠다.
최근에 보고 싶은 책은... Spring receipes.. 인데, 원서 이다.
그래도 읽어 보고는 싶다. 담달에 봐서 사야지,
기선형이 번역한 하이버네이트도 보고싶고.
아 욕심은 많아.
