반응형
 

개발자 에세이 4. 감출 수 없는 4가지(감기, 가난, 사랑, 그리고 프로그래밍 실력)

개발자 에세이 3. 대학교 4학년, 산타는 존재했다. (NHN인턴, 컴공) 개발자 에세이 2. 내가 원했던 연봉 3천의 삶(컴공 졸업을 앞두고) https://brocess.tistory.com/328 개발자 에세이 1. 인생은 내 멋대로 되

brocess.tistory.com


[ 포기하지 않으면 불가능은 없다. ]

인턴을 시작하고 1주일 동안 짧게 프로젝트를 진행 한 후 현업에 배치되었다.
약 6주 정도를 해당 부서에서 인턴 업무를 수행해야 했다.

인턴 중 한 명과 함께 글로컬개발팀?에 배정받게 되었다.
(2014년도의 일이라 정확한 부서명은 정확히 기억나진 않지만 해외에서 잘나가는 게임들을 들여와 국내에 맞게 로컬화 시키는 조직이었다)그 당시 해당 팀에서는 ‘포코팡(POCOPANG)’이라는 국민게임 및 다양한 게임들을 로컬화 시켜 개발 운영하고 있었다.

아무래도 아직 경험이 없는 인턴들에게 실제 운영되는 서비스 기능개발을 맡길 순 없었는지
둘이서 따로 프로젝트를 하나 진행해보라고 멘토분께서 제안주셨다.

같이 팀에 배정받은 분은 2살 많은 형이자 인턴 동기였다.
경쟁상대이긴 했지만 일단 똘똘 뭉쳐 프로젝트를 잘 완성해야만 했다.그렇게 몇일 간의 아이데이션 후 결정된 프로젝트는 바로
'유전자 알고리즘을 적용한 포코팡 게임 만들기' 였다. 스스로 성장해나가는 유전자 알고리즘을 개발하고 포코팡 게임을 만들어 적용시켜야 했다.

시작도 전이 었지만 머리가 지끈거렸다. '할 수 있을까' 라는 생각과 함께 부정적인 생각들이 머릿 속을 떠나지 않았다.

일단 포코팡과 같은 게임을 구현해야만 했다. 앞이 막막하긴 했지만 이미 주사위는 던져졌고 유니티를 활용해 클라이언트 개발을 진행했다.지금에 와서 생각해봐도 ‘어떻게 만들었지’라는 생각이 있지만 사람은 생각보다 궁지에 몰리게 되면 자신의 능력이상의 집중력과 능력을 발휘하게 되는 것 같다.

그렇게 2~3주 차에 어느정도 포코팡 클라이언트 개발을 마친 후 유전자 알고리즘을 이론을 학습하며 동시에 게임이 진행될 수록 스스로 성장해 높은 점수를 얻는 알고리즘을 개발하고 게임에 적용해 나갔다.

졸업작품을 진행하며 3~4개월이라는 시간동안 긴 프로젝트를 경험해보긴 했지만 이렇게 하루의 모든 시간을 할애하여 개발을 해 본건 이 때가 처음이었다.

원하는 기능을 몇 시간이고 구현하고 있지 못하는 나의 모습을 보며 한탄도 많이 하고 개발자로써의 길이 맞는지에 대한 의구심도 많이 들었다. 그만큼 나는 개발에 흥미가 많이 없었고 잘하지도 못했다.

그렇다고해서 힘들게 여기까지 왔는데 포기하고 싶지는 않았다.
원하는 만큼 완성도 있게는 만들지 못하더라도 포기하는건 죽기 보다 싫었다.

정말 태어나서 처음으로 미친듯이 개발만 생각하고 하루의 모든 시간을
개발에만 쏟아 부었던 것 같다. 6주라는 시간 동안 형과 나는 한 목표를 향해 주말도 포기한채 열심히 달렸고
프로젝트가 막바지에 다다라을 때는 우리가 애초 예상했던 것 보다 훨씬 완성도 있는 프로젝트를 팀원들에게 선보일 수 있었다.

매일을 ‘아 난 왜이렇게 멍청할까’라는 생각도 했었지만
그럼에도 불구하고 포기 하기보단 최선을 다하는 길을 선택했다.

‘불가능은 없다’라는 말처럼 정말 간절히 원하고 행동하면 그 꿈은 현실이 된다는 걸 증명했던 시간이었다.
포기하지 않고 움직이면 불가능할 것 같던 일도 현실이 되더라

반응형
반응형

오늘은 정말 인상 깊게 읽었던 포스팅 하나를 소개할까 합니다.

글의 제목은 '적당히 잘하는 개발자' 입니다.

한 번 쯤은 방문해 보셨을 법한 '자바캔'의 블로그를 운영하시는 최범균 님이 쓰신 포스팅입니다.

javacan.tistory.com/514#comment12490475

 

적당히 잘하는 개발자

졸업 전만 해도 굉장한 개발자가 되고 싶었다. 뛰어난 설계 능력과 코딩 속도를 자랑하는 그런 실력자 말이다. 이런 막연한 목표는 오래가지 않아 사라졌다. 3-4년 정도 경력을 쌓는 동안

javacan.tistory.com

이 글을 읽으면서 정말 많은 부분 공감하였습니다.

물론 저는 처음부터 '굉장한 개발자', '기술적으로 엄청 뛰어난' 개발자가 되고 싶지 않았음에도 많은 부분이 와닿았습니다.

개발자로 살아간다는 건 끊임 없이 나오는 IT기술들과 지식들을 습득하며 살아감을 의미합니다.

이렇다보니 어느 순간 '개발자로써 뒤쳐지면 어쩌지'라는 압박감을 가지고 살아가는 것 같습니다.

그리고 어느 순간 실력이 늘어나는 시점이 왔을 때 '와 나정도 실력이면 괜찮지'라는 생각이 들었다가 좀 더 다양한 경험들을 하며 공부를 하다보면 그런 생각을 했던 제 자신이 부끄럽게 여겨지는 시기도 오는 것 같습니다.

벼는 익을수록 고개를 숙인다는 말이 있듯이 IT분야에서도 통용되는 것 같습니다. 공부를 하면 할 수록 경력이 쌓이면 쌓일 수록 어느 한 편에 나도 모르는 불안감에 '모르는게 너무 많다'라는 생각이 듭니다.

하지만 제 생각엔 그렇습니다.

IT분야는 정말 광범위합니다. 한 사람이 그 모든 것을 잘 할 수 없습니다. 우리의 삶은 한정적이기에 굳이 지금 당장 필요하지 않은 것들을 습득하기 위해, IT 다양한 분야에서 뛰어난 개발자가 되기 위해 여가시간 모두를 사용하는 것은 어쩌면 즐거운 삶은 아닐 것 같습니다. 

너무 많은 부담감을 조금은 내려 놓고 지금 내가 하는 일을 잘하기 위해 시간을 보내다 보면 어느 순간 '적당히 잘하는 개발자'가 될 수 있을 거라는 생각이 듭니다. 적당히 잘하는 것도 쉬운 일은 아닙니다.

물론 뛰어난 개발자, 기술력으로 손꼽히는 개발자가 되는 것이 좋지 않다고, 나쁘다고 말하는 것이 절대 아닙니다.

어떤 개발자가 되고 싶은지는 본인이 선택하는 것이라고 생각합니다. 적당히 잘하는 개발자로 삶의 다양한 부분들에도 관심을 가지며 살아갈 것인지 많은 개인 시간과 노력을 투자해 정말 한 분야의 인정받는 뛰어난 개발자로 살아갈 것인지는 각자의 선택의 몫이라고 생각합니다.

또 정말 공감이 갔던 문구는 '꽤 많은 프로젝트가 기술 난이도가 아닌 다른 이유로 실패하는 것을 경험했다'입니다.

저 또한 다양한 프로젝트들도 경험하고 개인적인 토이프로젝트도 함에 있어서 해당 서비스들이 실패하거나 운영이 중단되는 이유는 결코 기술적인 부분의 결핍이 아니였습니다. 기술은 정말 중요하지만 서비스가 잘 돌아가기 위해 필요한 요소 중 하나라는 사실입니다. 높은 기술력 보다는 어쩌면 홍보나 마켓팅, 기획, 운영 등이 더 중요할지도 모릅니다.

어떤 개발자가 될 것인지? 이번 기회에 한 번 생각해보시면 좋을 것 같습니다.

youtu.be/GtJZTzJ2sxQ

 

긴 글 읽어 주셔서 감사합니다🙏

반응형
반응형

안녕하세요 오늘은 "개발자가 적성에 맞는지?" 에 대한 주제로 포스팅 해볼까 합니다.

일단 저는 판교 IT회사에서 7년차 개발자로 일하고 있습니다.

개발자분들이시라면 아니 대한민국에서 직장을 다니시는 모든 분들이시라면 한 번쯤은 "내가 하는 일이 내 적성에 맞는건가?" 라는 질문을 해보셨을거라 생각합니다.

저 또한 그렇습니다.

개발자로 처음 회사에서 일하던 2014~2015년 정말 하루 하루 수십번도 더 고민했습니다. 왜냐구요???

 

너무 못하는 것 같아서요. 주변 사람 동료들과 비교했을 때 너무 부족하다고 느꼈고 그로 인해 자신감과 자존감을 바닥을 향해 달려가고 있었으니까요. 경쟁사회에서 내가 남들에 비해 잘하지 못한다고 생각이 드는데 그 일이 재미있을 수가 있을까요??? 하물며 전혀 못해도 밥먹고 사는데 지장없는 게임을 하는데도 이 룰이 적용되는 걸 본다면요.

 

개발자로 일을 해서 밥벌이를 해야 하는 것은 결국 개발자로서의 능력을 갖추어야 하는 것이 첫 번째입니다. 이 기본적인 능력이 갖추어지지 않는 이상  '개발이 내 적성에 맞는건가'라는 고민이 뒤를 따라다니며 괴롭힐 것 입니다. 기본적인 능력이 갖추어지지 않은 상태라면 매번 회사에서의 일이 고되고 남들과의 비교에서 오는 자괴감에 더 이상 개발자로 일하고 싶지 않을 것 입니다.

 

저 또한 그랬습니다.

 

신입으로서 부족한게 당연한거지만 그럼에도 불구하고 잘하는 주변 동기들을 보며 한 없이 작아지는 저의 모습을 마주했습니다. 특히나 '개발'이라는 분야는 더욱 그런 것 같습니다. 같이 입사한 신입사원임에도 그 실력차이는 비교도 안 될 만큼 크게 날 수 있습니다. 하지만 그렇게 포기하고 싶지는 않았습니다. 정말 자존감은 하루 하루 바닥을 칠 정도로 힘들었지만 이렇게 포기한다면 어떤 일을 하더라도 잘해낼 수 없을 것 만 같았습니다. 정말 나중에 너무 힘들어 회사를 그만 두더라도 최소한 내 스스로에게 "그래 할 만큼 했어"라는 최소한의 핑계거리라도 있어야 아쉬움이 남지 않을 것 같았습니다. 

 

그래서 공부했습니다. 저의 목표는 남들에게 엄청난 인정은 받지 못할 지언정 스스로 '아 이 정도면 그래도 나는 최소한 개발자의 능력은 갖추었어!'라는 생각이 들정도였습니다. 그 정도 까지 가는데는 최소 2년에서 3년은 필요할 것 같다는 생각이 들었습니다. 그래서 공부했습니다. 회사가 끝나고 회사에 남아 최소 3~4시간 이상 공부하였습니다. 하지만 이 정도 공부는 저 뿐만 아니라 동기들 대부분이 하였습니다.

 

저는 이 정도로는 안된다고 생각했고 집 주변에 독서실을 끊어 주말 공휴일 독서실을 다니며 동기들보다 조금이나마 더 공부하려고 노력했습니다. 지금은 그 때처럼 주구장창 독서실에 앉아 책을 읽으며 개발공부를 하지는 않습니다. 하지만 그 당시 제대로 된 공부 방법도 몰랐고 무엇을 어떻게 해야 할지 감도 안잡히던 시절 내가 공부하고 있는 분야의 지식을 이론적으로 습득하는 것만으로도 제 스스로에게 굉장히 힘이 되었습니다. 그리고 회사에서 프로그래밍을 할 때 이해가 되지 않던 부분들에 대해서도 차근 차근 이론적인 공부가 뒷받침되니 이해되는 부분이 굉장히 넓어졌습니다. 그렇게 시작하였습니다.

 

저는 동기들보다 더 많이 노력하고 공부하여야 했습니다. 그렇게 시작한 공부했던 시절들이 "개발자 안했으면 어쩔 뻔 했어"라는 생각을 가지게 된 지금의 저를 만들었습니다. 6년 동안 기술블로그를 운영하고 회사가 끝나면 토이프로젝트를 하고 개발 관련 유튜브 영상을 찍고 있는 저를 만들었습니다. 신기하지 않습니까?

 

그래서 저는 생각합니다.

 

개발자가 적성에 맞는지? 고민하는 시간에 조금이라도 시간을 투자해 공부해야 한다고, 적성에 맞는지 안맞는지는 스스로가 그 분야에 대해 어느 정도 실력이 생기고 나서 해보는 것이라고, 그러지 않을거면 적성에 맞지 않아 그만뒀다고는 하지 말자고.

 

정말 잘하는 실력을 갖추었음에도 그 일이 재미없고 일을 하는 동안 지겹고 따분하기만 하다면 그게 바로 적성에 맞지 않는 것 입니다. 제가 생각하기엔 그렇습니다. 제가 경험했고 컴퓨터공학부 시절 코딩은 나랑 안맞는다며 살아온 제가 이렇게 변했습니다.

 

이 글을 읽는 모든 분들은 그래도 내면에 '개발을 잘하고 싶다'라는 생각은 조금이나마 다들 가지고 있으실 거라 생각합니다. 그렇기 때문에 이렇게 고민하고 계시는 거고 이 글을 여기까지 읽고 계실거라 생각합니다. 

 

그렇다면 '개발자가 적성에 맞는지' 확인하기 위해 그만 둘 땐 그만 두더라도 '밑져야 본전'이다는 심정으로 1년만 투자해보세요.

달라집니다.

해당 내용을 영상으로 만들어보았습니다.

www.youtube.com/watch?v=Z5EVaaKSx9A

 

반응형
반응형

2019 한 해 유익했던 IT기술블로그 모음 [1편]

 

2019 한 해 유익했던 IT기술블로그 모음 [1편]

매번 개발시 막힐 때 마다 구글에 검색을 하게 된다. 검색을 하다 보면 너무 깔끔하게 정리가 잘 된 글들을 만나기도 하고 정말 문제 상황에 대한 해결책만 정리된 글들을 보기도 한다. 그 중에 정말 두고두고 나..

brocess.tistory.com

 

이번에는 저번 포스팅에 이어 유익했던 IT기술블로그 2편에 대해 포스팅 해보도록 하겠습니다.

2020년에는 한 달에 한 번정도 읽었던 글들 중 괜찮았던 글들을 정리하는 시간을 가져보려 합니다.

 

1편에서도 말씀드렸다시피 저는 현재 지금 제가 주로 현업에서 다루는 기술스택은 다음과 같습니다.

[ 스프링, 자바, Vue JS, 리눅스, MYSQL, Hadoop, Spark, Hive, Impala, Cassandra 등]

 

1. 데이터 이상징후 탐지 시스템에 대한 SK플래닛 포스팅

현재 데이터를 다루는 업무도 하고 있다 보니 항상 데이터에 대한 품질 및 비정상적인 데이터 유입 및 처리 방법에 대해서도 관심을 가지고 있습니다. 이에 관련해서 SK 기술 블로그에 Spark Streaming을 사용해 탐지 프로세스를 정리한 글이 있어 추후 관련 시스템을 개발시나 유사한 모듈 개발시 많은 도움을 받을 수 있을 것 같아 남겨봅니다.

http://web.archive.org/web/20170606145044/http://readme.skplanet.com/?p=13557

 

데이터 입수 이상징후 탐지

수안녕하세요. Data Infrastructure팀(이하 DI팀)에서 최근에는 주로 Data Application 개발을 하고 있는 Data Engineer 추이삭입니다. 이번

web.archive.org

 

2. 시계열 데이터의 시각적 분석에 관한 글

데이터 시각화로 인사이트 도출을 하는 글로 다양한 예시와 쉬운 설명으로 정리한 글입니다. 

데이터를 다룰 때 항상 드는 생각은 일반 텍스트 파일형태로 적재되어 있는 것을 보는 것 보다 데이터 목적과 유형에 맞게 시각화시켜 본다면 다양한 인사이트를 도출해낼 수 있을 거라 생각합니다.

https://brunch.co.kr/@dimension-value/19

 

시계열 데이터의 시각적 분석(1) 어디까지 가능할까?

시계열 데이터를 활용한 다양한 시각화 사례 | 데이터 시각화만으로 인사이트 도출이 가능할까요? 가능하다면 어디까지 할 수 있을까요? 얼마 전 뉴스젤리 블로그에 발행한 '데이터 속 인사이트 찾기, '시각화'로 충분하다'라는 글에 대한 반응이 뜨거웠던 점을 생각해보면, 아마 많은 분들이 이 질문을 갖고 계셨던 것 같습니다!'시각화'로 하는 데이터 분석(visualization analysis)은 텍스트 형

brunch.co.kr

 

3. 자바 스트림에 관한 고급 정리 편

자바8버전 이상을 쓰시는 분들은 lamda나 stream을 많이 사용하실 텐데요. 관련해서 좀 더 stream을 잘 사용할 수 있는 방법과 일반적으로 그냥 stream을 썼을 때 놓칠 수 있는 부분들이 잘 정리되어 있어 공유해봅니다. 해당 블로그로 가보시면 stream 총정리글도 있으니 아직 자바8 stream에 대해 익숙하지 않으신 분들도 도움을 받으실 수 있을 거라 생각합니다.

https://futurecreator.github.io/2018/08/26/java-8-streams-advanced/

 

Java 스트림 Stream (2) 고급

이전 포스트에 이어서 Java 8의 스트림(Stream)을 살펴봅니다. 자바 8 스트림은 총 두 개의 포스트로, 기본적인 내용을 총정리하는 이전 포스트와 좀 더 고급 내용을 다루는 이번 포스트로 나뉘어져 있습니다. Java 스트림 Stream (1) 총정리 Java 스트림 Stream (2) 고급 살펴볼 내용 이번 포스트에서 다루는 내용은 다음과

futurecreator.github.io

 

4. 쿠팡 데이터 플랫폼의 진화

쿠팡이 데이터를 처리하는 시스템이 발전해가는 모습을 소개하며 어떻게 데이터를 다루고 있는지에 대해 잘 정리된 글입니다. 꼭 해당 글이 쿠팡의 데이터 처리 history만 설명하고 있다기 보다는 전반적으로 2010년 부터 데이터를 다루는 많은 회사들이 발전해 온 모습을 담고 있지 않나 생각해봅니다. 데이터 엔지니어들이 하는 업무가 궁금하시거나 대용량의 데이터들은 어떻게 처리되는지 궁금하신 분 들, 현업에서 데이터엔지니어로 일하시고 있는 분들이 읽으면 매우 좋을 것 같습니다.

https://medium.com/coupang-tech/%EC%BF%A0%ED%8C%A1-%EB%8D%B0%EC%9D%B4%ED%84%B0-%ED%94%8C%EB%9E%AB%ED%8F%BC%EC%9D%98-%EC%A7%84%ED%99%94-26c827c1ec09

 

쿠팡 데이터 플랫폼의 진화

쿠팡은 라스트 마일 배송과 모바일 퍼스트 플랫폼에서 고객이 상품을 발견하는 새로운 방식을 선사함으로써 한국의 이커머스 시장을 혁신하고 있습니다. 쿠팡의 미션은 고객이 “쿠팡 없이 그동안 어떻게 살았을까?”라고 생각하는 세상을 만드는 것입니다.

medium.com

 

5. 띵글, 훌륭한 개발 문화의 이면에 대한 포스팅

해당 포스팅을 보고 한국 IT산업에서 개발자로서의 삶과 방향에 대해 생각해보게 만들었던 글입니다.

글의 저자분은 개발자들이 관리자가 아니라 별도의 트랙을 따라 수석 엔지니어나 아키텍트, 임권급에 해당하는 특임 엔지니어(Distinguished engineer), 펠로우(Fellow) 혹은 CTO의 열학을 수행하는 것을 보고 싶다고 말하고 있습니다.

비슷한 내용으로 연재된 글들이 많으니 앞으로 개발자로서의 방향이나 지금 걷고 있는 길에 대해 고민이 되신다면 방문하셔서 좋은 내용의 글들을 보며  생각을 정리해보는 것도 좋을 것 같습니다.

http://channy.creation.net/blog/1238

 

훌륭한 개발 문화의 이면(7) – 잉여력이냐 vs. 효율성이냐 :: Channy's Blog

 

channy.creation.net

 

6. 클라이언트들과 직접 맞닿은 서비스를 운영하는 개발자가 읽지 않으면 손해인 글?

클라이언트와 접해 있는 시스템을 운영하다 보면 정말 많은 장애들을 맞닥드리게 되고 해당 장애를 처리하며 또 다른 사이드이펙트를 경험한 적이 있으실 겁니다. 우아한형제들 광고시스템팀의 개발자분이 그동안 경험했던 다양한 문제상황들을 얘기하며 주의해야 할 부분들에 대해 설명해주시고 있습니다. 읽어보시면 아시겠지만 분명 내가 장애를 냈던 상황과 유사한 내용이 있어 뜨끔하실지도 모르겠습니다. 

해당 블로그에 정리된 것들만 조심해도 우리는 크리티컬한 장애를 예방하는데 많은 도움을 얻을 수 있을 거라 생각합니다.

http://woowabros.github.io/experience/2019/09/19/programmer-murphy-law.html

 

개발자 머피의 법칙 - 우아한형제들 기술 블로그

안녕하세요, 우아한형제들 광고시스템팀의 손권남입니다.

woowabros.github.io

 

7. 데이터 품질에 관한 5개 체크포인트

네이버 기술블로그 D2에 19.08.06 연재된 글로 데이터 비지니스 업계의 개발자라면 '코드 품질' 만큼이나 '데이터 품질'에도 신경쓸 필요가 있다는 말이 제일 와닿았던 것 같습니다. 데이터 처리에 관심이 있으신분들은 시간내서 읽어 보시면 좋을 것 같습니다.

https://d2.naver.com/helloworld/1179024

불러오는 중입니다...

 

 

감사합니다. 이번 포스팅은 여기서 마치도록 하겠습니다.

연말 마무리 잘하시고 '나만알고싶은IT글' 카테고리의 포스팅은 2020년 2월 초에 찾아뵙도록 하겠습니다.

반응형
반응형

매번 개발시 막힐 때 마다 구글에 검색을 하게 된다.

검색을 하다 보면 너무 깔끔하게 정리가 잘 된 글들을 만나기도 하고 정말 문제 상황에 대한 해결책만 정리된 글들을 보기도 한다.

 

그 중에 정말 두고두고 나중에도 봐야겠다 싶은 포스팅들이 있다.

그 포스팅들을 메모장에만 정리해놓다 보면 이후에 어디에다 적어놨는지 찾기가 힘들어

해당 포스팅 글의 내용이 필요한 경우 찾아보기가 힘들다.

 

그래서 앞으로는 한 달에 한 번 정도의 주기로 내게 도움이 됬고 유익한 포스팅들을 내 블로그에 모아 볼까 한다.

그 시작을 2019년 유익하게 보았던 포스팅을 소개해 보려고 한다.

 

1편, 2편으로 나누어 7개 정도로 포스팅 하려고 한다.

그에 앞서 지금 제가 현업에서 다루는 기술스택은

[ 스프링, 자바, Vue JS, 리눅스, MYSQL, Hadoop, Spark, Hive, Impala, Cassandra 정도가 되는 것 같다. ]

 

1. 리눅스 서버 60초 안에 상황파악하기

실제 서비스 운영중 서버에서 장애가 났을 경우 핵심 정보를 파악하는 커맨드 명령어를 깔끔하게 정리해 둔 포스팅이다.

기본적으로 해당 포스팅에 기술된 10가지 명령어만 제대로 알고 있어도 장애시 좀 더 빠르게 원인을 찾아 낼 수 있을 것 같다.

https://b.luavis.kr/server/linux-performance-analysis 

 

Luavis' Dev Story - 리눅스 서버 60초안에 상황파악하기

 

b.luavis.kr

 

2. Slow Query를 발생시키는 어플리케이션 구현하고 Thread Dump 분석하기

쓰레드의 개념적인 내용과 Life Cycle의 간단한 설명과 함께 Slow Query를 실행하는 애플리케이션을 구현하고 이를 테스트 하는 과정을 체계적으로 설명하고 있다. 이 과정에서 발생하는 CLOSE_WAIT이 많이 쌓이는 이슈 및 쓰레드 덤프를 통한 분석에 대한 내용까지 일목요연하게 다루고 있어 실제 Database나 외부 시스템들과의 연계된 어플리케이션을 개발하고 있다면 꼭 읽어 보고 이러한 상황에도 유연하게 대처할 수 있도록 하자.

https://brunch.co.kr/@springboot/126

 

Thread Dump 분석하기

- 쓰레드 덤프 분석하기 | 쓰레드 기본 개념을 간단하게 정리하고, 간단한 예시를 통해서 쓰레드 덤프를 분석하는 방법에 대해서 공유한다. 쓰레드 개념 정리 쓰레드 기본 개념을 정리한다. 쓰레드란? 생략한다. 알아서 찾아보길 바란다. 쓰레드 종류 쓰레드는 데몬 쓰레드(Daemon Thread)와 비데몬 쓰레드(Non-daemon Thread)로 나눌 수 있다. 데몬 쓰레드는 일반적인

brunch.co.kr

 

3. MySQL 쓰면서 하지 말아야할 것 17가지

서비스를 개발하는 개발자라면 데이터베이스를 대부분 쓸텐데 해당 글을 읽어보면 꼭 mysql이 아니더라도 다른 rdbms에도 도움이 될 만한 내용을 깔끔하게 정리해두었으니 참고해보면 좋을 듯 하다.

https://blog.lael.be/post/370

 

MySQL 쓰면서 하지 말아야 할 것 17가지

*MySQL 쓰면서 하지 말아야 할 것 17가지* 권장사항이다. 이것을 이해하면 당신의 어플리케이션이 더 나은 성능을 발휘할 것이다. 다만 이것이 사람의 실력을 판단하는 척도로 사용되서는 안 될 것이다.   작게 생각하기 – 조만간 규모가 커질거라면 MySQL ecosystem을 봐야된다. – 그리고 캐싱 빡시게 안 하는…

blog.lael.be

 

4. Scala + Gradle intelli J로 프로젝트 구성하기

실제 spark 작업을 통해 데이터를 뽑는 adhoc작업도 간혹 진행하고 있는데 이 때마다 실제 운영서버의 spark-shell을 열어 작업을 했었다. 이로 인한 문제점은 spark-shell의 작업으로 인해 실제 운영서버에서 돌아야할 작업들이 리소스 부족으로 악영향을 받는 상황이 발생할 수 있다는 것이다. 하지만 편리상 spark-shell로 작업을 진행했었는데 앞으로는 작업해야할 내용들을 실제 로컬환경에 환경을 구성해 돌려보고 해당 작업이 완성되었을 때 spark-submit을 통해 configuration을 적절히 설정하여 돌리기로 맘먹었고 로컬에 환경을 구성할 때 참고했던 블로그이다. spark1.5, 1.6 버전대와 spark2버전대 scala+gradle template을 만들어 놓았는데 필요한 분이 있다면 공유드릴 수 있도록 하겠다.

https://krksap.tistory.com/584

 

Big Data Handling을 위한 Scala - 제9편 Scala + Gradle + Intelli J로 프로젝트 구성하기 01

Big Data Handling을 위한 Scala - 제9편 Scala + Gradle + Intelli J로 프로젝트 구성하기 스칼라 스터디를 시작하고 스칼라로 뭘 짜봐야 겠다는 생각을 했는데 배포까지 하려면 SBT보다는 Gradle로 빌드하는게..

krksap.tistory.com

 

5. Spark의 기본 연산들의 동작방식에 대해 잘 설명되어 있는 포스팅

Spark의 기본 연산들인 combineByKey, reduce, aggregateByKey, filter, groupByKey, flatMap 등 중요한 내용들이 참 잘 설명되어져 있다. Spark를 다루시는 분들이라면 참고해 보면 좋을 듯 하다.

https://backtobazics.com/category/big-data/spark/

 

Spark Archives - Back To Bazics

Spark combineByKey RDD transformation is very similar to combiner in Hadoop MapReduce programming. In this post, we’ll discuss spark combineByKey example in depth and try to understand the importance of this function in detail. Continue reading “Apache Spa

backtobazics.com

 

6. Spark 메모리 관리

Spark의 메모리 관리에 대해 잘 정리된 글로 실제 Spark를 사용해본 분들은 알겠지만 out of memory error가 자주 잘 발생한 경험이 있을 것이다. 메모리 기반 연산처리를 하기 때문인데 Spark가 메모리를 어떻게 사용하고 어떻게 Config를 구성하여 작업하면 좋은지 정말 잘 깔끔하게 정리되어 있고 심도 있는 내용까지 다룬다.

https://medium.com/@leeyh0216/spark-internal-part-2-spark%EC%9D%98-%EB%A9%94%EB%AA%A8%EB%A6%AC-%EA%B4%80%EB%A6%AC-2-db1975b74d2f

 

Spark Internal Part 2. Spark의 메모리 관리(2)

Unified Memory Management in Spark 1.6(1)

medium.com

 

7. 일급 컬렉션(First Class Collection)의 소개와 써야할 이유

일급 컬렉션이 뭔지 궁금하신분? 객체지향적 리팩토링하기 쉬운 코드로 가기 위해서는 왜 일급 컬렉션을 써야하는지 예시와 함께 잘 정리된 글이다. 해당 포스팅의 저자는 Enum과 마찬가지로 일급 컬렌션은 객체지향 코드로 가기 위해 꼭 익혀야할 방법 중 하나라고 소개하고 있다.

https://jojoldu.tistory.com/412

 

일급 컬렉션 (First Class Collection)의 소개와 써야할 이유

최근 클린코드 & TDD 강의의 리뷰어로 참가하면서 많은 분들이 공통적으로 어려워 하는 개념 한가지를 발견하게 되었습니다. 바로 일급 컬렉션인데요. 왜 객체지향적으로, 리팩토링하기 쉬운 코드로 갈려면 일급..

jojoldu.tistory.com

2019 한 해 내게 유익했던 IT기술블로그 모음 1편은 여기서 마치도록 하겠습니다.

다른 분들께도 유익한 포스팅 모음 글이 된다면 좋겠네요.

 

반응형
반응형

프로그래밍을 배워야하는 3가지 이유

 

오늘은 프로그래밍을 배워야하는 3가지 이유에 대해 얘기해보려고 합니다.

 그럼  프로그래밍을 배워야하냐

물론 IT회사에 개발자로 일하고 싶으신 분들은 무조건 배워야 하지만 

 개발자로 일하지 않더라도 프로그래밍을 배우면 좋은 3가지 이유에 대해 이야기 해보겠습니다.

 

 

[  번째로, IT시대를 살고 있는 지금 IT 우리의 삶과 떨어질  없는 존재입니다 ]

현재 IT 농업건설자동차의학  장르를 불문하고 많은 비중을 차지하고 있습니다.

병원에서는 의료용 로봇이 수술을하고 운전도 IT시스템에 의해 자율주행을 하는 시대에 살고 있습니다.

그렇기 때문에 프로그래밍을 이해하고 있는 사람과 그렇지 않은 사람간에는 사고의 깊이가 다를  밖에 없습니다.

마치 영어를 배우면 다양한 사람들과 소통을 하며  사람들의 생각과 문화를 이해할  있게 되고

영어로  수많은 문서를 읽을  있게 되며  넓은 세상을   있게 되는 것과 비슷하다고 생각합니다.

주변을 둘러보면 온통 우리의 삶은 온통 IT 접해있습니다프로그래밍을 배움으로써 삶에서 마주하는

새로운 기술, IT 서비스를   주체적으로 이해하고 사용하며 새로운 통찰력을 얻을  있습니다.

 

 

[ 두 번째로프로그래밍을 공부하게 되면 논리적으로 사고하는 문제해결능력을 기를  있습니다 ]

저는 문과출신 컴퓨터공학부 학생으로 대학생때와 개발자 5년차인 지금의 모습을 비교했을  

가장 크게 차이나는 부분은 어떤 문제가 주어졌을  논리적으로 사고하고 문제를 해결해 나간다는  입니다.

프로그래밍을 하게 되면 사소한 문제들에 많이 부딪힙니다문자 하나만 잘못 입력해도 컴퓨터에서 생각대로 동작하지 않으며

사람과의 커뮤니케이션방식과는 다르게 정해진 방식으로 컴퓨터와 대화하지 않고서는 문제를 해결할  없습니다.

따라서 컴퓨터가 프로그래밍 언어를 이해하고 처리하는 방법을 학습하고 그에 맞게 프로그래밍을 수행하여야 합니다.

 과정에서 논리적으로 사고하는 법을 학습하게 되고 프로그래밍과정중 문제를 해결하는 과정에서 문제해결능력 또한

기를  있습니다

실제로 스티브잡스 “컴퓨터를 어떻게 프로그래밍하는지 모든사람들이 배워야 합니다.

왜냐하면 그것은 당신에게 생각하는 법을 알려주기 때문입니다. 라고 말하기도 했습니다.

 

[ 세 번째로 머릿속의 생각을 현실세계에서 구현할  있습니다꿈의 현실화라고 말하고 싶습니다 ]

프로그래밍을 하며 느끼는 가장  매력포인트라고 생각합니다.

단순 반복적인 엑셀업무를 시스템화해서 자동으로 처리하고내가 생각만 해왔던 서비스를 웹사이트를 만들어 서비스 하는 

 머릿속에 있는 생각을 현실세계로 가져와 실현할  있습니다.(꿈의 현실화)

 

프로그래밍을 하게 되면 가장 크게 좋은 점을 3가지로 간추려보았는데요.

물론 프로그래밍을 처음 시작하면 어렵겠지만 영어처럼 언어를 공부한다는 생각으로 조급해 하지 않고

조금씩 공부해보는 것도 나쁘지 않을  같습니다다만 가장 프로그래밍을 빨리 배울  있는 방법은

목표의식을 가지고 하는 거라고 생각합니다내가 업무에서 이런 반복적인 업무들을 하고 있는데

시스템화 해서 자동화 하고 싶다던지 내가 생각하는 웹서비스를 운영해보고싶다던지 하는 동기부여가 있다면

  재미있게 프로그래밍 공부를 하실  있을  같습니다.


감사합니다 오늘 포스팅은 여기서 마치도록 하겠습니다!

 


반응형
반응형


Spark dataframe(스파크 데이터프레임)으로 작업 중 dataframe의 null값을 특정값으로 바꾸고 싶은 경우가 있다.


이 때 주의해야할 점은 dataframe의 컬럼의 자료형 타입에 맞게끔 변환해줘야 정상적으로 replace된다.



다음과 같은 데이터프레임(dataframe)이 있을 때 "bid_i"의 값을 0으로 변경하려고 다음을 실행


val result_df_q_new = result_df_q.na.fill(0, Seq("bid_i"))


위와 같은 명령을 수행하고 확인을 해도 정상적으로 null값이 0으로 변경되지 않은 걸 확인할 수 있었다.


원인은 bid_i의 자료형 타입에 맞지않게 변경하려했기 때문이다.



위에서 보듯이 "bid_i"의 자료형 타입은 string인데 0으로 변경(na.fill메서드를 하려고 하니 정상적으로 변환되지 않았던 것이다. 

(처리 도중 딱히 에러메세지가 없었다...)


val result_df_q_new = result_df_q.na.fill("0", Seq("bid_i"))


0을 string형(큰따옴표)를 씌워서 명령어를 주니 정상적으로 변경되는 것을 확인할 수 있었다.


데이터프레임(dataframe) 값을 na.fill을 통해 변경할 때는 자료형타입을 잘 확인하도록 하자!


반응형
반응형

동시성 코드와 블로킹(blocking)콜 그리고 아카(akka)

여러 개의 스레드가 동시에 작업을 수행하더라도 synchronized 블록이나 데이터베이스, 네트워크 API 호출 등을 만날 다른 스레드와 나란히 줄을 서서 순차적으로 작업을 수행해야 하는 경우도 있다. 암달의 법칙은 프로그램이 있는 속도의 상한이 이런 순차적 코드가 사용하는 시간에 의해서 제한된다고 말한다. 이러한 순차적 코드의 다른 이름은 블로킹(blocking)콜이다. 조금 과장해서 말하자면 자바 개발자가 스레드를 이용해서 만들어내는 '동시성' 코드는 일종의 신기루다. 사실은 코드 곳곳에 존재하는 블로킹 , 순차적 코드 때문에 전체적인 프로그램의 처리율은 이미 상한이 정해져 있지만 여러개의 스레드가 '동시에' 동작한다는 사실로부터 위안을 받을 뿐이다.


아카(akka) 스칼라(scala)언어로 작성되었지만 아래로 내려가면 자바의 동시성 패키지를 사용하기 때문에 아카를 사용하는 것은 궁극적으로 자바의 Thread Task 사용하는 것과 마찬가지다. 하지만 아카를 사용하면 프로그램 곳곳에 존재하는 순차적 부분, 블로킹 콜을 전부 없애거나 최소한으로 만드는 것이 가능해진다. 아카(akka) 이용해서 프로그램을 설계하는 것은 블로킹 호출이 일어나는 지점을 논블로킹 호출로 전환하는 작업을 수행하는 것을 의미한다.



반응형

+ Recent posts