반응형

마음에 와닿았던 글귀 몇개를 정리해본다.


정말 아들을 위한 따뜻한 아버지의 마음이 느껴진 책임과 동시에 어떻게 인생을 살아야 할지에 대해 생각해보게 했던 책이다.


지성 있는 인간은 서두르는 일은 있어도 허둥대는 일은 없다.


교양없는 인간으로 오인받을 정도로 무성의한 글씨를 쓰는 어리석음, 그런 품위 없는 짓을 해서 몇 초의

시간을  벌었다고 해도 그 시간은 아무 쓸모가 없다.


겁이 많고 자신이 없으면 상대가 남성이든 여성이든 자기 수준 이하의 상대와 사귀게 된다.

무엇을 하든지 본인이 '할 수 없다'고 생각하면 할 수 없다. '할 수 있다'고 자기 자신을 타이르면 어떻게든지 할 수 있게 되는 법이다. (크으)


사회에는 재능이 있어야 한다는 것이 첫째 조건이지만, 거기에 더하여 자기 생각을 확실하게 갖고, 그것을 남 앞에서 불필요하게 드러내지 않으며 확고한 의지와 불굴의 끈기가 있으면 무서울 것이 없다. 일부러 불가능에 도전할 필요는 없지만, 가능한 일이라면 갖가지 방법과 수단으로 도전하라. 그러면 길이 열리는 법이다. 한 가지 방법으로 안되면 다른 방법으로 시도하여 알맞은 방법을 찾아내면 좋다. 


아들아 시간을 낭비하기에는 인생이 너무 짧다 중 -


반응형
반응형

[ 100번의 도전(10) ] 운동&식단 일지(0613 - 가슴&삼두 운동) 


언제 벤치프레스 100을 칠수 있을까...


너무 욕심은 부리지말되 1RM씩이라도 무게를 늘려나가자



반응형
반응형


[ 100번의 도전(9) ] 운동&식단 일지(0612 - 등&팔운동)


데드리프트 무게를 많이 못쳤다 ㅠㅠ


1RM이라도 MAX에 도전해보자...


바벨로우도 고중량을 좀 더 섞어보자



반응형
반응형

vi 로 파일을 열었을 때 파일의 마지막 줄이 개행문자로 끝나지 않았을  경우 콘솔 하단에 파일이름 옆 [noeol]이라고 적혀있는 것을 볼 수 있다.


해당 문제를 해결하기 위해서 다음 명령어를 실행해준다.


echo "" >> fileName




반응형
반응형

Spark 직렬화 포맷

spark는 네트워크로 데이터를 전송하거나 디스크에 쓸 때 객체들을 직렬화해 바이너리 포맷으로 변환한다.

기본적으로 Java에 내장된 직렬화를 이용하지만 spark는 java 직렬화보다 훨씬 향상된 서드파티 라이브러리인

kryo를 쓰는 것을 지원한다.

반응형
반응형


[ 100번의 도전(8) ] 운동&식단 일지(0610 - 가슴운동)



반응형
반응형

[ 100번의 도전(7) ] 운동&식단 일지(0608 - 어깨운동)


어깨운동

바벨프레스

숄더프레스

사이드레터럴레이즈

바벨프론트레이즈

벤트오버레터럴레이즈


루틴을 바꿔서 여러부위에 자극을 더 주도록하자



반응형
반응형

[ 100번의 도전(6) ] 운동&식단 일지(0607 -등운동)


데드리프트 max 120x2


바벨로우는 가벼운 무게로 자극에 집중하며 올바른 자세를 유지하자


운동량이 좀 부족한듯 ㅜ.ㅜ



반응형
반응형

데이터 엔지니어로 살아가기 163일째(kafka, camus) 


기존에 kafka가 2개의 broker로 동작하고 있었는데 broker한대를 추가하게 되었다.


broker추가와 동시에 partition, replica 설정을 변경하는 작업을 하였다.


알파에서 테스트가 진행되었고 리얼에 적용을 하였는데 특정 topic으로 데이터를 처리하지 못하는 이슈가 발생하였다.


topic중 nginx - fluentd를 통해서 들어오는 데이터는 정상적으로 받고 있었지만


api서버에서 kafkaAppender로 로그를 produce하고 있는 topic이 정상적으로 동작하지 않았다.


원인은 api서버의 hosts파일에 kafka브로커들의 ip와 hostname이 등록되어 있지 않았기 때문이다.


기본적으로 api통신을 할 경우 acl이 뚫려 있고 어플리케이션 내부에서 ip로 목적지가 등록이 되어 있는 경우


문제없이 동작하여야 하지만 클라우데라를 통해 운영되고 있는 주키퍼, 카프카 등 하둡에코시스템이 호스트네임을 기반으로


서로 통신을 하고 있었기 때문에 ip정보만으로는 카프카 브로커를 찾아가지 못하는 문제가 있었다.


이번 문제로 많은 시간을 삽질을 하게되었지만 카프카 offset부터 camus가 어떤식으로 offset을 관리하고 있는지에 대해서


좀 더 깊게 들여다 볼수 있는 시간이 되었다.


camus는 현재 gobblin이라는 프로젝트로 넘어가 관리되고 있는 듯 싶었다.


카프카 특정 topic의 데이터를 hdfs에 적재해야한다면 gobblin을 검토해보면 좋을 듯 싶다.


이상~

반응형

+ Recent posts