대한민국 대표 개발자 [짱가™] 2ed

AOSA 1권 9장. CI 정리 http://www.aosabook.org/en/integration.html

http://www.aosabook.org/en/hdfs.html 의 내용을 정리하였으며 웹 상에서 여러 다른 정보도 참조하였습니다. 8장.HDFS introduction ㅇ 하둡 분산 파일 시스템(Hadoop Distributed File System, HDFS)은 기성 하드웨어에서 실행할 수 있도록 디자인된 분산 파일 시스템. ㅇ 다른 분산 파일 시스템과의 차이점 HDFS는 fault-tolerant 하고 저비용 하드웨어를 통해 배포할 수 있도록 설계됨. HDFS는 응용 프로그램 데이터의 접근에 높은 처리량을 제공하고, 대용량 데이터 집합을 갖는 응용 프로그램에 적합 ㅇ 하둡의 중요한 특징은 수 없이 많은 데이타와 계산의 파티션, 병렬 계산의 실행임 ㅇ hdfs는 메타데이타와 데이타를 분리하여 저장한..

나는 지식 노동자다. 그래. 노동자다. 아직 비즈니스를 만들고 어쩌고는 ... 뭐 먼 나라 얘기다.엔지니어 이다. 라고는 말하지만, 예전의 기준으로 보면 배운놈이 하는 일을 하는 거다.다만, 기술을 가지고 하니깐,,,, 엔지니어니 뭐니... 하는 거다.자신의 지식을 가지고 모니터와 대화하고 같은 지식 배경을 가진 사람들과 갑론을박 하면서 살아가는 이 세상에서 늘어가는 것은 기술과 자신의 지식에 대한 자부심과 아집일듯 하다. '지식 노동자' 란 내가 가진 지식으로 인정을 받고 싶어하는 사람일게다.그러다 보니 자기도 모르게 상대방을 누르려고 하기도 하고 자신의 영향력을 키우기 위한 행동을 하게 되기도 한다.아직도 인정받지 못하면 자괴감과 더불어 '그 자리에 내가 왜 있나?' 를 생각하기도 한다. 그래도 자존..

코드는 이해하기 쉬워야 해! 무엇이 코드를 '더 좋게' 만들까?return exponent >=0 ? mantissa *(1

읽기 좋은 코드가 좋은 코드다저자더스틴 보즈웰 지음출판사한빛미디어 | 2012-04-06 출간카테고리컴퓨터/IT책소개이 책은 코드를 작성할 때 언제나 적용할 수 있는 기본적인 원리... ( 맨날 뭐 하려고 하면 거창하게 생각하고 거창하게 시작해서 아무것도 못하는 것 같아서... 스텝 바이 스텝으로 천천히 생각하기로 했다. 오늘부터 한 챕터씩 '읽기 좋은 코드가 좋은 코드다' 를 정리해보기로 했다. '소설처럼 읽히는 코드' - 이게 내 평소 지론이다. 이것을 도와주는 책으로는 국내 책중에는 현재까지는 Clean Code 가 최고였다만,,,, 이 책 역시 던져주는 메시지가 꽤 좋으므로... 정리. 목차는 다음과 같다. 1장. 코드는 이해하기 쉬워야 한다 01. 무엇이 코드를 '더 좋게' 만드는가? 02. 가..

사용자 추가 하다가... 기록. 이전 5.0 대 버전에서의 사용자 추가는 아래같은 설정으로 우분투에서 추가했었다. ( mysql server setting ) $ sudo apt-get install mysql-server mysql-client root 패스워드 : root 로 설정 sudo vi /etc/mysql/my.cnf#bind-address = 127.0.0.1 --> 로 처리 sudo /etc/init.d/mysql restart mysql -u root -p use mysql select host, user from user ; #사용자추가INSERT INTO user (Host, User, Password) VALUES ('%','root',password('root'));INSERT ..

일을 하면서 대화를 하다보면 최초에 이야기 한 것과 달라져서 당황해 하는 나를 발견할 때가 있다. 우리가 어떤 일을 처리하거나 서로간의 대화를 통해서 이야기를 풀어나가는 프로세스를 분석하고 싶어졌다. 나는 프로그래머다. 정확한 정보가 없으면 솔루션을 제시할 수도 해결의 단초를 생각하기도 힘들다.때로는 해결책을 겨우 생각해 내고 이야기를 진행해 가는데 진행하다보면 전혀 다른 문제여서 접근법을 달리 해야 한다는 생각이 들때 당황하면서 상대를 질책하게 된다. 그렇기 때문에 Garbage in garbage out 의 규칙에 생각조차도 얽매여 있는 것 같다는 생각이 든다. 반대로 컨설팅 및 멘토링의 프로세스는 무언가를 꺼내어 놓을 지 모르는 상대방을 탐구하고 상대방과 대화를 하면서 욕구를 끄집어 내는 것을 먼저..

- 이 글 역시 바로 전 글과 같은 맥락에서 작성을 했는데.... 고민의 시간과 작성 시간이 아까워서 블로그에 남겨본다. 프로젝트를 해요?~~~프로젝트 사업을 만든다, 고객의 요구사항을 듣는다,제안서를 작성한다, 요구사항 분석서를 작성한다, 고객의 요구사항 중 비기능 요구사항을 식별한다, 비기능 요구사항에 따른 기술구조를 선택하고 솔루션을 선택한다, 아키텍처를 설계하고 검증을 위한 선도 개발을 한다 , 개발 표준을 제시하고 개발 표준의 준수여부를 체크한다. 위의 일련의 행위를 통해서 프로젝트가 만들어지고 진행되어집니다. 프로젝트가 진행되다 보면 팀간의 상호 인터페이스에서 부딪히는 역할 문제와 책임문제에서 자유로울 수 없습니다. 그런 역할 문제와 책임문제를 의사결정 해주고 승인해주는 것은 누구의 역할일까요..

- 1년쯤 전에 써본 아티클인데... 부끄러운 글이지만,,, 그리고 꽤 짜집기를 했지만, 이 짧을 글을 쓴다고 안돌아가는 머리 고생하고 고민을 꽤 한 시간이 아까워서 이렇게 블로그에 기록으로 남깁니다. 다시 읽어보니까,,,너무 나열식이다. ㅎㅎㅎㅎ. 왜 아키텍트일까? 흔히 IT 아키텍처를 말할 때 비교하는 건축 도메인과의 비교를 해 보면 고객의 요구사항을 받고 뼈대를 잡고 그 뼈대에 필요한 것들을 쌓아서 고객의 요구사항을 구현한다. 몇 천년 동안 지어진 건축물을 보면서 노하우가 쌓이고 시행착오를 극복해온 건축쪽 도메인과 달리 소프트웨어 분야는 역사도 짧을 뿐더러 아키텍처 자체가 기업의 자산과 보안이 되는 관계로 공유가 그다지 많지 않다. 그나마 인터넷의 발달과 오픈소스의 발전 그리고 블로그의 기술 포스팅..

주변에서 애자일을 도입해서 실패한 사례를 자주 접한다. 그리고 힘들었던 사람들도 많이 봤고... 일정 부분 겪는 부분도 있다. 고객들의 잘못된 받아들임으로 인해서 고생하는 SI 프로젝트의 사람들도 봤다. 그런데.... 그게 애자일을 잘못 받아들인 문제일까? 라는 생각을 해 보았다. 방법론의 문제일까? 애자일이 애초에 시작한 배경이 무엇일까를 생각해보면 답이 나온다. 수많은 프로세스에 따른 결과물. 그 결과물을 작성하기 위한 공정. 실제 프로젝트에 필요한 것이 무엇일까에 대한 고민. 이런 것들로부터 도출된 것이 애자일 프로세스이다. 그런데 ... 이런 프로세스를 공부한 사람들조차 도입할때는 프로세스만 도입한다. 그리고 명목을 입힌다. 그렇게 되면 무엇이 문제가 될까? 당연히 ... 형식만 입히게 되겠지. ..