Seungdols Company

“Fake it till you make it”의 함정"

Wed, 07 Sep 2022 23:59:00 GMT

원본은 아래 트위터에서 남긴 글입니다. 혼자만의 생각이라, 문체가 불편할 수 있는 점 사전에 사과 드립니다.

아래의 내용은 모두 어쭙잖은 내용일 수 있습니다. 모든 분들에게 도움이 되지 않을 수 있는 내용임을 밝힙니다.

“Fake it till you make it” 문구는 내 예전 jeykll blog 문구였는데 어느 순간 나는 이게 불가능하다는 것을 알게 되었다.

그래서 그냥 늘 “전 잘 모르는데”를 달고 살고, 상대에게 내가 알던게 잘못된 거면 배웠다고 말하고 몰랐던걸 알게 되면 많이 배웠다고 말한다.

결과적으로 나한테 “그 연차에 어쩌네 저쩌네 하는 사람”이 있다면, 어차피 같이 일 안하면 그만이다. 연차를 떠나서 꼭 상대방이 아는 걸 다 알아야 할 필요는 없다. 난 여기서 협업의 시너지가 생성 되는 지점이라고 믿는다.

결과적으로 주니어가 보기에 어쭙짢아 보이는 시니어를 무시할 필요도, 시니어가 주니어를 존중해주지 못할 이유도 없어지는 지점이라고 생각한다. 다 같이 좋은 서비스의 특징을 합일화 하면 회사도 만족할만한 성과 아닐까?

다시 돌아가 명문장인 “Fake it till you make it”은 과연 실행 가능한 말일까? 이 부분이 실행 가능하려면, 애초에 능력이 어느 정도 되는 프로그래머여야 된다는 것이다.

결과적으로 아직 해보지 않았지만, 지금까지의 경험치로 봤을때 직관이 생긴 시점에나 말할 수 있는 말인 것이라 생각 한다.

주니어, 시니어 모두 통틀어서 직접 코드로 찍먹 해보지 않았다면, 일단 아닐 가능성이 있다는 것을 염두해두고 말하는 것이 서로에게 유익하다. 최근까지만 해도 추측의 말로 “이럴 것이다.”라는 언어를 많이 써온 나부터 반성하게 되는 지점이다. 결과적으로는 좋은 프로그래머는 뭐든 찍먹을 해본자이다.

그래야 경험치가 쌓이고, 직관이 생긴다. 물론 그 직관 조차도 검증을 해보는게 “좋은 프로그래머”아닐까 싶다.

https://twitter.com/seungdols/status/1567191947160465409?s=20&t=1r5ep09f6-zKBxVjEDZF5A

노력의 힘이란

Tue, 02 Aug 2022 23:59:00 GMT

LinkedIn에서 구글 UX 리드 디자이너이신 김은주님의 소식을 팔로우 하고 있는데, 좋은 글을 보게 되어 공유 합니다. 구글에 40번의 지원 끝에 합격하게 된 포스팅인데, 두 가지의 생각이 들었습니다.

구글의 문턱은 높구나.
노력 하면 안되는 것은 없구나.

결과적으로 안 된다는 나의 마음 가짐일뿐이지, 노력 하면 된다는 것을 알 수 있었습니다. 그런데, 어쨌거나 39번의 실패가 아닌 reject였다는 점이 좋았습니다.

면접에 떨어졌다고 해서 실패가 아니라는 사실.

최근에 생전 처음으로 몇번의 면접을 봤었는데, 정말 긴장하니까 횡설수설 내가 무슨 말을 하는지도 잘 모르겠고, 내가 뭘 했더라? 기억도 잘 나지 않았습니다. 준비가 덜 되었으니, 당연히 불합격들을 받았습니다. 대신 깨닫는 것들이 많았습니다.

더군다나, 이력서나 경력기술서 같은 류들은 어떻게 써야 하는지도 너무 쉽지 않았습니다. 그렇지만, 결과적으로 계속 두들기면 문은 열리게 되어 있다는 사실을 이 글을 보고 깨달았습니다.

https://www.linkedin.com/posts/eunjookim_google-acceptedoffer-application-activity-6958417860129955841-E4yY?utm_source=linkedin_share&utm_medium=member_desktop_web

앞으로 더욱 노력 가보자고 💪🏻

Let's agree to disagree를 받아들이는 사람이 되자

Thu, 02 Jun 2022 23:59:00 GMT

아침에 유퀴즈 짧은 영상을 하나 보게 되었습니다.

이미 보셨을지도 모르지만, 사회 심리학자분께서 말하는 한국인의 심리를 말씀 해주시는데, 굉장히 공감이 많이 가게 됐습니다.

영상 후반부에 나오는 특징 중 하나가 “나와 의견이 다른 것을 참지 못한다” 결국 인정 해주지 못한다는 것이죠.

동의, 비동의 모두 같은 맥락의 의견입니다.

결과적으로 나와 생각이 다르면, 설득 하는 문화가 팽배하죠.

어찌 보면, 개발자가 일 하는 모든 공간에서 의견이 다를 수 있습니다.

흔한 코드 리뷰나 시스템 설계에도 의견은 다를 수 있습니다.

해당 영상을 보면서 나도 저렇게 행동하지 않았나? 나와 다르면, 설득 하려고 하지 않았나? 한번이라도 상대 입장, 관점에서 생각 해보기나 했나?

왜 이렇게 생각 하는지 들어보려고 노력 했던 적이 손에 꼽는 것 같습니다.

“왜 이렇게 코드를 작성했지? 어떤 의미지? 내가 리뷰한 코드가 더 좋지 않나?” 내 설계가 맞지 않은지? 바꾸도록 설득 해야겠다.

결과적으로 많은 토론으로 이루어진 설계가 더 단단해지고, 코드에 대해 이야기를 많이 할 수록 더 오래 살아남는 코드가 되는 것 같습니다.

하지만, 모두가 동의하는 것은 어디에도 없다는 것을 인정하고, “동의하지 않음”에 대해서도 용인해주고, 인정 해주어야 합니다.

Let’s agree to disagree. 개발자도 결국 사람입니다.

https://youtu.be/HqXaZqNZxVk

코드스피츠 77 - ES6+ 기초편 6회차 (Generator, Promise, Async/Await)

Wed, 27 Apr 2022 23:59:00 GMT

Generator

const infinity = function*() {
  let i = 0
  while (true) yield i++
}

console.log(infinity.next())

yield를 이용하면 블록을 중간에 끊어주는 효과가 발생 => JS에서는 하나의 문들을 Record로 만들어 주고, 해당 레코드를 실행 할지 말지를 결정 하게 됨.

suspension, generator, command pattern등 여러 가지 개념들이 설명 되어 나오는데, 각각을 잘 이해하는게 중요하다.

gererator + async + executor

generator => 흐름을 멈춰준다.

const profile = function*(end, next, r) {
  const userid = yield $.post('member.php', { r }, next)
  let added = yield $.post('detail.php', { userid }, next)
  added = added.split(',')
  end({ userid, nick: added[0], thumb: added[1] })
}

const executor = (end, gene, ...arg) => {
  const next = v => iter.next(v)
  const iter = gene(end, next, ...arg)
  iter.next()
}

executor(console.log, profile, 123)

위 코드 이해하는 것… 어렵..

executor() 함수가 호출 될 경우 -> next가 선언 되고, 해당 iter에서 실행 되면, profile 제너레이터의 첫번째에서 흐름이 중단 됨.

그게 바로 const userid = yield $.post('member.php', {r}, next); 이 부분이다.

그리고, const next = v=> iter.next(v); 이 코드에서 member.php 비동기 호출에서 응답 값인 id가 const userid = 값으로 전달 되고, 멈춰졌던 흐름이 다음 라인으로 이동 됨.

즉, executor 함수를 분리 해놓음으로써 profile 함수만 관리하면 됨.. 이와 유사하게 ko library라는게 있다고 한다.

위와 같은 방식을 generator의 coroutine pattern이라고 부른다고 함.

passive async controll

콜백을 보낼 수는 있지만, 언제 올지는 모른다.

$.post(url, data, e => {
  // ? 언제 오는가?
})

let result
$.post(url1, data1, v => {
  result = v
})

$.post(url2, data2, v => {
  result.nick = v.nick
  report(result)
})

active async controll

promise는 then을 호출해야 결과를 얻는다.

let result
const promise = new Promise(r => $.post(url1, data1, r))
promise.then(v => {
  result = v
})

const promise1 = new Promise(r => $.post(url1, data1, r))
const promise2 = new Promise(r => $.post(url2, data2, r))
promise1.then(result => {
  promise2.then(v => {
    result.nick = v.nick
    report(result)
  })
})

generator + promise

const profile = function*(end, r) {
  const userid = yield new Promise(res => $.post('member.php', { r }, res))
  let added = yield new Promise(res => $.post('detail.php', { userid }, res))
  added = added.split(',')
  end({ userid, nick: added[0], thumb: added[1] })
}

const executor = (end, gene, ...arg) => {
  const iter = gene(end, ...arg)
  const next = ({ value, done }) => {
    if (!done) value.then(v => next(iter.next(v)))
  }
  next(iter.next())
}

executor(console.log, profile, 123)

async / await

C#에서 JS로 넘어온 패러다임

const profile = async function(end, r) {
  const userid = await new Promise(res => $.post('member.php', { r }, res))
  let added = await new Promise(res => $.post('detail.php', { userid }, res))
  added = added.split(',')
  end({ userid, nick: added[0], thumb: added[1] })
}

profile(console.log, 123)

결국에 코드를 보면, 위에서 generator + promise 방식이나 async/await 방식이나 같다. 다만, 단점은 위 코드는 async에서만 yield가 된다. 응? 즉, 비동기일때만 위 코드에서 흐름이 suspension이 된다는 말이고, 동기인 경우 이를테면, while문에서는 안됨…

그럼 사실 generator + promise 방식의 코드가 더 낫다. 동기 비동기 모두 yield가 가능하다. 그런데, es8에서부터 async generator가 생겼다.

ref. https://ko.javascript.info/async-iterators-generators#ref-1893

위 페이지 끝장나게 번역 잘되어 있다.

alfred workflow 동작 오류 - python을 못찾을 경우

Sat, 19 Mar 2022 21:25:00 GMT

언제부터인가, alfred workflow가 동작을 안하는 걸 보니 python2 환경이라 그렇고, monterey 업데이트 좀 하다보니 아예 맥 기본 path에 python3만 존재하면서 오류가 발생 했다.

https://www.alfredapp.com/help/kb/python-2-monterey/

위 페이지를 참고해보면, 된다.

export PATH="/opt/homebrew/bin:/usr/local/bin:${PATH}"
eval "$(brew shellenv)"
brew install pyenv
pyenv install 2.7.18
ln -s "${HOME}/.pyenv/versions/2.7.18/bin/python2.7" "${HOMEBREW_PREFIX}/bin/python"

개발자로 살아남기를 읽고,

Thu, 03 Feb 2022 17:02:00 GMT

좋았던 부분이 워낙 많아 다 담을 수는 없지만, 크리티컬 싱킹이 나에겐 정말 와닿는 문장이었고, 팀원간의 강점과 약점을 공유 하는 것, 리더로서 투명성을 유지 해야 하는 것들이 정말 좋았다.

경력이 10년 차쯤 되면 시니어 개발자입니다. 이때는 혼자서만 잘한다고 끝이 아닙니다. 일을 크게 만들 줄을 알아야 하고요, 다른 사람을 이끌며 일할 줄 알아야 합니다. 프로젝트를 리드하고 기술을 결정하며 점점 더 큰 일을 더 많이 하게 되는 거죠. 여기까지는 ‘열심히 영역에 속합니다. 다음 위치에 다다르려면 조금 더 많은 것이 필요합니다.

블리자드에서는 이후 레벨의 개발자를 리드 개발자, 프린시펄 개발자라고 불렀습니다. 리드 개발자가 되려면 미지의 영역을 해결하는 능력이 필요합니다. 블리자드에서는 아는 일을 잘하는 능력보다 모르는 일도 분석해서 끝까지 처리하는 능력, 그래서 새로운 프로젝트를 맡을 수 있는 능력이 있어야 리드 개발자로 승진합니다. 리드 개발자 승진 평가에는 심지어 다른 팀의 디렉터들까지 참여합니다. 회사 전체에 영향력이 퍼져 있을 정도로 많은 일을 하고 있어야지만 리드 개발자가 되는 것이죠. 반면에 프린시펄 소프트웨어 개발자는 진정한 구루여야 합니다. 프로젝트의 개발을 리딩한다기보다는 정말 깊게 기술을 연구해서 회사에서 인정받는 기술 전문가이어야 합니다.

그다음은 디렉터입니다. 경력 20년이 넘어가는 위치입니다. 이제부터는 책임의 영역입니다. 저는 농담으로 디렉터를 정의하며 이런 표현을 씁니다. “모든 일을 할 수는 있지만 아무 일도 하지 않고 대신 모든 일에 책임지는 사람”이라고요. 단순히 일을 하는 사람이 아닙니다. 책임질 줄 알아야 하는 사람입니다. 그러려면 모든 것을 파악하고 옳은 결정을 빠르게내릴 수 있어야 합니다. 디렉터 위로는 VP of 엔지니어링’ 이나 CTO가 있습니다. 이 둘은 사실상 경영과 사업 영역에 속합니다. 개발과 기술을 기반으로 사업에 기여하는 모든 일을 책임집니다. 당연히 개발은 개발자들이 하는 것이므로 좋은 개발자들의 채용과 교육 그리고 개발 문화까지도 챙겨야 하며, 개발 프로세스도 잘 정립해야 합니다.

여러 레벨을 언급했는데요, 정리해보면 ‘어시스턴트, 어소시에이트, 미드 레벨 개발자’ 까지는 배우고 성장하는 시기, ‘시니어, 리드, 프린시펄 개발자’ 까지가 리드하면서 일하는 시기, ‘디렉터, VP, CTO’가 경영과 사업의시기에 속합니다. 그런데 모든 개발자가 경영과 사업의 시기까지 도달하기는 어렵습니다. 그래서 이에 대한 대안으로 서포트 시기를 마지막으로제안합니다. 우리나라 IT 업계는 10년 전에도, 지금도, 향후 10년 후에도개발자가 부족했고 부족하며 부족할 겁니다. 게다가 모든 개발자가 꼭 승진에 승진을 거듭하여 경영과 사업의 길을 갈 필요도 없습니다. 자신의 성향에 맞게 꾸준히 개발자 생활을 계속해나가는 전략도 중요합니다.

커리어패스 30년을 성장하는 시기, 리딩하면서 일하는 시기, 서포트하는 시기(또는 경영과 사업의 시기)로 나눠봤는데요. 다음 단계로 성장하려면 10년을 꼬박 채워야 하는 걸까요? 더 빠른 길은 없을까요? 그렇지 않습니다. 10년보다 중요한 건 성장입니다. 그런데 성장은 무엇일까요? ‘성장’은 역량이 늘어난다는 뜻입니다. 사람의 ‘역량’이란 무엇일까요? 첫 번째는 지식, 두 번째는 숙련도, 마지막은 경험입니다.

첫 번째 지식은 공부를 해야 쌓입니다. 지식을 쌓는 공부는 혼자서 하는 영역입니다. 물론 일하면서도 지식을 쌓을 수는 있지만, 근본적으로 본인이 하지 않으면 쌓을 수 없다는 측면은 같죠. 두 번째 숙련도는 같은 일을 여러 번 오래 반복해야 쌓을 수 있습니다. 결국 프로그래밍, 프로젝트, 소통, 협업을 해봐야 숙련도가 높아집니다. 얼마나 열심히 하냐에 따라 공부와 숙련에 드는 시간이 짧아질 수 있습니다. 반면 경험을 쌓는 데 드는 시간은 단축하기가 어렵습니다. 경험은 성공과 실패를 해봐야 하고, 이런 사람 저런 사람도 만나봐야 합니다. 다행인 것은 강연이나 책으로 다른 사람 경험을 간접 습득하면 시간을 줄일 수 있습니다. 왜 많은 사람이 책을 강조하는지 이제 알겠죠?

크리티컬 싱킹하라

대개는 상사가 일을 시키면 ‘네 알겠습니다’ 하고 곧바로 일을 합니다. ‘크리티컬 싱킹’ 이라는 말이 있습니다. 우리말로는 ‘비판적 사고’ 정도로 번역할 수 있습니다. 크리티컬 싱킹은 주어진 일의 앞뒤를 생각하는 습관입니다. ‘왜 이 일을 해야 될까?’, ‘이 일을 하다가 말면 어떻게 될까?’, ‘어떤 방식으로 일하는 게 최선일까?’ 문제의 상하좌우까지 고민하는 사고방식을 습관으로 들이면 모든 일을 더 깊이 들여다볼 수 있습니다. 두 사람에게 같은 난도의 일을 주고 1년을 일하게 한다고 해봅시다. 둘 다 갓대학을 졸업한 신입 직원이고 현재 역량이 같다고 합시다. 그러니까 둘다 채용되었겠죠. 1년이 지나고 보면 둘의 역량은 같을까요? 차이가 난다면 ‘크리티컬 싱킹’ 이 그 차이를 만든다고 생각합니다. 삽을 들고 가서열 번 땅을 파고 독을 묻은 다음에 돌아와라’ 하고 시켰을 때 그대로 하면 숙련도는 올라갑니다. 하지만 지식이나 경험은 잘 쌓이지 않습니다.

‘왜 10번만 파야 되지?’, ‘왜 삽으로 파야 하지?’, ‘곡괭이로 파면 안 되나?’, ‘꼭 파야 하나?’, ‘독을 왜 묻지’ 이런 질문을 하고 더 좋은 방법을 고민하면 어떻게 될까요? 관리자 입장에서는 전자가 편합니다. 시키는 대로 하니까요. 후자는 뭐 하나만 시키면 맨날 물어봅니다. 그래서 귀찮습니다. 그런데 1년이 지난 다음에도 전자한테는 여전히 설명을 길게 해줘야합니다. ‘동쪽으로 열 걸음 가서 땅을 열 번 파고 독을 묻어라. 그런데 후자한테는 김치를 잘 보관해봐’ 라고 하면 끝입니다. 땅을 파는 대신에 김치 냉장고를 구비해 보관할지도 모릅니다. 크리티컬 싱킹 습관이 들어 있으면 그 사람이 감당하는 업무 스케일이 계속 커지게 됩니다.

개발자 자세, 30년 동안 도그푸딩 실천하기

도그푸딩 Dogfooding 이라는 말이 있습니다. ‘내가 만든 개밥을 스스로 먹어라 Eat your own dog food’ 라는 말에서 유례했습니다. 우리말로 풀면 ‘본인이 만든 제품을 직접 써보라’ 라는 격언이 되겠습니다.

두 번째로 팀 관리를 살펴보겠습니다. ‘팀을 만든다 → 유지한다 → 제품을 출시한다’ 순서로 큰 그림을 그립니다.

팀을 포밍forming 하면 스토밍 stoming, 즉 폭풍처럼 마구 싸웁니다. 그러고나면 잔잔해지고 noming 사람들이 친해집니다. 마지막은 퍼포밍performing, 즉일을 잘하게 되는 단계로 진입합니다. 대부분의 팀이 이런 순서로 돌아갑니다.

여기서 핵심은 신뢰와 지식입니다. 무슨 뜻이냐면, 새로 결성된 팀에서처음 만난 사람들은 당연히 서로를 신뢰하지 않습니다. 그래서 지식도 공유하지 않습니다. 상대방을 믿지도 못하고 상대가 무엇을 하는지도 모릅니다. 이게 첫 단계입니다. 그러다 조금씩 자기가 하고 싶은 말을 합니다.그러면서 본인의 지식을 전하게 됩니다. 아직은 서로를 신뢰하지는 못하기 때문에, 상대방 말이 기분 나쁘게 들립니다. 그래서 싸움이 생깁니드 스토밍 단계에 접어드는 거죠. 사람은 참 이상합니다. 싸우다 보면 결친해집니다. 정이 드는 것이죠. 친해지면 신뢰가 생겨서 다른 사람의식을 믿고 잘 협력하게 됩니다. 비로소 팀이 잘 돌아가게 되는 거죠.

저는 새 팀을 만들 때마다 워크숍을 합니다. 워크숍 때마다 남들이써줬으면 하는 자신의 장점을 말하게 합니다. “나 C#을 정말 잘해. 나에게 물어봐줘” C# 고수가 동료라니 누가 반기지 않겠습니까? 약점도 말하게 합니다. 그런데 약점만 말하라고 하면 싫어합니다. 그래서 본인 약점을 말하되, 자신의 약점을 어떤 방식으로 도와줬으면 좋겠는지 말하게 합니다. “내 약점은 자리에 앉아서 혼자 일하는 걸 좋아하는 거야. 사람들이말 거는 것을 싫어해. 하지만 중요한 일로 말을 걸고 싶으면 책상을 한두번 톡톡 쳐줘. 그럼 하던 일을 멈추고 이야기할게.” “나는 일하다 보면 너무 집중해서 옆도 안 보고 앞만 보고 가. 그러니까 그럴 땐 꼭 옆에서 너무 빨리 가는 것 같으니 잠시 멈춰서 살펴보자고 알려줘.”

팀 존재 이유는 서로의 장점을 공유해서 극대화하고 약점을 보완해주는 것이므로, 서로가 강점과 약점을 알아야 합니다. 특히 약점을 공격하는 데 사용하면 안 됩니다. 약점은 당사자를 보호하고 팀워크를 유지하는데 사용해야 합니다. 팀 생성 초기에 이 워크숍을 진행하면 빠르게 신뢰단계(규범기)로 진입해 원활히 지식을 나누게 됩니다.

과거에 스타트업 얼라이언스에서 강연 하셨던 영상을 본 적이 있는데, 정말 정말 도움이 컸던 영상이었다.

[스타트업얼라이언스] 개발자가 갖추어야 할 9가지 기술 - 박종천 넥슨 부본부장 - YouTube

이 영상을 보면서 느낀 바로 개발자가 갖추어야 할 역량에 대한 부분이었다면, 이 책에서는 역량 뿐만 아니라 전략 그리고 향후 매니지먼트 영역 그리고 그 이상의 역할에 대한 설명을 하고 있는 책인데, 개발자 관련해서 이런 책은 본적이 없다.

그리고 일단 확실히 재미난 사실은 뛰어난 개발자는 명확함을 늘 지닌다고 하는데, 박종천님께서 쓰시는 글에는 명확함만이 있다.

군더더기가 전혀 없다는 것이 정말 책의 몰입감을 높이는 첫번째라고 할 수 있고, 확실하게 알고 있는 명확함을 기반으로 커뮤니케이션에 대한 영역에 대한 부분, 영어 학습에 대한 부분은 반성을 좀 많이 하게 되었다. 앞으로는 최대한 영어를 노출 시키는 훈련을 해야겠다고 생각 했다.

내가 알지 못하는 시니어 개발자, 리드 개발자 그리고 그 너머의 영역에 대해서는 미지의 세계였는데, 그에 대한 방향성을 명쾌하게 알려주신 것 같다. 물론, 그 길이 나에게 늘 정답일리는 없겠지만, 좋은 지침이 될 수 있는 비법서 같은 책이었다.

쉽게 읽히는 책이지만, 개발자에게 연차가 쌓일 수록 부담을 느낄 수 밖에 없는 영역들을 잘 설명 해주고, 내가 못하는 것과 잘 하는 것을 분리하고 그 것들을 팀원과 잘 공유하며 시너지를 내는 어떤 선순환의 고리를 잘 설명 해주신 것 같다.

책을 읽으면서 팀원들과 팀장과 이야기 하면서 읽고 싶기도 했다. 다 읽은 뒤 열심히 프로세스를 정립 하기 위한 토론도 해야겠지만, 그게 가능한 팀이 있고 불가능한 팀이 있다는 사실을 나는 안다. 현실은 냉혹하며, 늘 이상향 속에 내가 있지 않다.

내가 모르는 세계도 많을테고, 나는 회사를 1번 경험해본 사람이라서 다양함을 나는 모르고 우물안 개구리라는 것을 인정한다. 다만, 내가 속한 곳을 최대한 좋게 바꾸려는 노력은 나에게 어떤 제 2의 업무라고 생각한다.

내가 늘 인생 코드를 작성 하는 구루의 반열이라면, 사실 그런 경지는 경험해보지 못해 모르지만, 그때에는 아마 더 군더더기 없는 커뮤니케이션과 코드를 짤 것이라 생각 한다. 아마 그때는 더 수월하게 업무를 둘 다 해낼 수 있겠지 ? 라는 생각을 하곤 한다.

하지만, 지금은 아직 아니기에 나는 더욱이 팀과 팀원들의 시너지를 위한 방법을 고려 해야 하는데, 나는 이게 맞다고 늘 생각 했었는데, 누군가에게는 그게 늘 정답이 아니 였을 것이란 생각을 나는 못했다.

그래서 앞으로는 조금은 힘을 빼고, 세상 밖에서 공부를 좀 해야겠다고 생각 했다. 그리고 나도 스스로 공부를 좀 많이 하고 만들어보는 훈련을 해야 하는 의도적 수련을 해야겠다고 다짐하게 되었다. 나는 늘, 컴퓨터에 대한 지식을 몰라도 되고 하다보면, 경험하게 되는 날이 오면 공부 하자 생각 했던 사람인데, 시간이 지나고 보니 공부 할 수 있을 때 열심히 하는게 남는 것이라는 결론을 얻었다.

늘, 이건 왜 동작하지? 이건 내부가 어떻게 되어 있지? 고민만 하고, 알아보지 않고 추측으로만 개발을 해왔다. 물론 가끔 정 궁금하면 소스 코드를 보기도 했다. (오픈소스의 강점이 바로 이것이다. 투명성) 그런데, 추측만 하고 제대로 실험을 해보진 않으니 지식의 깊이가 깊어지지 않는다.

시간을 허비한 것에 대한 아쉬움은 있으나, 나 같은 개발자도 어딘가에 또 있겠지 하고, 생각 하면서 조금은 결을 바꿔서 앞으로는 그때 그때마다 공부 하는 습관을 들이기로 다짐 하게 된 계기가 바로 이거다. 나에게 몇년 남지 않은 시간이다.

이 책에서 말하듯 성장기 10년이고, 총 30년이라 가정 할때 나는 이제 4년 정도면 시니어 계층 개발자라는 것을 의심 할 여지 없이 그 계층으로 가야 한다. 물론, 연차가 시니어를 보장 하거나 대변하는 것은 아니지만, 업계가 그렇다. 평균적으로 그렇기 때문에, 나는 어느 정도 사람들을 리드 하고, 프로젝트를 수행 해야 할 역량이 있어야 한다.

그럴려면, 기술력은 기본이고, 커뮤니케이션 능력과 리딩에 대한 자세가 필요한데, 변명 아닌 변명으로 늘 급한 일정 탓을 하며, 기술력을 연마 하지 않은 부분이 요즘들어 잠을 설치게 하는 원인이다. 어쩌면 나는 몇년 전부터 의미를 잃어버린 사람 같다.

열정적이던 개발자에서 시니컬 해진 개발자가 되어버린 것 같았다. 책속에 나오듯 내가 첫 사용자가 되었을때, 개선점들을 제안 했는데 생각보다 기획의 영역은 굳건하므로 내가 개발 하더라도 스펙이 바뀌지 않는다. 그러면서 차츰 식어버린 날 탓하면서도, 나는 이제 정해진 것만을 수용하는 개발자가 된 것이다. 차츰 차츰 그렇게 낡아져 갔다.

요즘의 트렌드는 정말 빠르고, 봐야 할 언어, 프레임워크, 라이브러리, 패턴, 아키텍처등 수 많은 내용들의 범람이다. 되려 하나만 해야 한다면 모르겠으나, 하나만 하면 괜시리 뒤쳐지는 느낌을 또 받는다. 그렇다고 또 여러개를 하자니 시간은 없고, 쉽게 지친다. 그래서 1년에 한 가지 혹은 두 가지 정도의 기술만 연마해 보기로 했다.

늘, 고민은 많지만, 이 책을 읽으면서 어떤 개발자로의 삶에 대한 고민이 줄었다. 그 만큼 내 무수히 많던 고민을 굉장히 명확하고, 군더더기 없게 만들어준 책이라 가끔 읽으려 한다.

M1 맥북에어 사용기

Mon, 17 Jan 2022 23:49:00 GMT

상판/하판 모두 교체해서 거의 새거였던 내 애정이 담긴 2016 맥북프로 CTO를 팔고, M1 맥북에어 메모리 8GB, SSD 512GB를 당근에서 가져온지 2주 좀 넘게 써본 후기를 쓴다.

개인 공부 및 블로그, 주식 관련 공부로 휴대성을 증대 시키기 위해 맥북에어로 넘어왔다.

사실, 다들 M1칩 칭찬 자자 하길래 써봤다. 나는 뒷북 치는 개발자

웹서핑 + 유투브로는 최상 / 주로, 주식 관련 정보 리서치 / 블로그 글 작성에는 최고 (허벅지도 안아프다.)
IntelliJ + Chrome 조합 + etc 앱 (기타 개발앱, GoodNotes 등등) 실행 되고 있으면, IntelliJ에 코드 입력할때, 한자 한자 마음을 다해서 쓰게 되는 수준이 된다. 쉽게 말해 맛탱이 간다. (메모리 부족해)

고로, intelliJ와 다른 앱들을 여러개 키게 되면, 메모리가 일단 좀 부족하다. 여유가 되시면, 16기가, 512기가를 추천 하는데 개발 할 때, 메인 맥북이어야 한다면 무조건 프로로 가셔라.

2 포트의 경우, 가성비의 문제이기 때문에, 4포트가 될 경우 금액이 올라갈 가능성이 농후하다.

애플은 늘 그래 왔다. 절대 프로랑 에어랑 비등하게 팔지 않는다.

대략 후기는 CPU는 미친 녀석인 것 같다. 다만, 맥북 에어로 무거운 회사 프로젝트를 빌드/실행 하면서 유투브 틀고, 크롬으로 이 탭, 저 탭 열고 그러면, 크롬 🕊끼는 당신의 맥북 에어 메모리를 흥청 망청 쓸 것이다.

그러다보면 IDE는 슬슬 맛탱이 갈 준비를 한다.

추천 방향) 서브 맥북이라는 전제 하에서 이야기

금전 여유가 있다면, 확실히 맥북에어16기가 추천합니다.
메모리 8기가여도 충분히 토이 프로젝트는 IntelliJ는 돌릴 수 있다.
- 대신, 크롬 탭을 끄거나 파이어폭스 추천 (진심 쾌적함) 단, FE 개발자는 파폭을 쓰면 화면 구조가 달리 보일 수 있음.

시니어 엔지니어란 무엇일까?

Fri, 14 Jan 2022 00:11:00 GMT

시니어의 올바름?! (시니어의 길)

시니어의 덕목은 무엇일까? 궁금해진다.

이 업계에서 정한 경력 연차에 따른 어떤 사이클에 의하면, 아래와 같다.

주니어
- 업계 1-3년차 경력
중니어
- 업계 4 - 5년차 경력
시니어
- 업계 6년차 이상
Cxx
- 회사마다 다름
- 1x년차 이상

경력이 전부 인 세상이 아니지만, 엔지니어링 업계는 경력이 대다수 중요한 지표임은 확실하다.

시니어의 덕목이 무엇일지, 문득 궁금해지는 순간이 나에게도 왔다. 정답이 무엇인지 알 수는 없지만, 여러가지 책 속에 답이 있다는 생각이 든다.

매니저는 팀원이 성장하고, 새로운 것을 배우는 데 도움이 되는 도전 과제를 찾아서 알려줘야 한다. 좋은 매니저라면 도전 과제를 주는 것뿐만 아니라 프로젝트가 재미 없고 매력적이지 않아도 그 일의 가치를 이해시켜야 한다.

시니어 개발자에게 나쁜 습관이 스며있기도 하다. 최악의 습관은 잘 이해되지 않거나, 자신의 의견에 동의하지 않는 사람과는 논쟁하려는 경향이다. 신입 사원, 주니어 팀원과 업무를 잘 수행하려면, 몇 번이나 시간을 들여 노력을 쏟더라도 그들이 이해하는 방식으로 경청하고 소통해야 한다.

의사소통 과정에서 경청을 꼭 기억해두어야 한다. 다른 사람에게 발언 기회를 주고 그 사람의 말을 귀담아듣는다. 다른 사람의 말을 확실하게 이해하기 위해서 그 사람의 말을 반복해보는 연습이 필요하다. 이때, 다른 사람의 말을 잘 듣고 자신의 언어로 바꾸는 방법을 배운다. 다른 사람과의 의사소통과 경청을 잘못하면 더 이상 성장하기 어렵다.

성공한 팀은 서로 농담하고, 커피 마시고, 점심 먹고, 서로 친한 감정을 느끼고 동료애가 있다. 이런 팀은 서로 존중해야 하고, 업무 외에도 열정이 있지만, 팀을 매일 탈출해야 하는 어떤 것으로 보지 않는다.

중요한 것은 매니저가 팀을 디버깅 할 줄 알아야 한다는 것이다. 개발 7년차, 매니저 1일차 中

새로운 일에 도전할 때는 잘될 확률보다는 잘 안 될 확률이 더 높다. 남들은 잘하는 일을 내가 하면 잘 안 되는 경험을 하기도 한다. 중요한 것은 실패로부터 단단해지는 내공이다. 이 내공은 실패의 원인을 아는 지식이기도 하고, 실패를 반복하지 않을 기술이기도 하고, 다음 도전을 위한 맷집과 배짱이기도 하다. 실패를 많이 한다고 저절로 내공이 쌓이는 건 아니다. 실패가 반복되면 자존감에 상처가 나고 움츠러드는 게 당연하다. 남들은 다 잘하는 것 같은데 나만 못난 듯하고, 환경을 탓하는 마음도 생기고, 억울해서 화가 나기도 한다. 실패가 내공의 밑거름이 되려면 다음 세 가지가 필요하다.

실패한 경험이 풍부한 사람과 그렇지 않은 사람이 회사에 들어오면 그 둘의 차이가 확연하다. 회사 입사 시까지 큰 실패 없이 승승장구한 사람은 실수나 실패를 하지 않으려고 큰 프로젝트나 책임 있는 일을 맡기를 꺼린다. 그뿐 아니라 일이 잘 안 되었을 때 나락으로 떨어지거나 수습을 잘 못 하고, 회복하는 데도 오랜 시간이 걸린다. 심하면 회사를 그만두는 것으로 자신을 질책하거나 현장을 회피하는 방법을 선택하기도 한다.

하지만 실패와 수습을 많이 해 본 사람은 이럴 때는 빨리 잘못을 인정하고 사과를 해야 한다든지, 다음에는 더 잘해야겠다든지, 세상에는 이상한 사람이 많으니 재수가 없었다 생각하고 마음에 담아 두지 않는다든지 등등 여러 가지 방법으로 수습하고 앞으로 나아간다.

주니어나 시니어가 되더라도 그 직급이 감당할 만한 일을 맡고 있는 거라서 자신의 실패로 회사가 망하거나 지구가 멸망하는 일은 생기지 않는다. 다만 그 실패로 자신이 망할 수는 있다. 그러지 않기 위해서 실패에 대한 맷집을 키워야 한다.

성공의 결과보다 중요한 것이 과정의 복기다. 무엇 때문에 실패했고, 무엇 때문에 성공했는지 복기해서 시스템화하는 과정이 필요하다. 그래야 성공 확률을 높일 수 있고, 실패의 반복을 피할 수 있다. 지속 가능한 시스템을 만드는 일은 개인의 커리어는 물론이고 회사의 성장에도 중요하다. 과정을 복기하면서 인력의 문제인지, 프로세스의 문제인지, 팀별 역할 분담의 문제인지, 법규의 문제인지, 시장의 수용도 문제인지, 가격의 문제인지 등등 원인을 파악하고 변수를 체크하면서 다시 시도해야 성공 가능성이 커진다.

실패는 아프다. 하지만 성장하기 위해 필요한 과정이다. 실패를 상처로 두지 말자. 상처를 제대로 치료하지 않고 그냥 두면 곪아 터진다. 가장 위험한 건 상처의 아픈 기억 때문에 자꾸 움츠러드는 것이다. 상처가 나면 바로바로 치료하고, 왜 상처가 생겼는지 분석하고, 상처가 나지 않을 방법을 연구해 보며 툴툴 털고 일어나자. 그런 경험이 쌓여야 다시 해 볼 엄두가 나고 상처 나는 게 덜 무섭다. ‘까짓, 그것 가지고 안 죽는다.’ 이런 내공이 생길 때까지. 생각이 너무 많은 서른에게 中

구성원들이 문제를 제기하지 않고 침묵하는 이유는 조직에 만연한 ‘근거 없는 두려움Unfounded Fear’ 때문으로, 이러한 두려움은 구성원들이 가지고 있는 역량을 최대한 발휘할 수 없게 하며 조직에 생산적인 소통을 가로막는 걸림돌로 작용하고 있다.

심리적 안정감이란 상호 신뢰와 존중이 가능한 조직 문화의 핵심 동인으로, 동료들에게 본인이 가지고 있는 원래의 모습을 솔직하게 보여줘도 편안함을 느낄 수 있는 상태를 의미한다. 실수를 하거나 질문을 할 때, 소수 의견을 냈을 때도 구성원이 심리적으로 편안함을 느낄 수 있는 문화가 정착되어야 조직이 성장할 수 있다. 심리적 안정감이 없는 조직에서는 현상을 유지하는 데 머물거나, 리더의 과거 경험에 의한 편향된 의사결정을 하거나, 다양한 의견과 창의적인 아이디어를 반영하기가 어렵다.

심리적 안정감이 높은 조직은 어떤 모습일까? 가장 큰 특징 중 하나는 ‘Speak-Up’이 자유롭다는 것이다. ‘Speak-Up’이란 구성원들이 솔직하게 자신의 의견을 개진하는 것으로 두 가지 종류로 구분할 수 있다. 첫째는 업무 관행과 프로세스 개선을 위한 창의적이고 건설적인 아이디어를 제안Bublle up Suggestion하는 것이고, 둘째는 조직에 부정적인 영향을 끼칠 수 있는 관행, 사건, 행동에 대해 직급 구분 없이 자신의 소신을 말할 수 있는 것이다.

조직에 심리적 안정감이 형성되면 구성원은 언제나 문제를 제기해도 모욕당하지 않고, 무시당하지 않으며, 질책당하지 않는다고 확신하게 된다.

“리더로서 자신이 모든 정답을 갖고 있다고 생각한다면, 그 생각을 당장 집어치워야 합니다. 리더의 생각도 얼마든지 오답일 수 있다는 걸 왜 의심하지 않죠?”

‘나는 직원들에게 얼마나 자주, 그리고 분명하게 업무의 목적을 강조하고 있는가?’

리더는 스스로에게 질문을 던져야 한다.

리더가 마치 모든 정답을 안다는 듯이 군림하는 분위기에서는 그 누구도 문제를 제기할 수 없다. 반면 겸손과 호기심을 바탕으로 무엇이든 배우려는 리더와 함께라면 구성원은 자연스럽게 안정감을 느끼고 더 많은 아이디어를 제시하게 된다.

대개 질문하는 리더는 어리석고 나약하게 비칠 거라고 생각하지만 실제로는 전혀 그렇지 않다. 오히려 생각이 깊고 현명한 사람으로 보일 수 있다. 그렇다면 좋은 질문을 하기 위해서는 어떤 규칙을 지켜야 할까? 먼저, ‘정답을 모른다’는 태도로 물어야 한다. 긍정이든 부정이든 상대방의 대답에 제한을 두지 말아야 한다. 또한 구성원이 서로 간의 생각을 공유하는 데 도움이 되는 형태로 질문을 건네야 한다.

‘누구나 할 말은 하는 분위기’는 개인의 성격적인 특징과는 아무런 관련이 없다.

두려움 없는 조직 中

시니어의 역할?

그 안에서 시니어의 역할은 무엇일까?

팀안에서 시니어도 다양하듯이 다양한 시니어의 모습이 보이는 게 좋겠다. 늘, 그렇듯 “주니어든, 시니어든 중요한 것은 우리가 무엇을 하고 있는가?” 에 집중하는 것이 좋다는 생각을 했다.

만들어가는 과정이 좋아야 한다. 어떤 제품에 대한 소비자 결과는 사실 알 수 없다. 결국 스스로에게 만족감을 준다. 만족감, 혹은 충족감이 있어야 일을 오래 지속 하고 더 나은 방향으로 나아가게 만든다.

그럼, 오늘도 더 나은 방향을 향해 나아가기 위해 조금 더 만족스러움을 느낄 수 있는 길을 찾자.

내가 생각 하는 시니어의 모습은 무엇일까?

팀내의 어떤 문제해결을 한다. * 그게 기술적이든, 커뮤니케이션적이든
주니어를 리드 한다. * 기술/커뮤니케이션 모두
팀내의 문화를 구축 한다. * 보통은 시니어 레벨이 영향력이 있으므로, 문화를 구축하는데 힘 써야 한다.
팀내의 기술 부채를 갚는다. * 보통 대개의 시니어 엔지니어들이 팀내의 기술 부채를 잘 알고 있을 가능성이 높다.
팀내의 독소를 파악한다. _ 문화를 구축하는 것과 맥락은 비슷하나, 독소(유해인자)를 파악하는 것이 중요한데, 굉장히 객관적인 시각이 필요하다. _ 독소는 시스템, 사람, 문화 총망라하여 탐지를 해야 한다. _ 알고보면, 본인 스스로가 팀내의 독소 일 수 있다. _ 명심하자. _ 팀내 한명은 무조건 독소일 수 있다. _ 시스템 중 하나는 늘 고장의 원인일 수 있다. * 문화 중 하나는 고착화 된 악습일 수 있다.

그렇다면, 시니어 엔지니어들은 매니저 (리더)를 어떻게 도울 것인가?

뭐, 솔직한 말로 리더들은 알아서 잘 살겠지… 라고 하면 안되고! 시니어 엔지니어와 매니저는 정말 소통이 중요한 존재이다. 소통의 부재가 지속 되는 팀은 곧 망한다.

음, 이건 확실히 말할 수 있다. 굉장히 많은 일들을 겪기도 했고, 그로인한 나의 문제점을 알 수 있던 시간이었다.

아마, 앞으로도 그런 일들은 늘 일어날 것이라 놀라운 일은 아니지만, 내가 생각하기에는 데일 카네기의 “인간 관계론”을 늘 끼고 살아야 하는 존재가 바로 매니저 그리고 시니어 엔지니어 아닐까 싶다.

그리고 시니어 엔지니어와 매니저는 주니어/중니어에게 Bottom up - thinking을 제안 해야 하고, 늘 훈련 할 수 있도록 환경을 조성 해주어야 한다.

그러한 환경은 바로 내 생각에는 첫째가 바로, 실패 용인이다. 실패를 꼭 그 엔지니어에게 전가 할 필요가 없고, 주니어/중니어 엔지니어는 꼭 1년에 최소 한 번씩은 프로젝트가 말아먹더라도 도전적인 미션을 쥐어 주는 것이다. 물론, 이게 회사나 팀 입장에서는 큰 손해다. 리소스의 낭비로 보여질 수 있기 때문이다. 그렇지만, 이것들은 추후에 이익으로 돌아올 것이라 본다.

실패에서 우리는 큰 경험을 쌓고, 그 경험으로 새로운 일들을 더 잘 할 수 있을 것이라 생각 한다.

그 환경을 만들어 주는 것이 시니어의 올바름이라 생각 하고, 그 길로 나아가야 한다. 당연히 매니저는 시니어 엔지니어에게도 1년에 한 번씩 실패 용인을 줘야 한다.

주니어/중니어/시니어 모두 실패를 해봐야 고이지 않는다. 그건 어느 연차나 같고, 실패에서 배워야 하는 것이 곧 그 팀의 역량이자 힘이다. 그것을 이룩하는 데에는 매니저의 무단한 노력이 필요하겠지…🤔

사실 위 모든 생각들은 나만의 개똥철학 일 수 있다. 정답은 없지만, 나는 어떤 시니어가 될지를 고민해봤다.

나는 실패 용인 환경 조성자의 역할을 해야만 한다.

Volta?! (JavaScript command line tool)

Thu, 13 Jan 2022 22:56:00 GMT

volta (JavaScript command line tool)

원래 node 버전 매니저로 nvm을 제일 많이 썼다. 실제 실무에서도 물리서버에서 쓰거나, jenkins(유물 같지만, 실무에서도 짱짱하게 잘 썼다. 현재는 github action을 쓰고 있다.)에서도 nvm을 설치해서 쓰곤 했는데, 이제 로컬에서는 volta를 쓴다. 쓴지는 좀 됐다.

volta를 쓰는 이유는 nvm보다 훨씬 빠르다. 인터랙션이 훨씬 빨라서 쓰게 되었고, nvm 보다 더 가벼운 느낌의 Node 버전 매니저는 n이라는 것도 있는데, 잠시 쓰다가 바로 volta로 왔다.

volta install

# install Volta
curl https://get.volta.sh | bash

# install Node
volta install node

# start using Node
node

위처럼 설치를 해도 되고, MacOS 유저라면 homebrew로도 설치가 가능하다.

brew install volta

volta는 Rust라는 언어로 작성되어 굉장히 빠르다.

내가 생각하는 장단점

volta는 사실 버전 관리 매니저 툴이 아닌 어떤 종합적인 JavaScript command line tool이고, 실제 사용 하는 방법도 조금은 다르다.

우선, nvm도 가진 장점은 NodeJS 버전 변환이 용이하다. 이는 volta도 마찬가지인데, volta의 더 큰 장점은 프로젝트 별로 버전을 고정 시킬 수 있다.

volta pin node@12.20
volta pin yarn@1.19

Ref. https://docs.volta.sh/guide/understanding#managing-your-project

물론, nvm도 alias를 지정 할 수 있기 때문에, project 버전 별로 node 버전을 설치 후에 해당 project 이름과 버전을 설정 해두면, 명령어 하나로 버전을 바꿀 수 있다.

nvm은 전역 디렉토리에 node버전별로 디렉토리가 분리 되어 설치 되기 때문에, alias를 설정 한다고 해서, 모듈간 문제가 생길 일이 없다.

다만, 로컬에서 터미널을 실행 시킬 때, nvm 관련 커맨드를 같이 실행 해줘야 되는 문제 때문인지?! 어느 순간부터인가 굉장히 느려졌다.

그래서 volta로 이주하게 되었다.

volta usage

예를 들어 tsdx 라는 툴로 프로젝트를 하나 만든다고 가정 해보자.

volta install tsdx
# volta run [sub-command]
volta run tsdx create test

tsdx create는 tsdx 툴의 명령어이고, test는 만들어질 디렉토리 이름이다.

결과적으로 volta를 이용해 tool을 실행 시킬 때는 volta run을 쓰면 된다.

사실 사용법은 굉장히 쉽다.

volta commands

SUBCOMMANDS:
    fetch          Fetches a tool to the local machine
    install        Installs a tool in your toolchain
    uninstall      Uninstalls a tool from your toolchain
    pin            Pins your project's runtime or package manager
    list           Displays the current toolchain
    completions    Generates Volta completions
    which          Locates the actual binary that will be called by Volta
    setup          Enables Volta for the current user / shell
    help           Prints this message or the help of the given subcommand(s)

위와 같이 쓸 수 있는 명령어를 터미널에서 volta만 입력해도 볼 수 있다.

https://docs.volta.sh/reference/

자세한 부분은 위의 페이지에서 확인이 가능하고, 실제로 자주 쓰는 명령어는 install, pin, run 정도 밖에 없을 것 같다.

코드의 사연

Mon, 10 Jan 2022 00:32:00 GMT

서비스 개발을 하다보면, 느끼는 것들이 참 많다. 물론 서비스 개발뿐 아니라, 모든 개발들이 다 그렇겠지만, 레거시들에서의 서비스 운영, 신규 플랫폼 환경에서의 서비스 운영 등 쉬운 상황들이 보통은 없다.

대다수, 레거시 코드들을 보다가 가끔 현타가 올때가 있다. 도대체 왜 이 스펙은 여기에 있는건지? 진짜로 동작해야 하는 스펙인건지?

예전에 없어져야 할 스펙인데 왜 제거가 되지 않았던 것인지..하는 수 많은 고민들과 스트레스들이 가끔씩 나에게 큰 불편감을 안겨주기도 했다. (생각해보면, 나도 누군가에게는 같을 수 있다는 것을 망각 했다.)

레거시 코드를 유지보수를 하면서 어려움은 새 코드를 예쁘게 넣는게 쉽지 않다는 어떤 괴리감이 늘 고달프게 하는 것 같다.

내가 본 건, 클린 코드, 리팩토링 등 다양한 가이드 서적들이 있는데, 막상 적용하기는 겁난다. 무엇을 바꾼다는게 오래 된 레거시는 굉장히 큰 두려움이 된다. (관리 된지 몇년 지난 코드들은 거의 버그가 스펙일 수 있기 때문이다.)

서비스 장애라는 것도 개발자에겐 늘 따라다니는 두려움의 존재이나, 나는 무의식적으로는 개발자가 장애를 두려워해서는 좋은 서비스가 나올 수 없다라는 생각을 한다.

장애는 어떤 지점에서든지 발생 할 수 있고, 늘 장애유발 포인트들은 존재한다. 그 포인트들에서 벗어나려면, 개발자가 취해야 할 행동은 무엇일까? 늘 고민하면서도 쉽게 두려움에서 벗어나기는 어렵다.

그렇게 내가 서비스 개발자로 일하면서 느낀 바는, 결국, 오늘의 코드는 내일의 레거시다.

레거시를 잘 운용하려면, 일단 코드를 클린하게 짜는 것보다 실제 사라진 스펙이 코드에 존재 하지 않도록 하는게 더 중요하다는 생각이다.

결론적으로 기술부채를 갚는 것도 중요하나 비즈니스 스펙 제거를 잘 하는게 더 중요하다.

이 부분을 소홀히 하면, 나중에 개발자가 뭘 지울 수 있는 건지 모른다. 그렇게 일 하면서 이러한 일들로 인하여 스트레스를 받으며 일하곤 했는데, 늘 관심 가지고 있던 개발자분의 트윗을 보고 생각이 바뀌게 되었다.

https://twitter.com/asbubam/status/1479074937654882310

내가 집중 해야 할 관점은 “코드의 사연”이란 부분이지, 이게 왜 아직도 남아 있냐?에 대한것이 아니였구나.

결국, 마음을 편하게 하는데는 관점을 조금 다르게 하는 생각의 전환 훈련이 중요하다.

각자의 개발자들에서 오는 코드들에도 사연이 있고, 나한테 왔다면 응당 그 사연이 있는 코드를 올바르게 현시점에 맞춰서 바꿔 주는 작업이 중요하구나 생각하게 되었다.

그렇다면, 모든 문제가 쉽게 해결 되고, 마음도 가벼워진다는 것을 깨닫게 되었다. 그리고 코드도 더 깔끔해지고, 다음 사람이 오더라도 그 사람의 마음도 더 편해지겠구나.

MacOS 셋팅을 다시 해보자!

Sat, 08 Jan 2022 01:28:00 GMT

Macos 셋팅

Update: 2022-01-14

M1 맥북 에어를 구매하면서, 다시 새로 셋팅을 해야 하는 일이 생겼다.

주로 기본 설정은 subicura님의 macos 셋팅을 이용 한다.

homebrew

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

ref. https://brew.sh/index_ko

iTerm2

brew install iterm2

brew install wget

theme는 subicura님이 쓰시는 Snazzy를 사용한다.

wget https://raw.githubusercontent.com/sindresorhus/iterm2-snazzy/main/Snazzy.itermcolors .

zsh / oh-my-zsh

brew install zsh zsh-completions

sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

# zsh-syntax-highlighting
git clone https://github.com/zsh-users/zsh-syntax-highlighting.git $ZSH_CUSTOM/plugins/zsh-syntax-highlighting

# zsh-autosuggestions
git clone git://github.com/zsh-users/zsh-autosuggestions $ZSH_CUSTOM/plugins/zsh-autosuggestions

vi ~/.zshrc를 통해 zsh에 플러그인을 설정 한다.

plugins=(
  git
  zsh-syntax-highlighting
  zsh-autosuggestions
)

git clone --depth=1 https://github.com/romkatv/powerlevel10k.git $ZSH_CUSTOM/themes/powerlevel10k

vi ~/.zshrc를 통해 테마를 변경한다.

ZSH_THEME="powerlevel10k/powerlevel10k"

command line tool

neovim/spacevim

brew install neovim
brew tap homebrew/cask-fonts
brew install font-meslo-lg-nerd-font

vi ~/.zshrc입력후 neovim을 사용하도록 별칭을 지정한다.

which nvim
> /opt/homebrew/bin/nvim

alias vim="nvim"
alias vi="nvim"
alias vimdiff="nvim -d"
export EDITOR=/opt/homebrew/bin/nvim

spacevim 에서 jj to esc 설정하기

https://stackoverflow.com/questions/66654579/how-to-map-esc-key-to-jk-in-spacevim

Documentation | SpaceVim

~/.SpaceVim.d/init.toml 에서 아래의 설정 추가

;[options]
bootstrap_before = 'myspacevim#before'
bootstrap_after = 'myspacevim#after'

~/.SpaceVim.d/autoload/myspacevim.vim 에서 아래의 설정 추가

function! myspacevim#before() abort
endfunction

function! myspacevim#after() abort
    inoremap jj  <Esc>
endfunction

fzf

brew install fzf

fasd

brew install fasd

asdf

그런데, 잘 안 쓴다. (rbenv/volta를 주로 사용)

brew install asdf

tmux

brew install tmux

jq

brew install jq

bat

brew install bat

vi ~/.zshrc 후 alias cat="bat" 추가

그런데, 위처럼 설정 하니, 가끔 cat으로 그냥 보고 싶을 때가 있어서 그냥 명령어를 입력해서 사용 중

ngrok

brew install ngrok

docker

brew install docker

docker desktop: https://www.docker.com/products/docker-desktop

hammerspoon

brew install hammerspoon

만약, 한영 전환시 표시를 하고 싶다면, 기계인간님께서 만드신 인풋소스 오로라를 사용하면 된다.

ref. https://johngrib.github.io/wiki/hammerspoon-inputsource-aurora/

peco + zsh

https://www.44bits.io/ko/post/incremental-search-tool-peco 를 통해 커맨드 라인에서 증분 검색기를 이용 할 수 있는 peco를 소개 하고, 사용법과 zsh와 같이 사용하는 것을 소개 하고 있다.

# from http://qiita.com/uchiko/items/f6b1528d7362c9310da0 by uchiko

function peco-select-history() {
    local tac
    if which tac > /dev/null; then
        tac="tac"
    else
        tac="tail -r"
    fi
    BUFFER=$(\history -n 1 | \
        eval $tac | \
        peco --query "$LBUFFER")
    CURSOR=$#BUFFER
    zle clear-screen
}
zle -N peco-select-history
bindkey '^r' peco-select-history

위 내용을 ~/.zsh/peco-history/peco-history.zsh 경로에 저장 한다.

그리고, zshrc 파일에 아래 내용을 추가해주면 된다.

source ~/.zsh/peco-history/peco-history.zsh

rbenv

asdf에서 ruby/nodejs가 지원이 되지만, asdf를 쓰진 않는다. (설치만 해놓고 잘 안씀..)

brew install rbenv

vi ~/.zshrc열어서 다음과 같이 수정 한다.

[[ -d ~/.rbenv  ]] && \
export PATH=${HOME}/.rbenv/bin:${PATH} && \
eval "$(rbenv init -)"

그리고, 루비를 설치 해주자.

rbenv install 3.1.0
rbenv global 3.1.0
rebenv rehash

3.1.0 버전을 설치하고, 전역으로 설정 한다.

volta

brew install volta

node version manager로 rust로 만들어져서 빠르다. nvm은 생각보다 좀 느린 편이라, nvm에서 넘어왔다.

volta install node

최신 노드 버전을 설치 할 수 있다.

tig

brew install tig

gitui

brew install gitui

tig/lazygit과 비슷하나, 좀 더 빠르다. Rust로 작성 되었다.

lazygit

brew install lazygit

github star로만 보면, lazygit이 제일 높다. go로 작성 되었다.

emacs + spacemacs

brew install emacs

https://www.spacemacs.org

$ git clone https://github.com/syl20bnr/spacemacs ~/.emacs.d

$ emacs # 실행시 spacemacs 설정 시작 및 설치

https://www.youtube.com/playlist?list=PLPNohcoOBa5GejCpa5-Mw79bXnyynM1Nn

Spacemacs 사용법에 관한 최고의 영상들이다.

spacemacs jj - escaping

emacs ~/.spacemacs

(defun dotspacemacs/user-config ()
  (setq-default evil-escape-key-sequence "jj"))

Ref. https://github.com/syl20bnr/spacemacs/blob/master/doc/DOCUMENTATION.org#escaping

IDE

IntelliJ 설정

Vs code와 마찬가지로 플러그인을 좀 번잡하게 사용하는데, 정리를 한 번 하고 주로 쓰는 플러그인을 정리 할까 한다.

ideavimrc

사실 vi editor를 잘 쓰는 것은 아니지만, 무조건 쓰려고 하고 있다. 그래서 대다수 툴에 설정을 하는 편이다.

vi ~/.ideavimrc

set NERDTree

'clipboard'      'cb'    clipboard options
'digraph'        'dg'    enable the entering of digraphs in Insert mode
'gdefault'       'gd'    the ":substitute" flag 'g' is default on
'history'        'hi'    number of command-lines that are remembered
'hlsearch'       'hls'   highlight matches with last search pattern
'ignorecase'     'ic'    ignore case in search patterns
'iskeyword'      'isk'   defines keywords for commands like 'w', '*', etc.
'incsearch'      'is'    show where search pattern typed so far matches
'matchpairs'     'mps'   pairs of characters that "%" can match
'nrformats'      'nf'    number formats recognized for CTRL-A command
'number'         'nu'    print the line number in front of each line
'relativenumber' 'rnu'   show the line number relative to the line with
                         the cursor
'scroll'         'scr'   lines to scroll with CTRL-U and CTRL-D
'scrolljump'     'sj'    minimum number of lines to scroll
'scrolloff'      'so'    minimum nr. of lines above and below cursor
'selection'      'sel'   what type of selection to use
'showmode'       'smd'   message on status line to show current mode
'sidescroll'     'ss'    minimum number of columns to scroll horizontal
'sidescrolloff'  'siso'  min. nr. of columns to left and right of cursor
'smartcase'      'scs'   no ignore case when pattern has uppercase
'timeout'        'to'    use timeout for mapped key sequences
'timeoutlen'     'tm'    time that is waited for a mapped key sequence
'undolevels'     'ul'    maximum number of changes that can be undone
'viminfo'        'vi'    information to remember after restart
'visualbell'     'vb'    use visual bell instead of beeping
'wrapscan'       'ws'    searches wrap around the end of the file

imap jj <Esc>

let mapleader = " "
map <leader>a :action $SelectAll<CR>
map <leader>b :action GotoDeclaration<CR>
map <leader>c :action $Copy<CR>
map <leader>d :action EditorDuplicate<CR>
map <leader>e :action RecentFiles<CR>
map <leader>f :action Find<CR>
map <leader>g :action GotoLine<CR>
map <leader>h :action TypeHierarchy<CR>
map <leader>i :action ImplementMethods<CR>
map <leader>m :action EditorScrollToCenter<CR>
map <leader>n :action FileChooser.NewFolder<CR>
map <leader>o :action OverrideMethods<CR>
map <leader>p :action ParameterInfo<CR>
map <leader>q :action GuiDesigner.QuickJavadoc<CR>
map <leader>r :action Replace<CR>
map <leader>s :action SaveAll<CR>
map <leader>t :action Vcs.UpdateProject<CR>
map <leader>u :action GotoSuperMethod<CR>
map <leader>v :action $Paste<CR>
map <leader>w :action EditorSelectWord<CR>
map <leader>x :action $Cut<CR>
map <leader>y :action EditorDeleteLine<CR>
map <leader>[ :action EditorCodeBlockStart<CR>
map <leader>] :action EditorCodeBlockEnd<CR>
map <c-w><c-c> :action VimWindowClose<cr>
map [c :action VcsShowPrevChangeMarker<cr>
map ]c :action VcsShowNextChangeMarker<cr>
map [d :action QuickImplementations<cr>
map ]d :action QuickImplementations<cr>
map gcc :action CommentByLineComment<cr>
map <leader>ff :action FindInPath<cr>
map <leader>fu :action FindUsages<cr>
map <leader>su :action ShowUsages<cr>
map <leader>cv :action ChangeView<cr>
map <leader>bb :action ToggleLineBreakpoint<cr>
map <leader>br :action ViewBreakpoints<cr>
map <leader>ic :action InspectCode<cr>
map <leader>oi :action OptimizeImports<cr>
map <leader>re :action RenameElement<cr>
map <leader>rf :action RenameFile<cr>
map <leader>gq :action ReformatCode<cr>
map <leader>mv :action ActivateMavenProjectsToolWindow<cr>
map <leader>dd :action Debug<cr>
map <leader>dc :action ChooseDebugConfiguration<cr>
map <leader>rr :action Run<cr>
map <leader>rc :action ChooseRunConfiguration<cr>
map <leader>q  :action CloseActiveTab<cr>
map <leader>ga :action GotoAction<cr>
map <leader>gi :action GotoImplementation<cr>
map <leader>gs :action GotoSuperMethod<cr>
map <leader>gd :action GotoDeclaration<cr>
map <leader>gt :action GotoTest<cr>
map <leader>gr :action GotoRelated<cr>
map <leader>gb :action Annotate<cr>
map <leader>tl Vy<cr>:action ActivateTerminalToolWindow<cr>
map <leader>tl y<cr>:action ActivateTerminalToolWindow<cr>
map ]e :action GotoNextError<cr>
map [e :action GotoPreviousError<cr>

vs code

plugin들을 소개 하기에는 사용 하지 않는 플러그인들은 정리를 하고 해당 내용을 업데이트 하는게 좋겠다.

현재 맥북에어 설정에는 아래 설정만 되어 있고, 실제 다른 컴퓨터에는 엄청 많은 설정이 있는데, 정리가 필요하다.

settings.json

{
  "workbench.colorTheme": "Material Theme Darker",
  "vim.insertModeKeyBindings": [
    {
      "before": ["j", "j"],
      "after": ["<Esc>"]
    }
  ]
}

keybindings.json

// Place your key bindings in this file to override the defaultsauto[]
[
  {
    "key": "ctrl+shift+n",
    "command": "explorer.newFile"
  },
  {
    "key": "ctrl+shift+d",
    "command": "explorer.newFolder"
  }
]

그 밖에

evernote _ 무료 | 유료 _ 유료 사용중 _ …더 빡세게 써야겠다. _ 온갖 메모 _ 독서 후 독후감 정리 _ 재테크 _ 매매일지 _ 강의 메모
notion _ 무료 | 유료 _ 무료 사용중 _ 주로 드라마, 영화 감상 정리 _ 코드 블럭이 필요한 개발 관련 내용 _ 하루 일지 _ 일일 일지를 주간으로 관리 한지 얼마 안됐다. (진작 쓸걸..)
dynalist _ 무료 | 유료 _ 보통 1년 단위의 목표를 적어둠 * 앞으로는 좀 쪼개서 써볼까 한다.
things 3 _ 유료 _ 기기 수 제한 없음. _ 하루 하루의 해야 할 일들 _ 동기화 기능은 좋은데, 아이폰, 아이패드, PC 모두 따로 사야 함. * 아이폰/PC만 사서 사용
obsidian _ 무료 | 유료 _ 사실 예전에 쓰다가, 말았는데 요새 공부한걸 정리용으로 쓰려고 한다. (계획중)
itsycal * 메뉴바에 달력을 볼 수 있게 해준다.
translate tab * 유료 (단축키 지정시 바로 문장 번역)
SnippetsLab _ 유료 (각종 스니펫 저장) _ Alfred workflow를 지원 해줌. * 단축키로도 검색 가능
Alfred _ 유료 _ 기기 수 제한 없음. * 무조건 써야 하는 툴
popclip _ 유료 _ 기기 수 제한 없음. _ PC MacOS에서 아이폰스럽게 쓸 수 있도록 해주는 툴 _ 사실 굳이 필요할까? (잘 안쓰게 된다)
Bartender 4 _ 유료 _ 기기 수 제한 없음. _ 버전 업데이트 마다 구매 해야 하는 단점 _ 그치만, 사야 한다.
Allkdick _ 무료 _ 네이버 사전을 메뉴바에서 사용 가능 * 만든 개발자분 정말 감사합니다.
shifty _ 무료 _ > A macOS menu bar app that gives you more control over Night Shift. * 딱히 설명하기 애매했으나, 페이지에서 한 문장으로 설명한 것을 가져옴.
Dropover _ 유료 _ 기기 수 제한 없음. * 특정 파일을 클릭하고 흔들면, 임시?! 공간이 뜨는데, 굉장히 편리하다.
BetterTouchTool _ 유료 _ 기기 수 제한 없음. _ 터치바든, 온갖 키보드, 액션들을. 설정 할 수 있다. _ 주로 창을 이전/다음 데스크톱 이동시키는 Action을 설정 해두고 쓴다. _ 이거 하나만 해도 돈 값한다고 생각중.. _ 다만, 키보드 키 바인딩 변경도 커버 되지만, 이 부분은 karabiner 쓴다. 그외는 모든 영역을 해당 툴로 씀
Karabiner-Elements _ 무료 _ 키보드 키 바인딩 변경 최강앱
monosnap _ 무료 _ 스크린샷계 최강자 (window 유저는 pickpick인가? 쓰는게 최고)
Irvue _ 무료 _ 배경화면 자동으로 교체
DaisyDisk _ 유료 _ 기기 수 제한 없음. * DiskSpace 관리 앱
GoodNote5 _ 유료 _ 아이패드/PC 동기화 되면서 최고 _ 두쪽 보기 지원이 안되서, 아쉽다. _ 노트 앱(PDF 파일 주로 보는 용도) * Ebook을 주로 본다.
panda _ 무료 _ typora가 유료화 되면서 옮겨 왔다. _ macdown 쓰다가 bear에서 만든 거라 쓰는 중인데, 만족함 _ markdown editor
Contexts _ 유료 _ 기기 수 제한 없음. _ Radically simpler & faster window switcher _ 말그대로 윈도우 앱들 검색 하거나, 축약어로 전환 할 수 있도록 해줌

어쭙잖은 개발자의 2021 회고

Fri, 31 Dec 2021 23:53:00 GMT

2021 회고

목표

다이어트
영어공부
명상
- 하루 2번
마음일기 쓰기
경제/재테크 공부
등산
토이프로젝트
TDD/Rust/Vim/Kotlin 학습하기

이 중에서 성공 했던 것들은 거의 경제/재테크 공부 밖에 없는 것 같다. 그 중에서 명상은 그래도 지키려고 나름 노력 많이 했었다.

Vim은 확실히 쓰려다가 Emacs로 넘어갔다가 다시 Vim으로 돌아가려고 셋팅을 했다. Kotlin을 실무에 계속 쓰려고 Java를 빼고 Kotlin으로 주로 작업을 하고 있는데, 관성이 있는 건지, Kotlin 언어스럽게 코드를 구성하기가 굉장히 어려웠다.

자주 쓰여 있는 return null에서 벗어나고 싶은데, 어떻게 하면 저 문장을 안 쓸 수 있을지? 고민 중인데, 쉽지 않다. 저걸 안쓰려면, 해당 코드를 만지는 모두가 협의가 되어야 한다는게 아직까지 내 생각이다.

올해부터 내가 맡은 영역이 있는데 차근 차근 하나씩 없애보려고 노력 중이다.

강의

~~프론트엔드 Back to the Basics : 지속 가능한 코드작성과 성능 향상법~~

친구가 결제 해줘서 보게 되었는데, 태곤님은 워낙 프론트계의 구루셔서 열심히 보긴 했는데, 애매하게 팀원이 많아져서 팀이 FE/BE로 나뉘게 되었다.

그런데, BE쪽으로 가다보니 FE쪽의 마크업 개발 영역과는 더 멀어졌다. (애초에 프론트 서비스 개발이지만, 회사 자체가 마크업 개발은 따로 커뮤니케이션 해서 개발을 진행 하기 때문에, FE긴 하지만 HTML/CSS를 못하니 늘 불안 했다) 그래도, 태곤님 강의 들으면서 눈이 넓어지긴 했다.

스프링 프레임워크 입문

사실 3년전에 만 얼마주고 샀는데, 안보고 있다가 보게 되었다. 한 시간 좀 더 되는 시간에 스프링을 얼마나 알겠냐마는 그냥 유명한 분이시고 해서 샀었는데, 생각보다 내용이 알차진 않았다.

영화

마진콜
클로젯
프리즌
백두산
폴라
소울
PMC 더 벙커
미나리
고질라 vs 콩
낙원의 밤
서복
내일의 기억
더 스파이
비와 당신 이야기
잭스나이더의 저스티스 리그
분노의 질주 더 얼티메이트
담보
다만 악에서 구하옵소서
귀멸의 칼날 무한열차
제 8일의 밤
미드나이트
호텔 뭄바이
크롤
베놈2
보이스
이터널스
광해
발신제한
인질
국제수사
골든 슬럼버
모가디슈

드라마

사이코지만 괜찮아 (보다 말았다.)
경이로운 소문
도망치는건 부끄럽지만 도움이 된다.
도쿄구울
귀멸의 칼날
체르노빌
보좌관
시지프스 (보다 말았음)
DP
유레이즈미업
오징어게임
좋아하면 울리는 시즌2
도시남녀의 사랑법
마이네임
지옥
해피니스
고요의 바다

독서

뉴욕주민의 진짜 미국식 주식투자
규칙없음
시간여행TV의 주식투자 전략
IT좀 아는 사람
부의 골든타임
파이낸셜 프리덤
어느 날의 우리가 여느 날의 우리에게
한 컷의 인문학
부의 인문학
제시 리버 모어의 회상
디 앤서
초격차
강방천의 관점
내가 춤추면, 코끼리도 춤을 춘다.
생각이 너무 많은 서른 살에게
사랑의 기술
일주일은 금요일부터 시작하라
정서적 협박에서 벗어나라
나는 나로 살기로했다
사피엔스
초보자를 위한 투자의 정석
프로젝트 오너
부의 대이동
서울 자가에 대기업 다니는 김 부장이야기 1
서울 자가에 대기업 다니는 김 부장이야기 2
서울 자가에 대기업 다니는 김 부장이야기 3
월급쟁이 부자로 은퇴하라

작년보다 책을 너무 덜 읽었다. 그렇지만, 리디페이퍼를 산 이후로 속도가 붙어서 엄청 빠르게 책을 읽을 수 있었다. 재택 근무가 길어지니, 확실히 책보다 유투브를 더 많이 보게 되고, 경제학이나 재테크 관련 서적 보다 유투브를 많이 보게 되니 책을 읽는 시간이 줄게 되었다. 이 부분은 반성해야 된다…

팀의 분리 (FE/BE의 세상)

내가 일 하는 프론트 팀이 팀 안에서 FE/BE 파트가 나뉘게 되었고, 그 안에서 어찌 보면 일을 하게 되었는데, 생소하기도 하고 업무를 또 새로 또 받게 되었다.

한 9개월 정도 그 일을 했는데, 정말 적응이 안되고 오래 된 레거시다보니 일정이 더디게 지연 되었다. (내년에 열심히 하자)

거기다가 돈 관련 업무라 그런지, 수정사항 하나도 굉장히 조심스럽고, 레거시 스펙을 제거 하는 일도 굉장히 많은 사람들을 찾고 또 찾아내서 처리 해야 한다는 부담감이 속도를 저하 시키는 요인이었고, 실제로 잘못 되고 있는 걸 바로 피드백을 받을 수 없는 부분이 눈 가리고 칼질 하는 느낌을 받았다. (실제로 사고를 치기도 했다)

어떤 보완 할 수 있는 시스템의 부재도 크고, 리소스도 없고 그렇다고 내가 야근 하고 주말까지 반납해서 회사 일에 충성을 다 해야 하는건가? 생각도 들었다.

어찌보면 핑계 같기도 변명이기도 하지만, 어느 순간부터인가? 내가 회사 일을 열심히 한다고 술술 풀리는 것은 아니였다.

그래서 할 수 있는 시간에 최선을 다 하기로 생각 했다. 그래도 역부족이었을지도 모르겠다.

연차 대비 실력..? 글쎄

16년도 부터 일을 해왔으니, 그래도 시간이 지나고 일을 곧 잘 했던 것 같은데, 내가 모르는 부분은 왜 이렇게 많고, 내가 쓰는 기술도 모르고 지나친 부분이 어찌나 많은지, 한 해 내내 열심히 따라 가려고 해도 벅찬 느낌이었다.

어찌보면, 내가 지난 2년 동안에는 경제 관련 관심사만 두어서인지도 모르겠다. 그 이유가 아마 프로그래밍에 대한 어떤 번아웃이 오고 나니 퇴근 이후에는 정말 쳐다 보지도 않았다.

오히려 주식 시장이나 경제 관련 공부를 하는게 더 재밌었던?

그런데, 시간이 지나고 보니 내가 과연 연차에 대해 증명할 수 있는 실력을 가지고 있는지? 궁금해졌다.

코드의 퀄리티를 잘 하는 것은 아니라는 생각이 들었고, 인프라적인 지식은 많이 올라갔지만, 늘 코드와 인프라 운용은 대비 되는 부분 같다. 이것 하나만 잘 하는 것도 어려운데, 저것도 놓을 수 없으니, 어려움이 배가 된 느낌..?

그런데, 둘다 재밌으니 둘 다 놓지는 못하겠고, 그러다보니 더 산으로 간 느낌이다. 그래도 인프라와 개발 모두를 엮는 건 재미있는 요소라 생각 한다.

팀의 신입 개발자분이 빨리 성장 하려면 어떻게 해야 하는지 물어 왔을때, 내가 답했던 건 오히려 되물음이었다.

도대체 잘 하는 개발자가 뭘까요? 정량적으로 수치화 할 수 있는 잘함이 있을까요?

나는 아직도 모르겠다.

기술적으로 앎이 많던, 개발을 빠르게 해내던, 코드를 정말 깔끔하고 추상화 잘 하면서 작성 한다던지, 가독성이 좋은 등등,, 수 많은 좋음 사이에서 내가 늘 고민 하는 것은 “수정이 쉬운” 부분이 나는 추상화를 잘 설계 하는 것보다 중요했다. 물론 중복 없고, 추상화가 잘 된…그런걸 잘 지키며 만든 프로그램이 있을 수도 있지만, 적어도 나는 OCP를 잘 지키며 개발하는 게 능사가 아니라고 생각했다.

내가 말하는 쉬움은 누가 봐도 이 코드를 수정 하기 좋은가?

코드에 중복이 있기도하고, 폭포수 모델처럼 코드가 위에서 아래로 읽으면 이해가 되는 수준이고, 패턴도 전무하고 하는 느낌의 코드들이다. 서비스 개발에서는 추상화 시킨다고 공통화 하거나 하는 경우 문제가 연동 된 코드들이 많을 수록 장애 포인트가 커진다. 그러다보니 나는 “중복 러버”가 되었다.

차라리 중복 코드를 넣고, 나중에 서비스의 스펙이 사라지던, 그 서비스가 사라지던 하는게 낫다.

그 중복의 정도를 조절 하는 것이 제일 어렵다.

물론, 이게 정답도 아니고, 너의 한계야 라고 할 수도 있지만, 어쩔 수 없다.

내가 속한 곳에서는 서비스 개발의 목적은 최대한 빠르게 일정안에 기능 구현을 소화 해내고, 적정 트래픽도 받을 준비 (인프라 셋업)까지 다 해야 한다.

나는 내가 잘 하고 있다고 생각 하진 않는다. 나는 코드를 잘 짠다?와는 거리가 먼 개발자다. 사실 비즈니스 로직의 더러움을 코드가 가져다 주진 않는다고 생각 하는 편이다.

개발자는 얼마나 덜 짜는지가 서비스 완성의 척도라고 본다. 정말 필요한 부분만 코드를 작성 해서 서비스를 유지 시키는 게 중요하지.

기획자가 원하는 대로 수용해서 서비스 코드에 넣는게 중요한게 아닌 것 같다.

어쩌면, 개발자는 얼마나 코드를 덜 짜서!? 서비스를 확장 해나가는 건지가 중요한 능력 같기도 하다. 그리고, 그게 가능하면 좋겠지만 불가능한 경우도 있으므로, 결과적으로 실무는 늘 아름답지 않다.

책의 예제는 쉽고 간결하며, 굉장히 단순한 형태의 데이터를 기준으로 삼지만, 실무에서는 스펙도 더럽고, 레거시도 더럽고, 이상은 높다.

그것을 노력으로 서비스가 무너지지 않게 하는 것은 팀의 결합도인 것 같다. 나는 팀의 시너지가 소통에서 온 다고 생각 하는 사람이다.

개발자들끼리 이야기 하다가 어떤 이야기 나와서 내가 말한 건 이렇다.

“잘 한다고 그 사람과 일하고 싶진 않고, 그 사람과 일 하는게 재밌어야 오래 하고 싶어진다.”라고 말 했는데, 이게 나의 정답 같다.

2022년도에는 나도 일 할 때 재밌는 사람이고 싶다.

그래서 회사에 속한 개발자로써의 계획은 ?

불평/불만을 내려 놓기
인정을 빨리 하는 것

총 2가지를 지키고 싶다. 불평/불만을 말하는 것보다 지금 당장 실행 할 수 있는 것을 하는게 시간을 아끼는 방법이다.

그리고, 스우파를 보면서 느낀 건데, 허니제이의 강함은 “인정”에서 온다고 생각 했다. 밤새도록 했음에도 결과가 나오지 않더라도, 상대방보다 내가 더 잘 한것 같음에도 결과는 내가 패배일 수 있고, 내 의견이 팀의 색깔과 부합 되지 않거나, 방향이 다를 수 있다. 그럴때, 인정 하는 것

나는 늘 내 생각이 옳고, 고집 부렸던 것 같다. 그래서 나와 다르면, 늘 부정적인 시각으로 보거나 말을 했던 것 같다.

그 부분들은 이제는 내려놓고 온전히 할 수 있는 것에 집중 하는 팀원이 되고 싶다.

개인적인 목표

Kotlin의 세계관을 좀 더 잘 이해하기
Rust를 이해 해보자.
토이 프로젝트

작은 것부터 하나씩 만들어가보자.

어려운 프로그램도 결국, 단순하고 쉬운 함수 하나부터 시작한다. 그런 토이 프로젝트를 진지하게 해보길!

어쭙잖은 프로그래머로 산다는 것

Sun, 28 Nov 2021 21:12:00 GMT

가끔 그런 생각을 하곤 한다.

나에게는 어떤 유능한 도구를 만들거나, 프레임워크를 만들거나 하는 어떤 경험은 해본 적이 없다 보니 나에겐 선망의 대상

약간 굉장히 어려운 영역에 있다고 생각한다. 내가 하는 개발은 서비스 영역이라, 코드의 퀄리티 혹은 추상화에 대한 부분은 늘 어렵다.

이 업계에 몸 담은지도 그래도 좀 시간이 흘렀음에도 내가 느끼는 것은 더 나은 개발자가 되는 것은 무엇일까?

그리고, 프로그래머로 산다는 것은 무엇일까?

어쩌면, 누군가에게는 이 일이 그저 적절하게 사는데 필요로한 경제활동의 영위 정도 일 수도 있고,

누군가에게는 꿈을 펼칠 수 있는 어떤 발판이 될 수도 있고, 또 다른 누군가에게는 이 일을 하는 사람들에게 도움이 되는 것들을 만들어 가는 데 뜻이 있고 능력이 있을 수 있다.

유튜브 개발 관련 영상을 보다 보면, 급이 낮은 프로그래머와 높은 프로그래머를 나누는데 여러 가지가 있다고 한다. 하드웨어부터 수학등 뭐 굳이 필요한 것은 아니지만, 있다면 더 좋은 프로그래머가 되는 틀임은 분명하다.

그렇다고, 어중간한 프로그래머는 필요 없는 것일까?

실력의 급을 명확하게 가를 수 있을까? 어떻게 보면 프로그래머의 영역도 결국 경험의 차이인 것이고, 내가 경험하지 못했던 부분은 나에게 생소하다. 내가 해보지 않았다고 내가 못한 사람인가? (물론, 못할 수도 있지.)

그런데, 늘 유능한 프로그래머만이 팀에 있는게 중요한 포인트는 아니라고 생각한다.

프로그래머든 아니든 어떤 협업의 주체에서 일을 해야 하는 관계는 나 혼자만 잘한다고 잘 되는 것은 아니다. 고로, 내가 무언가 부족한 부분이 있더라도 괜찮다.

결국, 이 업계에서 오래 있으면서 여러가지 변화를 체득하고, 나만의 언어로 기술을 표현할 줄 아면 되지 않을까?

유퀴즈를 보다가 무릎을 치게 되었는데, 그게 바로 어느 기업의 부사장까지 올라갔다가 책방 주인이 되신 분의 이야기였는데, 굉장히 공감했다.

https://youtu.be/kB2puzk_IfQ

https://youtu.be/p-Kzlcff6sI

그리고, 생각 외로 반성도 많이 하게 되었다.

나는 늘, 감정을 잘 드러내는 팀원이었고, 사람이었다. 지난 몇 년을 돌아보더라도, 나는 누군가 나에게 도발을 취하면 나도 도발하며 맞대응하는 전략의 화법이나, 감정을 짜냈고 늘 경계하며 살았다.

그리고 그 감정이 무엇일까? 돌아봤는데, 내가 지닌 어떤 엔지니어로써의 능력이 굉장히 높지 않음에 대해 들킬까 하는 마음이 아녔을까? 늘, 이렇게 방향을 정해야 될까? 몇 년 차인데, 이 정도 시간 안에는 어느 수준의 코드 퀄리티는 내놓아야 하지 않을까?

조마조마했다. 늘 그랬다. 막연한 불안함을 지니고 일하다 보니, 늘 마음 한구석에는 더 잘하고 싶은 욕구가 있었다.

그러다 어느 순간 조금씩 내려놓고, 팀 스포츠라는 부분을 받아들이고 이해했다.

처음에는 유능한 개발자는 아니더라도 그래도 어느 정도 족적을 남길 수 있는 엔지니어가 되어야지! 마음먹곤 했다. 그런데, 그렇게 마음을 먹으니, 코드를 더 좋게 작성할 수 없다. “더 좋게”는 물론 상대적이지만, 내 나름의 상대적인 코드 퀄리티로 치자면 그렇다.

가끔 왜 이렇게 해놨을까? 이해가 안 되며, 이 정도로 이 업계에서 계속 일 할 수 있을까? 계속 나를 의심했던 것 같다. 어떤 코드의 자존감으로 치자면, 굉장히 낮은 거겠지?

늘 최선의 코드였지만, 뒤돌아 보면 아쉬운 코드들, 나의 흔적들은 다른 이들이 보더라도 이해하기 쉬운, 고치기 쉬운 코드 그리고 효율적이면 좋겠다는 염원을 늘 가지고 있음에도 포기가 안됐던 나날들이 되려 족쇄였고, 더 많은 버그를 만들어 냈다.

시간이 지나니, 팀 스포츠를 깨닫고 나니 내가 잘할 수 있는 영역에 최선을 다 하자. 남들이 빼먹은 부분을 내가 보완하자. 혹은 내가 빼먹은 부분은 누군가 날 보완해주겠지?라는 생각을 했다.

결국, 코드의 퀄리티 또한 팀 스포츠였고, 팀의 커뮤니케이션 레벨이 책임 진다.

프로덕트의 스펙들을 얼마나 이해하고, 얼마나 많은 방향들을 점검해봤는지? 에 대한 팀원들 간의 스포츠 게임이다. 스펙에 대한 이해도에 따른 높낮이가 평평하지 않고 굴곡진다면, 분명 버그를 만들어 낼 수밖에 없다.

내가 이해하는 바와 다른 이가 이해하는 바가 알맞은 정도여야 좋은 코드가 서비스에 포함된다. 그리고 좋은 업무 프로세스가 정착된다.

늘 나 자신의 능력을 의심하는 것보다 내가 다른 사람들을 보완할 수 있는 부분이 무엇일지? 관점을 옮기는 게 오히려 나에게도 더 큰 배움의 기회가 된다. 다른 사람과 이야기를 많이 해보는 게 결국 중요하다. 물론, 그게 틀린 설계, 잘못된 코드일지라도 정답으로 가는 길에 있는 아주 작은 점들이 될 것이므로 이야기를 많이 해나가는 조직이 유리하다.

고로, 프로그래머로 산다는 것은 태도가 중요하고, 마음 가짐이 결국 말에 담기고, 그 말들이 모여서 좋은 시너지를 만들고, 시너지가 모여 좋은 서비스, 사용자에게 닿아 있는 서비스가 된다고 생각했다.

Nginx HTTP Server 1장 정리

Wed, 17 Nov 2021 22:49:00 GMT

Nginx HTTP Server 책을 정리 하였습니다.

PCRE 라이브러리

엔진엑스를 컴파일 하는데 PCRE 라이브러리가 필요하다. 엔진엑스의 URL Rewrite 모듈, HTTP 모듈은 PCRE를 정규식 구문에 사용한다. pcre pcre-devel 두 가지 패키지를 설치하는게 기본적이다.

zlib 라이브러리

zlib 라이브러리는 압축 알고리즘을 개발자에게 제공하낟. 엔진엑스에서 gzip 압축을 하는데 필요하다. zlib zlib-devel 두 가지 패키지를 설치하는게 기본적이다.

openssl 라이브러리

강력한 범용 암호 라이브러리와 함께 보안 소켓 계층과 전송 계층 보안 프로토콜을 구현한다. openssl openssl-devel 패키지가 필요하다.

nginx 컴파일 옵션

--with-cc C컴파일러 대체 위치를 지정 한다.
--with-cpp C++ 컴파일러 대체 위치를 지정 한다.
--with-cc-opt C 컴파일러 명령행에 전달할 부가 옵션을 정의한다.
--with-ld-opt C 링커 명령행에 전달할 부가 옵션을 정의한다.
--with-cpu-opt 대상 프로세서 아키텍처를 지정한다.

기본 활성 모듈 설명

--without-http_charset_module 웹 페이지를 재인코딩하는 문자 세트(Charset) 모듈비활성화
--without-http_gzip_module Gzip 압축 모듈 비활성화
--without-http_ssi_moduleSSI(Server Side Include) 모듈 비활성화
--without-http_userid_module 쿠키로 사용자를 식별하는 사용자 ID(User ID) 모듈비활성화
--without-http_access_moduleIP 주소 범위의 접근을 제어하도록 구성할 수 있는 접근(Access) 모듈 비활성화
--without-http_auth_basic_module 기본 인증(Basic Authentication) 모듈 비활성화
--without-http_autoindex_module 자동 색인(Automatic Index) 모듈 비활성화
--without-http_geo_moduleIP 주소 범위로 변수를 지정할 수 있는 지리(Geo) 모듈 비활성화
--without-http_map_module키-값 형태의 자료 구조를 선언할 수 있는 맵(map)모듈 비활성화
--without-http_referer_module 참조 제어(Referer control) 모듈 비활성화
--without-http_rewrite_module 재작성(Rewrite) 모듈 비활성화
--without-http_proxy_module 다른 서버에 요청을 전달하는 프록시(Proxy) 모듈비활성화
--without-http_fastcgi_module
--without-http_uwsgi_module
--without-http_scgi_module 각각 FastCGI, uWSGI, SCGI 프로세스와 상호작용하는 FasICGI, uWSGI, SCGI 모듈을 비활성화
--without-http_grpc_module GRPC 서버로 요청을 넘기는 ERPC 모듈을 비활성화
--without-http_memcached_module 멤캐시디 데몬(Memcached daemon)에 연동되는멤캐시디 (Memcached) 모듈 비활성화
--without-http_limit_conn_module 정의된 구역(zone)에 따라 자원 사용량을 제약하는연결 제한(Limit Connections) 모듈 비활성화
--without-http_limit_req_module 사용자당 요청 횟수를 제한하는 요청 제한(LimitRequests) 모듈 비활성화
--without-http_mirror_module 배후에서 원래 요청을 복제해서 부가 요청을 만드는요청 복제(Mirror) 모듈 비활성화
--without-http_empty_gif_module 메모리에서 공백 Gif 이미지를 제공하는 빈 GM(EmptyGIF) 모듈 비활성화
--without-http_browser_module 사용자 에이전트(User Agent) 문자열을 해석하는브라우저(Browser) 모듈 비활성화
--without-http_upstream_hash_module 업스트림 구역에서 hash 지시어를 제공하는 업스트림 해시(upstream Hash) 모듈 비활성화
--without-http_upstream_ip_hash_module 업스트림 구역에서 ip_hash 지시어를 제공하는 업스트림 IP 해시(Upstream IP Hash) 모듈 비활성화
--without-http_upstream_least_conn_module 업스트림 구역에서 least_conn 지시어를 제공하는최소 업스트림 연결(Upstream Least Conn) 모듈 비활성화
--without-http_upstream_keepalive_module 업스트림 구역에서 keepalive 지시어를 제공해 업스트림 연결을 캐시하는 업스트림 연결 유지(UpstreamKeepalive) 모듈 비활성화
--without-http_upstream_zone_module 업스트림 구역에서 zone 지시어를 제공해 공유 상태보관 구역을 설정할 수 있는 업스트림 구역(UpstreamZone) 모듈 비활성화
--without-http_split_clients_module A/B 테스트에 사용할 변수를 만드는 고객 분할(SplitClients) 모듈 비활성화

주요 사전 구성 요소는 기본적으로 GCC, PCRE, zlib, Openssl 이다.

nginx master process: 해당 프로세스는 루트에서 실행 해야 한다. 루트로 실행 하지 않으면, 80 포트, 443 포트에 접근 할 수 없다.
nginx worker process: 설정 파일에 서술한 user 지시어로 지정한 계정에 따라 주 프로세스가 자동 생성한다.

nginx command

nginx -s stop : 데몬을 강제로 종료한다. (TERM 시그널)
nginx -s quit : 안전하게 데몬을 종료한다. (QUIT 시그널)
nginx -s reopen : 로그 파일을 다시 연다.
nginx -s reload : 구성 파일을 다시 읽는다.

설정 테스트

sbin/nginx -t 로 구성 파일이 정상적인지 테스트 할 수 있다. -t 옵션 자체가 test의 의미이다.

운영 중인 설정 파일을 조작하는 건 위험하니, 임시 파일을 만들고, 해당 파일을 테스트 하는 것이 좋은데, 이때 쓸 수 있는 옵션이 -c 이다.

$ sbin/nginx -t -c /home/seungdols/apps/nginx/conf/nginx-temp.conf

위와 같이 임시 파일을 테스트 할 수 있다.

기타 명령어

sbin/nginx -V 를 입력하면 어떤 버전인지? 빌드시 전달 된 arguments는 무엇인지 알 수 있다.

-g 을 이용하면, 구성 파일에 포함 되지 않은 추가 구성 지시어를 지정할 수 있다.

jenkins tip을 정리하자.

Thu, 05 Aug 2021 22:47:00 GMT

Job이 안 죽고 Zombie 상태로 계속 돌 때

Go to “Manage Jenkins” > “Script Console” and run a script:

 Jenkins.instance.getItemByFullName("JobName")
        .getBuildByNumber(JobNumber)
        .finish(hudson.model.Result.ABORTED, new java.io.IOException("Aborting build"));

ref. https://stackoverflow.com/questions/14456592/how-to-stop-an-unstoppable-zombie-job-on-jenkins-without-restarting-the-server

build queue가 꽉 차서 해소가 안될 때

Go to “Manage Jenkins” > “Script Console” and run a script:

Jenkins.instance.queue.clear()

ref. https://support.cloudbees.com/hc/en-us/articles/360051376772-How-can-I-purge-clean-the-build-queue-?page=3

실행 중인 Job을 한번에 중지 시키고 싶다면?

Jenkins.instance.getAllItems(AbstractProject.class).each {it ->
  it.getBuilds().each {
    if (it.isBuilding()) {
      if(it.getDisplayName().contains("JobName")) {
          println(it.getFullDisplayName());
          it.doStop()
      }
    }
  }
}

ref. https://sites.google.com/site/xiangyangsite/home/technical-tips/software-development/jenkins/cancel-all-jobs-in-the-queue/stop-running-jobs

JENKINS-48300: if on an extremely laggy filesystem error

wrapper script does not seem to be touching the log file ~~

(JENKINS-48300: if on an extremely laggy filesystem, consider -Dorg.jenkinsci.plugins.durabletask.BourneShellScript.HEARTBEATCHECKINTERVAL=86400)

위와 같은 에러가 발생 할때, 아래 방법을 사용.

파이프라인에 추가

script {
  System.setProperty("org.jenkinsci.plugins.durabletask.BourneShellScript.HEARTBEAT_CHECK_INTERVAL", "3800");
}
pipeline {
 // todo
}

Go to “Manage Jenkins” > “Script Console” and run a script:

System.setProperty("org.jenkinsci.plugins.durabletask.BourneShellScript.HEARTBEAT_CHECK_INTERVAL", "3800");

ref. https://pythonq.com/so/jenkins/382418

Logback maxHistory가 동작을 안한다?

Sun, 13 Jun 2021 22:00:00 GMT

Logback maxHistory bug

logback의 rolling 정책중 하나인 SizeAndTimeBasedRollingPolicy 를 사용하는데, maxHistory가 동작을 하지 않는 이슈가 있는데, 이게 1.2.3버전에 있는 버그였다.

https://stackoverflow.com/questions/47752955/logback-sizeandtimebasedrollingpolicy-applies-totalsizecap-to-each-day-in-maxhi

https://jira.qos.ch/browse/LOGBACK-1361

그런데, 아직 1.3.0이 릴리즈가 되진 않았다. (https://mvnrepository.com/artifact/ch.qos.logback/logback-classic) 계속 alpha버전만 업데이트가 되고 있다.

spring-boot-starter-web 모듈은 기본적으로 spring-boot-starter-logging 을 참조하는데, 이 모듈에서 logback을 release버전을 참조 하고 있다.

조치 방법은 아래와 같다.

spring-boot에서 spring-boot-stater-logging 의존성을 제거 후 logback-alpha5 를 사용하는 방법
log4j2로 교체
- https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter-log4j2
cron으로 스크립트를 돌려서 로그를 정리 해주는 방법
- docker환경인 경우 tinycron으로 스크립트를 동작 시키는 방법이 있다.

코드스피츠 77 - ES6+ 5회

Fri, 26 Mar 2021 15:29:00 GMT

코드스피츠 77 - ES6+ 5회차 (Block, Non-Block & Sync, Async)

Block, Non-Block

Flow를 막고 있는 것을 Block이라고 하고, 그런 상태를 blocking(상태)로 표현 한다.

업계 표준이 존재함. 그 표준 시간 동안 멈춰 있으면, Blocking/Non-Blocking으로도 볼 수 있다.

Flow is blocking

for (const i of (function*() {
  let i = 0
  while (true) yield i++
})())
  console.log(i)

// script timeout
// 플랫폼의 안정성을 위해 블록 되는 시간이 길면 강제 종료 시킴.

Blocking function

점유하는 시간만큼 블록을 일으키는 함수

const f = v -> {
  let i = 0;
  while(i++ < v);
return i;
}
f(10);
f(1000000000000000000); // blocking function

인자에 따라서 빨리 실행 될 수도 있고, 배열의 원소가 1억개 이상이면, blocking function이라 부르고, 이런 함수는 인자에 따라서 blocking 의 범위가 늘어나고 좁아든다.

Java의 HashSet과 JavaScript의 WeakSet과 유사하다. 이 두 객체는 blocking function이 아닌데, 이유는 인자에 따라서 blocking이 정해지지 않고, Hash에 따라서 값을 찾을 수 있다. (비용이 항상 정해져 있음)

그리고 우리는 뭔지 모르게 Blocking Function으로 작성을 한다. 인자에 따라서 정해져있는지 체크를 하진 않는다.

함수 한 두개가 Blocking Function이라면, 어플리케이션 전체가 기저의 영향을 받게 되어 운. 안좋으면 강제 종료 될 수 있다.

그래서 코드를 잘 짜야 한다.

Blocking Function의 종류

배열 순회, 정렬
DOM 순회
이미지 프로세싱

Blocking Evasion

독점적인 cpu점유로 인해 모든 동작이 정지됨
타임아웃체크에 의해 프로그램이 강제 중단됨

제어 받는 코드로 어플리케이션으로 작성하면, OS가 제어권이 훨씬 높고, 어플리케이션이 중단 됨. (어플리케이션이 아무리 돌아도 전화 오면 모바일은 전화 우선권이 높다. 예시를 들어주심.)

블록킹의 조합을 예측할 수 없다.

const f = v -> other(some(v), v * 2);
f(10);

순차실행

1 2 3

시분할 운영체제의 동시 실행

1 2 1 2 3 1 2 1 같은 순서로 실행

왜 시분할로 실행 하는가? 멀티태스킹 지원이 필수이기 때문..

자바스크립트 쓰레드

Main UI Thread 1 (얘가 흔히 아는 싱글 쓰레드)
BackGround Thread N
Web Worker Thread (HTML5에서 나오게 됨.)

Main UI Thread

자신의 시간큐를 무한 루프 돌리면서 프레임을 실행 시킴.

Frame - 명령큐

프레임마다 타임스탬프를 포함하고 있다.

이를 Suspension Pattern이라고 부른다. 공급자, 소비자 모델이다.

기본적으로 JavaScript는 Blocking Evasion을 frame내의 시간을 잘라서 실행 시킴으로 해결함.

Time slicing

const looper = (n, f) => {
  for (let i = 0; i < n; i++) f(i)
}
looper(10, console.log)
looper(10000, console.log)

Time Slicing (Manual)

const looper = (n, f, slice = 3) => {
  let limit = 0,
    i = 0
  const runner = _ => {
    while (i < n) {
      if (limit++ < slice) f(i++)
      else {
        limit = 0
        requestAnimationFrame(runner)
        break
      }
    }
  }
  requestAnimationFrame(runner)
}

위 함수는 n보다 slice에 의해 제어가 다음으로 계속 넘어가게 된다.

looper(12, console.log)

Time Slicing (Auto)

const looper = (n, f, ms = 5000, i = 0) => {
  let old = performance.now(),
    curr
  const runner = curr => {
    while (i < n) {
      if (cur - old < ms) f(i++)
      else {
        old = performance.now()
        requestAnimationFrame(runner)
        break
      }
    }
  }
  requestAnimationFrame(runner)
}

5초마다 다음 프레임으로 넘어 가게 된다.

Sync, Async

Sync - 서브루틴이 즉시 값을 반환

const double = v => v * 2
console.log(double(2))

Async - 서브루틴이 콜백을 통해 값을 반환

const double = (v, f) => f(v * 2)
double(2, console.log)

Sync 예시

Block - 즉시 플로우 제어권을 반환하지 않음.

const sum = n => {
  let sum = 0
  for (let i = 1; i <= n; i++) sum += i
}
sum(100)

Non Block - 즉시 플로우 제어권을 반환함

const sum = n => {
  const result = { isComplete: false }
  requestAnimationFrame(_ => {
    let sum = 0
    for (let i = 1; i <= n; i++) sum += i
    result.isComplete = true
    result.value = sum
  })
  return result
}
const result = sum(100)
const id = setInterval(() => {
  if (result.isComplete) {
    clearInterval(id)
    console.log(result.value)
  }
}, 10) // Java에는 Future

JavaScript에 img태그에서 이렇게 예전에 썼었다. Sync-Non-blocking방식을 쓴다. 요즘에도 이런 방식을 쓰는 경우가 있다.

Async 예시

Block

const sum = (n, f) => {
  // Blocking이 걸린다.
  let sum = 0
  for (let i = 1; i <= n; i++) sum += i
  return f(sum) // Async의 조건
}
sum(10, console.log)

Non-Block

const sum = (n, f) => {
  reqeustAnimationFrame(_ => {
    let sum = 0
    for (let i = 1; i <= n; i++) sum += i
    f(sum)
  })
}

sum(10, console.log)

Sync

Block
- normal API
- legacy API
Non-Block
- old API
- IOCP
- Future
- Img.complete

Async

Block
- Trap (이 경우는 제일 잘못된 방식)
Non-Block
- Modern API

Similar Async Block

const sum = (n, f) => {
  reqeustAnimationFrame(_ => {
    let sum = 0
    for (let i = 1; i <= n; i++) sum += i
    f(sum)
  })
}
sum(1000000000, console.log)
console.log(123)
// 이런 경우에는 프레임마다 죽을 수도 안죽을 수도 있음.

Math.random은 속도가 느리고, 차라리 배열 1000개 만들고 그걸 돌리는게 훨씬 성능이 좋다.

위와 같은 경우도 무조건 비동기이지만, 블로킹이 되기 때문에 이런 방식의 코드를 작성 하면 안된다.

const backRun = (f, end, ...arg) => {
  const blob = new Blob([`onmessage = e=> postMessage((${f})(e.data));`], {
    type: 'text/javascript',
  })
  const url = URL.createObjectURL(blob)
  const worker = new Worker(url)
  worker.onmessage = e => end(e.data)
  worker.onerror = e => end(null)
  worker.postMessage(arg)
}

const f = v => {
  let sum = 0
  for (let i = 1; i <= v[0]; i++) {
    sum += i
  }
  return sum
}

let i = 1000
while (i--) backRun(f, console.log, 100000)

워커 함수를 쓰는건 백그라운드 쓰레드를 쓰는 것인데, CPU 코어수의 2배정도만 해야지 그 이상 하게 되면 OS의 시분할 작업으로 동작하기 때문에 굉장히 느리다.

위와 같이 작성 하면 안된다.

코드스피츠 77 - ES6+ 4회

Mon, 01 Mar 2021 20:02:00 GMT

Complex recursion

단순한 배열을 루프인 경우는 간단히 이터레이션을 작성할 수 있음.

{
  [Symbol.iterator]() { return this; },
  data: [1,2,3,4],
  next() {
    return {
        done: this.data.length == 0,
        value: this.data.shift()
    }
  }
}

문제는 다층형 그래프는 어떻게 이터레이션을 할 것인가?

{
  [Symbol.iterator]() { return this; },
  data: [{ a: [1,2,3,4], b: '-'}, [5,6,7], 8, 9],
  next() {
    return /// 어떻게 작성 해야 할까?????
  }
}

{
  [Symbol.iterator]() { return this; },
  data: [{ a: [1,2,3,4], b: '-'}, [5,6,7], 8, 9],
  next() {
    let v;
    while (v = this.data.shift()) {
      switch (true) {
        case Array.isArray(v):
          this.data.unshift(...v);
          break;
        case v && typeof v == 'object':
          for(var k in v) this.data.unshift(v[k]); // hasOwnProperty 써줘야 함.
          break;
        default:
         	return { value: v, done: false };
      }
    }
    return { done: true };
  }
}

컨테이너가 아니면 잘라서 계속 넣는 방법을 이용하면 쉽게 해결, 실제 위 코드에서는 런타임 평가이기 때문에 카운트 변수로 100번이나 만번으로 최대 동작 회수를 넣어주는게 좋다.

위 코드는 오류가 있다. data쪽에 a에 값 아무걸로 바꾸면 문제가 생긴다.

아래 코드로 바꿀 수 있다.

{
[Symbol.iterator]() { return this; },
  data: [{ a: [1,2,3,4], b: '-'}, [5,6,7], 8, 9],
  next() {
    let v;
    while (v = this.data.shift()) {
      if (!(v instanceof Object)) return { value: v}; // null인 경우 조건을 넣어줘야 함.
      if (!Array.isArray(v)) v = Object.values(v);
      this.data.unshift(...v);
    }
    return { done: true };
  }
}

const Compx = class {
  constructor(data) {
    this.data = data
  }
  [Symbol.iterator]() {
    const data = JSON.parse(JSON.stringify(this.data)) // 여기에 대괄호를 붙이면 더 안전하다. 데이터가 무엇이 오든 배열 형태로 받게 됨.
    return {
      next() {
        // es6 문법임 (function 작성)
        let v
        while ((v = data.shift())) {
          if (!(v instanceof Object)) return { value: v } // null인 경우 조건을 넣어줘야 함.
          if (!Array.isArray(v)) v = Object.values(v)
          data.unshift(...v)
        }
        return { done: true }
      },
    }
  }
}

const a = new Compx([{ a: [1, 2, 3, 4], b: '-' }, [5, 6, 7], 8, 9])
console.log([...a])

이런 코드의 문제를 발견하려면, 단위 테스트를 작성하는게 중요하고 단위 테스트는 커버리지가 중요하다.

const Compx = class {
  constructor(data) {
    this.data = data
  }
  *gene() {
    const data = JSON.parse(JSON.stringify(this.data)) // 여기에 대괄호를 붙이면 더 안전하다. 데이터가 무엇이 오든 배열 형태로 받게 됨.
    let v
    while ((v = data.shift())) {
      if (!(v instanceof Object)) yield v
      else {
        if (!Array.isArray(v)) v = Object.values(v)
        data.unshift(...v)
      }
    }
  }
}

const a = new Compx([{ a: [1, 2, 3, 4], b: '-' }, [5, 6, 7], 8, 9])
console.log([...a.gene()])

아까 보다 직관적으로 코드를 작성 했다. if - else로 확실하게 명확하게 케이스를 분리 해준다. 주석에 의존하지 말고 코드를 먼저 명확하게 작성 하면 코드에 주석을 넣을 이유가 없다.

Abstract Loop

다양한 구조의 루프와 무관하게 해당 값이나 상황의 개입만 하고 싶은 경우

(data, f) => {
  let v;
    while(v = data.shift()) {
        if(!(v instanceof Object)) f(v);
        else {
          if(!Array.isArray(v)) v = Object.values(v);
          data.unshift(...v);
         }
       }
    }
}

statement로 확정 되어 있어서 재활용이 불가능하다.

결국 제어문을 직접 사용할 수는 없고 구조 객체를 이용해 루프실행기를 별도로 구현

if (!(v instanceof Object)) {
} else {
  if (!Array.isArray(v)) v = Object.values(v)
  data.unshift(...v)
}

위 코드에서 if - else 부분이 개별구조 객체 부분이므로 뺄 수 있음. 대신 외부에서 if를 제거 하려면, 외부에서 객체 하나씩 분리해내면 된다.

팩토리 패턴과 컴포지트 패턴으로 이용한다.

const Operator = class {
  static factory(v) {
    if (v instanceof Object) {
      if (!Array.isArray(v)) v = Object.values(v)
      return new ArrayOp(v.map(v => Operator.factory(v)))
    } else return new PrimaOp(v)
  }
  constructor(v) {
    this.v = v
  }
  operation(f) {
    throw 'override'
  }
}

const PrimaOp = class extends Operator {
  constructor(v) {
    super(v)
  }
  operation(f) {
    f(this.v)
  }
}

const ArrayOp = class extends Operator {
  constructor(v) {
    super(v)
  }
  operation(f) {
    for (const v of this.v) v.operation(f)
  }
}

Operator.factory([1, 2, 3, { a: 4, b: 5 }, 6, 7]).operation(console.log)

객체의 분기를 통해서 루프 실행기의 분기를 제거 함.

const Operator = class {
  static factory(v) {
    if (v instanceof Object) {
      if (!Array.isArray(v)) v = Object.values(v)
      return new ArrayOp(v.map(v => Operator.factory(v)))
    } else return typeof v == 'string' ? new StringOp(v) : new PrimaOp(v)
  }
  constructor(v) {
    this.v = v
  }
  operation(f) {
    throw 'override'
  }
}
const StringOp = class extends Operator {
  constructor(v) {
    super(v)
  }
  operation(f) {
    for (const ch of this.v) f(ch)
  }
}
const PrimaOp = class extends Operator {
  constructor(v) {
    super(v)
  }
  operation(f) {
    f(this.v)
  }
}

const ArrayOp = class extends Operator {
  constructor(v) {
    super(v)
  }
  operation(f) {
    for (const v of this.v) v.operation(f)
  }
}

Operator.factory([1, 2, 3, { a: 'abc', b: 5 }, 6, 7]).operation(console.log)

구글 크롬에서 스크립트 창에서 실행할 때, const는 재할당이 안되니까 불편한데, 모든 코드를 if(1) 로 감싸면 계속 재실행이 된다. 이것 팁이다.

ES6 Iterable

const Operator = class {
  static factory(v) {
    if (v instanceof Object) {
      if (!Array.isArray(v)) v = Object.values(v)
      return new ArrayOp(v.map(v => Operator.factory(v)))
    } else return new PrimaOp(v)
  }
  constructor(v) {
    this.v = v
  }
  *gene(f) {
    throw 'override'
  }
}

const PrimaOp = class extends Operator {
  constructor(v) {
    super(v)
  }
  *gene(f) {
    yield this.v
  }
}

const ArrayOp = class extends Operator {
  constructor(v) {
    super(v)
  }
  *gene(f) {
    for (const v of this.v) yield* v.gene()
  }
}

for (const v of Operator.factory([1, 2, 3, { a: 4, b: 5 }, 6, 7]).gene())
  operation(console.log(v))

Lazy Execution

최적화 영역은 사실 3%정도에 속한다. 결국에 내가 최적화 하는 것보다는 엔진이 최적화하는게 훨씬 이득. 표준 함수가 있으면 표준 함수가 유리하다. 내가 최적화 하는게 별 의미가 읍..슴

사실 최대의 최적화는 렌더링이 97%이다. DOM 얼마나 적게 건드리는건지가 중요하다. 그리고 구조적으로 복잡성을 줄이는게 제일 좋다. 알고리즘 관점으로는 표준함수를 쓰는게 제일 좋다.

const odd = function*(data) {
  for (const v of data) {
    console.log('odd', odd.cnt++)
    if (v % 2) yield v
  }
}
odd.cnt = 0
for (const v of odd([1, 2, 3, 4])) console.log(v)

나머지 연산자의 경우 양의 정수에만 동작 한다. (예외처리 해주려면, 음수인걸 반전 시켜주도록 처리 하는게 좋음.)

const take = function*(data, n) {
  for (const v of data) {
    console.log('take', take.cnt++)
    if (n--) yield v
    else break
  }
}

take.cnt = 0
for (const v of take([1, 2, 3, 4], 2)) console.log(v)

for (const v of take(odd([1, 2, 3, 4]), 2)) console.log(v)

coroutine의 suspension을 이용하는 방법이다. 제어문이 실행 되다가 멈출 수 있는 걸 이용할 수 있다. 반복이 굉장히 효율적으로 동작하게 된다.

const Stream = class {
  static get(v) {
    return new Stream(v)
  }
  constructor(v) {
    this.v = v
    this.filters = []
  }
  add(gene, ...arg) {
    this.filters.push(v => gene(v, ...arg))
    return this
  }
  *gene() {
    let v = this.v
    for (const f of this.filters) v = f(v)
    yield* v
  }
}

위의 개념이 Java 8의 Stream 개념과 같고, 일반적인 함수형 언어 Stream이라고 하는 개념이다.

const odd = function*(data) {
  for (const v of data) if (v % 2) yield v
}

const take = function*(data, n) {
  for (const v of data)
    if (n--) yield v
    else break
}

for (const v of Stream.get([1, 2, 3, 4])
  .add(odd)
  .add(take, 2)
  .gene())
  console.log(v)

지연 실행을 이용해서 중복을 제거하고 추상 루프를 만들 수 있다. 정확하게 필요한 반복 횟수만 실행하는 함수를 만들 수 있다는 장점이 있다.

add(take, 2)

위 코드에서 커링으로 보면 된다. Stream 클래스의 add 함수에서 ...arg로 풀어서 인자로 넣어준다. v => gene(v, ...arg)이 부분이 커링 함수이다. (…나만 커링을 또 까먹은 것인가…)

지금 까지는 동기적인 루프에 대해서 말 했는데, 비동기는 더 어렵다. 이정도까지는 괜찮다. 그리고 함수형으로 배우면 더 어렵고, JavaScript의 Generator 문법으로 배우는게 훨씬 이해가 쉽다. 그리고 코드가 간략해진다.

그런데, 지금까지의 스펙이 2015년도 스펙이므로 구닥다리의 개념이다. (심지어 나는 이걸 2021년에 보고 있다..)

해마다 ECMA 스펙에 각 언어들의 최종 스펙들을 다 넣고 있음.. 그래서 배우기가 쉽지 않다. (이 말은 결국 깊하게 배워서 잘 쓰기가 어렵다.)

그러면, 결론적으로 JavaScript를 내가 쉽다고 생각하면 내가 그 언어를 잘 못쓰고 있을 가능성이 높다.

코드스피츠 77 - ES6+ 3회

Sun, 14 Feb 2021 22:56:00 GMT

interface

인터페이스란 사양에 맞는 값과 연결된 속성키의 셋트
어떤 Object라도 인터페이스의 정의를 충족시킬 수 있다.
하나의 Object는 여러개의 인터페이스를 충족시킬 수 있다.

interface test

test라는 키를 갖고
값으로 문자열인자를 1개 받아 불린 결과를 반환하는 함수가 온다.

{
  test(str) { return true; }
}

interator interface

next라는 키를 갖는다.
값으로 인자를 받지 않고, IteratorResultObject를 반환하는 함수가 온다.
IteratorResultObject는 value와 done이라는 키를 갖고 있다.
이 중 done은 계속 반복할 수 있을지 없을지에 따라 불린값을 반환한다.

{
  next() {
    return {value: 1, done: false}
  }
}

//
{
  data: [1,2,3,4],
  next() {
    return {
      done: this.data.length == 0,
      value: this.data.pop()
    };
  }
}

iterable interface

Symbol.iterator라는 키를 갖고
값으로 인자를 받지 않고 iterator Object를 반환하는 함수가 온다.

{
  [Symbol.iterator]() {
    return {
      next() {
        return { value: 1, done: false; };
      };
    }
  }
}

iterator만 존재하게 되면 루프를 한 번 돌면, 원본 데이터의 소비가 다 끝나기 때문에, 재실행이 불가능하다. 고로, iterable이 사본을 넘겨주면, iterator에서 루프를 도는 개념으로 이해하면 된다. (내가 이해한 걸로는 그렇다. 맞을까?)

iterable을 이용해서 iterator를 얻는 구조로 설계가 되어 있다. (패턴으로도 정립이 되어 있다.)

Loop to iterator

현대 언어는 추세가 문을 식으로 바꾸고 싶어 한다. 이유는 flow에 한번 동작하면, 재소비가 불가능하고, 내가 원하는 곳에 넣고 실행하기가 불가능하다. 그래서 statement를 expression으로 바꾸고 있다.

let arr = [1, 2, 3, 4]
while (arr.length > 0) {
  console.log(arr.pop())
}

while(계속 반복할지 판단) {
  반복시 처리
}

{
  data: [1,2,3,4],
  next() {
    return {
      done: this.data.length == 0, // 반복 판단
      value: this.data.pop() // 반복시 처리
    };
  }
}

iterator interface는 자기 자신의 대한 정보를 다 갖고 있다. (Self-description)

반복자체를 하지 않지만
외부에서 반복을 하려고 할때
반복에 필요한 조건과 실행을
미리 준비해둔 객체

반복 행위와 반복을 위한 준비를 분리 함.

미리 반복에 대한 준비를 해두고
필요할 때 필요한만큼 반복
반복을 재현할 수 있음

그래서 statement로 loop를 돌리지 않고, iterator로 loop를 돌리게 된다.

ES6+ Loop

약식으로 직접 iterator 반복처리기를 구현

const loop = (iter, f) => {
  // iterable이라면, iterator를 얻는다.
  if (typeof iter[Symbol.iterator] == 'function') {
    iter = iter[Symbol.iterator]()
  } else return

  // IteratorObject가 아니라면 건너 뜀
  if (typeof iter.next != 'function') return

  do {
    const v = iter.next()
    if (v.done) return // 종료처리
    f(v.value) // 현재 값을 전달함.
  } while (true)
}

const iter = {
  arr: [1, 2, 3, 4],
  [Symbol.iterator]() {
    return this
  },
  next() {
    return {
      done: this.arr.length == 0,
      value: this.arr.pop(),
    }
  },
}

loop(iter, console.log)

내장반복처리기 구현

Array destructuring

const iter = {
  [Symbol.iterator]() {
    return this
  },
  arr: [1, 2, 3, 4],
  next() {
    return {
      done: this.arr.length == 0,
      value: this.arr.pop(),
    }
  },
}

const [a, ...b] = iter
console.log(a, b)

언어 스펙을 준수하면 언어의 지원을 받을 수 있다.

Spread

const iter = {
  [Symbol.iterator]() {
    return this
  },
  arr: [1, 2, 3, 4],
  next() {
    return {
      done: this.arr.length == 0,
      value: this.arr.pop(),
    }
  },
}

const a = [...iter]
console.log(a)

array의 스펙에 따라 지원 되는게 아니라 iterable을 구현했기 때문에 언어의 지원을 받을 수 있는 부분이다. (착각 하지 말 것.)

Rest Parameter

const iter = {
  [Symbol.iterator]() {
    return this
  },
  arr: [1, 2, 3, 4],
  next() {
    return {
      done: this.arr.length == 0,
      value: this.arr.pop(),
    }
  },
}

const test = (...arg) => console.log(arg)
test(...iter)

for of

const iter = {
  [Symbol.iterator]() {
    return this
  },
  arr: [1, 2, 3, 4],
  next() {
    return {
      done: this.arr.length == 0,
      value: this.arr.pop(),
    }
  },
}

for (const v of iter) {
  console.log(v)
}

iterable을 구현한게 Array도 있지만, String도 있기 때문에, 바로 문자열을 해체 할 수 있음.

Practice

제곱을 요소로 갖는 가상 컬렉션

const N2 = class {
  constructor(max) {
    this.max = max
  }
  [Symbol.iterator]() {
    let cursor = 0,
      max = this.max // next 함수 입장에서 free variable
    return {
      done: false,
      next() {
        // free variable 관점에서는 이 영역이 closure area이다.
        if (cursor > max) {
          this.done = true
        } else {
          this.value = cursor * cursor
          cursor++
        }
        return this
        // iterable interface, itrable interface의 요구조건을 충족한다.
      },
    }
  }
}

console.log([...new N2(5)])

for (const v of new N2(5)) {
  console.log(v)
}

폰 노이만 머신에서 메모리에 적재 되면, 쉴틈 없이 처리 된다는 사실을 기억 해야 함.

쉴 틈 없이 적재된 명령어가 처리 되는 동안 꼼작도 못하는 상태를 뭐라고 부를까?

이를 동기 명령이라고 부른다. 적재된 명령이 한번에 쭉 실행 되는 것을 말한다.

이 동기 명령이 실행 되는 것을 관찰하는 게 Flow이다. 동기 명령이 실행 되는 동안 우리는 cpu를 간섭할 수 없다.

cpu를 간섭할 수 없는 현상을 blocking이라고 한다.

Generator

Iterator의 구현을 돕는 generator

const generator = function*(max) {
  let cursor = 0
  while (cursor < max) {
    // 시작과 종료에 대한 제어권을 다 가지고 있음.
    yield cursor * cursor
    cursor++
  }
} // 위의 N2 class와 역할을 같다.

console.log([...generator(5)])

for (const v of generator(5)) {
  console.log(v)
}

부수적인 코드를 줄이고 위의 N2 class와 같은 역할을 할 수 있게 한다. (개인적으로 서비스 코드(실무)에서 써본적은 없다)

generator는 iterable이자 iterator를 반환 한다. (중요한 부분은 for of 구문에서는 generator를 쓸 수 없음. 하지만, 반환 된 건 for of에서 돌아간다. 왜냐면, iterable이자 iterator라서 돌아감…대혼란?!)

yield 키워드는 generator 안에서만 쓸 수 있다. 그리고 yield는 suspend 기능을 가지고 있다.

이 기능은 결국 while문 안에서 yield 위치에서 멈춘다. 즉, statement가 멈춘다. generator는 여러번 반복해서 돌기 때문에 co-routine(coroutine)이라고 부른다. ref. 코루틴

generator는 문법적으로 축약을 많이 해주고 제어권을 많이 가져갈 수 있도록 해준다. 다만, es5로 변환될때 굉장한 오버헤드가 생긴다. generator를 iterable로 변환을 해줘야 하는데, 그 역할을 보통 babel이 해주는데 babel에서는 보통 generator를 번역해주긴 하지만, 금기시 함. ref. Babel은 Generator를 어떻게 바꾸나 를 보면, regeneratorRuntime를 이용해서 iterable interface를 충족하고 있다.

ref. https://babeljs.io/docs/en/learn/#generators 를 보면, 금기 한다는 말은 없는 것 같기도 하다. 내가 못찾는 것일 수도 있다.

코드스피츠 77 - ES6+ 1회

Sat, 13 Feb 2021 21:06:00 GMT

어떤 언어나 프레임워크와 같이 떠내려가지 않게 근본에 대해 공부해야 한다.

프로그램에도 합리주의, 상대주의 철학이 내포되어 있다. 켄트 벡이 말한 프로그램을 작성하는데 3가지를 내포하고 있어야 한다.

가치
1. 의사소통
2. 단순함
3. 유연함
원칙
1. 지역화
2. 중복제거
3. 대칭성
패턴
1. 개발론
2. 설계론
3. 각종 적용 패턴
동기
1. 돈
2. 시간

위에 대해서 켄트벡의 구현 패턴에서 설명하고 있다.

프로그램을 짰을때, 왜 이렇게 했는지? 설명할 수 있어야 한다.

프로그램이 뭔데? 컴퓨터가 뭔데?를 물어보면 그 사람의 기본 지식을 알 수 있다.

Program & Timing

Language code - Lint Time
Machine language - Compile Time
File
Load
1. 파일이 컴퓨터 메모리에 적재
2. 메모리에 적재 된 것만 프로그램
3. 프로그래머의 영역의 마지막
Run - Run Time
Terminate

Run Time 에러는 기본적으로 잡기 어렵다.

계속 발생하면, 프로그램을 싹 다 바꿔야함.
기본적으로 잘못 만들어서 발생함.

Context Error도 있음.

커뮤니케이션이 안되어서 그럴 수도 있음.
개발자끼리 코드 스타일이 달라서 이해를 못해서 발생.

Script Program

Language Code
File
Load
Machine Language
Run
Terminate

Run Time

Memory (Program)

명령
값

CPU (Consumer)

외부버스
제어유닛
연산유닛
데이터유닛

처리 순서

Loading
Instruction Fetch & Decoding
Execution

실제 시나리오 (Complie Language)

Essential Definition Loading
VTable(Virtual Memory Table) Mapping
Run
Runtime Definition Loading
Run

Run (Static Time)

Declare Base function, class …

(Run Time)

Delare extended function, class …

(Static Time)

(Run Time)

Use function, class

프로그램 하나에도 각 레이어별로 상대적인 관계가 이루어진다.

Memory, Address, Pointer, Variables, Dispatch

Memory

고유한 번호를 주소로 갖는 주소체계를 갖고 있다.

ex)

A = “TEST”, &A= 11
B = &A *B = “TEST”

참조의 참조일때 직접 참조를 쓰면 문제가 생긴다.

함수형 패러다임은 참조를 사용 안함. 값만 사용.
객체지향 패러다임은 직접 참조 하는 것을 안함.

Double Dispatch

두번의 참조를 거치고 나서 값을 얻는 경우를 말함.

Lexical Grammar

Control Character
White Space
Line Terminators
Comments
Keyword
Literals

Language Element

Statements

(실행기가 어떻게 실행 할지에 대한 방법을 제공)
공문
for (let i = 0; i < 10; i++);
;;;;;;
식문
제어문
선언문
메모리상에 변수 할당
단문
if(true);
중문
if(true){;;}
```
var a, b
if (true) {
a = 3
b = 5
}
```

if (true) a = 3
else b = 5
if (true) a = 3
else if (a > 2) b = 3
else b = 5
if (true) a = 3
else {
if (a > 2) b = 3
else b = 5
}

Expression
- 값식
- 3;5;6;
- if(true)3
- 연산식
- 호출식
- JS는 return이 없는 함수를 호출해도 return이 있다.
Identifier
- 기본형/참조형
- 변수
- 상수

변수란, “메모리 주소의 별명이다”라고 말 할 수 있다. 그리고 총 3가지의 정보를 담고 있다.

메모리 주소 위치
어떤 타입인지?
어디까지 크기를 갖는지? 알고 있음.

이 정보들을 VTable에 넣어 놓는다.

Sync Flow

폰 노이만 머신은 CPU에서 명령어가 끝날 때까지 중단이나 개입이 불가능함.

Flow Control

흐름 제어를 할 수 있도록 해주는 역할

Sub Flow

공통된 부분을 뽑아서 흐름을 바꿈
- ex) 함수, 클래스를 이용한다.

코드스피츠 77 - ES6+ 2회

Sat, 13 Feb 2021 21:06:00 GMT

코드스피츠 77 - ES6+ 1/2회차

인사이드 자바스크립트, 자바스크립트를 말하다.

좋은 책이나, 3.1버전의 자바스크립트 엔진 기반으로 설명 되어있다.

현대 ES5이후의 자바스크립트 엔진이 달라졌다. 해마다 엔진 스펙이 달라진다.

엔진 스펙을 공부한다고해서 그게 장점이 되지 않는다.

그러면 뭘 배우냐?

작동원리 보다는 자바스크립트 자체의 추상적인 의미나, 체계를 배우는 게 훨씬 이득이다.

자바스크립트 엔진은 statement를 record로 바꿔주고, Record를 처리 하고, 그 다음 Record를 처리 하는 방식으로 동작한다. statement와 record는 대응 된다.

Flow control statement들은 Completion Record로 바뀐다.

그리고 Record를 뭘 선택할지 결정하는데 사용 된다.

Direct Flow Control

ABC언어들은 if, while, for를 제공하고, 다른 언어들이 이런 개념을 지원 한다면 ABC언어의 자손 언어라고 생각 할 수 있다.

Label

Identifier

$로 시작 할 수 없는 특징 제외하고는 자바스크립트 변수 선언과 동일하다.
:을 붙이면 label로 인식한다.
label은 브라우저가 해석하기에 Record로 해석 되지 않는다. 즉, statement로 볼 수 없다.

Scope

label은 같은 스코프안에 2개가 존재 할 수 없다. (static parsing에서 결정 됨.)
함수로 범위가 제한 됨.
label scope가 따로 있음.
- {}로 감싸면 스코프가 제한적으로 생성 됨.
- label shadow도 발생할 수 있음.
- 외부 label, 내부 label 간의 label scope로 인해서 외부 label이 가려지는 현상이 발생 함.

const test = () => {
abc: {
  console.log('start')
  if (true) {
    break abc
  }
}
console.log('end')
}
test()

label range & label set

const label_test = () => {
  console.log('0')
  abc: if (true) {
    break abc
  }
  console.log('1')
  bbb: console.log('2')
}
label_test()

go to처럼 건너 뛰려면, 세가지 방법 밖에 없다.

label scope를 선언 한다.
iteration label
switch label
예외적으로 loop의 continue

그리고 label이 ABC언어에서의 if, loop를 도입하기 전 원하는 곳으로 흐름을 이동시키기 위한 방법으로 고안한 것이었다.

현대 label과 과거의 goto와 차이점은 직접 이동 하는 것은 불가능하고, break, continue로 아래로 이동하는 것만 가능하다.

label이 위에 있으면 위로 갈 수는 없다. 그리고 왔다 갔다 할 수 없게 만들어져 있다.

loop에서는 왜 label name없이 break에서 쓸 수 있을까?

JS engine에서 암묵적으로 label name을 정해준다.
이게 바로 auto label이라고 부르며, undefined named label이라고도 한다.
while, for문에서 주로 발생 됨.

앞주석을 쓰는 경우도 있음.

console.log('end') // a
console.log('00000000000') // a
console.log('000000000000000000') // a
A: console.log('end')
B: console.log('00000000000')
C: console.log('000000000000000000')

label구문은 블럭의 마지막부분으로 보내는 ABC언어의 예외라는 특징을 가지고 있다.

Java의 label 스펙을 그대로 JavaScript에서 그대로 가져 왔다.

Switch

Special label block만 쓸 수 있다.
- case []:, default:
Fall through
- break를 안 쓰면 default label까지 동작하는 현상
runtime evaluation switch vs non-runtime evaluation switch의 차이
- ```
switch (true) {
default:
console.log('c')
case true:
console.log('a')
case false:
console.log('b')
}
```
// a // b

switch (true) { default: console.log(‘c’) case 1: console.log(‘a’) case false: console.log(‘b’) }

// c // a // b

// 값에 대한 라우팅 테이블 방식

const a = true
temp17:
switch(a) {
 default: console.log('c')
 case f1(a): console.log('a') break temp17;
 case f2(a): console.log('b')
}
console.log('end')

값에 의한 라우팅(분기) 개념이므로 case에 대한 값이 확정적일 필요는 없다. 어차피 Runtime에 평가되기 때문에 값 자체가 확정적일 필요 없음.

// chain of responsiblity

switch (true) {
case f3():
case f4():
}

// example
switch (true) {
case network() === 'online':
case network() === 'wifi':
case network() === 'offline':
case localCache():
default:
}

https://refactoring.guru/design-patterns/chain-of-responsibility 패턴과 유사하다.

Switch가 Runtime에서 실행 된다는 말은 곧 한 줄씩 순차적으로 해석 실행 된다는 말이다. 아래 다음에 영향을 주게 된다.

let c = 2
switch (true) {
  case c++ > 5:
    console.log(c)
    break
  case c++ > 5:
    console.log(c)
    break
  case c++ > 5:
    console.log(c)
    break
  case c++ > 5:
    console.log(c)
    break
  case c++ > 5:
    console.log(c)
    break
  case c++ > 5:
    console.log(c)
    break
}

// 7

코드스피츠 77 - ES6+ 2/2회차

77 - 2/2회차는 오디오가 녹음이 안되어서 73 - ES6 2회차 2/2로 시청 했다.

https://www.youtube.com/watch?v=U6dmAT8KImY

if (식) 옵셔널
if (식)
else

if (c === 1) {

} else if (c === 2) {

} else if (c === 3) {

} else {

}

// 위의 코드와 같음.
if (c === 1) {

} else {
  if (c === 2) {

  } else {
    if (c === 3) {

    } else {

    }
  }
}

제어문에서는 if와 else문만 있다. 즉, 중문, 단문이 if else의 식으로 들어오는 형태다.

if (c < 5) {

} else switch (c) {

}

if (c > 5) {

} else for () {}

if / else가 익숙하면, 위의 코드도 이상할 것이 없다.

if (c === 1) {
} else if (c === 2) {
} else {
}

if (c === 1) {
} else {
  if (c === 2) {
  } else {
  }
}
// 위와 같음

else는 후방 결합을 하게 된다. 그렇기 때문에 그에 대해 이해하지 못하면 버그가 생기게 된다. 이를 방지 하기 위해서는 중괄호로 바꿔서 쓰면 된다. (else if`를 쓸 필요가 없다.)

if 중첩은 부분적인 집합의 경우에만 써야 된다. 분기가 모두 동등하면, switch를 쓰면 된다.

if (c === 1) {
} else {
  if (c === 2) {
  } // else가 없는 경우, 코드를 다 확인 해야 된다. else에 온 이상, else로 끝나야 한다.
}

개발의 지향점은 결국, 수정 해야 할 영역만 수정 하게끔 하는 것이 목적이고, 목표이다. 결국, 코드는 의도를 담아야 한다.

if문은 결국, 중첩된 구조를 기술하거나 단일 if else문을 이용해서 mandatory optional을 기술 할때 쓰고 병행 조건에 대해서 switch를 쓰는게 당연한데, switch는 병행 조건을 기술함으로써 예외가 발생하거나 나머지가 발생 할 수 있어서, 반드시 default를 써야 된다.

코드가 mandatory로 시작하면 mandatory로 끝나던지? optional이면, optional으로 끝내야 된다.

코드의 기본은 정리다. (프로그래밍의 도 같은 책도 찾아 보니 있었다.)

for

for (expression; expression; expression) {}

// '', false, 0, undefined, null, NaN -> falsy
for (var i = 0; truthy; ex) {}

for는 정말 특이한 녀석에 속한다.

for문의 truthy로 평가 되어야 하는 곳에 공문 (비어있는 식)이 오면, 무한 루프로 동작 하게끔 언어 상에서 예외로 두고 있다.

while

while (thuthy) {}

let a = -1
while (a > 2) {
  a++
}

// 가정: 이런식으로 작성 된 코드가 있을 수 있음. 굉장히 어렵다.

while (act.method().c) {
  other.action()
}

let a = act.method().c
while (a) {
  other.action()
  a = act.method().c
}

무조건 while문의 조건식이 while body안에 다시 등장하도록 만들어야 버그가 없다.

let a = act.method().c
while (a) {
  let r = other.action()
  a = act.method().c
  if (r === 'abc') a = fasle
}

while문 안에 if문으로 무한루프에 빠지지 않게 방어로직을 넣어주는 것도 좋다.

while문은 중문이 오는게 정상이다.

do-while

do {} while (thuthy)

do a++
while (a) // 정상 문법

어쭙잖은 개발자의 2020 회고

Sun, 03 Jan 2021 19:49:00 GMT

원래는 회고를 잘 하지 않았는데, 2019년 상반기 회고가 마지막이었다.

사람들은 회고를 많이 잘 하는 것 같아서 내심 부럽기도 하고, 개발자들은 자기 자신을 잘 되돌아보고 연마 하기 위해 노력 많이 하는구나 생각 했다.

내가 2020년도 한 해 동안 무엇을 했을까 기록 했던 것들을 적어보자.

계획 했던 것들 중에서 이룬 것들은 무엇일까?

👍목표

개인적인 목표

영어 공부 하루에 10분씩이라도 꾸준하기
- 이건 실패
~~블로그 꾸준히 포스팅 하기~~
- 나름 선방 한 것만 같다.
~~여행가기~~
- 사람들 없는 곳 찾아다니기
~~등산 최소 5개의 산을 오르기~~
- 지리산 일출
- 청계산
- 광교산
- 관악산
- 마니산
~~일빵빵 스토리가 있는 영어회화 1권 완독~~
~~저금 습관화 하기~~

개발 목표

TDD
- 나에게는 너무나 어려운 쥐약인 부분이다.
Rust
- 뭘 바꾸기만 하면 컴파일이 실패하여 헤매이게 한다.
GraphQL
~~puppeteer/playwright 써보기~~
- 실제로 E2E 시스템을 구축 해보았다.

🎥봤던 영화

나쁜녀석들:포에버
천문
닥터 두리틀
비포 선 라이즈
조커
비포 선 셋
히트맨
컨테이젼
작은 아씨들
해리포터 - 죽음의 성물1
해리포터 - 죽음의 성물2
비스티걸스
버즈 오브 프레이
내가 사랑했던 모든 남자들에게
내가 사랑했던 모든 남자들에게 파트2
범블비
레이니 데이 인 뉴욕
결백
블러드샷
플립
강철비2: 정상회담
프로젝트 파워
발레리안: 천개 행성의 도시
나의 마더(I am mother)
토탈리콜
블랙머니
다만 악에서 구하소서
미션임파서블-로그네이션
다키스트 마인드
정직한 후보
침묵
바람바람바람
살아있다
삼진그룹 영어토익반
콜
그린랜드
테넷
올드가드
더 서클

📖 읽었던 책

팩트 풀니스
마음의결
7일 만에 끝내는 해외 주식 투자
잠든 사이 월급 버는 미국 배당주 투자
자본주의 생존공략집
잔소리 고양이
더 해빙
메트릭 스튜디오
스위스 은행가가 가르쳐주는 돈의 원리
새는 날아가면서 뒤돌아 보지 않는다.
개발 7년차, 매니저 1일차
내가 주식을 사는 이유
입맛대로 연애할 순 없을까?
내가 사랑하는 지겨움
일곱개의 회의
오늘은 이만 좀 쉴게요
예민한게 아니라 섬세한 겁니다.
술 먹고 전화해도 되는데
오늘도 예민하게 잘 살고 있습니다.
운, 준비하는 미래
연애를 잘하고 싶은데 방법을 모르겠어
나에게 시간을 주기로 했다
울트라 러닝
아무튼, 양말
쓰레기처럼 사랑하라
그동안 나는 너무 많이 참아왔다
말투 하나로 의외로 잘 되기 시작했다
두려움 없는 조직
애쓰지 않고 편안하게
행복의 기원
듣고 싶은 말을 했더니 잘 풀리기 시작했다
서른의 연애
사랑밖의 모든 말들
보통의 언어들
당신이 알고 싶은 음성인식 AI의 미래
부의 본능
연애도 계약이다
존리의 부자되는 습관
나를 돌보지 않는 나에게
발가 벗은 힘
을의 연애
작지만 강한 기업에 투자 하라.
아무것도 아닌 지금은 없다.
상자 밖에 있는 사람
결국은, 자존감
부의 추월차선
만남은 지겹고 이별은 지쳤다.
Red Roses
시작의 기술
아주 작은 습관의 힘
돈이 보이는 빅데이터
책, 이게 뭐라고?
다크호스
알고리즘이 욕망하는 것들
주식 투자의 기술
켄 피셔의 역발상 주식투자
우리가 빛의 속도로 갈 수 없다면
매일 매일 좋은 날

57권의 책을 읽었다. 1년 동안, 물론 적지 않은 책도 있고 여전히 읽고 있는 책도 있었다.

내가 그렇다고, 지적인 능력이 올라갔거나 재테크에 관심 많았는데 수익률이 좋았는가? 사담을 하자면, 주식의 수익률은 애초에 코로나 위기때 사서, 호황기 시장일때 매도 했기 때문에 수익률이 좋은 거지. 내 실력이 늘었다거나 내가 기업 분석을 더 잘 한다거나, 밸류에이션을 추정 하거나 하진 않았다.

예전 보다는 좀 더 투기성 짙은 행동을 덜 한다는 점에서 투자 책은 나에게 유익했다.

나의 생각들

내가 바뀐 점은 무엇이 있을까? 1년 동안 개발과 먼 거리를 유지 했던 것 같다. 요즘 들어 어떤 에너지 고갈이라고 해야 할까?

서비스 개발자로 일하면서 시키는 일만 하다보니 내가 뭘 좋아하던 사람인지를 잊어버린 것을 크게 깨달은 한 해 였다.

Java & Spring WebMVC framework 기반에서 React & Next.JS 기반으로 오기까지 벌써 이미 리액트 환경은 1번 개편 한 환경으로 건너 오게 되었고, 여전히 서비스 페이지에서 이전을 못한 페이지도 있다.

벌써 3년째 시스템 개편과 서비스 과제를 동시에 하거나, 레거시 환경에서 선 오픈하고, 후에 시스템 개편때 포함 하는 작업들을 하게 된다.

상반기에는 서비스 개발에 속해있던 카탈로그 서비스 개발을 주로 했고, 그 이후에는 팀 내의 SRE를 위해서 모든 팀내 메뉴얼을 다시 보강 하는 작업을 했다.

그 이후에는 E2E 시스템을 PC/Mobile 영역을 나눠서 시스템을 구축 했다. 배포 부터, 테스트 도메인 추가까지 어떻게 해야 손이 덜 가는 시스템을 만들까? 알림을 어떻게 받을까?

라이브러리는 이걸 쓸까? 저걸 쓸까? 고민 했다.

보다 더 편리하고 탄탄한 시스템을 구축 하고 싶었는데, 나의 역량 밖이었던 것만 같아서 솔직히 연차를 어디로 먹었는지? 잠이 안왔다. 짜증도 나고, 화도 많이 났다.

업무적으로도 고민의 연속이었으며, 나는 어떤 개발자인가?라는 물음의 연속이었다. 여전히 답을 못하고 있는 현실이다.

트위터에 있는 수 많은 개발자들은 앞으로만 정진 하는데, 나는 토이프로젝트도 안하고, 어영부영 살면서 서비스 기획 과제나 울며 겨자 먹기식으로 팀장님이 시키는 일을 하기 급급했다. (물론, 남들은 업무도 하고, 공부도 하는 데 안한 것은 나의 문제였다. 사실, 매해 업무에 최선을 다 하는 편이다. 아마 나의 그릇 사이즈의 문제라 생각 한다.)

가끔 나는 이런 이상향을 원하는데 같이 함께 하지 않는지? 왜 이 큰 틀 안의 서비스 조직은 바뀌지 않는지? 답답해했다.

왜 서비스의 장애가 개발자만의 영역인가?

기획자나 디자이너등도 같은 서비스를 만들어가는 주체가 아닌가? 라는 생각을 하면서 보냈고, 답을 얻지는 못했다.

큰 회사이니까, 내 역할만 하면 된다는 마인드인건가..? 생각하기도 했다. 그나마 얻은 답은 굳이 그래야 하지 않아도 되는 문화가 문제라 생각 한다.

개발팀은 개발팀 알아서, 기획은 기획 알아서, 디자이너는 디자이너 알아서, 문제가 생기면 그떄서야 우린 이런 걸 원한다. 설명 하는데에 허비 되는 시간들. 새로운 서비스, 신규 스펙 추가등, 사업적인 긴급 스펙 추가등 다채로운 변수들 사이에서 결국, 나를 일깨우고 나아가게 하는 것은 업무적인 일들이 아니였다.

나 스스로 내가 무슨 개발자인지를 설명 할만한 포트폴리오 혹은 기록들이 필요 하다. 앞으로는 준비를 잘 해야겠다고 생각 했다.

회사는 결국 업무적인 것들은 기본으로 해내고, 그 외에도 약을 팔 수 있는 개발자가 되기를 소망 한다. 나쁘게 말하면, 싸지만 능력은 뛰어난 개발자가 되길 원한다. 그렇기 때문에 업무는 진작에 끝내 놓고, 남는 시간에는 새로운 시스템이나, 어떤 적용 가능한 것들을 연마하고, 실제로 적용까지도 해야 한 해의 성과가 된다.

너무 순진하게 5년동안 굴렀던 게 아닐까 싶기도 하지만, 이제라도 깨달아서 좀 다행인 부분이다.

나는 그래서 내가 인턴 면접으로 뽑고 멘토링도 미약하게나마 했었던 팀원분에게 조언 한 부분은 아래와 같다.

회사를 사랑 하지 말라.
이력서를 업데이트 하면 좋다.
내가 무슨 일을 했는지 대외비 유출 하지 않는 범위에서 정리 해두자.
내 팀 바깥의 팀이 어떤 일을 하는지? 어떤 사람이 있는지 궁금해하자.
바깥 세상에 좋은게 있다면, 소개 해주고 적용 하자.

💻쿠팡 신입 연봉 6000?썰에 대한 나의 생각

여러 회사들이 긴장하는 쿠팡의 파격적인?! 조건이다. 여기서 쿠팡의 이점은 신입 연봉 6천 + 쿠팡 상장의 로또라 생각 한다.

쿠팡 상장이 로또가 되는 부분

자사주 선택 매수권을 준다.
스톡 옵션을 준다.

물론, 쿠팡이 두 가지 옵션을 안 줄 수는 있다. 어느 정도 개국공신들의 잔치가 될 가능성은 있지만, 그 것을 제외 하고라도, 메리트는 네이버나, 카카오, 배민, 토스등도 신입 개발자에게 연봉 6천을 주지 않는다. (내가 알기론 그렇지만, 개발의 고수라면 받을 수도 있지 않을까?)

그런데, 중요한 점은 내가 얼마나 받느냐 보다 내가 앞으로 얼마나 성장세를 유지 할 수 있는 개발자냐?가 중요한 부분 같다.

빨리 빨리 연봉을 올려서 1억을 찍으면 우리의 개발 인생이 끝나는걸까? 결국, 이 업계의 유리 천장은 있고, 애초에 그 유리 천장을 깨줄 어떤 젊은 시툐가 나오면 좋겠지만, 노조가 나온다 한들, 한국의 개발자 주니어 레벨, 시니어 레벨의 연봉 상한선은 있고, 실리콘 밸리처럼 주지 않는다.

아마 받더라도 극소수겠지? 그럼, 내가 빨리 6천에서 7천 받고 8천을 지나 1억을 찍어도 더 이상 움직일 수 없는 몸값이 되어 버려서 젊은 나이에 어느 회사에서도 받아줄 수 없는 개발자가 된다.

그리고 그렇게 빨리 연봉을 올릴 수 있는 실력이 나에게 있는가? 그리고 연봉을 빨리 올리려면, 잦은 이직 찬스가 필요하다. (대부분의 회사 연봉 인상률은 물가 상승률과 비슷하게 간다. 물론, 고성과자라면, 좀 더 준다.)

잦은 이직은 과연 개발자에게 좋을까?

유지보수를 안하는 개발자를 서비스 개발자들은 좋아할까? 그럼 능력이 출중하여 유지보수를 안해도 되게끔 플랫폼을 구축하는 실력을 가진이라면 옆 동료도 좋아할 수 있다.

그런데, 개발은 혼자 하는게 아니다. 서비스는 한 명의 유능함으로 굴러가진 않는다. 결국, 같이의 가치로 서비스는 굴러가고, 개발자는 성장 한다.

지금 있는 회사에서 나를 너무 싸게 부리는 것 같다며, 쿠팡으로 이직 해야겠다는 생각을 하는 이들이 많을 것 같다. 그 중에 나도 포함이다.

곰곰히 생각해보니, 돈 보다 중요한건 자신만의 우선순위가 중요할 것 같고, 이는 예전에 남긴 개발자가 지원 해야 할 회사를 고를 때, 필요한 안목 중에 하나였다.

내 입장에서는 사람, 서비스, 문화 총 3가지가 중요하다.

물론, 위의 글을 읽어보면 쿠팡 관계자는 나를 비웃을 수 있다. “합격도 안한 사람이 말이 많구나 하며…”

그럼에도 내 고민을 남겨보자면 결국 사람이다. 내가 생각하는 최고의 칭찬은 “개발 진짜 잘해” 이런 것보다 “같이 일하고 싶다. 아니면 같이 또 일하고 싶다.”라는 평가를 듣는 것이다.

개발 퍼포먼스가 뛰어난 사람은 세상에 많고, 그에 비해 개발 퍼포먼스가 떨어지는 개발자도 많지만 그 안에서 나는 누구도 할 수 없는 1인분을 해내는 개발자이고 싶다.

자신만의 개발자 철학은 무엇일까? 다른 사람들의 생각이 궁금하다.

2021년의 목표는 ?

개인의 목표

영어책 샀던 총 4권은 끝내고 싶다.
- 기초 문법책
- 회화책
- 스피킹 낭독책
- 일빵빵
경제 뉴스 하루에 5분씩 읽기
다이어트 71kg까지 감량하기
등산 꾸준히 하기 (최소 5개의 산)
독서 70권
명상 하루에 10분씩 2회 하기

개발자 목표

Ansible 커뮤니티에 기여하기
Kotlin 배우기
Spring Batch 학습하기
Rust 배우기
TDD 연습하기

올 한 해의 끝자락에서 이 모든 목표들을 이뤘다고 말할 수 있으면 좋겠다.

그냥 저냥 #위클리뉴스 #94

Mon, 28 Dec 2020 14:13:12 GMT

🖥 개발자에게 도움이 되는

그것이 알고 싶다 - 왜 개발자는 글을 못 쓸까? - LINE ENGINEERING

이 글은 개발자가 글을 왜 안 쓰게 되는 가에 설명을 하고 있는데, 제목이 틀렸다. 못 쓰는가? 라고 해야 할 게 아니라 왜 안 쓰게 되는가? 라고 했어야 맞다.
모든 개발자가 블로그, 잡지, 책 집필을 꼭 해야만 하는 건 아니다. 애초에 관점을 테크니컬 라이팅에 맞출 거라면, 기술 스펙 문서 작성에 초점을 맞춰야 하지 않을까?

DEVIEW 2020 발표자료와 영상이 공개되었습니다.

Deview 라이브 몇개의 영상을 봤었는데, 일 하는 중에 보느라 못본 것도 있는데, 다시보기로 올라와 다행이다.

2020년 회고

1년간 스터디, 번역등 다양한 참여를 하셨는데, 읽다보니 나로써는 내년 목표를 생각하게 되는 회고여서 고마운 글이었다.

💻 Front-End

2020년과 이후 JavaScript의 동향 - JavaScript(ECMAScript)

2020년과 이후 JavaScript의 동향 - 라이브러리와 프레임워크 1

같이 보면 좋을 것 같아서 JS 동향과 라이브러리, 프레임워크 글을 읽어 보았는데, React, Angular 쓰는 모든 사람들이 보아도 좋을 글이라는 생각이 들었다. React 17의 이벤트 바인딩 변경, Recoil 설명등 유용한 부분이 많았다.

2020년과 이후 JavaScript의 동향 - 라이브러리와 프레임워크 2

Vue.JS 3.0의 설명, Svelte의 설명을 하는 두번째 JS 라이브러리, 프레임워크 글인데, 읽어보면 도움이 많이 된다. Vue.JS를 실무 레벨에서 써보진 않아서 살짝 멀어진 느낌이지만, 3.0이 향후 4.0으로 가는 가벼운 발걸음이 아닐까? 하는 생각이 들게 했다. 정말 상세하게 쓰여 있어서 내가 대충 읽고 넘어간 부분도 있다.

프론트엔드 개발자의 역할

요즘 프론트 엔드 개발자의 고민과 영역 범위에 대한 부분을 짧고 간결하게 잘 남겨주셨다. 특히나 프론트 엔드만 하는 팀에 속하면 이 고민이 마크업까지만 해당 되는데, 나 같은 경우는 풀스택에 속한다. 이럴 경우 도대체 어떤 선택을 하는게 좋을지 매순간 고민이다. 여전히 내가 뭘 더 하고 싶은지를 잘 모르겠다.

👋🏻 일반적인

2021년, ‘그만두기 목록’ 만들기

하반기에 읽은 책 중에 아주 작은 습관의 힘이라는 책이 있었는데, 그 책에서 말하길 나쁜 습관도 없애야 한다고 하는데, 생각 못하고 있었다가 내년 목표를 세우다가 왜 해야 할 것만? 생각하고 있는지? 내가 하지 말아야 할 것들도 생각 해야 하는데 하는 생각을 하는 와중에 읽게 된 글이다.

메모는 성공을 가져온다

메모를 꾸준히 하려고 하지만, 생각처럼 쉽지는 않다. 그에 대해 방법을 가이드 해주는 글이다. 내 입장에서는 메모를 하는게 이제까지 해온 바로는 뭐라도 메모 하는게 훨씬 도움이 된다. 그게 진짜 펜을 들고 메모장에 쓰는 것이든, 컴퓨터 노트에 타자를 치거나, 아이패드로 펜으로 쓰는 것이든 말이다. "기록은 곧 역사다"라는 말을 좋아한다.

그냥 저냥 #위클리뉴스 #93

Tue, 15 Dec 2020 21:13:30 GMT

🖥개발자들에게 도움이 되는

내 맘대로 위클리 뉴스 - 2020년 49주(2020.11.28 - 2020.12.4)

React 관련 보안 문제를 처리 하는 방법, Java 관련 글이 좋았고, Django + React를 이용한 튜토리얼도 좋았다.

백엔드 개발자가 회사에서 리액트 세미나를 진행하기까지

백엔드 개발자가 리액트를 쓰면서 겪은 경험기를 토대로 회사에서 세미나를 진행 했던 이야기를 남겼는데, 대단하다는 생각이 들었다. 비싼 강의도 자진해서 듣고, 배움에 대한 열정이 이렇게 지닐 수 있다는 점이 참 놀랍고도 멋졌다.

New from Universe 2020: Dark mode, GitHub Sponsors for companies, and more - The GitHub Blog

Github universe에서 공개된 주요 기능에 대한 정리이다. Auto-merge pull requests 기능, Dependency review 기능 등이 기대 된다.

Free Online Tutorials and Courses

모든 튜토리얼에 대한 모음집 페이지라고 생각하면 쉽다.

💻Front-End

[A6] Statecharts: 복잡한 UI 상태를 지배하는 방법

FSM을 오랜만에 들어보긴 했지만, 이 모델을 Reducer에서 쓰는 방법이나, statecharts를 이용한 UI 상태 관리를 할 수 있다는 점이 신선하기도 하고, 놀라웠다. 여전히 쪼렙인지라, 영상 한 번 보고 이커머스 UI에 어떻게 접목시킬 수 있을까? 라는 질문에 답이 생각 나진 않는다.

💻Back-End

Kafka, Pulsar, Kinesis 총 세가지 도구에 대해서 설명 해주는 영상인데, 20분정도이지만 짧지만 알차게 설명을 해준다.

👍🏻일반적인

[책이벤트] 이타적인 인재만 성공하는 이유 | 조용민 구글 매니저 | 비전 창의성 역량 | 세바시 1302회

이타적인 인재의 위대함에 대해서 설명하는 세바시 영상인데, 시간 남을때 보면 도움이 된다. 총 3가지의 태도에 대해 설명 하는데, 개발자에게도 이 3가지의 마음이 중요하다고 생각 했다.
- 문제 해결을 위한 목적에 대한 집요함.
- 기회를 발견하는 창의적인 유연성.
- 기술의 가치를 높이는 사용자 친화적 배려심.

그냥 저냥 #위클리뉴스 #92

Sun, 06 Dec 2020 18:13:21 GMT

🖥개발자에게 도움이 되는

내 맘대로 위클리 뉴스 - 2020년 47주(2020.11.14 - 2020.11.20)

Java 관련 책 추천은 단계별로 추천하고 있어서 좋았고, 내가 보지 못한 책들도 많아서 공부를 너무 안했구나?! 하는 마음이 들고 JavaScript import/Export 관련 글이 이해하기 쉽게 설명 하고 있어서 좋았다.

데이터 엔지니어링이란

요즘 나의 커리어를 어디로 가져가야 맞을까를 굉장히 고민하는데, 데이터 엔지니어링이 나에게 적합해 보인다는 생각을 많이 하게 되는데, 해당 역할에 대해 간결하고 확실하게 설명을 잘 해주셨다.

월간 개발자스럽다 #61

각기 다양한 글과 이벤트 정보가 수록 되어 있는데, 미국과 한국 UX디자이너의 인재상 차이가 인상 깊다.

누구나 원하는 개발자되기

이 글에서 말하는 것처럼 결국, 미리 미리 준비 해야 함과 동시에 의도적인 수련을 했어야 자신의 어떤 성장세를 유지할 수 있다는 점이다. 그럼, 결국 회사에서 시키는 일만 하는게 아니라, 내가 뭘 했는지도 잘 정리 하고, 공부도 해야 된다는 말인데. 이게 쉽지 않다. 즉, 현재 속한 회사에서 평생 일할 것 처럼 애정을 쏟지 말자.

💻Front-End

FE개발자의 성장 스토리 02 : Babel7과 corejs3 설정으로 전역 오염 없는 폴리필 사용하기

전역 스코프에 폴리필을 추가 하지 않고 서비스를 운영 하기 위한 해법들을 소개 하고 있다. babel에 대한 상세한 설명이 되어 있다.

이직하려는 친구에게 보내는 프런트엔드 개발 면접 질문

정말 주요한 개념들이자, 단골 질문들의 리스트를 뽑아주셨다. 이것만 대답할 줄 알면, 이직이 좀 더 쉬워지지 않을까?

자바스크립트 개발자를 위한 ReasonML

ReasonML이라는 언어를 들었는데, 참 신기하게도 실무에서 이미 쓰고 있는 회사 블로그의 글이다. OCaml 이란 언어는 대학교 전공 수업시간에 들은 게 다 였는데, 실제로 쓰일 수 있구나를 또 한 번 깨닫게 된다.

🎼일반

주식으로 돈 못 버는 사람들 특징

투자에 왜 실패하는지 뼈를 날리는 기사다. “카”의 명언이 인생의 참 뜻이 되기도 하는구나 깨닫는다.

책 리뷰, 꼭 써야 할까요?

예전에는 책에 나오는 주요 부분만 따로 옮겨 적곤 했다. 이를테면, 본문에 나오는 ‘질서’만 했다. 그런데 2년 전부터 독후감을 에버노트에 템플릿으로 만들고 적다보니 나름 대로 의미가 있었다. 이 행위가 ‘초서’에 해당한다. 그리고, 나의 생각이나 느낀점들을 정리 하다보면 이 책에서 주는 의미들을 한 번씩 곱씹을 수 있다는 장점이 있다. 그래서 나도 추천.

그냥 저냥 #위클리뉴스 #91

Tue, 10 Nov 2020 18:11:57 GMT

💻개발자에게 도움이 되는

어느 고졸 개발자의 10년의 회고록

솔직히 부러움이 많이 남는 글이었다. 이렇게 열정적일 수 있구나. 개발이 이렇게 신나보이는 분은 내 입장에서 너무 부러웠다. 👍🏻

뱅크샐러드의 특별한 스펙, ‘테크 스펙’ | 뱅크샐러드

사실 테크 스펙이란게 예전에는 회의적으로 생각 했는데, 이제는 굉장히 중요한 부분이 아닐까? 하는 생각을 하게 되었다. 그 이유는 예전에는 팀원이 굉장히 적었는데, 2-3배로 늘어나면서 테크 스펙이 필요하구나! 하는 생각을 많이 하게 되는데, 팀원분 중에 잘 하는 분은 이미 이전부터 하고 계신데, 나도 따라서 잘 해야겠구나를 느꼈다.

새 버전에 맞게 git checkout 대신 switch/restore 사용하기 :: Outsider’s Dev Story

checkout이 이제는 switch, restore 두가지의 명령으로 나뉘어 사용하는 것이 가이드로 대체 되는 것 같다. 의미상 이해하기 쉬워졌다고 생각한다. 해당 기능에 대해 설명하는 글이다.
switch 키워드로 새로운 브랜치를 만드려면, -c 옵션을 써야 한다.

🌟Java

JVM 메모리 해부학

Eclipse Collection을 알게 된 계기이면서 생각보다 JVM object가 굉장히 무겁구나를 깨닫게 되었다. 이런 작업을 왜 안해봤을까? 하는 생각을 했다.

💻FE

좋은 코드란 무엇일까?

좋은 코드에 대한 개인의 생각 그리고, 방향성을 알려주는 글이며, 실제 리액트 코드로 예시를 보여줌으로써 좋은 코드가 무엇인지에 대해 더 쉽게 이해할 수 있는 글이다.

naver/fe-news

FE관련 다양한 아티클이 소개 되어 있는데 30 Days of React가 인상적이다. 30일간 직접 해보면 도움 많이 될 것 같다.

FEConf Korea

FEConf 영상이 올라 와 있는데, 신청 하지 않았던 사람도 라이브를 놓쳤던 사람들도 다시 볼 수 있어서 좋다. 그리고 다양한 주제가 있어서 재밌었다.

Ansible 사용하면서 삽질 경험, 약간의 팁

Sat, 07 Nov 2020 16:20:00 GMT

예약어를 변수명으로 썼을때 이슈

예약어가 존재하는데, 예약어를 변수명으로 쓰면 arguments를 넘겨줘도 값 대입이 안된다.

ex)

host_vars/main.yml

role: “{{ role_name }}”

-e “role_name=test” 했더니 값에 role에 해당하는 이름이 계속 들어가서 알게 됨.

ansible -m shell 모듈 관련

ansible -m shell로 tomcat을 실행시켜도 모듈 실행이 끝나면 꺼지는데, nohup을 같이 줘야 하는 이유는 왜일까…

shell script file자체가 daemon으로 실행하는데도…?

이 부분은 검색을 해야봐야 할듯.

roles 하위 role에 remote_user 지정 경고

[DEPRECATION WARNING]: Using 'remote_user' as a role param has been deprecated. In the future, these values should be entered in the `vars:` section for roles, but for now we'll store it as both a param and an attribute..

This feature will be removed in a future

release. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.

단, ansible_user로 셋팅하면 동일하다. 그리고 ansible core 소스를 까봐도 동일하다.

ansible 요약
- https://gist.github.com/andreicristianpetcu/b892338de279af9dac067891579cad7d

host os / host os version 가져오기

gather facts가 true 여야 한다.

- name: Set ansible host os version
  set_fact:
    host_os_version: "{{ hostvars[inventory_hostname]['ansible_distribution_major_version'] }}"
    host_os: "{{ hostvars[inventory_hostname]['ansible_distribution'] }}"
  tags:
    - apache

원래 위와 같이 가져오곤 했는데, 굳이 위와 같이 가져오지 않아도 된다.

ansible_distribution_major_version

위와 같이 사용해도 hostvar이라는 magic variable을 가져올 수 있게 된듯하다.

get_url 파일명 지정 하기

wget 명령어에는 --content-disposition명령어로 업로드된 파일 명으로 다운로드 할 수 있다.

그리고, 파일명을 바꿔서 다운로드 할 수도 있다.

그런데, ansible에서 어떻게 처리를 해야 할까 고민스러웠다.

찾아보니 해당 PR이 있었다.

Modified the get_url module to respect the content-disposition header if… by Tinche · Pull Request #4785 · ansible/ansible

사용법

- name: Down file install something
  get_url:
    url: 'https://test-something.seungdols.com/0a7056be-648d-1539-8164-93453fad7d6a'
    dest: /home/seungdols/dev/test-some_module.tar.gz

dest 경로 마지막에 내가 원하는 파일명으로 셋팅 해주면 된다.

docs에도 나와 있다.

get_url - Downloads files from HTTP, HTTPS, or FTP to node - Ansible Documentation

앤서블 정리

플레이북 실행 속도를 높이기 위한 tip

파이프라이닝으로 SSH 처리 수 줄이기

일반적으로 앤서블은 task 실행마다 SSH명령을 여러번 실행(임시 디렉토리 생성, 모듈 스크립트 전송, 모듈에 실행 권한 부여, 모듈 실행 + 삭제)하지만, 파이프라이닝 설정을 활성화화면, 모듈 스크립트의 전송을 처리할 필요가 없어진다. 곧, SSH처리 수가 감소하여 (모듈 실행만으로 완료) 성능 개선으로 연결될 수 있다. 즉, 이 설정을 SSH를 통해 모듈을 실행하는 모든 경우에 유효하여 항상 활성화 해두는 것이 좋다.

[ssh_connection]
  pipelining = True

파이프라이닝이 기본적으로 비활성화 된 이유는 sudo를 이용해 관리자 권한으로 실행할 때, sudoers 설정 파일에서 requiretty를 비활성화해야 한다는 제약이 있어서 그렇다. 그리고 앤서블 자체가 모든 시스템에 기본 설정만으로 문제 없이 동작해야 한다는 철학을 가지고 있어서 기본 설정에 파이프라이닝 설정 하는 것을 권장 하지는 않는다.

requiretty가 활성 상태인 호스트를 작업 할 때도 playbook을 이용해 파이프라이닝 대응 처리 자체를 ansible에서 처리가 가능하다.

- name: pipleining 대응
    hosts: all
    become: yes
    vars:
      ansible_ssh_pipelining: no
    tasks:
      - name: ansible_user에 대한 requiretty 설정을 비활성화
        lineinfile:
          dest: /etc/sudoers
          regexp: '^Defauls:{{ ansible_user }}\srequiretty'
          line: 'Defaults:{{ ansible_user}} requiretty'
          validate: 'visudo -cf %s'
          backup: yes

forks로 동시 병렬 배포 수 제어

여러 대에 동시에 배포시 먼저 조정 해야 하는 것이 호스트에 최대 동시 접속 수를 표시하는 forks입니다. 기본 설정은 ansible 방침에 따라 5개로 설정 되어 있어, 이 값을 늘려주면 됩니다.

단, MacOS 에서는 20으로 줘도 에러가 발생하는데, 이를 위해서는 파일 오픈 갯수를 늘려주어야 합니다.

암호화 관련

ansible-vault라는 명령으로 키 파일등을 암호화 할 수 있음.
https://www.vaultproject.io/
vault 프로젝트또한 모듈로써 완벽하게 지원해줌.

앤서블 동작 순서

Variable loading
Fact gathering
The pre_tasks execution
Handlers notified from the pre_tasks execution
Roles execution
Tasks execution
Handlers notified from roles or tasks execution
The post_tasks execution
Handlers notified from post_tasks execution

Jenkins 셋팅 전 확인 하면 좋은 정보

Sat, 07 Nov 2020 16:15:00 GMT

Jenkins version 선택하기

jenkins download url : http://mirrors.jenkins-ci.org/

위 주소에서 war-stable에 있는 리스트에 있는 버전을 선택하는 것이 가장 탁월한 선택이다. 허나, jenkins는 매주 업데이트 하는 것으로 알려져 있고, Stable version은 3개월 단위의 버전 업데이트 집합이라고 할 수 있다.

고로, stable version이라고 해서 다 안전한 버전인 것은 아니다.

https://jenkins.io/changelog-stable/ 이 주소에서는 stable 버전에 대한 업데이트 내용과 함께 괜찮은지에 대한 투표를 할 수 있다. 여기에서 참고하는 편이 stable 버전 선택에 도움을 준다.

Jenkins download

wget 명령어를 이용해 .war 파일을 다운 받는다.

wget http://mirrors.jenkins-ci.org/war-stable-rc/2.32.3/jenkins.war

Command

URL

http://<jenkins.server>/restart
http://<jenkins.server>/safeRestart
http://<jenkins.server>/exit
http://<jenkins.server>/safeExit
http://<jenkins.server>/quietDown
http://<jenkins.server>/cancelQuietDown

Remote API

URL can be invoked by a Remote API.

Using wget:

$ wget --user=<user> --password=<password> http://<jenkins.server>/restart
$ wget --user=<user> --password=<password> http://<jenkins.server>/safeRestart
$ wget --user=<user> --password=<password> http://<jenkins.server>/exit
$ wget --user=<user> --password=<password> http://<jenkins.server>/safeExit
$ wget --user=<user> --password=<password> http://<jenkins.server>/quietDown
$ wget --user=<user> --password=<password> http://<jenkins.server>/cancelQuietDown

Using cURL:

$ curl -X POST -u <user>:<password> http://<jenkins.server>/restart
$ curl -X POST -u <user>:<password> http://<jenkins.server>/safeRestart
$ curl -X POST -u <user>:<password> http://<jenkins.server>/exit
$ curl -X POST -u <user>:<password> http://<jenkins.server>/safeExit
$ curl -X POST -u <user>:<password> http://<jenkins.server>/quietDown
$ curl -X POST -u <user>:<password> http://<jenkins.server>/cancelQuietDown

Jenkins CLI

$ java -jar jenkins-cli.jar -s http://<jenkins-server>/ restart
$ java -jar jenkins-cli.jar -s http://<jenkins-server>/ safe-restart
$ java -jar jenkins-cli.jar -s http://<jenkins-server>/ shutdown
$ java -jar jenkins-cli.jar -s http://<jenkins-server>/ safe-shutdown
$ java -jar jenkins-cli.jar -s http://<jenkins-server>/ quiet-down
$ java -jar jenkins-cli.jar -s http://<jenkins-server>/ cancel-quiet-down

Unix-based

$ sudo service jenkins restart
$ sudo service jenkins stop
$ sudo service jenkins start

$ sudo /etc/init.d/jenkins start
$ sudo /etc/init.d/jenkins stop
$ sudo /etc/init.d/jenkins restart
# Or in the latest distribution of Linux:
$ sudo systemctl start jenkins.service
$ sudo systemctl stop jenkins.service
$ sudo systemctl restart jenkins.service

Tomcat

# Tomcat as a Unix service:
$ service tomcat7 start
$ service tomcat7 stop
$ service tomcat7 restart

# Tomcat as a Windows service:
$ <tomcat.home>/bin/Tomcat.exe start
$ <tomcat.home>/bin/Tomcat.exe stop

# Tomcat running Mac/Linux/Unix binaries:
$ $CATALINA_HOME/bin/startup.sh
$ $CATALINA_HOME/bin/shutdown.sh

# Tomcat running Windows binaries:
$ %CATALINA_HOME%\bin\startup.bat
$ %CATALINA_HOME%\bin\shutdown.bat

# Tomcat 7+:
http://<tomcat-server>:8080/manager/text/stop?path=/jenkins
http://<tomcat-server>:8080/manager/text/start?path=/jenkins
http://<tomcat-server>:8080/manager/text/reload?path=/jenkins

Stand-Alone

$ java -cp $JENKINS_HOME/war/winstone.jar winstone.tools.WinstoneControl reload: --host=localhost --port=8001
$ java -cp $JENKINS_HOME/war/winstone.jar winstone.tools.WinstoneControl shutdown: --host=localhost --port=8001

# start jenkins with control port
$ java -DJENKINS_HOME=/path/to/home -jar jenkins.war --controlPort=8001

그냥 저냥 #위클리뉴스 #90

Mon, 05 Oct 2020 21:11:15 GMT

🖥개발자에게 도움이 되는

기술 뉴스 #159 : 20-10-01 :: Outsider’s Dev Story

outsider님의 기술 뉴스입니다. 이번 글에서 인상 깊었던 글은 블루홀에서 무엇을 배웠나?, 개발자를 위한 정보 검색 팁 글이 인상 깊고, visx 라이브러리는 진짜 유용해 보인다. 갓비엔비..

내 맘대로 위클리 뉴스 - 2020년 40주(2020.9.26 - 2020.10.2)

sangkon 님의 위클리뉴스이며, react DOM, Redux, React cheatsheet 글이 인상적이었고, python에서 gzip이 어떻게 수행 되는지에 대한 글은 파이썬을 주로 쓰지 않아서 좀 어렵긴 헀다.

테스트 코드

테스트 코드에 대한 생각과 실제로 어떻게 하고 있는지를 써주셨는데, 공감가는 부분은 "의미 있는 테스트 코드를 만들고 유지 할 수 있는 건 팀의 역량이다" 라는 소제목이 달린 단락이 마음에 와닿았다. 나는 보통 테스트 코드를 그렇게 작성하는 개발자는 아니고 노력하는 편이고, 그보다 동작 하지 않는 테스트 코드를 지우거나, 수정하는 걸 하려고 노력 하는 편이다. 팀 모든 사람들이 유지 되게 만드는 환경을 만들어야 한다. 어차피 관리 되지 않는다면, 지우는 것이 맞다. 아니면 고치거나. 기왕이면, 위 글처럼 Rule을 가져가는 것도 좋다고 생각 한다.

월간 개발자스럽다 #59

한 달간의 개발자스럽다 글 모음인데, 내가 보지 못했던 글을 볼 수 있어서 좋다. 나는 못봤던 Java 관련 Project Loom에 대해 알 수 있었다. 네이버 스마트 주문 성능 개선에 대한 글도 유용했다.

👍🏻일반적인

다른 이에게 고집이 세다고 말하는 사람의 고집은 얼마나 셀까?

고집이 세다 고 말하는 이유에 대한 세가지 관점에 대한 정리인데, 흥미롭다. 나름의 근거를 지니고 있어서 재밌게 읽을 수 있다. (로고스, 파토스, 에토스의 부재로 설명 한다.)

한 주 업무 80%를 월요일에 한다면 미친 짓일까

월요병을 물리치는 최고의 방법은 월요일을 알차게 보내는 것이라는 생각을 하게 된 적이 있다. 사실, 나는 월요병이 큰 사람은 아닌데, 가끔 월요일에 중요도 높은 업무를 하면, 일주일이 가장 알차게 많은 업무를 할 수 있다는 사실을 깨달았는데, 이 글을 보니 월요일을 더욱 알차게 보내야겠다는 생각을 하게 되었다.

그냥 저냥 #위클리뉴스 #89

Tue, 29 Sep 2020 20:09:46 GMT

⌨️개발자가 보면 좋을

뱅크샐러드는 어떻게 레거시 서비스를 박살 내는가 | 뱅크샐러드

뱅크 샐러드에서 사용하는 레거시 서비스를 개편 하기 위한 준비, 방법을 통해 안전하게 신규 서비스로의 이전 작업 했던 부분에 대해 설명 하고 있다. 내용을 읽을 때 뱅크 샐러드의 백엔드는 Go와 gRPC를 쓰고 있다는 것을 기억해야 한다. 이슈 없이 이전을 위해 기존 서비스와 신규 서비스 요청 응답의 diff 체크, diff에 대한 대시보스를 통한 확인 등 정말 일을 짜임새 있게 진행 하는 구나! 하는 느낌을 받았습니다. 그리고, 목적 중심의 지향을 위해 도입한 템플릿 도구와 문서를 통한 원칙 정하기가 참 좋았습니다.

여러분의 CS 교육에서 누락된 학기

번역 하자면, 놓쳤던 학기라는 제목의 유투브 채널도 있고, 페이지도 있는데 위 페이지는 해당 컨텐츠의 번역본이다. 해당 내용에서는 학기에서 알려주지 않는 텍스트 에디터, Git, Debug등을 알려 준다.

차근차근 오픈소스에 기여해보기 (동기부여 편)

오픈 소스에 기여 하는 방법, 어떤 종류들이 있는지 상세하게 소개 하고 있다. 특히, Gatsby 같은 경우는 Pair 프로그램이 있다는 사실이 놀라웠다. (나도 오픈 소스 기여를 해볼까? 하는 목표가 문득 생겼다.)

🖥Front-End

크롬 확장프로그램 개발⛏️ 회고

줌 인터넷에서 크롬 확장 프로그램을 개발한 경험기를 고민/프로젝트 구조, 만들고 난 뒤의 생각까지 정리를 잘 해주셨다. 그리고 중간 중간 마다 깨알 팁들을 잘 적어주셨다. (VueJS로 개발 하셨다.)

FE플랫폼팀이 궁금하세요? - 함께 성장해가는 개발팀 이야기

카카오 FE플랫폼 팀에 대해 아주 상세한 기술 스택과 어떤 업무를 하고 있는지를 잘 소개 해주고 있다.

유용한 테스트 케이스를 위한 개발자의 자세 : TOAST Meetup

테스트 코드에 대한 견해인데, 실제 모듈 코드와 테스트 케이스를 동일하게 생각해야 한다는 점이 당연하게 생각하지만, 실제로 그렇게 하진 않아서 읽으면서 뜨끔 하기도 했다. 여기서 견해는 테스트 코드 보다 테스트 케이스에 대한 의미 부여를 한 것이 좀 다르게 다가왔다.

3항 연산자의 재발견

3항 연산자에 대한 가독성에 관한 글인데, 생각보다 세로 줄 쓰기가 정말 가독성에 도움이 되어 놀랐다. 👍🏻

14. 야 너두 할 수 있어. 비전공자, COBOL 개발자를 거쳐 네이버에서 FE 개발하게 된 이야기

차성원님의 발표인데, 정말 알차다. 우선, 많은 이들이 질문 하는 것들에 대해 앞부분에서 QnA로 답변을 해주시고, 코볼 개발자에서 네이버 이직 후 어떤 길을 걸어 오셨는지? 설명 해주는 부분은 꼭 보도록 하자. 그리고, 발표 내용인 어떤 개발자가 좋은 사람인지? 어떻게 FE를 학습 했는지? 알 수 있다. (이 분께서 만드신 것들이 엄청나다..)

🖱일반적인

[직장인의 글쓰기] 5. 일기를 에세이로 만드는 방법

일기와 에세이의 차이는 내용의 본질의 대상이 소모에 있는지? 생산에 있는지? 에 큰 차이가 있는 것 같다. 이 차이를 잘 설명하고, 어떻게 하면 일기를 에세이로 바꿀 수 있는지? 설명한 글이다.

영화로 영어 공부하는 가장 효과적인 방법

3단계의 핵심을 설명하면서 영화 한 편으로 영어 공부하는 방법을 상세하게 정리 하고 있다.

그냥 저냥 #위클리뉴스 #88

Mon, 21 Sep 2020 22:10:10 GMT

💻개발자에게 도움이 되는

NAVER FE devtalk: 디자인 시스템에 대한 소개와 효율성 개선 및 구축 경험공유

7월에 했던 FE devtalk에 대한 발표 영상이 공개 되었다. 여러 회사에 계신 분들이 다양한 주제와 깊이로 발표 하셨기 때문에 시간 날 때 참고하면, 도움이 많이 된다. 특히 디자인 시스템에 관심 있는 사람이라면 필수다.

GitHub Codespaces 살펴보기 :: Outsider’s Dev Story

Github와 VS Code의 융합으로 Github Codespaces가 출시 되었는데, 아웃사이더님께서 베타로 먼저 테스트 해본 경험글을 남겨주셨다. 생각보다 괜찮아 보이고, 가격도 그렇게 비싼 편이 아니라서, NodeJS서버 개발 같은 건 아이패드로 바로 개발 가능해 보인다.

k8s 필수 애플리케이션, 테라폼으로 한번에 설치하기 - 서비큐라 개발로그

Kubernetes, Helm Provider에 대한 영상인데, 테라폼이 정말 강력하게 구성을 해주는 것을 볼 수 있고, 설명을 차근 차근 해주신다!

기술 뉴스 #158 : 20-09-15 :: Outsider’s Dev Story

이번 기술 뉴스에서는 개인적으로 스크럼에 관한 글이나, 깃허브 컨테이너 레지스트리등에 관한 글들이 좋았다.

Rust for Java developers - codecentric AG Blog

Java 개발자를 위한 Rust 설명인데, Java 코드와 Rust 코드 Dual로 구성을 하고 설명을 하고 있어서 Java 코드를 읽을 줄 알면, 매칭 되는 러스트 언어를 학습 할 수 있다.

AWS Lambda와 SQS를 이용한 대용량 엑셀 처리

왜 엑셀 다운로드를 분리 하게 되었는지에 대한 설명이 있어서 이해하기에 좋았고, 엑셀 다운로드에 대한 고민과 해결책을 AWS Lambda와 SQS를 통해 해결한 경험 글이고, 현재 단점과 나아가야 할 점에 대해서도 잘 정리 해주셨다.

How HTTPS works

추천을 받아 해당 링크를 알게 되었는데, 정말 이해하기 쉽게 되어 있다. 강추!!!👍🏻

[B급 프로그래머] 9월 3주 소식(개발/관리도구, 고성능 서버/데이터베이스 부문)

B급 프로그래머님의 9월 3주 소식인데, 다양한 소식들이 많고, 특히 hwplib라는 한글 라이브러리 (자바)가 신기하고 재밌었다. 그런데, 이제 한글을 멀리 한지 시간이 많이 지나 가끔 그 시절이 그립기도 하다. (물론, 많이 쓰는 곳도 있겠지!?) 아직, 읽기 기능만 지원 하는 것 같다. 그리고 그 외로 react + typescript cheatsheet라던가, tmux 입문기는 도움이 많이 된다. 원래 tmux를 기본으로 쓰곤 했는데, 생각보다 요즘은 또 잘 안쓰고 있다. (서버 작업 시에는 필수다)

👋🏻프론트 엔드

Vue 3 가볍게 훑어보기

VueJS 3에 대한 바뀐 점과 어떻게 써야 하는지에 대한 소개인데, 제목은 가볍게 이지만, 내용은 정말 알차게 담겨 있다.

TypeScript를 활용한 서비스개발

당근마켓에서 TypeScript를 통해 어떻게 서비스를 개발 하는지에 대한 기술 스택 소개이다. NestJS는 옛날에 한 번 보고, 생각 못하고 있었는데, 다시 보게 되어 새로웠다. (데코레이터 패턴이라…🤔)

next.js를 이용해 레거시 프로젝트를 점진적으로 개선해나가기

Django + VueJS 기반의 페이지를 점진적으로 Next.JS로 개선해가는 과정을 도입 이유, 어떻게 배포할지? 실제적으로 어떤 방법으로 진행 했는지에 대해서도 잘 남겨주셨다. (이런 글들이 정말 도움이 많이 된다.)

🔧도구

GitHub CLI 1.0 is now available - The GitHub Blog

github cli tool이 출시 되었다. MacOS는 brew install gh로 쉽게 설치 가능하다! 회사 엔터프라이즈에서 써볼까? 생각 중이다. 설정을 할 수 있게 되어 있다. 그런데, 공통으로 둘 다 쓸 수 있는지? 인증이 2개가 적용 되는지는 모르겠다. (아직 github만 시도 해봤다.)

Visualize Data Structures in VSCode

VS Code에서 디버그로 데이터 구조를 시각화 할 수 있는 플러그인에 대한 소개이다.

Nx: Extensible Dev Tools for Monorepos

Monorepo를 위한 개발 툴인데, 이것도 처음 접하게 되었다. (lerna 와 다른 개념인가 생각 했는데, 10분 소개 영상을 보면, 비슷한 것 같기도 하다.)

Flume

NodeJS용 editor 모듈이라고 하는데, 써 보진 않았지만, 기억하고자 기록 한다.

팀에 무언가를 도입 한다는 것은...

Tue, 15 Sep 2020 23:59:00 GMT

🛠팀에 도구를 도입하고 싶은 경우

도구를 도입한다는 건, 일단 팀의 규모가 어느 정도 되는지에 따라 달라진다. 예를 들어, 4명인 팀과 8명인 팀, 16명인 팀인 경우 모두가 다르다.

내가 현재 속한 4명, 5명 시절부터 8명, 현재의 16명이 된 팀이 된 경우인데, 도구를 도입하고 싶은 경우 도입 했던 경험을 쓰려고 한다. 사실, 현재 속해 있는 팀원들이 모두 도구나 프로세스 도입에 대해서 보수적인 팀이 아니다 보니, 도구를 도입하는 것은 어렵진 않았다. 책임만 지면 된다. 😂

도구를 도입 하는 것에 대해 내가 느낀 세 가지가 있었다.

👉🏻첫째로는 내가 그 도구를 잘 아는가?

일단, 내가 도입하고 싶은 도구가 뭔지? 그리고 그 도구가 왜 필요한지를 알아야 한다.

예를 들어서 내가 했던 일이 입사 이후 부터 지금까지 서버 관리 업무가 주로 있었다.

메인 역할은 아니지만, 서브로 항상 존재 해 왔는데, 예전에도 발표를 했던 적이 있지만, 예전 방식이 너무나 불편하고 수동으로 해야 하는 점이 수고스러워 서버 설정 관리를 자동으로 동일하게 할 수 있는 툴을 도입 해야겠다고 생각 했다.

중요한 건, 나는 내가 하는 업무가 더 잘 되길 바랐다. 그래서 조사를 했었다. 서버 설정을 편리하게 잘 할 수 있는 것들이 무엇이 있을까?

Chef
Puppet
Ansible

위의 툴들이 모두 프로비저닝 툴에 대표 툴들인데, 나는 사내의 시스템과도 잘 맞을 수 있는 Ansible이라는 툴을 더 찾아 보았고, 책을 주문하고 튜토리얼을 경험 해보니 괜찮았다. 그래서 해당 도구를 도입 하기로 선택했다. 그 외 나머지 도구들에 대해서는 왜 Ansible 보다 덜 좋은지에 대해 찾았고, 사람들에게 설명 했다.

결국에는 내가 편하자고 도입한 도구이고, 도움은 정말 많이 되었다. 물론, 문제점은 존재 했다.

👋🏻둘째로는 그 도구를 도입하여, 얻게 될 이점은 무엇일까?

도구를 도입하는 것에 대해서는 당연히 이점이 있어야 한다.

이점이 없다면 도구를 배우고 활용하는 러닝커브의 비용을 설명 할 수 없다.

결론적으로 그 도구가 왜 좋은지? 어떻게 해서 이 팀에 도움이 되는지를 명확하게 설명할 수 있어야 한다.

결코, 내가 그 도구의 마스터 클래스에 도달 할 필요는 없다. 그냥, 지금 있는 환경에서 보다 더 나을 것 같은 도구라는 판단이 되고, 사용 해보니 도움이 된다면 도입 하는 전략이 나는 좋다고 생각 한다.

물론, 팀 사람들이 그 도구에 찬성 하지 않을 수도 있다.그렇지만, 일정 부분 동의를 한다면, 도입 하는 것이 좋다. 어차피 책임은 내가 지게 된다.

그런데, 모두가 반대 한다면, 그것은 나의 아집 일 수 있으니 구분을 잘 하도록 하자.

실무에서 써 보지도 않고, 이걸 잘 한다고 할 수 있을까? 실무에서 쓴다고 해도 잘 아는 것도 아니며, 잘 하는 것도 아니다. (방심하지 말자🤣)

그리고 팀 사람들 중에는 그 도구에 별 관심이 없는 사람도 있게 마련이다. 팀은 규모가 커질 수록 사용하는 도구는 많아 지고, 담당하는 역할이 나뉘게 된다. 고로, 팀 내에 도구를 도입한다는 것은, 무관심과 동의속에서 무언가를 얻어내야 하는 쉽게 말해 나와는 목표가 다른 사람들 사이에서 내가 원하는 것을 얻어내는 과정이다.

🎤셋째로는 다른 사람도 그 도구를 잘 쓸 수 있게 만들 수 있을까?

그런데 문제는 나만 그 도구를 쓰게 되는 것이 문제가 될 수 있다.

일련의 자동화 된 시스템이라면, 한 번 구축 후에 유지보수 할 일이 없지만 만약, 지속적인 유지보수를 해줘야 하는 도구들이라면 이야기가 달라진다.

그럼, 나는 팀 내의 다른 사람에게 그 도구를 잘 쓸 수 있도록 도움을 주어야 하고 가이드를 해야 한다. 나에겐 그에 대한 책임이 있다.

그럼 내가 그렇게 할 수 있는지에 대한 부분을 생각 해야 한다.

팀 내 사람들이 찬성 했다고 해서, 도구만 도입 한다고 해결 될 문제가 아니다. 결국, 내가 A/S를 잘 해야 하고, 팀원을 위한 교육도 해야 한다는 것이다.

어떻게 생각해보면, 도구를 도입 한다는 점이 어쩌면, 개개인에게는 장기적인 손해일지도 모른다는 생각을 할 수도 있겠다.

그렇지만, 팀 내의 사람이 많아질 수록 그 도구에 관심 없는 사람과 있는 사람이 나뉘게 된다.

관심 있는 사람들이 도입한 도구에 대한 담당 그룹이 되면 된다. 그리고 도구를 많이 도입 한 사람일 수록 커뮤니케이션에 대한 스킬도 늘고, 도구에 대한 기술에 대해 잘 알게 된다.

그래서 기왕이면, 좋다고 생각 되는 도구들을 팀에 잘 정착시키는 일들을 하는 것이 개인의 개발자 경험으로써는 남는 게 많지 않을까? 싶다.

그리고, 추가적으로 쓰자면, 무분별하게 도입하는 것은 반대다. 좋다고 해서 그 모든 것들이 팀에 맞는 것은 아니기 때문이다. 그러니 적당한 도구를 도입하기 위해 고민 해보자.

👋🏻팀에 문화를 도입 하고 싶은 경우

도구를 도입하는 것과 문화 혹은 프로세스를 도입하는 것은 차이가 있다.

그 이유에 대해 말해 보고자 한다. 예시는 애자일 문화에 대한 이야기이다. 내가 속한 조직은 서비스 개발 팀이다.

결국, 일정이 개발자의 니즈에 따라 결정 되지는 않는 경우가 많다.

사업적인 이슈, 제휴적인 측면, 기획적인 측면에 따라 일정은 고정 되어 있다. 그러한 일정은 개발자가 마음대로 조율 할 수 없는 환경임을 인지하자.

올해, 팀에서 경험하고 있는 부분이다. 팀에 올해 애자일 프로세스 방식을 작게 도입하게 되었는데, 내가 속한 회사의 업무 스타일이 아니다. (모두가 원활한 목표를 위해서는 관련 된 모든 직무의 사람들의 이해가 뒷받침 되어야 하고, 이미 같이 그러한 문화에 동참하고 있어야 오해가 적지 않을까?와 같은 생각을 했다.)

어쨌거나, 작게 시작하기로 했으나, 애자일에 관련 된 부분들이 다양하긴 하지만 스프린트 도입, 데일리 스크럼, 스프린트 회고, 플래닝들에 대한 부분들을 진행하고 있다.

물론, 애자일 프로세스는 도구를 이용하여 수치를 정확하게 정량적으로 계산 할 수 있는 도구의 도움이 필수적일 수도 있지만, 사람마다 애자일 프로세스를 어떻게 보느냐?에 대한 관점이 다를 수 있다.

그런데, 애자일이 무얼까. 내가 생각 하는 애자일과 팀 내의 사람이 생각하는 애자일의 이해도가 다를 수 있고, 목표 지향점이 다를 수 있다.

내가 생각하는 애자일 프로세스는 공유 + 성장이다. 당연히, 프로덕트를 개발 하는 조직이라면, 애자일 프로세스가 정말 딱 들어 맞을 수도 있다. (내 생각이 틀렸을 수도 있다.)

그런데, 서비스 개발이라는 특성이 있는데, 아니, 회사의 특성이랄까? 😱그런 부분들이 아쉬울 때가 있다.

내가 생각하는 애자일 프로세스의 핵심은 공유, 성장이라 데일리 스크럼과 회고가 참 좋다고 생각 한다. (이게 애자일의 근본이 아닐 수 있음에 주의 하자. 난 애자일을 잘 모른다.)

팀의 사람이 적을 때는 사실, 누가 말 안해도 누가 무슨 일을 하는지 대강 알 수 있다. 그런데, 팀의 사람이 배수로 늘다 보니, 코드가 굉장히 빠르게 바뀌는데, 누가 무슨 일을 하는지 모른다.

그리고, 어떤 스펙이 왜 이렇게 바뀌었는지? 나도 모르는 사이에 바뀐다.

고로, 데일리 스크럼이 필요해졌다. 왜냐하면 공유가 잘 되어야 하기 때문이다. 공유가 안되면, 서비스는 장애가 발생 한다.

수 개월 진행하면서 느낀 점은 그랬다. 애자일 프로세스의 공유가 업무 클라이언트(기획자, 혹은 고객등)간의 공유이기도 하지만, 나는 애자일 프로세스의 공유에서 제일 중요한 점은 개발자 간의 공유가 제일 중요하다고 생각 한다.

결국, 서비스는 개발자에 의해 발전 되어 가고, 동시에 녹슬기도 한다. 그런 양날의 검 같은 이슈 사이를 건너는 개발자들이 합이 잘 맞으려면, 공유가 기본이다.

그런데, 내가 생각하는 공유는, 이 일을 하고 있다 너머의 내가 이런 이슈를 만났는데, 헤매고 있다면, 누군가에게 알리고 다른 사람들도 그런 이슈를 같이 해결 하려고 노력하는 그림을 말한다.

그리고, 생각보다 기술적인 이슈 보다 서비스 도메인 측면의 이슈가 있을 수도 있기 때문에 개발자 간의 공유가 중요하다.

이 모든 것들은 팀 내의 수준 합의가 필요하다. 어떤 문화를 도입하는 것에 대해서 모두 포용할 것인지? 아니면 작게 포용할 것인지?

문화를 도입하는 것은 행동을 변화 시키는 일이다. 결국, 누군가는 책임을 지는 역할을 분담 해야 지속적으로 행동을 변화 시킬 수 있다.

그 역할은 누군가 계속 해야 하는 것이 아니라 지정제로 혹은 원하는 누군가가 돌아가면서 해야 장점만을 누릴 수 있다.

애자일 문화 도입이든, TDD의 문화 도입이든, 결국 중요한 것은 행동을 변화 시키는 일은 굉장히 어렵고 사람마다 이해도와 목표 지향점이 다를 수 있는데, 이를 잘 협의 하는 것이 중요하다.

이런 것들을 잘 생각 해보아야 한다.

사람들의 이해도가 다를 때 어떻게 할 것인가?

사람들 개개인의 목표 지향점이 다를 때 어떻게 할 것인가?

두 물음에 답을 할 수 있을 때에 팀 내에 문화를 도입 하는 것이 좋겠다.

결론적으로 쉽지 않지만, 도전은 언제나 좋다. 🤟🏻

Google I/O '19 - puppeteer 관련 영상 정리

Mon, 14 Sep 2020 22:10:02 GMT

Modern Web Testing and Automation with Puppeteer (Google I/O ‘19)

puppeteer 성능 높이기

cosnt browser = await puppeteer.launch()

it ('', async() => {
  const context = await browser.createIncognitoBrowserContext();
  // ...
  await context.close()
})

브라우저의 새로운 시크릿 컨텍스트를 생성해서 테스팅 하는 것이 더 빠르다.

렌더링이 되기 전에 테스트를 돌리다 보면, 테스트가 실패하는 이슈가 발생하는데, 기본적인 해결책은 sleep을 넣어준다.

await page.waitFor(1000)

그런데, 이 방식은 좋지 않다.

page.waitForSelector()
page.waitForReqeust()
page.waitForResponse()
page.waitForFunction()
page.waitForNavigation()

page.waitForXX API를 사용하자.

위의 예시에서 page.waitForSelector()를 사용하면, DOM 요소가 나타날 때까지 기다리게 된다.

Geolocation 설정

page.setGeolocation({})

서비스 워커 체크도 가능하다.

await context.waitForTarget(target => {
  return target.type() === 'service_worker'
})

네트워크 모니터링

page.on('request', reqeust => {
  console.log(request.method())
})
page.on('response', response => {
  console.log(response.method())
})

그 밖에 다양한 API를 제공 한다.

Headers
POST data
Content
From cache, From service-worker

네트워크 요청 가로채기

await page.setRequestInterception(true)
page.on('request', reqeust => {
  if (request.resourceType() === 'image') {
    request.respond({ body: randomCatImage() })
  } else {
    request.continue()
  }
})

키보드/마우스

await page.keyboard.press()

성능 테스트

const metrics = await page.metrics()

await page.tracing.start({ path: './trace.json' })
// something doing
await page.tracing.stop()

코드 커버리지

page.coverage.startCSSCoverage()
page.coverage.stopCSSCoverage()
page.coverage.startJSCoverage()
page.coverage.stopJSCoverage()

Accessibility

const snapshot = await page accessiblity.snapshot()

그 밖의 툴 (use puppeteer)

그냥 저냥 #위클리뉴스 #87

Mon, 14 Sep 2020 22:10:02 GMT

💻개발자에게 도움이 되는

팀에 새로운 도구를 도입하고 싶다.

so-so님이 팀에 도구를 도입 하는 것에 대한 생각을 남겨 주셨다. 이것과는 별개로 나도 한 번 써 봐야겠다. 팀에 도구를 도입 하거나, 어떤 일련의 프로세스를 도입 하는 것에 대한 글을 나도 한 번 써 보면 좋겠다는 생각이었다.

코드숨(codesoom)을 끝내며

12주간 진행하는 코드숨 교육을 끝낸 회고에 대한 내용이며, 코드 숨 교육에 대한 커리 큘럼이 나와 있고, 어떻게 진행 하고, 프로젝트는 무엇을 했는지? 잘 남겨져 있다. (어떤 부분이 어려웠는지…새로웠던 부분들도 잘 나와 있다.)

전국에 맥도날드 주소가 어떻게 될까? | Daily Log

전국 맥도날드, 스타벅스 매장에 대한 정보를 알고자 시작 헀으나, API가 도와주지 않고, query limit에 걸려 여러 시도를 통해 스펙 타협을 통해 결론을 얻어낸 후기를 잘 담고 있다.

빌드/테스트는 내가 해줄게. 너는 코딩에 집중해 (by GitHub Pull Request Builder)

PR - Build ci를 webhook으로 연동 하는 가이드인데, 정말 스텝 바이 스텝으로 잘 나와 있다.

신규 서비스 배포 전에 실험과 개선을 반복한 이야기

마켓 컬리의 재고 관리 시스템을 개발 하며 겪은 이슈들과 해결 방안들을 정말 생생하게 엿볼 수 있어서 너무 좋았다.

🖥Front-End

TypeScript enum을 사용하지 않는 게 좋은 이유를 Tree-shaking 관점에서 소개합니다. - LINE ENGINEERING

Tree-shaking에 대한 관점에서는 생각해본 적이 없었는데, 결국 좋은 점으로는 union types를 쓰는 게 enum보다 좋다고 설명하는 글인데, 읽어보면 도움이 된다.

리액트 앱에서의 중앙 집중식 API 에러 핸들링

Error를 중앙 집중 형태로 따로 분리 내어 404, 400, 500 등등 상태 코드에 따른 핸들링을 하는 방법을 소개 하고 있다. Redux/Apollo 모두 소개를 하고 있으니 읽어 보면 도움이 된다. 사실, 그냥 지나치기 쉬운 소재이긴 한데, 사용자 친화적인 웹이 되려면, 이런 부분도 노력 해야 하지 않을까? 생각 한다.

✔ 우아한 테크러닝 3기: React & TypeScript 1회차

✔ 우아한 테크러닝 3기: React & TypeScript 2회차

✔ 우아한 테크러닝 3기: React & TypeScript 3회차

✔ 우아한 테크러닝 3기: React & TypeScript 4회차

우아한 테크러닝 4회차에 걸친 시리즈 글인데, 정말 자세하게 기록 되어 있고, 정리가 정말 잘 되어 있어서 참고 하기 좋다.

Apache httpd core dump 이야기 (Tomcat AJP연동시 깨알팁)

Wed, 09 Sep 2020 23:00:00 GMT

위 내용은 상당히 오래 전에 발생 했었습니다. 현재는 nginx를 사용하고 있습니다.

😱 어느 날 이슈가 발생했다!

[Fri Oct 27 20:12:49 2017] [notice] Apache/2.2.31 (Unix) mod_jk/1.2.41 configured -- resuming normal operations
[Fri Oct 27 20:12:49 2017] [notice] child pid 87300 exit signal Segmentation fault (11)
[Fri Oct 27 20:12:55 2017] [notice] child pid 87301 exit signal Segmentation fault (11)
[Fri Oct 27 20:13:00 2017] [notice] child pid 87302 exit signal Segmentation fault (11)
[Fri Oct 27 20:13:05 2017] [notice] child pid 87303 exit signal Segmentation fault (11)
[Fri Oct 27 20:13:10 2017] [notice] child pid 87304 exit signal Segmentation fault (11)
[Fri Oct 27 20:13:15 2017] [notice] child pid 87305 exit signal Segmentation fault (11)
[Fri Oct 27 20:13:20 2017] [notice] child pid 87306 exit signal Segmentation fault (11)
[Fri Oct 27 20:13:25 2017] [notice] child pid 87307 exit signal Segmentation fault (11)
[Fri Oct 27 20:13:30 2017] [notice] child pid 87313 exit signal Segmentation fault (11)
[Fri Oct 27 20:13:35 2017] [notice] child pid 87314 exit signal Segmentation fault (11)
[Fri Oct 27 20:13:40 2017] [notice] child pid 87315 exit signal Segmentation fault (11)
[Fri Oct 27 20:13:45 2017] [notice] child pid 87316 exit signal Segmentation fault (11)
[Fri Oct 27 20:13:50 2017] [notice] child pid 87317 exit signal Segmentation fault (11)
[Fri Oct 27 20:13:55 2017] [notice] child pid 87319 exit signal Segmentation fault (11)
[Fri Oct 27 20:14:00 2017] [notice] child pid 87320 exit signal Segmentation fault (11)
[Fri Oct 27 20:14:05 2017] [notice] child pid 87321 exit signal Segmentation fault (11)
[Fri Oct 27 20:14:10 2017] [notice] child pid 87322 exit signal Segmentation fault (11)
[Fri Oct 27 20:14:15 2017] [notice] child pid 87323 exit signal Segmentation fault (11)
[Fri Oct 27 20:14:20 2017] [notice] child pid 87324 exit signal Segmentation fault (11)
[Fri Oct 27 20:14:25 2017] [notice] child pid 87325 exit signal Segmentation fault (11)
[Fri Oct 27 20:14:30 2017] [notice] child pid 87331 exit signal Segmentation fault (11)

원인은 모르지만, apache process가 정상적으로 로드 된 이후 child process를 만든 뒤에 child process가 어떤 이유인지 모르게 자꾸 죽어 버리는 현상이 발생한다.

apache core dump 설정

참고

Apache Software Foundation

Apache CoreDump

How to get a core dump from apache when segfaulting

# 루트 권한 계정
$ cat /proc/sys/kernel/core_pattern
core
$ sudo /sbin/sysctl -w fs.suid_dumpable=2
$ sudo /sbin/sysctl -w kernel.core_pattern=/var/tmp/core-%e.%p
kernel.core_pattern = /var/tmp/core-%e.%p
$ cat /proc/sys/kernel/core_pattern
/var/tmp/core-%e.%p

# 일반 계정
$ ulimit -c unlimited
$ ulimit -c
unlimited

gbd라는 툴이 필요로 한데, 해당 툴을 설치하는 방법은 리눅스 OS마다 상이합니다.

http://www.gdbtutorial.com/tutorial/how-install-gdb

🛠 코어 덤프 파일을 gbd로 분석

#0  0x00007f03cd74bf04 in jk_shm_check_maintain () from /seungdols/apache/modules/mod_jk.so
Missing separate debuginfos, use: debuginfo-install apr-1.4.8-3.el7.x86_64 apr-util-1.5.2-6.el7.x86_64 cyrus-sasl-lib-2.1.26-20.el7_2.x86_64 expat-2.1.0-10.el7_3.x86_64 glibc-2.17-196.el7.x86_64 libcom_err-1.42.9-9.el7.x86_64 libdb-5.3.21-19.el7.x86_64 libgcc-4.8.5-11.el7.x86_64 libidn-1.28-4.el7.x86_64 libselinux-2.5-6.el7.x86_64 libssh2-1.4.3-10.el7_2.1.x86_64 libstdc++-4.8.5-11.el7.x86_64 libuuid-2.23.2-33.el7_3.2.x86_64 ~~ 일부 생략 ~~ openssl-libs-1.0.2k-8.el7.x86_64 openssl098e-0.9.8e-29.el7.centos.3.x86_64 pcre-8.32-15.el7_2.1.x86_64 zlib-1.2.7-17.el7.x86_64
(gdb) bt
#0  0x00007f03cd74bf04 in jk_shm_check_maintain () from /seungdols/apache/modules/mod_jk.so
#1  0x00007f03cd735d30 in wc_maintain () from /seungdols/apache/modules/mod_jk.so
#2  0x00007f03cd724560 in jk_handler () from /seungdols/apache/modules/mod_jk.so
#3  0x000000000043fc50 in ap_run_handler ()
#4  0x00000000004405a7 in ap_invoke_handler ()
#5  0x00000000004510d6 in ap_process_request ()
#6  0x000000000044df8d in ap_process_http_connection ()
#7  0x00000000004491dc in ap_run_process_connection ()
#8  0x0000000000449678 in ap_process_connection ()
#9  0x0000000000458126 in child_main ()
#10 0x00000000004582e4 in make_child ()
#11 0x0000000000458355 in startup_children ()
#12 0x0000000000458829 in ap_mpm_run ()
#13 0x0000000000425d77 in main ()

정확하게 분석을 한건 아니지만, back trace를 통해 어디서 문제가 발생했는지는 알 수 있었습니다.

즉, 부모 프로세스가 정상적으로 로딩은 되었고, httpd.conf 파일에 명시된 초기 mpm을 실행하는데, 초기 갯수는 httpd.conf 설정한 값의 수 만큼 child process가 생성 됩니다.

이로 인하여 어떤 문제인지 추적 할 수 있게 됩니다. 그런데, 쉽지는 않기 때문에 기왕이면 이렇게 분석할 일이 없는게 정말 좋습니다.

깨알 Tip

1. Apache - Tomcat instance load balancer 설정시 host ip를 꼭 넣어주자.

추가적으로 팁을 하나 넣자면, 같은 서버 내에서 Apache - Tomcat instance를 Load Balancing 할때, 설정 파일에 worker process의 host ip를 명시적으로 넣어 주는 게 좋습니다.

특히, mod_ssl을 사용 하지 않고, Apache - Tomcat instance load balancer를 설정 하려면, workers-lb.properties 파일 내에 worker.tomcat1.host=127.0.0.1로 설정을 해주어야 한다. tomcat2가 있다면, 똑같이 설정 해야 한다. (만약 다른 서버에 있다면, 다른 서버 ip를 기입해야 한다.)

이유는 mod_jk 쪽에서 메모리를 해제하고 다시 생성하는 때에 host정보를 얻어 오는 데에 대한 Crash가 발생하면서 일어나는 문제가 발생 할 가능성이 있다.

2. AJP 보안 이슈

최근 Apache Tomcat의 원격코드실행 취약점(CVE-2020-1938)을 악용할 수 있는 개념증명코드(Proof of concept code, PoC)가 인터넷상에 공개되어 사용자의 보안 강화 필요하다.

참고 - https://www.krcert.or.kr/data/secNoticeView.do?bulletinwritingsequence=35292

버전 업데이트를 해서 처리 할 수 있다.
Tomcat 설정인 server.xml에 Connector 설정에서 requiredSecret 혹은 secret을 설정 하여 해결 하는 방법도 있다.

https://tomcat.apache.org/tomcat-8.5-doc/config/ajp.html
AJP 기능이 불필요한 경우 Connector 비활성화 주석 처리 하면 된다.

BFF가 뭘까?

Wed, 09 Sep 2020 22:00:00 GMT

본문 내의 이미지는 모두 참고 출처의 이미지를 사용하였습니다.

Backend for Front-end의 약자로, 일종의 아키텍처 패턴입니다.

환경적, 시스템적인 Monolithic 구조를 쓰다 이제는 SPA, MSA 시대에 도래 했다.

Back-End와 Front-End의 통합된 단일 구조를 쓰다가, 이제는 두 영역이 분리 되어 서버가 각각 올라가기도 하고, 분리의 시대가 되었다.

통합된 API를 쓰다가 영역별로 쪼개어진 API를 사용 하는 시대가 되었기도 하다. 결국 통합에서 분리의 미학으로 관심사가 이동되었다.

다수의 페이지를 보던 환경에서 단일 페이지내에서 다중 컨텐츠의 영역으로 바뀌었다. (이는 아무래도 모바일의 영향이 아닐까 한다.)

위와 같은 구조를 쓰다보니 문제가 생겼는데, API를 어떻게 관리 해야 할지 애매한 부분이 생겼다. 각 End-point에서 사용하는 API를 관리하기가 어려워졌다.

위와 같은 구조를 또 만들게 되었다. 그런데, 웹만 있는게 아니고 다른 기기도 있다. 쉽게 말해 EndPoint가 다양하다.

위처럼 하다보니 생각보다 통합한 API를 쓰는게 불편한 문제가 발생한다. API 배포가 중요해진다. Public API 영역이 단일 장애 포인트가 된다. 위와 같은 경우를 API Gateway라고도 부르기도 한다.

그리하여 각각의 End-point를 위한 Backend가 중간 매개 서버로 등장하게 되었다.

참고 문서를 보면 여러가지 다양한 용어와 구조가 나오는데, 사실 용어 차이이기도 하고, 어떤 구조가 정답이라고는 애매하다.

사실 환경에 맞는 시스템 구조를 만들어가는 게 중요하지, 그림이 중요한게 아니다.

위의 그림도 정답이라고는 할 수 없다. 어떠한 아키텍처든지 자신의 서비스, 환경에 따라 이렇게도 저렇게도 하는것이지 사실, BFF패턴의 주요 관심사는 EndPoint를 위한 중간 서버 혹은 시스템의 개념으로 이해하면 좋겠다.

ref.

그냥 저냥 #위클리뉴스 #86

Mon, 07 Sep 2020 20:09:48 GMT

🖥개발자에게 도움이 되는

[마틴 파울러] 소프트웨어 아키텍쳐의 중요성 (한글 자막)

영상을 보면서 결국 중요한 것은 장기전인 관점이다. 내부 품질과 외부 품질, 그리고 프로젝트를 진행하는 사람들 사이의 공유, 그리고 확립된 스펙정의서 이 모든 것이 소프트웨어의 전부이구나 싶었다.

월간 개발자스럽다 #58

월간 개발자스럽다 8월호인데, 8월간의 글타래들이 모여있다. 만약, 놓친 글들이 있다면, 읽어보자.

(긴글주의) 좌충우돌 Mazassumnida 개발기

방학 때임에도 열심히 개발 작업을 하신 분의 경험 후기인데, 읽어보면 재밌고, SVG의 다채로움에 매료 될 수 있어서 좋았다. 👍🏻

캐시 성능 향상기 (Improving Cache Speed at Scale) : TOAST Meetup

redis 캐시 성능 향상에 대한 영상을 보고 정리 해주셨는데, 정말 쉽고 자세하게 남겨 주셨다. (debouce를 도입 하는 건 정말 새로웠다.)

데이터 아키텍처의 변화

데이터 아키텍처에 변화를 이해하기 쉽게 표현 하고 있다. 그런데, AWS기반이라 다소 좀 아쉬운 부분은 AWS를 안쓰는 경우가 조금 궁금 했다.

시니어 개발자처럼 VSCode 사용하기

유용한 기능 소개와 스니펫 사용법을 알려주는데, 굉장한 도움이 된다. 스니펫을 열심히 써봐야겠다.

💻Front-End

2020-08-31: Firefox 80, D3.js 6.0.0, Chrome 85, Puppeteer & Playwright

정말 다양하고 양질의 JavaScript관련 글들을소개 하고 있다. 특히,puppeteer, playwright를 위한 root-cause라는 프레임워크가 새로 태어났는데, 문서가 아직 없어서 좀 아쉽긴 했다. 그 외 문서도 참고해보면 좋겠다.

개츠비 프리로딩과 프리패치

프리패치, 프리로딩 그리고 개츠비에서는 무엇을 사용하는지 상세하게 설명 하고 있다.

개츠비의 이미지 처리 방식

개츠비에서 이미지를 어떻게 처리 하는지에 대한 설명이 자세하게 수록 되어 있다.

NAVER D2

wasm에 대해 자세하게 소개하는 글이다. 관련된 아티클은 링크도 추가 되어 있어서 관심이 있다면, 따라가며 읽어 보는 것도 좋아보인다.

🛠Tool

Vimac - 키보드로만 macOS 사용하기 | GeekNews

Vimium은 크롬 확장 플러그인으로 크롬 안에서 vi editor처럼 쓸 수 있게 해준다. 그런데, 위의 앱은 맥 전체에서 vi 처럼 쓸 수 있도록 해준다. (상당히 퀄리티가 높다.)

🙌🏻일반적인

어도비 플래시, 엣지 브라우저에서도 “굿바이”

어도비 플래시가 이제는 엣지에서도 사용할 수 없게 된다. 기억 속의 뒤안길로 사라지는 기술이 되었다. 마시로마로와 졸라맨등 한때는 정말 재밌었던 기억이 있었다. 그때는 아마 이렇게 JavaScript가 대인기가 된다고는 몰랐겠지?

렘수면이 짧으면 수명도 짧아진다?

수면의 단계는 렘수면과 논렘수면의 스위칭으로 반복 되며 수면을 취하게 되는데, 논렘수면의 단계가 길어야 몸의 Refresh가 되며, 뇌의 세포에도 영향을 미친다. 그렇게 자세한 글은 아니지만, 결국 건강이 좋아지는 방법은 잠을 잘 자는 것이고, 잠을 잘 자려면, 건강 해야 한다…? 특히, 정신적인 평온함이 있어야 한다고 한다. 잠들기 전에 꼭!!! 핸드폰을 멀리하고 짧게라도 명상을 하고 잠들자. 혹은 책을 읽자!

경청의 수준을 3단계로 나눠보았다

점점 더 경청의 태도가 중요한 세상이 되었다. 사람들은 만나서 보통 각자 휴대폰을 하는 시간이 있을때가 있는데, 이럴때가 나는 굉장히 괴롭다. 누군가를 만나서도 휴대폰을 봐야 한다니…😂 결국, 점점 시대는 휴대폰 안에 있는 것 같다.

그냥 저냥 #위클리뉴스 #85

Sun, 23 Aug 2020 21:08:16 GMT

🖥개발자에게 도움이 되는

삽질하는 멍개씨 : 네이버 블로그

문서화에 대한 2가지의 툴(Sphinx, apidoc) 을 소개하고, 활용하는 방법에 대해 소개 하고 있다. apidoc은 실제로 쓰고 있는데, 생각보다 깔끔하고 좋다. node.js에서 미들웨어를 express 대신 koa를 쓴다면, swagger 모듈을 쓰기가 번잡 해진다.

우아한테크캠프 인턴들의 7월의 회고 - 우아한형제들 기술 블로그

우아한 테크 캠프 인턴분들의 생생한 후기를 볼 수 있었고, 한 때의 열정 가득 했던 순간이 생각 나게 하는 글이었다.

기술 뉴스 #156 : 20-08-15 :: Outsider’s Dev Story

다양한 주제에 대한 글들이 많이 있고, 제일 관심 많은 부분은 Rome이라는 FE 툴체인이 공개 되었는데, 정식으로 사용 하려면 어떻게 해야 하는지 알아봐야 할 것 같다. (툴이 왜 이렇게 많이.. 빨리 나오는 것인가..😂)

Lifehacks

요즘 이 책을 많이 보시는 것 같은데, 나는 파이썬을 정말 필요할 때만 쓰는 사람이라, 아직 엄두가 나진 않지만, 파이썬을 주류로 하시는 분들은 이 책을 읽으시면 도움이 되지 않을까? (나도 사보고 싶긴 하다.)

내 맘대로 위클리 뉴스 - 2020년 33주(2020.8.9 - 2020.8.15)

내 맘대로 위클리 뉴스 지난 주에 올라왔는데, 사실 늦게 보긴 했지만, 좋은 내용이 많았다. Redis 대기열 처리 글, NodeJS 의 Promise에 관한 글 시간 날 때 읽어보면 도움이 확실히 크게 된다.

💻FE

yeonjuan/dev-blog

JavaScript의 null vs undefined 반환에 대한 고민인데, 참신하기도 하고, 내용이 알차서 좋다.

naver/fe-news

네이버 FE 뉴스 8월 FE 관련 글 모음입니다. 유용한 툴 소개부터, 다양한 주제에 대해 소개 하고 있어 관심 가질 만한 소재가 많습니다.

React 컴포넌트를 커스텀 훅으로 제공하기 - LINE ENGINEERING

React Custom Hook을 소개 하기 위해서 예로 Check List를 이용해 Custom Hook을 이용하면 컴포넌트 비대를 완화 할 수 있는지 소개 하고 있다.

헐레 벌떡 nginx rewrite, redirect 써보기

Thu, 13 Aug 2020 22:40:00 GMT

원래는 긴급하게 작업을 해야 할 이유가 거의 없긴 하지만, 갑자기 오늘 불현듯이 인프라 설정을 바꿔야 했는데, 그 이유는 현재 서비스 중인 프로젝트의 플랫폼이 레거시와 2년전의 신규 플랫폼, 다시 최신의 플랫폼 총 3가지를 쓰고 있는데, 아무래도 서비스가 워낙 많고, 플랫폼 전환 하려면, 일정을 받아야 하는데, 그게 마음대로 쉽지 않다 보니 2년전의 플랫폼도 어느새 레거시가 되었다.

그런 작업을 계속 해오고 있는데, 오늘 작은 실수를 발견 하게 되어, 긴급하게 처리를 하게 되었다.

그 처리는 특정한 uri path로 접근을 하지 못하게 막거나? 아니면, 정상적인 경로로 이동 시켜야 하는 일이었다.

사실, nginx에서는 그게 그렇게 어렵진 않은데, 중요한 부분은 nginx를 빌드 하여 사용하는 경우 기본 모듈에 rewrite가 없고, rewrite 모듈을 사용하려면, 해당 모듈에서 참조하는 pcre 의존 모듈이 필수적으로 필요하니, 꼭 참고 해야 한다. (nginx-rewrite)

중요한건 사실 uri path가 그렇게 어렵진 않은데, 순간적으로 당황하고, 뭔가 요즘 들어 항상 루즈한 루틴에 살았는데, 갑작스레 긴박함 + 재미가 있었다. (팀원들 여러명이 이렇게 하는 게 좋겠다. 저렇게 하는게 좋겠다. 하는 이야기를 자주 하는데, 그런 재미가 긴박할 수록 더 재미나고, 성장을 하게 만든다.)

문제는 위에서도 말했다시피, 단순한 경로 실수인데, 이를 고치기 위해 처리 하는 방법은 총 세가지다.

특정 패턴에 맞춰서 해당 경로의 요청이 오면, 404 not found를 리턴 한다. (사용자는 에러 페이지를 보게 된다.)
경로가 잘못 되었더라도, 정상적인 경로로 rewrite해준다.
경로가 잘못 되었으니, 정상적인 경로로 redirect한다.

우리는 1번을 처음에 말하고 있었지만, 그럼에도 불구하고, 서비스 개발자는 사용자 친화적이어야 하고, 친절함을 베푸는 것이 좋다고 팀장님이 말씀하셨고, 우리는 2번, 3번으로 방향을 전환했다.

2번의 방법으로 해결 한다고 생각 하자. 예시는 다음과 같다.

문제의 경로

사용자가 http://seungdols.dev/new-board/1로 인입을 하면 안된다고 해보자. (정상적인 경로는 /board/:boardNumber로
- 즉, new-board/:boardNumber의 경로로 오게 된다. 이 경로를 막고 원래 페이지로 보내보자.

rewrite의 해결 방법

rewrite regex replacement [flag];

위의 형식으로 작성을 하면 된다. 해당 구문이 나올 수 있는 곳은 server, location, if 구문 안에서 나올 수 있다.

플래그는 아래와 같다.

last
- 현재 블록 안에서 rewrite 작업을 하고, 다음 작업 처리를 진행 한다.
breeak
- 현재 블록 안에서 rewrite 작업을 한 뒤에, 처리를 종료 한다. 하지만, rewrite 다음에 rewrite가 아닌 다른 작업까지는 실행 한다. (무한 반복 실행을 방지함.)
redirect
- 302 temporary redirect를 하게 된다.
permanent
- 301 permanent redirect를 하게 된다.

사실 위의 플래그를 잘 모르고, 처음에 아래와 같이 작성 했었다.

사실 break는 대충 감으로 넣었는데, 막상 다시 집에 돌아와 보니 flag만 바꿔도 되는건데 착각 했다.

이 부분은 밑에서 다시 토로 하도록 하겠다!

해결은 아래와 같이 했다.

rewrite ^/new-board/(.*)$ /board/$1 break;

위 처럼 하게 되면, 사용자가 다음과 같이 접속 해도, 정상적인 페이지가 나온다. 하지만, 문제는 uri path가 잘못된 경로인데, 여전히 그대로 남아있게 된다. 이는 잘못된 주소를 계속 인입 하게 만드는 경향 있다.

그래서 rediect하는 방법으로 정했는데, 왜 flag를 제대로 못봤을까? ㅠㅠ 그래서 아래 방법으로 처리 했다.

location redirect의 방법

location ~ regex pattern {
  return [redirect code] redirect path;
}

위와 같이 작성하면 되는데, redirect code는 301, 302로 하면 된다.

301과 302의 차이는 브라우저 캐싱을 하는지? 안하는지?의 차이이다. 선택적으로 하면 되는데, 나는 302로 결정 하고, 아래와 같이 해결 했다.

location ~ ^/new-board/(.*)$ {
  return 302 $scheme://$host/board/$1;
}

위 처럼 작성 해서 해결 했는데, 사실 위의 rewrite의 flag만 제대로 봤어도, flag만 보고 해결 했을 텐데 좀 아쉬웠다.

그래도 이렇게 기억에 남아서 정리를 하게 되었다.

역시 공부를 해야 되는 구나 싶었다. 물론, 이렇게 또 한번 공부 하게 되었다.

간만에 그래도 재밌게 긴급하게 처리 했다.

참고

https://www.journaldev.com/26864/nginx-rewrite-url-rules

그냥 저냥 #위클리뉴스 #84

Mon, 03 Aug 2020 23:08:04 GMT

💻For Developers

‘웹 크롤러’ 좀 그만 만들어라

웹 크롤러에 대한 명확한 기준을 제시하고 있는데, 이 글이 트위터에서 핫했는데, 특유의 문체 때문이지 않을까? 싶다. 사실 글의 내용으로는 맞는 말이 있는데, 또 너무 과격한 표현이 문제이지 않을까? 생각 하다가도, 어떤 이들은 이런 문체의 글을 좋아하겠다 생각 했다.

해외취업 후기 1. 프롤로그

해외 취업에 대한 계기와 준비 과정 실제 인터뷰 진행한 후기를 정말 자세하게 알 수 있다.

Google Coding Interview ｜구글 신입 엔지니어 인터뷰 준비 후기

Google’s Foobar Coding Challenge ｜구글 푸바 챌린지 후기

원래 위의 구글 엔지니어 인터뷰 준비 후기를 보다가 푸바 챌린지를 통해 인터뷰를 보게 되셨다고 하셔서, 그에 대한 관련 글도 같이 가져왔는데, 해외 취업이나 구글 취업에 관심이 많으신 분들이라면, 흥미롭게 읽을 수 있고 도움이 되는 부분들이 많으니까 꼭 읽어 보기를 추천 한다.

카카오 개발자가 카카오스럽게 일하는 방법 - 애자일코치파트

카카오가 카카오스럽게 일 하기 위해 최근 애자일 코치 파트를 신설 했다고 하는데, 목표와 어떻게 운영 되고 있는지 나와 있다! 그런데, "이렇게 하고 있다"에 대한 핵심이 약간 없는 느낌이라 아쉬웠다.

흔들리는 도커(Docker)의 위상: OCI와 CRI 중심으로 재편되는 컨테이너 생태계

도커가 컨테이너 계의 표준으로 자리를 잡아 왔으나, 현재 컨테이너 생태계는 도커를 대체 하려는 움직임을 보이고 있는데, 이에 대한 이유와 대안으로 나온 기술들에 대해 설명 하고 있다.

🖥Back-End(Java)

[Java] Comparable vs Comparator 비교

두 인터페이스의 사용과 예시 그리고 무엇이 다른지에 대해 상세하게 소개 하고 있으며, 더 나아가 흔히 잘 모를만한 정보를 자세하게 설명하고 있다.

System.console() vs. System.out | Baeldung

Java에서 출력에 대한 두 가지인 System.console()과 System.out 두 차이에 대해 설명 하고 있다. 그렇게 어렵지 않은 내용이라 이해가 쉽게 쓰여 있다.

🖥Front-End(JavaScript)

Google JavaScript Technical Interview

Google JavaScript 기술 인터뷰인데, 일단 가장 관건은 Callback과 Promise에 대한 확실한 개념 이해?! 중요한 것 같다. 보다 보니 나는 정말 얕게 알고 있구나 싶었다. 더불어 Async/Await 에 대한 깊은 이해…가 중요하다.

Use ternaries rather than && in JSX

&& 보다 삼항 연산자를 사용하라는 글인데, 왜 삼항 연산자가 더 좋은지 설명하고 있다.

deno 첫 외주 후기

Rust 프로젝트의 SWC에 대한 수정 외주를 받아 해당 작업을 진행한 후기를 남겨 주셨는데, Rust는 잘 모르기도 하고, Deno에 대해서도 대충 컨셉만 아는 터라 좀 신기하기도 하면서 재밌게 읽었다. 근데, 정말 대단한건, 개인 오픈 소스 프로젝트신데 스타수가 8700개를 받은 프로젝트이다. (부럽다…)

웹페이지 다크 모드 지원하기

웹 페이지 다크 모드를 정말 손쉽게 적용 하는 방법에 대해 소개 하고 있다.

Use Chrome DevTools Like a Senior Frontend Developer

개발자 도구에 대한 정말 다양한 꿀 기능들을 소개 하고 있는 글인데, replay XHR 기능은 정말 대박이다. 이걸 왜 몰랐을까!!!

🖱Tool

Next.js 9.5

next.js 자체에 redirect, rewrite가 가능해지고, bundle이 ID기반에서 Content Hash기반으로 바뀌게 되어, 좀 더 나은 캐싱 전략으로 향상 되었다고 한다. 추가적으로 운영 환경의 React Profile도 지원 된다. webpack5 도 beta 모드로 지원 한다. Optional Catch All routes도 좀 더 유연하게 개선 되었다고 하는데, 실제로 써본 적이 없어서 잘 모르겠다.

🙌🏻 일반적인

‘아주 사소한 불편’을 해결해 ‘큰 트래픽’을 만들어낸 사이트 ①

인스타 공백 넣기등 불편함을 아주 획기적으로 수정하여, 사람들이 많이 찾는 서비스가 된 3가지를 소개 하고 있다. 이런게 정말 아이디어라고 생각 한다.

그냥 저냥 #위클리뉴스 #83

Mon, 27 Jul 2020 20:07:07 GMT

👍🏻 개발자에게 도움이 되는

온라인 코드 리뷰에 대해서

온라인 코드 리뷰와 더불어서 같이 하면 좋은 것이 오프라인 코드 리뷰인데, 이는 굉장히 리뷰 하기 까다롭고, 양이 많은 경우 퀵하게 오프라인으로 하는 방법이 좋다. 그런데, 대다수 바쁜 시간을 할애 해야 하므로, 온라인 코드 리뷰가 제일 좋다고 생각하고, PR에 올라온 코드를 온라인으로 설명하고, 허점은 없는지 다 같이 찾는 것도 팀내에서 가끔 있는 일이다. (데일리 스크럼 끝나고 잠시 온라인 코드 리뷰 하는 것도 좋겠다.)

서버에 걸리는 부하, 추측하지 말고 계측하자

서버 부하에 대해 자세하고, 깊게 알아볼 수 있는 글이다. 더불어서 top/sar 명령어를 통해 나타나는 지표들을 통해 서버 커널에서의 프로세스 부하를 설명 하고 있다.

데이터 분석가의 재능과 능력치

재능과 능력에 대한 그 애매모함이 가끔은 개발자들을 괴롭히는데, 데이터 분석가의 관점에서의 재능과 능력에 관한 이야기도 비슷한 맥락이라 가져왔다.

💻Front-End(JavaScript)

NAVER D2

레거시와 신규 플랫폼을 어떻게 서비스에 노출 시키는지 잘 나와 있는데, React SSR 적용보다 실무에서 어떻게 레거시 시스템과 신규 시스템을 운용하는지를 보면, 신입 개발자에게 도움이 많이 된다.

깊은 복사와 얕은 복사에 대한 심도있는 이야기

깊은 복사와 얕은 복사에 대해 깊이 있는 글로 JS와 JSON에 대한 스펙 이야기, 이유와 대안까지 자세하게 설명하고 있다.

이벤트 핸들러를 대하는 개발자의 자세

이벤트 핸들러의 명확한 네이밍을 잘 정하는 것부터가 정말 중요하다고 생각 한다. (기왕이면, 팀내에 코드 네이밍 룰을 정하는 것도 방법이 아닐까? 생각 한다.)

코드스피츠 88 - async await #1/2

Async / Await의 기본이 되는 Sync flow / Non-Blocking에 대하여 자세하게 학습 할 수 있다. 물론, JS는 기본적으로 알아야 이해할 수 있다.

아무것도 모르고, 아무것도 안 하는 것의 힘

결국 지식을 쌓아 지혜로 승화시키는 것은 얼마나 어려운 일인가. 누구나 투자가가 될 수 있으나, 워렌 버핏은 될 수 없는 이유는 지혜로움의 유무이지 않을까? 싶다.

말투에도 쿨톤·웜톤이 있다?

결국, 일 할때는 쿨톤, 그 외에는 웜톤 말투를 쓰는게 좋아보이는데, 쉽지 않은 이유가 말투는 습관이고, 바꾸기가 어렵다. 그리고 정답도 없다.

성공적인 나이 듦과 실패한 나이 듦

나이듦을 준비 하는 것도 중요하겠다는 생각이 들었는데, 소개한 책을 읽어보면 도움이 좀 될까?

그냥 저냥 #위클리뉴스 #82

Mon, 13 Jul 2020 23:07:17 GMT

🙌🏻개발자가 읽으면

그 때 성장이라고 생각했던 것들

이 글을 읽는 나 조차도 뼈를 퍽퍽 맞았으니, 다들 읽고 뼈 맞고, 제대로 공부 하는 방법으로 나아가면 좋겠다. (물론, 나의 블로그에 접속 하여 이 글을 보는 독자 또한 나랑 같이 뼈 맞는다에 나의 왼손 터널 증후군을 걸겠다.) 근데, 너무 뼈 맞지 않아도 된다. 일일 커밋 하는 게 어디인가? 나처럼 귀찮아 하는 사람은 다음 다음생정도에나 가능한 행위이다. 알고리즘 푸는게 어디인가? 풀다 보면 이직이 쉬워진다. 지식쇼핑 하는게 어디인가? 나는 퇴근 후 넷플릭스만 본다. 모두 정답은 없다. 다만, 중요한 건 내가 했던 행위들은 나만의 언어로 이해하고, 체화 하여, 그 정보가 지식이 되어 남에게 다시 전달 가능한 순간이 언젠간 온다. 애플의 아버지가 말 했지. 연결 된 점을 이으면 그게 인생이라 했다. 뼈 맞고 위안을 해본다.

내 맘대로 위클리 뉴스 - 2020년 26주(2020.6.21 - 2020.6.27)

Kotlin + Spring boot로 REST API 개발 하는 글, JAVA 15에 추가 된 기능 소개 글이 나에겐 제일 좋고, 다른 APP, JS, Python 관련 글도 좋다! (APP은 내가 몰라서 못 읽는다.)

[B급 프로그래머] 7월 2주 소식(개발/관리도구, 고성능 서버/데이터베이스 부문)

이번 큐레이션에서는 제일 좋은 건 서비큐라님의 MacOS 셋팅 개정판이다. (소리 질럿!) / 그 외 다수의 아티클들이 있는데, 알짜 가득하다.

💻Java

Optional ofNullable() method (With Examples) | Java Code Geeks - 2020

ofNullable() 함수에 대한 설명인데, 내부 구현 코드 예시가 나오는데, T가 List로 넘어오면, EmptyList 해줘야 하는거 아닌가..?!!??! 아마 오버로딩 하지 않았을까? 하는 추측 (IDEA 실행하기 귀찮다.) 근데 가만 보면, Optional 쓸 때, isPresent() 쓰지 않으면서 유연하게 함수형 function과 default value로 처리를 하고 싶은데, 막상 실무 코드에서 유지보수 하면서 넣는 건 너무 어렵다.

Convert an Array of Primitives to a List | Baeldung

Primitive Array to List로 변환 하는 방법 여러가지를 소개 한다. Java 코딩을 안 하다 보니 몰랐던 함수를 알게 되어 가져왔다. .boxed() 처음 봤다. 역시, 이것 저것 해봐야 늘게 된다.

🖥JavaScript

Learn Next.js - A free video course on React and Next.js.

next.js를 배울 수 있는 영상이 무료로 유투브로 올라가 있다. 다 보진 못했지만, 차근 차근 알려준다. 영알못도 가능하다!

Rush

Rush는 monorepo 관리를 도와주는 도구이다. 사실 써 봐야 알 것 같은데, 지금은 딱히 뭐가 좋은지는 잘 모르겠다. (장점은 MS가 개발했다.) 장점은 엄청 많다. NPM이랑 쿵짝이 잘 맞는다는 점..(JS가 적합해보임)

👋🏻 일반적인

우린 이제 그만 만나겠구나: 인연의 유통기한에 대하여

인연에 대한 고민이 든다면, 이 글을 읽어보면 좋겠다. 인연의 유통기한은 서로의 상호작용이 한 쪽에서만 끝나도 끝나는 거다. 그게 연인이든, 친구든, 지인이든.

차가운 사수와 일하는 법: 머리는 차갑게, 가슴은 더 차갑게

내 사수 왜 이렇게 차갑지? 뭘 배울 수 있을까? 고민스러울때 읽어 보자.

그냥 저냥 #위클리뉴스 #81

Mon, 06 Jul 2020 22:07:18 GMT

💻 개발자에게 도움이 되는

Teach Yourself Computer Science

프로그래밍 분야별로 좋은 책과 좋은 온라인 강의를 추천 해주는데, 멧돼지 책은 하도 유명해서 다 읽어보셨을 것 같다. (몇 달째 멧돼지 책 페이지가 안 넘어가고 있는 중이다.)

What is FinOps? - FinOps Foundation

DevOps 개념을 실체화 하여 운영하는 것은 SRE였는데, 이제는 FinOps로 가는 길인가보다. 사실 뭔가 했는데, 이제는 클라우드 운영 모델이라는 것을 FinOps라고 한다.

The end of the Redis adventure

Redis의 메인테이너가 메인 테이너에서 물러나고, Redis 커뮤니티에 의해 Redis를 개발하도록 물러난다고 한다. 아무래도, 오랜 시간 Redis를 유지보수 하는 일이 마냥 재밌기만 한 일은 아니였다고 한다. 개발을 좋아하는 사람이지, 유지보수만 할 생각은 없다고 한다. 역시, 참 개발자다.

Passion is like genius; a miracle.

코드 읽기에 관한 노하우를 전수하고 있는데, 이게 진짜 중요한 내용이라 생각 한다. 시니어 엔지니어가 주니어엔지니어에게 전해 줄 수 있는 최고의 방법이라 생각한다. (일종의 스팀팩 수준) 꼭, 기억해두자. 사수에게 어떤 식으로 해당 시스템을 이해 했는지 물어보자.

[IT 개발자와 일할 때 필요한 모든 개발지식] A to Z 자료 모음집 By 그랩

비개발자가 개발자와 소통 하기 위해 알면 좋을 내용 모음이다. 해당 내용을 기획자, 디자이너, 프로젝트 매니저 혹은 프로덕트 매니저가 알아두면 좋겠다.

기술 뉴스 #153 : 20-07-04 :: Outsider’s Dev Story

fetch mocking을 그만 하라는 글이 있는데, 참 유익했다. 그래서 기억이 많이 남는데, 다른 글들도 유용하니 읽어보면 좋은데, 내가 지식이 짧다보니 읽어봐도 뇌리에 각인이 잘 안되었다.

🐋Container

모두의 쿠버네티스 (Kubernetes for everyone)

도커와 쿠버네티스에 대한 핵심 개념을 빠르게 배울 수 있다.

🖥Front-End

naver/fe-news

Front-End에 대한 다양한 글이 모여 있는데, 특히 127개의 유용한 JavaScript 코드 조각 모음이 가장 실용성이 좋았고, 애니메이션, React Hook MVVM 시리즈는 이해하긴 어렵지만 유익 했다.

tsconfig 컴파일 옵션 정리

TypeScript를 적용 하려면, tsconfig가 필수인데, 해당 설정에 대한 옵션을 한국어로 모두 번역 및 정리 해주셨다. 정말 보기 편하다.

더 로드 투 런 리액트 (The Road to React 한국어)

Robin Wieruch가 리액트 학습에 대한 책을 두번째로 만들어 배포 하고 있으며, 무료로도 구입 가능하다. 그리고, 개발자분들이 한국어로 번역도 해주셨다. (다음엔 꼭, 번역 참여를 해야겠다.)

그냥 저냥 #위클리뉴스 #80

Tue, 23 Jun 2020 21:06:08 GMT

💻JavaScript

typescript-cheatsheets/react-typescript-cheatsheet

React + TypeScript에 대한 치트 시트인데, 좋은 내용들이 정말 잘 정리 되어 있다. 나도 요즘 틈틈히 보면서 setup 하는 부분을 좀 공부 하고 있다. setup이 제일 어렵다. 이젠 TS로 개발 안하는 곳이 없는 것 같다.

Front-End Dev Tools For increased Productivity

FE개발자가 알아두면 생산성이 좋을 툴 소개 글인데, 나는 Easings의 툴을 자주 쓰게 되었다. 요즘들어 스르륵 하는 애니메이션을 너무 좋아한다. browserhacks 이 툴 같은 경우는 브라우저 별로 css/js를 간단하게 체크 하는 툴인데, 좋아보인다. 그외 다양한 툴들이 소개 되고 있다. Neumorphism 같은 경우는 좀 어려운데, 이 부분은 구현하고자 한다면, 상세하게 찾아 보아야 한다는 생각이 들었다.

👋🏻일반적인

한계를 넘는 가장 쉬운 방법은 관점을 바꾸는 것이다

한 가지일만 하는 것이 아닌 여러 가지 일을 하고 싶거나? 하고 있는데, 의문이 든다면 읽어보면 좋을 글이다.

“너의 에너지는 너를 위해 써” 절대 사람을 피해 이직하지 마라

지금 있는 조직에서 불만이 있거나? 회사를 옮기려는 이들이 한 번쯤 읽어보고 고민해보면 좋은 글이다.

현대인에게 필요한 내 마음을 쉬게 하는 연습

"내 마음을 쉬게 하는 연습"이라는 책을 소개하며, 현대인에게 필요한 쉼을 설명 하고 있는데, 나에게 딱 필요한 책이라 생각 했다. 카트에 일단 넣어 두었다.

🛠Tool

Learning Resources

TS에서 사용할 수 있는 추상화된 FP 함수들을 제공 해주는 라이브러리이다. 라이브러리에 의존하거나 무분별하게 쓰는건 좋지 않다. 용량을 늘리게 되고, 결과적으로 응답이 느리게 된다. 하지만, 잘 쓰면 유용하다. 혹은 개인 프로젝트쪽에서 써보고 실무에 써보면 좋은 프로세스 같다고 생각 한다. 이 라이브러리는 사실 잘 쓰면 정말 좋은게 많은데, FP 자체가 어색해서 문제였다.

그냥 저냥 #위클리뉴스 #79

Sun, 14 Jun 2020 17:06:18 GMT

🙌🏻개발자에게 도움이 되는

8년 간의 개발자 생활 회고 (1)

8년 간의 개발자 생활 회고 (2)

8년 간의 개발자 생활 회고 (3)

개발자 회고 시리즈 글인데, 읽어보면 참 많은 도움이 된다. 배울점과 자신이 생각한 부분에 따라 이직을 결심하는 부분도 정말 대단한 용기라 생각 한다.

Spotify’s Failed #SquadGoals

스포티 파이의 Scaling Agile에서 비롯한 Squad 팀 모델은 실패했다는 내용의 글이다. 어떤 부분들이 문제였는지? 써있는데, 개인적으로 스포티파이의 팀 모델이 나름의 장점이 된다고 생각했는데, 실상은 그렇지 못했나 보다. 저렇게도 팀 모델을 가져갈 수 있다는 점이 약간은 힙하다 생각 했다. 그런데, 조직의 크기에 따라 달라지는 것은 반영하지 못한 까닭일지도 모른다. 애자일 모델이 만능이 아니다.

코드 악취를 맡는 후각 훈련의 시간

마켓컬리 블로그에 실린, 리팩토링을 위한 코드 악취에 대한 인지 방법과 리팩토링의 장점에 대한 글을 남겨 주셨는데, 상당히 현실성 있고 좋은 내용이다. (한 달마다 리팩토링 주간이 있으면 좋겠다. 😭)

💻JavaScript

[react] 리액트 훅 MVVM #1

[react] 리액트 훅 MVVM #2

[react] 리액트 훅 MVVM #3

리액트의 Hook MVVM이란 제목의 시리즈 글인데, 리액트를 좀 더 깊게 이해하는데, 도움이 된다. 물론 쉽진 않은게 리액트 사용에 대한 새로운 시각이랄까? 어떤 관점이 추가 되다 보니 조금 어려운데, 이해하면 다각도로 이해하는 방법이 된다.

🖥Java

Contents

코로나로 집콕을 하는 와중에도 유능한 개발자분은 번역을 해주신다. 네이버에서 일하시는 분이 스프링 배치 공식 문서를 번역 해주셨다.

Contents

스프링 배치 번역하신 네이버 개발자께서 리액티브 스프링 공식 문서를 번역을 해주셨다.

Sharing Dependencies and Gradle Plugins between Kotlin/SpringBoot Services - StackHawk

gradle에 kotlin을 도입하다 보면, gradle DSL을 kotlin으로 바꿀지 말지? 어떻게 바꿀지? 고민스러운데, 그런 고민을 도와주는 글이다.

JetBrains가 사랑하는 Java의 25가지 특징

제목에서도 나와 있지만, Java의 장점 25가지인데, Java가 업데이트를 빠르게 진행하면서 7 → 8로 가는데 걸린 시간을 현재 최대한 줄이고 있는 것 같다. Java 업데이트 하위 프로젝트들이 좋은 기능을 추가하려는 프로젝트들이 많은데, 그 프로젝트들이 얼른 추가 되어 Java를 끌어 올려 주면 좋겠다.

👍🏻일반적인

출근시간이 11시반인데 왜 늦죠?

지각에 대한 새로운 인식을 가져다 준 세일즈 부스트의 일화이다.

그냥 저냥 #위클리뉴스 #78

Mon, 25 May 2020 23:06:35 GMT

💻개발자에게 도움이 되는

738/clean-code-typescript

클린코드 typescript편이다. 읽어두면 도움이 된다.

TS3.9에 대한 릴리즈 노트 내용 번역이다. Optional Chaining 관련 및 코딩시 가능한 실수등에 대한 부분이 개선 되었고, ECMAScript와 더 호환하려는 개선이 추가 되었다.

Hexo에서 Gatsby로 블로그 마이그레이션 야크쉐이빙 후기

Gatsby로 블로그를 마이그레이션 한 경험기인데, 블로그를 이전하려는 분들이 본다면 도움이 많이 된다.

Distributed Cache로 Hibernate Second Level Cache를 적용하여 성능 튜닝하기 - 이론편

Distributed Cache로 Hibernate Second Level Cache를 적용하여 성능 튜닝하기 - Distributed Cache Cluster 개발편

Distributed Cache로 Hibernate Second Level Cache를 적용하여 성능 튜닝하기 - Second Level Cache 적용편

Second Level Cache를 도입하고, 이를 위해 Distributed Cache를 선택하고, Hazelcast을 선택한 배경부터 시작한 개발까지 시리즈글로 되어 있는데, 나는 개발 하면서 캐시 레이어를 2-depth로 구성 해 본적이 없어서 좀 생소하긴 했지만, 재밌게 읽었다.

Google News Initiative Training Center

구글에서 공개한 머신러닝 개론에 대해 학습을 할 수 있는 곳이며, 한국어도 지원 된다.

How Notion Uses Notion

Notion 사용에 대한 가이드이다.

The HTTP headers you don’t expect

HTTP의 헤더에 관한 내용인데, 흔히 모르고 지나치기 쉬운 정보를 알려주고 있다. (진짜 처음 봤다.)

13 Security Tips for Front-End Apps

FE app들의 13가지의 보안 팁이다. 사실, 아는 것도 있지만, 정말 막연하게 아는 지식들이 전부인 것 같다. 알아두면 분명히 도움이 많이 된다. (SQL 인젝션 같은 것도 단순 공격이 되어 버린 세상이지만, 방어하는 것은 진짜 중요하다.)

Getting Started with Rust by Building a Tiny Markdown Compiler

러스트를 배우는데 가장 좋은 예시가 뭘까? 러스트를 이용해 작은 마크다운 컴파일러를 만들어 보는 튜토리얼인데, 꽤 길다. (Rust를 좋아한다면, 도전 해볼만 하다.)

naver/fe-news

네이버 fe-news 5월의 큐레이션이다. ES2020 기능, TS3.8등의 스펙들외 다양한 FE news들이 포함 되어 있다.

🔧Tool

Iosevka

오픈 소스로 공개 된 폰트인데, 다양하게 설정이 가능 하다. (실제 써보지는 않았습니다.)

그냥 저냥 #위클리뉴스 #77

Sun, 17 May 2020 22:05:04 GMT

🖥개발자에게 도움이 되는

해외개발자 _ 진짜 개발자가 하는 일 1

해외에서 일 하는 개발자의 경험기인데, 결국 언어만 다르고 일 하는 방식은 같은 것 같다. 뭐… 회사마다 문화가 다른 것은 별개로 보도록 하자.

GraphQL을 오해하다

graphQL을 쓰면서 겪은 경험기 글로, JS를 주로 쓰고 graphQL을 JS단에서 도입 하고자 하는 분들에게 도움이 많이 될 수 밖에 없는 글이다.

git add -patch의 e 옵션

커밋을 정말 atomic하게 쪼개어 작업을 해야 하는데, 그 부분을 git add -p 옵션을 쓰는데, 수동으로 더 쪼갤 수 있는 옵션이 있다는 것은 처음 알게 되었다. (알면서도 git add -p는 잘 안 쓰게 된다.)

DDD 했더니 비대해지는 엔티티, 좋은 대책은 ?

DDD와 클린 아키텍처를 보다가 Entity가 너무 비대해지며, 개선하기 위해 적용한 방법을 소개하는데, Bounded Context로 Entity를 쪼개는 방식을 소개하고 있다.

gr을 이용한 많은 git 저장소 관리하기

여러 Repository에서 작업을 하는 사람이라면, 저장소를 한 번에, pull받고, log를 확인 하던 부분들을 하나의 명령으로 관리 할 수 있어서 좋다.

월간 개발자스럽다 #54

다양한 주제의 글들이 모여 있는 월간 개발자스럽다 큐레이션이다. 도커나 컨테이너쪽 글도 많기 때문에 항상 다양한 주제에서 도움이 많이 된다.

기술 뉴스 #150 : 20-05-15 :: Outsider’s Dev Story

아웃사이더님의 기술뉴스 #150번째의 기술 큐레이션이다. 양질의 글들이 모여 있는데, 이번에는 k8s의 coreDNS 글, k8s의 인증 관련한 시리즈 글이 나에게 너무나 큰 도움이 많이 되었다. 그리고 Helm이 졸업 단계 프로젝트가 되었다는 소식도 반가웠다. (요즘 공부중인데, 쉽진 않다…)

팀 문화의 탄생 - 우아한형제들 기술 블로그

아웃사이더님의 큐레이션에도 있었지만, 너무 좋은 글이라 가져왔다. 사실 이런 지속적인 변화를 꿈 꾸는 팀 문화를 가져가는 것이 옳은 일인지? 아닌지? 애매할 때가 있다. 개발자로 일 하고 있으나, 그렇게 성장에 크게 큰 욕구가 없는 개발자도 있기 때문에 모호하다. 여전히 4년이 넘는 시간 동안 일하면서 어떤 변화를 만들어 낸다는 것은 정말 대단한 일인데, 이 팀에서는 2년 이상 성장하면서 팀 문화를 만들어 왔다. 우아한 형제들이여서 가능한 것일까? 나에게 자문을 하게 된다. 되든 안 되든 우리팀에도 점진적으로 도입 할 수 있으면 좋겠다. 꼭, 신입 개발자분들이 많이 읽고, 각 회사 각 팀에 많이 공유하면 좋겠다. (나같은 사람이 말하면 불만인데, 신입 개발자가 말하면 트렌드 일 수 있다.)

💻Java

Spring REST Docs에 날개를… (feat: Popup) - 우아한형제들 기술 블로그

Spring REST Docs를 활용하는 조직에서 적용 해보면 좋을 수 있는 꼼수 꿀팁 글이다. (물론, 우리팀은 Gitbook으로 관리를 하고 있다.)

🛠Tool

Recoil

facebook에서 새로운 상태 관리 라이브러리를 공개 했다.

그냥 저냥 #위클리뉴스 #76

Mon, 11 May 2020 10:05:22 GMT

💻개발자에게 도움이 되는

naver/fe-news

Naver 개발자들이 한달 간의 주요 글들을 큐레이션 하고 있는데, 이번 달은 PR의 Best practice에 대한 글이 좋았다.

리팩터링에 대한 단상

리팩토링 2판을 읽고 느낀 리팩토링에 대한 개인의 생각인데, 정말 좋은 말이 본문에 있었는데, "필요한 순간에 필요한 리팩토링을 한다." 이 말이 리팩토링에 대한 설명으로는 끝인 것 같다.

Looking Back on Four Years at The Times

타임즈 CTO로 4년간 일 했던 회고록인데, 정말 좋은 내용이 많고 되게 사람이 겸손하구나?! 싶은 느낌을 많이 받았다. **서비스는 4년여 동안 100만에서 500만의 구독자로 성장하게 되었고, 여러 시스템들의 개편과 주요 기술들 도입, 클라우드로의 이전등 다채로운 경험**들이 많았는데, 그 부분을 잘 설명 해주고, 평가에 대한 부분, 문화도 빼놓지 않고, 기술 해주셨다.

await의 함정, 숨은 병목을 찾자

await의 순서, 혹은 Promise.all을 통한 응답 지연을 최소화 하는 것에 대해 소개 하고 있다.

The Best Medium-Hard Data Analyst SQL Interview Questions

데이터 분석가의 SQL 인터뷰 질문 모음이다. (개발자가 보아도 도움이 많이 될 것 같은데, 영어라 나름 시간이 좀 오래 걸릴 것 같고, 영어 공부는 덤으로 된다.)

hmmhmmhm/how-to-using-sign-with-apple-js

JavaScript로 애플 로그인을 구현 할 때의 이슈와 상황들을 잘 정리 해 주신 글이다. Server/Client를 나누어서 구체적으로 설명하고 있다.

CSS 팁: 팝업창을 멋지게 만드는 너무 간단한 방법

팝업창을 정말 쉽게 만드는 방법인데, backdrop-filter을 이용한다. 너무 쉽게 가능해서 놀라운 수준…

👍🏻일반적인

존경받는 리더들이 가진 커뮤니케이션 패턴 8가지

핵심은 간결하고 명확한 커뮤니케이션 스킬에 있으며, 상호 존중 하는 태도가 드러난 다는 점이라는 생각이다. 앞서 말한 태도는 모두의 의무이며, 필수이다.

매일 10km씩 걸으면 살 빠져요?

몸을 움직이는 것과 살 빼기는 당연하지 않다. 그러나, 스트레스 다이어트는 가능하다.

데이터 분석팀은 왜 비즈니스에서 중요한 역할을 하지 못하고 있을까?

데이터 분석을 비즈니스 분석에 한정 하기 때문인 것 같다. 내 생각에는 IT서비스에서 바라는 데이터 분석과, 기획, 영업, 제휴등 비즈니스적인 관점에서의 데이터 분석이 다른 것 같다. 일단, BI에 의한 의사결정에 대한 프로세스 자체가 없다. 애초에 특정 결정 권자가 결정 드리븐으로 일을 진행 하는 경우가 많다. 대다수는 아바타의 느낌을 지울 수 없을 것이다. 물론, 그들 각자가 일은 다 하고 있다. 그런데, 결정권은 문이 하나라 항상 더디게 진행 된다. 그러다 보니 데이터 분석에 대한 부분은 항상 뒤쳐지고, 항상 업데이트가 늦다. 항상 커뮤니케이션이 다를 수 밖에 없을 것 같다. 결국, 경험의 부재와 니즈의 부재가 제일 크지 않을까?

더 나은 남편이 되기 위한 팁

어려운 것은 없다. 그냥 대화 많이 하고, 상호 존중이 답이다.

그냥 저냥 #위클리뉴스 #75

Sun, 26 Apr 2020 20:04:17 GMT

💻개발자에게 도움이 되는

신규입사자가 바로보는 마켓컬리

마켓컬리의 신규 개발자가 본 마켓컬리의 문화를 체험하고 쓴 후기이다. 선한 영향력이란게 이런 문화를 두고 하는 말 같다. 나도 이제 감정적인 부분은 내려두고, 하루에 하나씩 복리 구조의 팀을 만들어가는데 일조 해야겠다.

ziishaned/learn-regex

정규식 잘 모르던 분들이 참고 하기 좋은 정규식 배우기 페이지입니다.

xguru/awesome-awesome-awesome

Awesome list를 모아둔 Awesome Meta list 저장소이다.

Greg Hausheer

비개발자가 개발자를 인터뷰 하는 방법에 관한 글이다.

PostgreSQL is the worlds’ best database

PostgreSQL이 좋은 이유에 대해서 소개 하고 있다. 그런데, 세세하진 않아서 신뢰가 좀 떨어진다.

10 Things I Hate About PostgreSQL

PostgreSQL을 싫어하는 10가지 이유인데, 자세하게 써두어 무엇이 강하고, 약한지 알 수 있는데, 정말 시스템의 메인디비로 쓸 수 있는지? 조금 궁금하다.

서버 개발 인턴 robin의 성장기

서버 개발 인턴을 하고, 정직원이 되어 일을 하며 성장한 경험기에 대해서 자세하게 남겨져 있는 글인데, 카카오의 업무 프로세스 문화를 알 수 있다.

[B급 프로그래머] 4월 4주 소식(빅데이터/인공지능, 읽을거리 부문)

빅데이터/인공지능 관련 글타래 모음이다. Go로 신경 네트워크를 구성 하는 글이 있는데, Go가 Python의 대체제가 될 수도 있을까?라는 얄팍한 생각을 잠시 했다.

내 맘대로 위클리 뉴스 - 2020년 16주(2020.4.12 - 2020.4.18)

JS/Python/JVM/Mobile로 글들이 분류 되어 있다. Spring Security 핵심 기능에 대한 설명 하는 글이 관심 갔고, 잘 써보지 않아서 좀 이해가 바로 되진 않는 편이었다.

구글에서 세 번째 SRE 도서 Building Secure and Reliable Systems 무료 공개

구글에서 벌써 세번째의 SRE 시리즈 도서를 무료로 공개 하고 있다고 하는데, 이에 대한 소개와 링크를 제공 하고 있다.

Node.js 라이브러리 Readability로 전문 RSS 만들기

Node.js를 활용하여, 읽기 모드를 통한 RSS 만드는 예제를 코드와 함께 소개 하고 있습니다.

🌟AI

한국어 NLP dataset 모음

NLP dataset 모음인데, NLP하는 분들에겐 도움 많이 될 것 같다. (항상 공부 하고 싶다가도, 쉽지 않은 분야다)

The A-Z of AI

AI의 A-Z로 잘 분류가 되어 있다. 사이트를 어떻게 구성 했는지는 몰라도, 디자인을 정말 잘 했다. 계속 머무르고 싶게 만들었다.

💻JavaScript

Cookie Recipes

쿠키에 관해서 정리를 정말 잘 해주셨다. 쿠키에 관해서 모르는 부분이 있다면 참고하면 좋겠다.

🔧쓸만한 도구

Percona-QA/pstress

DB를 테스팅 하는 툴이다. 어떨때 써야 할지 아직 감은 오지 않았다.

ls보다는 exa를 사용하자! 모던 리눅스 명령어 소개[번역]

여러가지의 CLI에서 사용할 수 있는 도구를 소개 하고 있다. 물론 거의 대부분 쓰고 있는데, 굉장히 좋다. (일단 예뻐야 한다.)

🙌🏻일반적인

폴 그레이엄 - 우리가 버려야 할 습관(1/2)

폴 그레이엄 - 우리가 버려야 할 습관(2/2)

우리가 버려야 할 습관이라는 글로 2개의 글이 번역 되었는데, 폴 그레이엄이라는 사람이 블로그에 쓴 긴 내용의 글이다. 곰곰히 생각해보면, 이런 글들이 가끔 사색하게 만든다. 너무 너무 좋은 안목과 지적이다. 꼭 읽어보면 좋겠다.

매일 1%씩 나아져 37배 성장한 내가 되는 방법

아주 작은 습관의 힘 저자의 이야기를 소개하는 글이다. 정말 작게 시작해 성장케 하는 방법을 소개하는데, 자세한 부분은 책을 읽는 것도 방법이다.

그냥 저냥 #위클리뉴스 #74

Sun, 19 Apr 2020 20:05:39 GMT

👍🏻개발자에게 도움이 될만한

Remote work: A series of best practices for a remote workplace

깃허브 블로그에 소개 된 원격 근무에 관한 글인데, 원격 근무에 대해 겪는 상황에 대해 가장 좋은 예를 소개 한다. (시리즈)

44BITS 뉴스레터 2020년 14-15주

44bits 뉴스 레터이고, 도커 관련 글, 스탠다드아웃 관련 링크가 잘 정리 되어 있다.

개발자와 명상

나도 요즘 명상에 관심을 많이 가지고 있는데, 좋은 글을 만났다. 명상을 시도 하시고, 꾸준히 하시는 분이셨다. 나는 집중력이 정말 낮은 수준이다. 주의력 결핍에 가깝다고 해야 하지 않을까? 싶기도 한데, 이를 고치고 조금 예민한 성격을 둔하게 만들기 위해 명상을 해야겠다. 결심 했다. 좋은 팁과 과정들을 잘 남겨주셔서 시도 해보려고 한다.

[포트폴리오] 👨‍💻 나만의 개발자 포트폴리오 만들기

개발자 포트 폴리오에 대해서 정리 해주셨는데, 정말 깔끔하게 어떻게 구성해야 하고? 어떤 정보들을 참고 했는지 잘 나와 있다.

나는 코드를 쓸테니, 너는 인프라를 맡거라.

Lambda를 이용해 Serverless Architecture를 구성하여, 서비스를 제공 하면서 겪었던 팁과 노하우를 정리하고 있다. 나는 써본 적이 없어서 뭐가 좋다. 아니다.를 말하긴 어렵다.

기술 뉴스 #148 : 20-04-15 :: Outsider’s Dev Story

아웃사이더님의 기술 뉴스인데, 이번 글은 고의 철학, 서머 타임 관련한 배치 작업에 대한 글 타래가 흥미로웠다.

개발자 비급(祕笈) - 3. 나의 폭망한 프로젝트 답사기 :: Channy’s Blog

변화는 결국, 사용자의 편의성 제공이 될지? 불편함의 기준이 될지 아무도 모른다. 결국, 서비스란? 정말 조금씩 바꿔야 하는 것이 정답이라는 생각이다. 화면만 바뀐다는 생각을 개발자, 기획자 모두 버려야 한다. 사용자는 오직 화면만 가지고 사용 한다.

GitHub is now free for teams

깃허브의 모든 기능이 팀에게 무료로 제공 된다. 이로써 private repo를 team에서 마음껏 생성 할 수 있다.

Why I stopped using Microservices - RWieruch

MSA에 대해 자신의 생각을 공유 한 글인데, 중간 중간 이해 못하는 단어가 있어서 좀 어렵긴 했다. 그렇지만, 저자의 생각은 아주 간단 명료하게 좋은 점/나쁜 점을 잘 비교 있다고 생각한다.

💻Java

Java Thread Deadlock and Livelock | Baeldung

Deadlock과 LiveLock에 관한 설명인데, 코드로 설명을 하고 있고, 해결책에 대해서는 좀 명확하지는 않지만, 큐를 분리 하는 정책으로 회피 하는 방법을 소개 한다.

Writing Templates for Test Cases Using JUnit 5 | Baeldung

Junit5를 이용해 테스트 케이스를 템플릿 기능에 대하여 소개 하는데, 사실 정확히 어떻게 써먹어야 할지 좀 이해하기 어려웠다. 오히려 좀 복잡한 느낌이었다.

Java 14: Records | Java Code Geeks - 2020

Java 14 preview feature로 Records 타입이 들어왔는데, 아직 실험적이다. kotlin의 data class와 유사해보인다.

🖥JavaScript

Stop using client-side route redirects

Client Side에서 Redirect를 그만 두어야 하는 이유에 대해 설명하는데, 정말 사용자를 생각 하는 구나 싶기도 하면서, 브라우저, HTTP에 대해 잘 아야 하는 이유가 바로 이거구나 싶었다. 리다이렉트를 어디로 보내야 할지 알고 있다면, 리다이렉트는 서버측에서 제공 하는 것이 옳구나를 또 한 번 깨닫게 되었다.

Todo list 만들기는 이제 그만 - 우아한형제들 기술 블로그

To do list로 React, Redux를 맛 보았다. 그렇다고 막상 실무에 써먹기란 정말 어렵다. To do list만들던 이해도를 가지고 실무를 할 순 없다. 그래서 사람들이 많이 생각을 통해 나온 새로운 데모 realworld.io에 대한 소개이다. 이런 것이 있는지 처음 알게 되었다. (그리고 사람들 정말 대단하다..😭)

ECMAScript 2020: the final feature set

드디어 ECMAScript 2020 스펙이 TC39의 승인으로 결정 되었다. 해당 링크에는 어떤 기능이 추가 되었는지? 나와있다.

🙏🏻일반적인

리브라, 글로벌 단일통화서 법정화폐 연동 여러 스테이블코인으로 전환

리브라가 결국 법정 화폐와 연동 하기로 결정 하면서, 가격이 고정 형태로 제공 될 것 같아졌다. 아마 변동성이 적은 코인이 될 것이며, 이로 인하여 또 어떻게 코인 시장이 바뀔지 모르겠다. 애초에 코인이 현물 화폐와 연동이 된다면, 사실 편리성을 증대 시키는 매개체가 되지 않을까? 싶기도 하다. 이제는 정말 화폐 다운 화폐로 진화 하면 좋겠다. 그렇지만, 다른 스테이블 코인과 차별화 된 점이 무엇일까… 그건 페이스북의 횡보에 달려 있는 문제 같다.

설탕을 끊자 모든 것이 바뀌었습니다

이 글을 읽으면서 내가 나도 모르는 당의 노예였던가? 싶기도 하다. "당이 떨어진다."라는 순간이 오면 쉽게 화가 나고, 짜증이 쉽게 유발 된다. 강력한 트리거 아닐까? 중요한건 서서히 설탕이라는 존재는 좀 덜 먹는 방법인데, 쉽지 않다. 글의 작성자는 설탕을 원래 적게 먹는 라이프 스타일이었기 때문에 쉽게 가능한 부분이고, 일반인은 쉽게 끊기 어려운데, 시작 하기 쉬운 것부터 시작 해야겠다. 올해는 나도 조금씩 주스, 라떼 종류라도 좀 멀리 해야겠다.

handlebars의 삽질, JSP속에서

Mon, 13 Apr 2020 22:00:00 GMT

JSP 상에서 handlebars를 사용할 때, Controller에서 ModelAttribute 넘겨줄 시에, 데이터로 사용 할 값은 그냥 오브젝트 넘겨줄 경우, 오브젝트 형태로 넘어가기 때문에, handlebars에서 데이터로 사용하기 어렵다.

[Category(id="asdfasdf", name="asdfasdf"), Category(id="asdfadf", name="asdfadf)]

위와 같이 오브젝트 타입까지 넘겨지게 된다. 그렇게 되면,JSON.parse를 통해 배열로 만들 수 없기 때문에, JSON string형태로 controller에서 넘겨주면 아래와 같이 사용할 수 있다.

modelMap.addAttribute("Categories", JsonUtils.write(categories));

위와 같이 넘기게 되면, 아래와 같이 데이터가 구성 된다.

[{id="asdfasdf", name="asdfasdf"}, {id="asdfasdf", name="asdfasdf"}]

그럼 아래처럼 JSON.parse를 이용해 string -> object 형태로 바꿔 주면 된다.

var data = {
              Categories: '${CategoriesJson}'
            };

console.log(typeof data.Categories);
console.log(JSON.parse(data.Categories));

왜 이걸 모르고 있었나… 한심하구나…

그냥 저냥 #위클리뉴스 #73

Sun, 12 Apr 2020 20:04:22 GMT

💻개발자에게 도움이 되는

(번역) 세상은 왜 CSS개발자를 필요로 하는가?

CSS 개발자가 필요한 이유, 솔직히 내가 항상 생각하는 유능한 마크업 개발자가 절실하게 필요한 이유가 이 이유이다. 물론, 프론트 개발자가 다 해도 되는 분야이기도 하지만, 나는 전문적인 마크업 개발자가 필요하다고 생각하는 편이다. 그래야 프론트 개발자가 더 집중도 있게 개발이 가능하리라 생각 한다. 물론, 이 글에 반대 하는 이들도 있으리라 생각 한다.

쿠폰 재고의 설계 및 개발

쿠폰 재고에 대한 설계와 개발을 스펙과 전체적인 디자인에 대해 잘 소개 하고 있으며, 특정한 문제와 어느 정도의 논이슈 처리등에 대한 근거와 감안 할 수 있는 이유, Redis를 사용한 명확한 이유를 잘 제시하고 있어서 정독 하면 좋겠다.

git 교육 자료

기계인간님께서 남겨주신 Git의 교육자료인데, Git을 학습하는 새로운 시각이다. 정말 좋은 내용이기 때문에 읽어보면 좋겠다. (그런데, CLI의 달인이셔서 멋있다..)

빠르고 정확하게 답변을 받을 수 있는 질문하는 법 | asbubam’s blog

질문 하는 법에 대한 부분이 중요 하지 않을 것 같지만, 빠르게 내가 원하는 정보를 얻기 위해서는 질문에 대해서도 '잘' 하는 것이 중요한데, 정말 세세하게 정리가 되어 있다.

개발 조직의 문화와 제품의 개발 속도

Post Mortem을 하는 개발 조직은 정말 좋은 문화라고 생각 한다. 보통 이 문화가 없으면, 장애를 낸 개발자에게 대부분, "XX끼 때문에 장애 났다"고 말하거나, 속으로 생각 한다. 근데, 그렇게 문화를 갖고 있으면, 아무런 도움이 되지 않는다. 아무도 도전적인 것을 하지 않게 된다.

vivi의 카카오 겨울 개발자 인턴십 성장기

fred의 카카오 겨울 인턴십을 돌아보며

카카오의 신입 개발자 온보딩 과정 - 개발자로 거듭나기

두 달 간의 신입 개발자 온보딩 과정을 돌아보며 - 신입 개발자들과의 인터뷰

인턴십부터 신입 개발자들의 온보딩까지의 과정을 알 수 있는데, 카카오의 문화를 조금은 알 수 있다. 회사에 입사하는 모든 이들에게 적정한 온보딩 문화를 부여 하는게 좋다고 생각하는 편이다. 신입 개발자만 이 회사에 처음 오는 것이 아닌, 경력직들에게도 일정 시간 필요한 문화가 아닐까? 생각 한다.

코드리뷰로 시작하는 건강한 개발 문화

건강한 문화는 무엇일까? 고민스러울 때가 있다. 코딩 스타일에 대한 부분은 요즘 컨벤션으로 보통 통일 하는 추세이다. 그리고 테스트 코드를 작성해도 된다. 하지만, 모두가 작성 하진 않는다. 그럼 좋은 문화일까? 문화는 결국 같은 수준과 방향성을 팀내 모두가 가져야 하지 않을까? 생각하게 되었다.

기술 뉴스 #147 : 20-04-01 :: Outsider’s Dev Story

여러 글 모음이 있는 글인데, 리액트 렌더링의 모니터링을 위해 Profiler를 이용해 Grafana로 전송 하는 글이 참 신기 했다. 저런 생각을 하는 구나 싶기도 하고, 실무에서 잘 쓸 수 있을까? 싶기도 하고, 좀 재밌어 보이긴 했다. Dropbox의 Sync 알고리즘을 Python에서 Rust로 재작성을 했다고 한다. 초창기 코드이다 보니 아마 나름의 레거시였을터! 좋은 글이 공유 되었다.

2. 진화하는 기업문화

진화 하는 것은 다양한 사람들이 모여 있다는 뜻일까? 왜 한국 기업에서는 미국 기업의 문화, 글로벌 진출 하자 하면서도 그러한 문화가 그려지지 않는 것인가? 궁금하다.

[B급 프로그래머] 4월 1주 소식(개발/관리도구, 고성능 서버/데이터베이스 부문)

다양한 글 모음들이 존재 하는데, 너무 많아서 다 읽어보진 못했다. Next.js 소식, Git 관련 글, 도커 글들을 참고 했다.

ECMAScript 2020의 새로운 점

Optional Chaning 같은 경우는 TS 3.7에서부터는 쓸 수 있어서 편리한데, 다양한 기능 제안들이 나왔고, 대부분 Stage 3에 온 기능들이 있어서 확인 해보면 좋겠다.

FrontEnd Application에서 Null 다루기

Null에 관한 부분인데, 컴포넌트는 데이터에 대한 유효 처리를 하지 않고, Store Level에서 한다는 부분도 좀 재미났다. 우리는 생각보다 대부분 컴포넌트 레벨에서 처리 하는데, Store Level에서 처리하는 방법도 좋은 생각이다 싶었다. 어떻게 잘 적용할 수 있을지? 고민 해야겠다. (Optional Chaining을 써도 결국 Object property의 depth가 깉어지면, 코드는 더럽다.)

useCallback과 React.Memo을 통한 렌더링 최적화

useCallback, Memo에 대해 상세하게 잘 정리 되어 있는 글이다.

Acing the JavaScript Interview: top questions explained

JavaScript 인터뷰 중에 받을 수 있는 질문에 대한 설명 글인데, 질문의 질도 좋지만, 설명도 잘 되어 있다.

컴포넌트 분리의 미학

코드를 기반으로 컴포넌트 분리에 대해 React 코드로 잘 설명 하고 있는데, 특히 예시를 잘 들어주어 쉽게 이해 할 수 있었다.

Lerna(🐉)로 모노레포 해보러나?

lerna가 주목 받기 시작했다. yarn workspaces의 경우 모듈간의 중복 설치를 막아주는 오버헤드를 줄여주는 점은 좋지만, 의존성 관리가 쉽지 않다. (실무에서 써보고 있는데, 팀 내에서 진짜 작게 써볼만하다고 생각한다.) 차라리, lerna가 “더 좋을 수도 있겠다”라는 생각이 드는 요즘에 딱 좋은 글을 발견 했다.

🐳Container

도커 이미지 잘 만드는 방법 :: 조은우 개발 블로그

도커 레이어를 줄이면 좋은줄 알았는데, 이제는 아니라니! 새로운 사실을 알게 되었고, 다양한 꿀팁들이 있는 글이라, 꼭 꼭 읽어보시면 좋겠습니다.

스포카에서 Helm을 도입 하는 이야기

스포카에서 Helm을 도입하여 적용하면서 얻은 노하우를 블로그에 남겨주셨다. 나도 이제 막 공부를 하는 단계인데, Helm을 적용 할 예정이시라면, 꼭 읽어보시면 좋겠습니다. (range 메모..)

🔧Java

ApplicationContext 와 WebApplicationType

이 글을 읽고나니 내가 쓰는 스프링에 대해 너무 무관심 했구나 라는 사실을 알게 되었다. 이 글을 읽어 보시면, 구현체를 어떻게 선택하는지 알 수 있다. (물론, 직접 따라 들어가봐도 될 것 같다.)

👍🏻일반적인

같이 일하고 싶은 사람

이 글에서만 나오는 것 뿐만 아니라 일 잘 하고 싶은 것에는 아마 긍정적인 영향력도 포함 되지 않을까 한다. 나는 생각해보면, 부정적인 말을 많이 하는 동료에 가깝지 않았나? 반성 해본다.

빠듯하게 살던 직장인이 ‘경제적 자유’를 얻은 비밀: “매일 밥 먹듯 하는” 재테크 달인 박지수 작가 인터뷰

이 글에서 강의 대한 홍보보다는 이 분처럼 여유롭게 투자 하는 것이 중요하고, 항상 원칙적인 투자 바운더리가 있다는게 내가 배워야 할 점이었다. 결국, 돈을 잃지 않고 투자를 유지 하는 것은 결국, 일확천금을 얻는 것에 대한 자유로움으로부터 시작 된다. 그 부분을 깨닫게 되었다.

‘근데’를 자주 쓰나요? 상대방의 머리에는 부정적인 그림이 그려집니다

‘근데’를 나도 생각보다 정말 많이 쓰는 편인데, 이 글을 읽고 아! 사소한 단어지만, 상대방에게는 좋지 않을 수 있다는 점을 깨달았다. 역시, 가는 말이 고와야 하는구나.

Ansible로 config 파일을 선택적으로 배포하자.

Tue, 07 Apr 2020 10:36:00 GMT

ansible의 기초 지식이 있다는 전제 하에 설명을 진행 합니다.

우선 아래와 같은 구조가 있다고 생각하자.

ansible-playbooks
  - group_vars
  - host_vars
  - inventory
  - roles
    - deploy_config
    - pc
    - api
    - mobile

role기반의 playbooks를 모아두기 위한 구조이다. 내가 속한 팀에서 위와 같은 디렉토리 구조를 잘 쓰고 있다. (더 좋은 방법이 있다면, 알려주시면 좋겠습니다.)

tomcat, apache, nginx, logstash, elasticsearch, kafka등과 같은 모든 툴들에는 설정 파일이 필요하다. 그리고 관리 해야 하는데, 나는 주로 해당 서버에 쓰이는 설정은 같은 디렉토리에 넣어둔다.

pc에 관련한 tomcat, nginx, logstash등 하나의 디렉토리에서 셋업에 필요한 모든 설정을 넣어둔다. 그리고 디렉토리 구조는 동일 하게 맞춰 준다.

특별하게 상이 하게 구성을 하게 되면, 해당 role을 통합하여 사용하기가 어렵다.

우선 위와 같은 구조에서 톰캣 설정 파일인 server.xml을 서버별로 배포를 해야 한다고 생각해보자.

  - roles
    - deploy_config
      - tasks/main.yml
    - pc
      - files/tomcat/server.xml
    - api
       - files/tomcat/server.xml
    - mobile
       - files/tomcat/server.xml
   deploy_config.yml -> deploy_config role 실행 파일

---
- hosts: '{{ host }}'
  vars_files:
    - 'group_vars/main.yml'
  roles:
    - deploy_webconfig
  serial:
    - '10%'

위 파일은 최상위 디렉토리에 있는 deploy_config.yml 파일의 내용이다. 특정 role을 실행 시킨다.

우리는 동일한 tomcat 설정이지만 mobile, pc, api 서버의 tomcat 설정은 다르다. 각 서버에 맞는 tomcat/server.xml을 배포 해야한다.

deploy_config의 task를 어떻게 구성 할 것인가?

---
- include_vars: 'roles/{{ host }}/vars/main.yml'
  tags:
    - default
- name: Stop webapps.sh
  shell: nohup /seungdols/scripts/stop_webapps.sh
  tags:
    - stop_webapps
- name: deploy httpd.conf
  template:
    src: 'roles/{{ host }}/templates/conf/httpd.conf.j2'
    dest: /seungdols/apps/apache/conf/httpd.conf
    owner: irteam
    group: irteam
    mode: 0644
    backup: yes
  tags:
    - deploy_httpd_template

- name: deploy httpd.conf
  copy:
    src: 'roles/{{ host }}/files/conf/httpd.conf'
    dest: /seungdols/apps/apache/conf/httpd.conf
    owner: irteam
    group: irteam
    mode: 0644
    backup: yes
  tags:
    - deploy_httpd_copy
- name: deploy server.xml of tomcat
  template:
    src: 'roles/{{ host }}/templates/tomcat-server.xml.j2'
    dest: '/seungdols/apps/tomcat/conf/server.xml'
    owner: irteam
    group: irteam
    mode: 0644
    backup: yes
  tags:
    - deploy_tomcat_config
- name: Start webapps.sh
  shell: nohup /seungdols/scripts/start_webapps.sh
  tags:
    - start_webapps

위와 같이 어플리케이션을 동작 시킨다.

stop apache httpd | nginx
stop tomcat
deploy config
start tomcat
start httpd | nginx

왜 이렇게 하는지는 자유롭게 구성하면 된다. 내가 중요하게 생각하는 것은 template과 copy를 tags로 구분 해두었다.

이는, 특정 서버 마다, 특수하게 변수 처리를 하여 쓰는 것도 있고, 그냥 단순 파일만 복사해도 되는 경우가 생기기 마련이었다.

위와 같이 써도 문제는 없다. 그런데, 문제는 서버 한대에 톰캣 인스턴스를 하나만 운용하지는 않는다. 그렇게 되면 어떻게 해야 할까?

물론, 이 글에서는 tomcat instance load balancing에 대해서는 설명 하진 않는다.

톰캣 설정을 복사 하는 부분을 수정 하면 된다.

  - roles
    - deploy_config
      - tasks/main.yml
    - pc
      - files/tomcat1-server.xml.j2
      - files/tomcat2-server.xml.j2
    - api
      - files/tomcat1-server.xml.j2
      - files/tomcat2-server.xml.j2
    - mobile
      - files/tomcat1-server.xml.j2
      - files/tomcat2-server.xml.j2

파일 구성이 위와 같이 달라질 것이다. 그렇게 되면, 반복을 통해 아래와 같이 deploy_config/tasks/main.yml의 내용 중 일부를 아래와 같이 수정 하면 된다.

- name: deploy server.xml of tomcat
  template:
    src: "roles/{{ host }}/templates/{{ item }}-server.xml.j2"
    dest: "/seungdols/apps/{{ item }}/conf/server.xml"
    owner: irteam
    group: irteam
    mode: 0644
    backup: yes
  with_items:
    - tomcat1
    - tomcat2
  tags:
    - deploy_tomcat_config

그런데, 이렇게 할 경우에는 api서버만 tomcat3의 인스턴스 설정이 있다고 하면 어떻게 할까? 그럴떄는 그냥 편리하게, task를 분리 했다.

- name: deploy server.xml of tomcat
  template:
    src: "roles/{{ host }}/templates/{{ item }}-server.xml.j2"
    dest: "/seungdols/apps/{{ item }}/conf/server.xml"
    owner: irteam
    group: irteam
    mode: 0644
    backup: yes
  with_items:
    - tomcat1
    - tomcat2
  when: host != 'api'
  tags:
    - deploy_tomcat_config
- name: deploy server.xml of tomcat
  template:
    src: "roles/{{ host }}/templates/{{ item }}-server.xml.j2"
    dest: "/seungdols/apps/{{ item }}/conf/server.xml"
    owner: irteam
    group: irteam
    mode: 0644
    backup: yes
  with_items:
    - tomcat1
    - tomcat2
    - tomcat3
  when: host == 'api'
  tags:
    - deploy_tomcat_config

위와 같이 구성하면, host가 api가 아닌 서버만 tomcat1,tomcat2 설정 파일을 배포 할 것이며, api서버인 경우 tomcat1, tomcat2, tomcat3 설정 파일을 배포하는 task를 실행 하게 된다.

task에 있는 host는 플레이북을 실행 시킬 때, 외부에서 인자로 넘겨주는 외부 변수 값이다. 실행시 결국 host=api | mobile | pc의 값을 넣어주게 된다.

실제 실행은, 아래와 같은 명령을 입력 하면 된다.

ansible-playbook deploy_config.yml -i inventory/hosts -e "host=pc"

나는 되도록, 설정 파일 배포시 role별로 배포를 하는 것을 좋아한다. 총 3번의 배포를 해야 하는데, 배포는 같은 role인 deploy_condig role을 이용한다.

한번에, 배포 하는 것은 실수를 야기한다. 특히, 잘못 배포시, 배포 영향도를 줄이는 것이다.

물론, 자동화도 가능하다. deploy role하나로 3번의 반복이니, 외부 실행 스크립트에서 분기 해주면 된다.

만약, 디렉토리 이름도 달라져야 한다면, 아래와 같이 task를 구성 할 수도 있다.

- name: deploy server.xml of tomcat
  template:
    src: 'roles/{{ host }}/templates/{{ item.config }}-server.xml.j2'
    dest: '/seungdols/apps/{{ item.dir }}/conf/server.xml'
    owner: irteam
    group: irteam
    mode: 0644
    backup: yes
  with_items:
    - { config: tomcat1, dir: alpha }
    - { config: tomcat2, dir: alpha1 }
    - { config: tomcat3, dir: beta }
  when: host == 'pc-test'
  tags:
    - deploy_tomcat_config

실제 파일 이름과 디렉토리 이름이 상이할 경우 위와 같은 방법도 가능하다. 물론, 당연히 같은 행위를 하는 task가 3개가 되지만, 각 영역이 다르므로 when의 조건문을 잘 넣어 주어야 한다.

- name: deploy server.xml of tomcat
  template:
    src: 'roles/{{ host }}/templates/{{ item }}-server.xml.j2'
    dest: '/seungdols/apps/{{ item }}/conf/server.xml'
    owner: irteam
    group: irteam
    mode: 0644
    backup: yes
  with_items:
    - tomcat1
    - tomcat2
  when: host != 'api' and host != 'pc-test'
  tags:
    - deploy_tomcat_config
- name: deploy server.xml of tomcat
  template:
    src: 'roles/{{ host }}/templates/{{ item }}-server.xml.j2'
    dest: '/seungdols/apps/{{ item }}/conf/server.xml'
    owner: irteam
    group: irteam
    mode: 0644
    backup: yes
  with_items:
    - tomcat1
    - tomcat2
    - tomcat3
  when: host == 'api'
  tags:
    - deploy_tomcat_config
- name: deploy server.xml of tomcat
  template:
    src: 'roles/{{ host }}/templates/{{ item.config }}-server.xml.j2'
    dest: '/seungdols/apps/{{ item.dir }}/conf/server.xml'
    owner: irteam
    group: irteam
    mode: 0644
    backup: yes
  with_items:
    - { config: tomcat1, dir: alpha }
    - { config: tomcat2, dir: alpha1 }
    - { config: tomcat3, dir: beta }
  when: host == 'pc-test'
  tags:
    - deploy_tomcat_config

when만 잘 지키면, 각 영역에 맞게 설정 파일 배포하는 role을 손쉽게 쓸 수 있다. 이렇게 하지 않고, 공통적인 task를 분리해서 include_task로 불러서 task 파일 자체를 분리해도 된다. (가변적인 부분만 따로 분리하고, 하나의 task로 만들어도 무방하다.)

apache httpd + tomcat + node 운용하기?

Tue, 07 Apr 2020 10:36:00 GMT

apache httpd + tomcat instance + node server

서버 한대에 아파치 웹서버, 톰캣 인스턴스 그리고 노드 서버 까지 운용할 수 있을까?

답은 가능하다.

LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule proxy_scgi_module modules/mod_proxy_scgi.so
LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
LoadModule proxy_balancer_module modules/mod_proxy_balancer.so

위의 모듈을 이용해, tomcat 서비스, node 서비스를 둘 다 동시에 서비스 할 수도 있고, tomcat 서비스는 로드 밸런싱도 할 수 있다. (proxyhttp or proxyajp 이용 하면 된다.)

만약, apache httpd에서 tomcat을 proxy 형태로 로드 밸런싱 하고자 한다면, 아래와 같이 설정 하면 된다.

    ProxyPassMatch ^/(.*[.](jsp))$ balancer://tomcat
    ProxyPassReverse ^/(.*[.](jsp))$ balancer://tomcat
    ProxyPass / http://localhost:{{ NODE_PORT }}/ Keepalive=On retry=0
    ProxyPassReverse / http://localhost:{{ NODE_PORT }}/
    <Proxy balancer://tomcat>
        BalancerMember ajp://localhost:{{ tomcat1_ajp_port }} loadfactor=1 route=tomcat1 Keepalive=On
        BalancerMember ajp://localhost:{{ tomcat2_ajp_port }} loadfactor=1 route=tomcat2 Keepalive=On
        ProxySet lbmethod=bytraffic
    </Proxy>

로드 밸런싱 메소드는 httpd 문서를 보면 된다.

물론, 굳이 이런 상황이라면, apache httpd를 고집하지 말고, nginx로 가면 된다.

참조

modproxybalancer - Apache HTTP Server Version 2.4

Apache mod_proxy를 이용한 reverse proxy와 로드밸런싱

httpd mod_proxy 와 tomcat lb 설정에 따른 load balancer 구현

그냥 저냥 #위클리뉴스 #72

Sun, 05 Apr 2020 23:04:25 GMT

💻개발자에게 도움이 되는

LINE 메시징 서버가 새해 트래픽을 대비하는 과정 - LINE ENGINEERING

라인 메신저의 특이한 문화 중 하나가 바로 "신년 대응", 라인 개발자들의 책을 읽어보니 다들, 12월 31일에 모여서 신년 대응 이후 퇴근을 한다고 하던데, 사실 경험 해보고 싶은 문화이기도 하다. 그만큼 라인 메신저팀의 주된 업무인데, 이를 위해 대비 하는 과정에 대해 담고 있다. 그리고 Armeria를 적극 도입하는 것을 알 수 있었고, Spring framework와 같이 쓸 수도 있다는 점이 매력적이긴 하다. 물론, Armeria는 그냥 자체로 써도 안전성이 있는 것 같다. 써 보고 싶긴 하다.

SI회사에 입사하기 전 읽으면 좋은 글 - SI의 단점

여전히 바뀌지 않은 문화인 것 같다. 내가 대학 졸업 전부터도 "SI는 가지 말아라"는 선배들의 조언을 들었다. 일단 가는 순간 개미 지옥이라 빠져 나오기 쉽지 않다고 말이다. 그런데, 이런 문화를 가진 곳에 내가 발을 들여 놓았다면, 나는 아마 개발자를 포기 했으리라…😭그럼에도 불구하고, SI에도 조금씩 변화는 오는 중이라 믿고 있다.

세상에 나쁜 코드는 없다.

이 분의 말처럼, 나쁜 코드는 없다. 누군가는 이해하기 쉬운 코드이라도, 팀원은 그 코드가 이해하기 어려운 코드 일 수도 있다. 즉, 나만의 코드가 정답은 아니라는 소리이며, 클린 코드더라도, 팀원들의 이해 수준이 그 수준이 아니라면, 끌어 올려주거나? 아니면 내가 적당한 수준의 코드를 만들어 나아가는게 좋다고 생각 하는 편이다. 결국, 팀원들 모두가 같은 수준의 코드 생산을 해야 한다. 이렇게 코드를 만드는게 정말 어렵다.

LINE 신입 SW 개발자 코딩 테스트, 이렇게 만들어졌습니다 - LINE ENGINEERING

LINE에서 신규 개발자를 채용하기 위해 개발자 코딩 테스트를 작년부터 개편하기 시작했다고 한다. 나는 이런 변화가 정말 좋다고 생각 한다. 알고리즘 대회로 변질 되어 버린, SW 개발자 코딩 테스트가 이렇게 실질적인 문제로 변화 하는 것은 좋다고 생각 하고, 다른 회사들도 알고리즘 대회에서 벗어 났으면 좋겠다.

다 함께 TDD

TDD는 쉽지 않은 영역이긴 하다. 습관의 영역이기 때문이다. 누구나 테스트 코드 짜고 싶어 한다. (물론, 그렇지 않은 사람도 있을 것이다.) 조금씩 훈련 하는 것이 좋다고 생각 하는 편이고, TDD 보다는 부담감을 줄일 수 있는 방법으로 접근하면 좋겠다. 내 생각은 구현체를 먼저 작성해도 좋다. 다만, 해당 구현체를 테스트 할 수 있는 테스트 코드를 나와 내 동료가 같이 쌓아 올리는 공간에 보관 하는 것이 중요하다.

💻Java

Java 예외처리 ( feat. Effective java )

매번 아는 것 같은 느낌이지만, 막상 내가 예외 처리를 잘 하고 있는건가? 의문이 들었다. 다시 좀 봐야 할 책은 Effective Java 3판인가...!

토비의 봄을 담은 제네릭 1편

Java Generics에 대해 정리를 정말 잘 해주셨다. 나도 봤던 내용들인데도 시간이 지나니, 잊혀진다. 다시 복습 중요한 것 같다.

토비의 봄을 담은 제네릭 2편 람다와 인터섹션

람다와 인터섹션의 개념을 정리 한 글인데, 생각보다 이해가 쉽지 않다. 계속 봐도 봐도 Java를 저렇게 쓰는거구나 싶기도 하다.

조금 더 괜찮은 Rest Template 1부 - Retryable

Retryable을 이용한 Rest Template을 소개 하는 글이다. 삽질한 방법들에 대해 자세하게 소개 하고 있다.

조금 더 괜찮은 Rest Template 2부 - Circuit-breaker

Circuit-breaker에 대해 설명 하는 글이며, 실제 코드를 기반으로 예시 단계별로 설명하고 있어서 따라 하기 쉽다.

Learning Functional Programming with JavaScript - Anjana Vakil - JSUnconf

함수형 프로그래밍에 대한 기본을 잘 설명 해주시고, 발표자가 앎과 모름에 대해 정확하게 잘 구분 하시는 부분이 좋았고, 좋은 레퍼런스랑 라이브러리를 소개 해주셨다.

An introduction to functional programming

위의 유투브 영상에서 도움을 많이 받았다고 한 함수형 프로그래밍에 대한 설명글이다. 조금 길지만, 도움이 많이 된다.

naver/fe-news

네이버에서 FE 뉴스 큐레이션을 진행하는데, 이번 4월에 해당하는 글 모음입니다. 함수형 프로그래밍에 대한 글이 좋고, 번역도 5번째 글까지 번역이 되어 있다. 그 외에도 유익한 글들이 있다.

🛠Tool

‘매일 써도 좋을’ 비주얼 스튜디오 코드 확장 기능 7가지

VS Code plugin 추천 글이다. Data preview, jumpy 같은 툴들은 진짜 유용해 보여서 보자마자 설치 했다. Jumpy는 사실 vim을 잘 쓰면 바로 적용이 가능한 부분인데, 사실 그렇게 vim의 하드 유저는 아니여서 설치해보았다.

mori

immutable.js는 익히 들어 봤지만, mori는 처음 들어 보았다. clojurescript 기반으로 작성 되어 있고, JS로 바로 사용 한다고 하는데, 개인 프로젝트에서 써봐야겠다.

그냥 저냥 #위클리뉴스 #71

Sun, 29 Mar 2020 15:04:06 GMT

🖥개발자에게 도움이 되는

[B급 프로그래머] 3월 4주 소식(빅데이터/인공지능, 읽을거리 부문)

빅데이터/인공지능 관련한 글 타래가 모여 있어서 관심 있는 글만 읽어보면 좋겠다.

내 맘대로 위클리 뉴스 - 2020년 13주(2020.03.22 - 2020.03.28)

Python, JavaScript, JVM, Etc 항목으로 분리 되어 관심 분야만 읽기 좋은데, 이번엔 JVM쪽의 글이 나에게 도움이 많이 되었다. (kotlin에 관심 많았는데..)

내가 웹 브라우저를 사용하는 방법

기계인간님이 즐겨 쓰시는 웹 브라우저의 플러그인 2가지의 소개 글입니다.

[OKKYCON: 2018] 양완수 - 테스트를 돌보기 위한 매우 간단한 실천 방법들, 그리고 효과

오래된 영상이기는 하지만, 팀원분이 추천 해주셔서 보게 된 영상이다. 테스트 코드 작성의 이유? 장점?에 대한 부분에 대해 잘 설명 해주셔서 재미나게 보았다.

💻Java

Java ArrayList vs LinkedList | Baeldung

두 가지를 어떨때 써야 하는지에 대해서는 깊이 고민 해보지 않았는데, 원소 추가, 삭제, 조회에 대한 성능을 통해 두 Collection의 사용 상황을 가이드 하고 있는 글이다. 결국, 읽기가 더 많다면, ArrayList, 쓰기가 더 많다면, LinkedList를 쓰는게 효과적이다.

Java 14 New Features | Java Code Geeks - 2020

Switch Expression, Switch Expression Arrow Operation, Switch Expression Yield Operation, Text block, Records(preview jdk15)등 신규 기능들이 많이 추가 되었다. 아마 JDK15, 16정도가 되면, JS 문법과 거의 유사 해지거나, Kotlin 정도의 간편함이 도래하지 않을까?

🙏🏻일반적인

한 분야에 집중하지 못하는 사람이 더 성공하는 이유

한 가지 방면에서 뛰어나다고 먹고 살 수 있는 시대가 아니기 때문에, 다양한 활동을 꾸준히 해야 한다고 한다. 결국 “멘탈 모델이 중요하구나” 싶었다.

한미 통화스와프 긴급 체결의 배경과 의의

통화스와프에 대한 의미를 잘 몰랐는데, 정확하게 설명해주고 있어서 좋은 공부가 되었다.

그냥 저냥 #위클리뉴스 #70

Sun, 22 Mar 2020 19:03:48 GMT

🖥개발자들에게 좋은

[번역] 개발자를 위한 면접 지침

개발자들과 면접관 모두에게 도움이 되는 글이라고 생각 한다.

이렇게 기획하면 안 돼요! #회원가입

회원 가입에 대한 기획 가이드를 알 수 있다. 하지만, 이 글이 꼭 정답은 아닐 것이다. 회원 가입 하나에도 수 많은 방식과 좋은 기능들이 추가 될 수 있다는 생각을 하게 되었다.

Deno는 과연 NodeJS를 대체할 수 있을까?

이미 많은 생태계를 이룩한 Node.JS 진영에 Deno가 출현하는 것은 좋은 현상이라고 본다. 아마, 확실하게 좋은 장점, 이식성만 확보된다면, 바로 쓰일 수 있을거라 생각 한다. (일단, 라이언 달이 두 언어의 창시자이기 때문 안정성은 확보 되었다고 생각 한다.)

신입 개발자 면접 질문 시리즈

면접 질문에 대해 정말 자세하게 잘 나와 있어서 Java를 주로 했다면 정독 하면 좋겠다. 그리고 Java가 주력이 아니여도 읽어보면 좋을 내용이 많다.

그래서, ROP가 뭔데 씹덕아 (Railway oriented programming)

ROP에 대해서는 무지했는데, 이 글을 보면 정말 이해하기 쉽다. 결국, 함수형 프로그래밍과 합성 지향 프로그래밍이 대세가 되지 않을까? 싶다.

뉴모피즘은 새로운 UI 트렌드가 될 수 있을까?

Flat Design이나 Meterial Design이 거의 디자인의 표준이 된 상황에서 뉴모피즘 UI에 글로 이 글을 읽으면서, 나는 오히려 이 부분이 현대 웹페이지에서 보고 싶은 미래 지향 디자인 같았다. (내 느낌만...)

재택근무 10가지 프로 팁

에어비엔비에서 일하는 개발자 동료분이 공유한 재택근무 팁에 대한 글입니다.

조언을 해준다는 것

한 때, 나도 조언병에 걸린적 있다. 대학 동기가 전공을 하고도 다른 일을 하다가, 돌고 돌아 이 일을 한다고 했을때, 진짜 하고 싶은지에 대해? 고민을 했으면 좋겠다고 한 적이 있다. 생각해보면, 그저 응원만 해주면 되는 일인데, 요즘에 깨닫게 되었다. (사실, 그때나 지금이나 동일한 생각은 자신이 정말 좋아하는 일인지?가 중요하다고 생각 한다.)

2.0 까지 해본 개발자

이 글을 읽으면서 당근마켓 대표님의 어떤 혜안이 느껴진다. 이유 있는 기능 추가, 그리고 보수적인 기능 확장. 모두 맞는 말이다. 기능 추가는 누구나 다 할 수 있다. 중요한 건 그 기능이 "왜 출시 되어야 하는지? 정말 사용자에게 좋은지?"를 생각하는 서비스에서 일 해보고 싶다는 생각이 요즘 정말 간절하다. 새로운 것만 해본 개발자도 나는 별로 좋아 하는 편이 아니다. 어떤 개발자도 레거시를 좋아하는 개발자는 없다. 여건이 되지 못해 기술 부채를 쌓았을 뿐. 그럼에도 불구하고, 그 기술 부채 속에서도 유지보수를 가능케 하는 것도 능력이다. 꼭 새로운 프로젝트, 신규 기능 개발만이 성과인 것이 아니다. 새로운 기술, 새로운 언어만이 나의 실력이 아닌 것이다.

문제 없어요 증후군 (No-Problem Syndrome)

NPS에 대해 알게 되어 기분이 좋았다. 이러한 것도 문제라고 볼 수 있구나. 사실 일하면서 이러한 일들이 문제라고 이미 느끼고 있었다. 문제 없다고 외치는 것은 본인에게만 좋은 일이다. 그리고, 무분별한 외침은 동료를 힘들게 한다.

다시 찾아간 지표의 세계

데이터 사이언티스트가 바라본 지표에 관한 글인데, 정말 유익하다.
지표에 대한 확실함을 잘 모르겠다고 일 하면서 기획자랑 많이 이야기를 했다. 이런 클릭이 왜 필요한지? 무엇이 중요한 것인지에 대해 심도 깊은 이야기를 못하는 서비스 개발자에게 아쉬운 영역이었다. 이 글을 읽다 보니 무엇이 목적인지? 중요하다는 생각을 하게 되었다. 허상지표와 실질지표의 구분도 정말 중요하구나를 배웠다.

지표를 바르게 사용하는 것

지표에 관해 윗글을 읽다 아래 글을 읽게 되었는데, 지표에 관해 좀 더 명확하게 알게 되었고, 써주신 4가지에 대해 정말 감탄하게 되었다.

💻JavaScript

Front-End Dev Tools For increased Productivity

프론트 엔드 개발 생산성에 도움을 주는 개발 도구 소개 글이다. (마크업적인 툴들이 많다.)

Mistakes Junior React Developers Make

주니어 리액트 개발자가 하는 실수들에 대한 부분인데, 가장 민망한 건 "충분히 테스트를 하지 않음"에 대한 부분이었다.

Unified Numberformat 맛보기

숫자에 대한 포맷이 신규 스펙으로 제정 되었고, stage 4로 모던 브라우저에서는 반영이 될 예정인 Unified Numberformat의 소개이다.

The Road to React [Book 2020] - RWieruch

리액트를 배우는 책으로 유명한데, 해당 책이 개정 되었다.

GraphQL resolver testing - RWieruch

GraphQL의 resolver를 jest로 테스팅 하는 방법에 대해 소개 하고 있다. 리졸버는 테스트 하는 코드를 넣어 두는 것은 좋은 방법이 될 수 있겠다. 생각 했으나, TDD를 하기란 쉽지 않더라. 매번 반성한다.

💻Java

JUnit5로 계층 구조의 테스트 코드 작성하기

BDD 테스트의 일종으로 D-C-I pattern의 테스트 코드 작성법에 대한 소개이다. 해당 글을 읽으면서 오! 이렇게 하니까 정말 술술 읽히는 테스트 코드구나! 생각 하게 되었다.

7 JVM arguments of Highly Effective Applications | Java Code Geeks - 2020

Java 어플리케이션의 도움을 주는 JVM 옵션들을 소개하는데, 기본적으로 추가 하는 부분들이 있고, 내가 써보지 않은 부분들도 있다. (timezone은 생소했다.) 각 옵션에 대해 잘 설명 하고 있다.

Java IO vs NIO | Baeldung

Java IO/NIO에 관한 글로, 굉장히 짧기 때문에 읽어 보면 좋다. 물론, 버퍼를 잘 다루는 방법은 소개 되어 있지 않지만, 제일 중요하다.

Difference Between Thread and Virtual Thread in Java | Baeldung

Thread와 Virtual Thread의 차이에 대한 설명인데, 이해하기 쉽지 않았다. 여러번 읽어 보아야 하는데, carrier thread가 무엇인지는 나오지 않았다. 대충 이해한 바로는 가상 쓰레드가 실행 되는 공간이라고 이해 했다. 결론은 가상 쓰레드가 캐리어 쓰레드를 차단 하지 않기 때문에 비용이 훨씬 저렴하다는 것이 핵심 같았다.

Java 14 Released

JDK 14 정식으로 릴리즈 되었다. 다양한 기능들이 대거 추가 되었다. Pattern Matching, Switch Expression등외 JFR Event Streaming이 추가 되었다. (참고)

Ktor로 Todo 서비스 빠르게 만들기 | Popit

kotlin의 경량 프레임워크인 Ktor로 TODO 어플리케이션 만들어보기 글이며, kotlin에 관심을 가지고 있는데, Ktor를 처음 알게 된 계기가 되었다.

🙌🏻일반적인

매뉴얼은 세세하게, 화상회의는 매일, 평가는 아웃풋으로

Gitlab, InVision의 두 회사 이야기를 하는데, 두 회사의 업무 스타일과 원격 근무에 대한 문화를 소개 하고 있다.

한계를 그만 뛰어넘을래

문득 한계에 부딪히는 일들이 많아 스트레스를 받는 분들이 읽어보면 좋겠다.

성장하는 사람의 큰 특징: 설득의 자세

설득의 중요성에 대해 알 수 있는 글이다. 설득을 잘 하는 사람은 영향력과 어떠한 근거가 있다는 것이다.

미니멀리스트 옷장을 만드는 10가지 방법들

패션에 대해서는 무지한데, 읽다 보니 공감을 많이 하게 된 글이다. 입을 옷은 적고, 옷걸이에 걸린 옷들은 많다면, 이 글이 도움이 되리라 생각 한다.

그냥 저냥 #위클리뉴스 #69

Sun, 15 Mar 2020 19:03:45 GMT

정산지기를 향한 첫걸음 (feat. 파일럿 프로젝트) - 우아한형제들 기술 블로그

우아한형제들에 입사하신 분의 파일럿 프로젝트에 대한 피드백 경험기 그리고 어떻게 리팩토링 했는지에 대해 두달 간의 여정이 잘 녹아 있어서 읽어보면 도움 되는 부분들이 많았다. 읽으면서 부러웠던 부분은 확실히 신입 교육이 앞으로의 개발자로 일함에 있어서 중요한 길라잡이가 된다는 생각이다. (내가 속한 회사도 이런 단계적인 프로젝트 사이클이 처음에 있으면 좋겠다 생각하지만, 또 대규모 채용을 하는 입장에서는 쉽진 않겠지…라는 생각이다.)

개발자를 위한 레디스 튜토리얼 01 : TOAST Meetup

개발자를 위한 레디스 튜토리얼 02 : TOAST Meetup

개발자를 위한 레디스 튜토리얼 03 : TOAST Meetup

개발자를 위한 레디스 튜토리얼 04

레디스 관련 튜토리얼 시리즈 글인데, 해당 글을 읽으면서 레디스가 어떤 녀석이고? 어떤 기능을 하는지? 관리는 어떻게 해야 하는지 기본적인 지식을 쌓일 수 있고, 꿀팁을 다량 얻을 수 있다.

새로 입사한 개발자가 프로젝트에 기여하는 방법 한 가지

신규 입사자가 프로젝트에 기여하는 방법에 대한 글인데, (기계인간) 종립님의 작업은 항상 기본에 충실 하면서도 다른이들에게 배움의 기회를 준다는 점에서 박수를 보내고 싶다.

STOP!! You don’t need Microservices.

MSA가 왜 필요 없는지?를 설명하는 글이지만, MSA를 무족건적으로 비판하는 것은 아니다.

웹 개발을 하는 사람들을 위한 9가지의 인기 있는 저장소 모음이다. You don't know JS는 특히 유명하다.

초보 개발자를 위한 IT영단어 정리

본적 없는 영단어는 외워 두면 좋다.

공개적으로 학습하라!

netlify에 일하는 개발자가 쓴 글을 번역한 글인데, 공개적으로 학습하라는 말은, 결국 배운게 있고, 어떤식으로든 학습을 하여, 컨텐츠를 생산하라는 조언이다. 그의 말에 동의 한다.

좋은 회사 기술 블로그는 어떻게 운영되는가 | GeekNews

좋은 회사들은 어떻게 기술 블로그를 쓰는지?에 대한 부분인데, 읽어보면 좋겠다. 도입할 수 있는 부분이 있다면, 도입 해보면 좋은 부분들이 많다.

GitLab’s Guide to All-Remote

gitlab은 전 세계 모든 직원들이 원격 근무를 하는 유일한? 회사라 알고 있는데, 해당 원격 근무에 대한 가이드글이다.

개발자들이 꺼려하는 까칠한 규식이 형

나도 어렵게 생각하는 정규식은 사실 모든 개발자들이 꺼려하는 것 같다. 물론 좋아하는 사람들도 있다. 그런 정규식과 친해지는 방법에 대한 그리고 실무에서 발생한 문제를 어떻게 처리 하는지를 소개하고 있다.

집에서 일했을 뿐인데 생산성이 폭발했다 | 뱅크샐러드

뱅샐에서 재택 근무를 거의 4주차에 접어 들면서 파악한 재택 근무의 효율성에 관한 이야기이다. 물론, 룰을 정해 일 하기 때문에 기존 근무와 크게 달라지지 않은 것을 볼 수 있다.

Container

도커 베스트 프랙티스 (번역)

dockerfile을 잘 작성 하기 위해서는 레이어별 캐싱을 잘 활용하는 것이 중요하고, 좋은 방향으로 도커 파일을 관리하는 것이 좋은데, 도커 베스트 프랙티스라고 유명한 도커의 튜토리얼 가이드 글이 있는데, 해당 글의 번역 글이다.

JavaScript/FE

Saga Pattern과 redux-saga

redux-saga에 대해 상세하게 설명 해주신 글입니다. 해당 글에는 saga-pattern에 대한 설명도 있습니다. 요즘은 확실히 redux-thunk보다 많이 사용하는 느낌을 많이 받는다.

ReactJS의 Virtual DOM과 Repaint, Reflow | DrakeJin

React에서 Virtual DOM을 사용하는 이유, 브라우저에서 Repaint, Reflow가 발생하는 이유와 원인에 대해 정리 한 글

Introduction to Algebraic Structures - Functional Programming for JavaScript Developers

함수형 프로그래밍의 대수 구조에 대해 소개 하는 글인데, 이해하기 쉽지 않다. (~~아마, FP의 지식이 없기 때문이지 않을까?~~)

[번역] await vs return vs return await

JS로 작업을 하다 보면, 애매할 때가 있는 그 부분의 의문을 없애주는 글이었다. Return-awaiting에 대해 이해할 수 있는 글이다.

JS: The Observers

JS 기본 내장 옵저버들의 기능 설명이다. 알아두면 좋은 기능들이 많다.

engine262

JS를 이용해, JS엔진을 만든 프로젝트이다. 거의 대다수의 기능이 구현 되어 있다.

🚀 Visualizing memory management in V8 Engine (JavaScript, NodeJS, Deno, WebAssembly)

V8엔진의 메모리 관리법을 시각화 하여 보여주는 글이다. (GC를 생각해보면, JAVA의 JVM의 GC와도 유사한 느낌을 받았다.)

Monolithic 서버사이드 타입스크립트 세팅 01

Monolithic 서버사이드 타입스크립트 세팅 02

타입 스크립트 세팅에 대한 가이드 글이다. 디렉토리 구조부터 설정 파일들의 내용까지 상세하게 가이드. 단점은 koa를 쓰는 경우 swagger를 쓰지 못할 수 있다. (과거 쓰려고 했으나, Express만 존재)

리덕스를 도입하는데 주저하게 만드는 장벽들 - 1. redux-saga 쓰지 말아야 할 이유

Redux는 현재 가장 인기 있는 상태 관리 라이브러리이다. 전역 single store에서 모든 상태 관리를 한다. 요즘의 추세는 Apollo + graphQL의 조합이 아닐까? 한다. 에어비엔비에서 FE를 하시는 분의 강의 영상이다. 이 영상을 보고 나면 궁금한게 왜 굳이 Thrift layer를 두었을까? 하는 의문이다.

React Router v6 in Two Minutes

React Router v6가 이제 베타 버전으로 나왔는데, 추가 된 기능들에 대해 짧게 짧게 소개 하고 있다. 유용한 기능이 추가 되었다.

Learn CSS Positioning - Ahmad Shadeed

CSS의 position에 대해 그림으로 배울 수 있는 페이지이다. 그림으로 보니 이해가 쉽다.

Java

[MVC Servlet의 모든 것] 자바 EE, Servlet, ServletContext 등 개념

Java EE, Servlet, ServletContext에 대하여 자세하게 설명 한 글.

Design Patterns in the Spring Framework | Baeldung

Spring framework에 녹아 있는 패턴들에 대해 소개 한다. 만약, 스프링 프레임워크를 사용 하는 사람들이라면, 한 번쯤 읽어보면 좋다.

레거시 코드를 점진적으로 개선한 경험

레거시 코드를 어떻게 개선 했는지? 스스로 절차를 만들어 개선한 경험기를 공유하는 글입니다.

Tool

MonoLisa

개발자를 위한 폰트이다. 눈이 편하도록 고안 되었다. (유료)

Redis Client Download

redis client는 주로 유료가 많은데, 해당 툴은 크로스 플랫폼을 지원하는 redis client 툴이다.

그냥 저냥 #위클리뉴스 #68

Sat, 07 Mar 2020 08:53:00 GMT

💻개발자에게 도움이 되는

기술 뉴스 #145 : 20-03-02 :: Outsider’s Dev Story

라인 메신저에서 트래픽을 대응 하기 위해 고군분투 하는 내용, Armeria 관련 글들이 인상적이었다. 그 외에도 재밌는 내용들이 많아 읽어 보길 추천한다.

연봉 2억 5천도 살기힘든 미친동네. 실리콘밸리

실리콘 밸리를 꿈꾸는 사람들이 있다면, 봐야 할 영상. 페이스북, 구글, 아마존에 다니더라도 문제는 샌프란시스코의 집값이 어마어마하게 높다는 문제가 있다. 대략, 10억-20억 연봉을 받으면 편할 순 있을 듯 하다. 근데 그럴 일이 없다. (시니어 엔지니어의 연봉도 3-5억 사이)

ROKROKSS

도커와 가상 머신에 대한 비교 그리고 컨테이너가 어떻게 발전 되어 왔는지?를 정말 자세하게 소개 하고 있으며, 윈도우에서는 어떻게 구현을 하는지도 설명 한다. 자세한 설명이다 보니, 굉장히 OS 영역에 관련 된 정보들이 있어서 이해 하는데 쉽진 않다.

월간 개발자스럽다 #52

이미 소개 했던 글들도 많지만, 많은 이들이 본 글들이기에 다시 봐도 좋은 글들이 많이 있고, 내가 보지 못한 글도 있어서 재미있게 봤다.

라운드 로빈(Round Robin) DNS를 활용한 로드 밸런싱(Load Balancing)

DNS를 이용해 부하 분산을 하는 방법은 처음 봤는데, 역시 내가 모르는 정보들이 정말 많다는 것을 알 수 있었다. 이 방법 또한 장/단점이 모두 있는데, health check에 대한 부분이 가장 핵심이었다.

하루에 1000번 배포하는 조직 되기 | 뱅크샐러드

1000번의 배포를 할 수 있는 조직인가?에 도달 하기 위한 여정을 그린 글인데, 뱅크 샐러드의 개발 철학들이 좋은 방향으로 성장하는 느낌을 받았다. 그러한 부분들이 결국에는 개발자들에게는 이점이 아닐까? 싶기도 하다. 그런 점에서 다양한 기술들을 잘 활용하는 방식이 좋아 보였고, bot을 통해 배포 자동화를 이룩하는 것은 큰 장점이라고 생각한다.

폐쇄망 환경의 배포 시스템 개발기 | 뱅크샐러드

뱅크샐러드의 블로그인데, 이번 글은 폐쇄망 환경에서 쓸 수 있는 배포 시스템 개발한 경험을 잘 정리 해주었다. 선택과 집중을 통해 무엇이 필요하고, 어떤 부분이 중요한지를 잘 선택하는 고뇌가 담겨 있어 좋았다.

원격근무 가이드 총정리

원격 근무에 대한 다양한 글들이 있어서 참고 하기 좋다. 코로나로 인하여 원격근무를 시행하는 곳이 많은데, 나는 좀 더 평소에도 유연하고 자유로운 체계를 가지면 좋겠다는 생각도 있다. 물론, 불편한 점도 있지만 굳이 주 5일을 매일 출근 해야 한다는 것도 큰 비용이라는 생각이다. 꼭 출근만이 업무일까? 회사들의 다양한 근무체계가 생겨나면 좋겠다. 퇴근 했다고 해서 우리가 일을 안하는 건 또 아니지 않는가?

개발자가 공부로 살아남는 방법

참 좋은 글을 많이 써두셨는데, 공부에 관하여 불안함이나 어떤 방향으로 가야 할지 모르겠다면, 읽어보면 도움이 많이 된다. 충분히 고민을 많이 하셨고, 앞서서 다양한 시도를 해 봤기에 나오는 팁들이 아닐까? 생각 한다.

iOS 개발자 싱가폴 이직기

좋은 글을 자주 올려주시고, 번역도 자주 해주셔서 염탐하는데, 이직기를 생생하게 올려주셨다. 사실 이직 안해본 나로써는 아직 두려움의 시도라 생각하는데, 다들 잘 하는 걸 보면 대단하다는 생각이 든다. 물론, 해외에서 일하게 되는건 되게 꿈 같은 일이라 글을 읽으면서 부럽기도 했다.

A half-hour to learn Rust

30분동안 러스트를 배울 수 있는 글인데, 기초적인 문법과 러스트를 잘 설명 하고 있다. 러스트를 배우고 싶다면, 한 번 배워보는 것은 어떨까? 결국, 프로그래밍 언어를 배우는 가장 빠른 방법은 튜토리얼과 언어 컴파일러를 설치 하는데서 시작하는 것 같다? 그리고 "Hello World"

deploy 브랜치 전략 활용 방법

일을 하다 보면, 매번 토론의 장을 만드는 것이 바로 Branch Strategy을 정하는 것인데, 가장 많이 쓰는건 Gitflow일 것이다. 물론, 굉장히 많은 전략들이 있다. 가장 중요한 부분은 자동화 관리 되어야 할 브랜치들은 자동화를 도입하는 것이다. 모든 브랜치를 수동 관리 하는 것은 어렵다. 그와 관련 되어 고민을 통해 만든 deploy 브랜치 전략에 대한 당근 마켓의 일화이다. 읽어보면 도움이 많이 된다.

Container

Istio를 활용해 Multi Cluster 환경에 Service Mesh 구성하기

Istio를 활용해서 멀티 클러스터 환경에서의 서비스간 통신이 가능함을 실제 예제를 보여주며 설명하고 있다. Service Mesh가 무엇인가? 감이 잘 오지 않는다면, 쿠버네티스 서비스 메시 기술, ‘이스티오’란?, Service Mesh란? 두 링크를 확인 해보자.

💻Front-End

나는 프론트엔드를 안다고 말할 수 있을까?

내가 생각하는 개발자 중에서 글을 정말 잘 쓰시는 분인데, 이 분도 이러한 고민을 안고 살아간다는 점은 나에게 좀 적잖은 충격이긴 했다. 나는 실질적으로 풀스택 개발을 하고 있는데, 농담처럼 하는 말이 하나 있다. "하나도 잘 하기 어려운데, 둘 다 해야 되니 둘 다 결국 못하는 사람"이라고 말하곤 한다. 항상 고민이었던 물음이었다. 그런데 어떻게 생각해보면, 개발자라는 범주 아닐까? 라는 생각을 한다. 퍼블리셔의 내용이 나왔으니 하는 말이지만, 쉽게 말하면 마크업(퍼블리싱)에 대한 부분도 개발자라 생각 한다. 수준 높은 마크업을 만들어 내는 사람들은 정말 적다. 그럼에도 그들은 스스로 개발자라 불리는 것이 익숙치 않은데, 나는 이게 문제라 생각 한다. 무언가 만들어 내는 역할을 지녔다면, 개발자 그리고 내가 어떤 영역에 앎과 모름에 대한 부분은 모든 것에 있어서 상대적이다. 잘함에 대한 부분도 마찬가지다.

Redux에서 Normalize 다루기

현재 내가 일하는 곳에서 Nomalize를 잠시 고려를 하기도 했었지만, 사실 구조적으로나 심리적인 요인에 의해 정규화를 하기는 어려웠다. (물론, 지금은 또 다를 수 있다.) 하지만, 변하지 않는 진실 하나는 결국 어떤 목적을 가지고 어떤 방향으로 나아가는지? 정답이 아닐까? 생각 한다. 본문에 써 있듯이 정규화가 모든 상황에 정답은 아닐 것이다. 예전에는 필요 없었다고, 지금은 필요하지 않은 건 또 아니다. (그래서 어렵다.)

2020-02-25: TypeScript 3.8 정식 릴리스, ESLint 7.0.0 변경 예정 사항

JavaScript와 관련된 기술 뉴스를 큐레이션 하는 주간 블로그이다. 2월 글이긴 하지만, 관심 있는 글들이 있어서 가져왔다. TS3.8이 릴리즈 되었는데, 실무에서 아직 적용을 하진 않았다. 그치만, 3월 내로 적용하면 쓸만한 것들이 있어 보였다.

🛠Tool

ytdl-org/youtube-dl

CLI에서 유투브 영상을 다운 받을 수 있도록 해주는 툴이다.

Bashhub · Every command.

Bash의 히스토리를 Hub에 올리는 건데, 사실 좋은가? 싶기도 하다. (peco를 잘 쓰면 된다.)

Download Blisk - a browser for web developers

개발자를 위한 브라우저인데, 써 봐야 좋은지? 안 좋은지? 알지 않을까? 크로미움 기반이다. 장점은 확실히 있어 보여서 써 보려고 한다.

Compare salaries and career levels across companies | Levels.fyi

외국 회사의 연봉과 레벨에 대한 정보를 알 수 있는 페이지이다.

🤟🏻일반적인

협업에 관하여

"모든 일에 참여해서 하나부터 열까지 같이 하는 것이 협업이 아니다. 협업이란 프로젝트에 참여하는 사람들의 전문성을 레버리지(leverage) 하는 것이다." 이 글에서 협업의 진짜 목표를 알게 되었다. 윈윈 하는 방법에 대해 정말 잘 소개 하고 있고, 예시를 통해 어떤 오해를 하게 되는지? 소개 한다.

그냥 저냥 #위클리뉴스 #67

Mon, 02 Mar 2020 19:11:00 GMT

👍🏻개발자들에게 도움이 되는

3 DevOps Trends to Watch in 2020

2020년의 DevOps의 3가지 트렌드인데, 프로젝트 관리 / 알림 (경고) / SaC(Security as Code)로 3가지를 압축했다. 사실, 트렌드라고 하지만, 예전부터 어느 순간 드러나던 주제이기도 했다.

How 1500 bytes became the MTU of the internet

ethernet이 1500MTU를 쓰게 된 계기인데, 사실 내용이 쉽진 않았다. (영어)

What 8 years of side projects has taught me | Jungle Coder

8년간 사이드 프로젝트의 경험을 통해 배우게 된 내용에 대한 정리가 잘 되어 있다. 그런데, 진짜 중요한 포인트는 어떤 목적이 있는지?가 더 중요하다.

개발자 찾아 삼만리

개발자를 어떻게 하면 잘 채용할 수 있을까?에 대한 깊은 고민과 함께 방법에 대한 고뇌들이 잘 녹아 있다. 물론, 쉬운 일이 아니지만, “어떻게?” 해야 할까?에 포인트를 정말 잘 맞추었다고 생각 한다.

스타트업 기술 블로그 모음을 만들며

3일간 작업 했던 기술 블로그 모음 개발기를 써주셨는데, 원티드에 올라온 회사 목록을 하나씩 다 찾아 수집을 하며 겪은 후기이다. 나도 물론 프로그래밍 관련 큐레이션을 하고 있지만, 생각보다 수집하는게 쉽지 않은데, 이런 글 타래들을 엮어 주는 서비스들이 많이 나오는 것 같다. 메일로 보내주는 서비스도 있고, 그런데 이런 글들을 보면 볼 수록 나도 만들고 싶은 생각이 좀 있다. (연습할 겸?)

VGraupera/1on1-questions

원온원 미팅에 대한 질문 리스트인데, 테크리더이거나, 매니저 직급이라면 꼭 보면 좋겠다.

23 rules to run a software startup with minimum hassle

소프트웨어 스타트업을 운영할 때 번거로운 일들을 줄이는 23가지 (국)룰을 소개하는 글이다. 일부는 동의 하는데 일부는 잘 모르겠더라.

[2019] 200만 동접 게임을 위한 MySQL 샤딩

MySQL을 쓰고 계신 분들이라면, 샤딩에 관한 좋은 정보를 얻을 수 있다.

깃(Git) 개념과 상황별 팁

커밋 단위를 정말 작게 쪼개어 커밋 하는 습관을 들이려면, add -p를 통해 hunk 단위로 커밋 하는 것을 좀 연습해야 하는데, 사실 쉽지는 않다. Git을 사용하면서 상황별 팁이 잘 소개되어 있는 글이다.

쿠스의 개발이야기 - 다음 회사에서는 이렇게 해봐야지

퇴사한 분이 쉬면서 작성 하신 글인데, 어떻게 회사 생활을 하는지에 대한 고민이 담겨 있는 글이다. 인상 깊은 부분은 문제 발생시, 공론화 하고 실제 해결을 위한 노력을 하는 부분인데, 많은 공감이 갔다. 나도 문제가 발생하면, 혼자 욕하는 게 전부 였는데, 왜 나는 노력 할 생각을 못했나 싶기도 하다. 공론화 하고, 같은 방향성을 지닌 사람들이 있다면, 해결 하면 된다. 올해의 작은 목표가 되지 않을까? 싶다.

The Developer’s Way

"모두가 코딩을 배울 필요는 없다"라는 영상이다. 짧기 때문에 직접 보면 좋다. 무언가 기술을 잘 활용하는 것도 방법이라는 생각이다.

타다 웹 프론트엔드의 모든 것

타다에서는 monorepo를 활용하고 있는데, 여러 개의 프로젝트를 하나의 레포지토리 안에서 관리하고 있다. 물론, 각 규칙이 잘 정리 되어있다. 정말 구조화를 잘 하고 있다는 생각이 들었다. 물론, 실제로 내가 일 해본 환경이 아니라서 잘 와 닿진 않지만, 장점/단점이 모두 있지 않을까? 생각 되기도 했다. ( Protobuf는 요즘 많이 쓰는 ? 일종의 트렌드 같긴 하다. 일종의 인터페이스 정의 언어로 관리 하고 있는 부분이 신기하면서도 생소 했다.monorepo, Protobuf 구글이 정말 지대한 영향을 끼치는 회사라 생각 된다.)

3년 후, 다시 만난 기능 공장

🖥JavaScript

[Testing] 0. React Testing 시리즈를 들어가며

[Testing] 1. 프론트엔드, 무엇을 테스트 할 것인가

[Testing] 2. 프론트엔드, 어떻게 테스트 할 것인가

[Testing] 3. Store와 비즈니스 로직 테스트

[Testing] 4. 컴포넌트 테스트와 검증

[Testing] 5. 여러 테스팅에 대한 단상

테스팅에 관하여, JBEE님이 작성해주신 시리즈 글인데, 진짜 상세하게 잘 써 있어서 꼭 꼭 참고 했으면 좋겠다.

Vue.js: The Documentary

Vue.js의 창시자인 Evan You 인터뷰에 대한 영상이다. (영어)

🖥Java

Spring RestTemplate Mock 기반 테스트 하기

RestTemplate의 Mocking하여 테스트 하는 방법에 대한 글이다. 왜 테스트를 해야 하는가?에 의문이 있는 사람들도 있겠지만, 테스트 코드를 작성하는 습관은 좋다고 생각 한다. 나도 습관화가 안되어 있지만, 최대한 작성 하려고 노력 해야겠다고 결심했다. 그리고 스프링 기반에서도 테스트를 잘 도와주는 라이브러리, 테스트 프레임워크들을 잘 활용 하자!

🤟🏻일반적인

네이버 지도 vs 카카오맵 사용자 경험 비교(PC)

네이버 지도 서비스와 카카오맵의 사용자 경험 비교인데, 사실 각 영역별로 비교를 하고 있는데, 실제로 사용자 시나리오에 대한 UX 비교가 더 있었으면 좋겠다. 단순한 UI의 비교에 지나지 않아 아쉽기도 했다.

진짜 대박이라면, 소액으로도 대박을 칠 수 있다

결국 깨어있음이 투자의 성공이 아닐까? 생각 하기도 한다. 물론 포트폴리오의 다각화는 중요하다.

좋은 말을 곱씹는다는 것

계속 옲조리면 된다는 저자의 문구가 참 인상 깊었다. 살면서 조심스럽지만, 항상 경계해야 할 부분이 되는대로 산다. 같다.

사이드 프로젝트의 정석

사이드 프로젝트의 예를 윤종신 10년이 넘도록 진행 해오는 윤종신의 일화를 소개하고 있다. 결국에는 본업 하면서도 사이드적인 자신만의 강점을 지닐 수 있는 훈련을 해야 한다는 의미로 받아들였다. 생각해보니 나는 항상 필드만 뛰는 선수였지 않았나? 생각 한다. 필드를 뛰는데 연습을 하지 않으니 곧 다치거나, 골을 먹히는 사람이 되겠구나..느꼈다. 사이드 프로젝트는 필수구나!

‘꼰대’와 ‘스승’의 차이

"하나는 전달 방식이다. 듣는 사람의 입장을 고려해 말한다.", "다른 하나는 자기 자랑의 의도가 없다는 점이다." 두 문장으로 압축 할 수 있으며, 그 차이를 잘 설명하고 있다.

최근 읽은 인사이트 넘치는 칼럼 3편 소개

박병은님이 남기신 칼럼의 인용 문장이 와 닿았다. 마이크로 매니징을, 디테일로 착각하지 말자. 진짜 디테일은 지시받은 사람이 미리 명확하게 알 수 있게 설명해주는 것을 말한다. 작은 꼬투리를 잡는 것이 아니다. 이 문장이 국내 많은 회사에 있는 리더들에게 전달 되어야 할 문장이 아닐까? 싶다. 나머지 칼럼들도 읽어보면 유익하다. 문병로님의 기초 확립 과정에 대한 부분, 상당히 중요하다.

일을 하면 일하는 티를 내보자

일 하는 티를 어떻게 낼 것 인가?에 대한 글이라기 보다는 방법에 대한 이야기로 보면 좋겠다. 나는 이런 스타일인데, 어떻게 하면 더 효과적 일지에 대한 내용으로 읽어보면 좋겠다. (물론, 나의 칭찬이 남의 입에서 나오게 하는 것은 무조건 중요하다.)

‘잘하고 싶어서’의 모순

잘 하고 싶은 마음이 꼭 매번 걸려 넘어지게 만든다. 그리고 옥죄어 오는 마음 중에 하나라 생각 한다. 내려 놓을 수록 더 빠르게 갈 수 있다는 것을 왜 까먹는지 모르겠다. 이 글을 쓴 사람도 그렇지 않았을까? 생각 한다.

치앙마이 한 달 살기를 꿈꾸는 당신이 꼭 봐야 할 15가지 질문

개발자들의 한달 살기가 치앙마이를 많이 보게 되는데, 그 다음이 싱가폴인데, 싱가폴은 물론 물가가 엄청날테고, 치앙마이가 가장 한 달 동안 여행하기 좋은 곳이 아닐까 한다. 물론, 비수기는 별로일 것 같고, 성수기 시즌에 앞서서 딱 한달 다녀오면 좋겠다. 치앙마이 한달 살기에 대한 꿀팁들이 잘 정리 되어 있다.

사람의 능력 보는 법: 주변인을 보자

결국 사람이 나이 들수록 얻어야 하는 것은 사람인가? 싶기도 하다. 결국, 혼자 사는 세상이 아니라는 말이다.

그냥 저냥 #위클리뉴스 #66

Mon, 24 Feb 2020 23:28:00 GMT

🙏🏻개발자가 보면 좋은

개발자 직장생활과 실력향상 관련 좋은 글

조대협님의 글과 임백준님의 칼럼 두 글을 같이 인용한 글이다. 확실히 다 맞는 말이다. 하나를 선택 하라고 한다면, "모든 것을 알아야 한다는 강박을 버려라"를 선택하고 싶다. 자칫하면, 함정에 빠지기 쉬운 것이 지식의 학습 욕구이다.

How to read technical books

기능 공장에서 일하고 있다는 12가지 신호

몇 개의 부분들을 빼고 나면, 내가 속한 회사의 모습이긴 했다. 역시, 기능 공장에 해당 하는 회사인가? 싶기도 했다. 그럼에도 불구하고, 이 곳에서의 장점은 확실하게 있긴 하다. 이 안에서 조금씩 변화를 만들어 가는 것이 좋다고 생각 한다. 하나씩 변화를 주는 방법을 찾아야겠다.

[번역] 마틴 파울러 CQRS 포스팅

CQRS에 대해 핵심을 정말 잘 설명하는 글이라고 생각 한다. 원문으로 읽어 보는 것도 추천한다. 물론 어렵긴 하다.

원티드 제품 개발 5년의 기록

원티드 서비스가 커 온 발자취를 알 수 있는 글인데, 정말 빠르게 서비스를 키워내고, 선택과 집중을 정말 잘 하는 기업이 아닌가? 라는 생각을 했다. 사실 서비스 중심의 회사는 잘 할 수 있는 것과 굳이 하지 않아도 되는 부분들을 잘 구분 하는 것이 중요하다는 생각을 한다.

처음 발표를 준비하는 개발자들이 알아두면 좋을 것들

발표에 대한 A-Z를 정말 잘 정리 해주셨다. 발표를 할 기회가 있다면 꼭 이 내용을 숙지 하도록 하자.

들어는 보았나 몹 프로그래밍!

페어 프로그래밍도 해본 적 없는 나에게는 생소하지만, 몹 프로그래밍을 하게 되면, 좋은 경험을 많이 하게 될 것 같다. (약간은 부럽기도 하다. 물론, 막 검색하고, 그런 취향이 있기 때문에 민망할 것 같기도 하다.)

배달의민족 최전방 시스템! ‘가게노출 시스템’을 소개합니다. - 우아한형제들 기술 블로그

Spring framework 5의 WebFlux를 정말 잘 쓰는 조직이 아닐까? 하는 생각이 이 글을 읽고 난 뒤에 깨달음이었다. 나는 기술을 이렇게 쓰고 있는 걸까? 하는 이유 모를 부끄러움도 있었다. 나는 어쩌면, 굉장히 얕은 수준의 기술만 쓰는 사람 인지도 모르겠다는 생각과 함께 이런 고차원적인 방법도 중요하구나? 라는 생각을 하게 되었다.

코로나인포 개발기: 프론트엔드 편

코로나 바이러스 관련 정보를 위한 코로나 인포의 프론트엔드를 담당 했던 분의 개발 공유이다.

Illustrated.dev

일러스트를 통해 웹 개발에 대해 설명을 하고 있는데, 퀄리티가 좋고 그림으로 이해할 수 있어서 정말 좋다.

자바스크립트 성능 향상 방법

일전에 공유 했었던, 자바스크립트 성능 향상 방법의 번역글입니다.

patch-package를 활용한 NPM 패키지 패치(patch) 사례 (feat. React Native)

의존하는 모듈의 수정을 한 경우에는 어떻게 관리를 해야 할까? 하는 고민이 있을 때, 참고 하면 좋겠다. 물론, 오픈 소스를 주로 사용하니 직접 수정 PR을 보내는 방법이 있는데, 시간이 급한 경우 정말 유용하지 않을까?

코로나 실시간 뉴스 알림 챗봇 만들기 COVID19NEWS BOT

크롤 방식 보다는 RSS를 이용해 다음 뉴스 데이터를 가져오는 방식을 이용하여 키워드에 대한 뉴스 알림 봇을 개발한 경험기 공유이다.

안심번호 마이크로서비스 개발하기

당근 마켓의 안심 번호 마이크로 서비스 개발하며, 겪은 점이 정리 된 글이다. 다만, 왜 gRPC로 통일 하려고 하는지는 잘 모르겠다.

IT기자, 개발자로 돌아오다…CODEF 합류 10개월 후기 - 오세용닷컴

IT기자에서 개발자로 다시 돌아와 일 한 후기에 대한 글인데, 난 이런 경험 같은 글들이 많아 졌으면 좋겠다. 경험은 사실 귀중한 자료이기 때문에, 감정이나 어떤 노력에 대한 부분들이 더 자세 할 수록 좋다고 생각 한다.

오픈서베이 개발팀은 어떤 과제를 해결하고 있을까?

시스템 구조와 회원 시스템 개편에 대한 공유 글이며, 쉽지 않은 일들은 해내는 개발팀이구나!라는 생각을 하게 되었다.

멀티 쓰레드 프로그램 설계를 위한 8가지 규칙

동시성의 예술이란 책의 4장에 나오는 내용을 번역한 글입니다. 이 책의 번역본을 찾아 봐야겠다는 생각을 하게 되었습니다.

🖥Java

Querydsl Projection 방법 소개 및 선호하는 패턴 정리 - Yun Blog | 기술 블로그

QueryDSL Projection에 대해 선호 하는 패턴 정리 글인데, 써보진 않아서 와 닿지는 않지만, JPA + QueryDSL을 쓴다면, 이 글을 참고 해보는 것도 좋겠다.

Spring WebFlux와 Armeria를 이용하여 Microservice에 필요한 Reactive + RPC 동시에 잡기

Spring framework5의 WebFlux와 Armeria에 대해 잘 소개 하고 있는 글이며, RPC를 쓰면 왜 성능이 더 빨라지는지에 대해서는 설명이 없어서 조금은 아쉽다.

💻JavaScript

타입스크립트 기초 연습

리액트를 쓰면서 TypeScript를 안 써 본 분들이라면, 이 글을 읽고 적용 해보는 것도 좋아 보인다. 자세하게 잘 정리 되어 있다. 물론, 리액트를 공부 하는데에는 타입 스크립트가 굳이 필요하진 않다.

🛠Tool

evanw/esbuild

go로 개발 된 번들러인데, 속도가 정말 어마어마하게 빠르다고 벤치 마크에 나와 있다.

m3db/m3

우버에서 개발하여 오픈 소스로 만든 메트릭 솔루션인데, 시계열DB까지 모두 오픈 소스로 공개 했다. 프로메테우스랑도 연동이 가능해보이며, 쿼리 엔진까지 탑재 되어 있다.

heelhook/chardin.js

이미지 위에 사용법에 대해 설명 하는 레이어를 오버레이 형태로 표현 할 수 있게 해준다.

Panolens.js

360도 파노라마 뷰 JavaScript 라이브러리이고, 해상도가 높은 이미지에 적합하다고 생각 한다.

getgauge/taiko

Node.js 기반의 웹 테스팅 라이브러리인데, smart selector와 레코딩 기능이 탑재 되어 있어, 간편하게 만들어 코드를 통해 지속적인 테스팅을 할 수 있어 좋아 보인다.

그냥 저냥 #위클리뉴스 #65

Sun, 16 Feb 2020 21:25:00 GMT

👍🏻개발자가 보면 좋은

견고한 node.js 프로젝트 설계하기

Node.js 프로젝트 관련 되어 읽어보면 좋을 글입니다. 자세하게 구조부터 설명을 하고 있습니다. 유용한 npm module도 적절하게 사용하며 설명을 하고 있습니다. 특히, 백그라운드 작업에는 PubSub패턴을 쓴다는 게 참 좋아 보였다. 사실 써 본 적은 없는데, 요즘 관심을 많이 갖고 있다.

깃 사용자가 가장 흔히 저지르는 6가지 실수와 대처 방법

Git을 사용하다가 깜빡하는 경우들이 있는데, 그런 경우들에 딱 맞는 6가지 상황에 대해 해결법을 가이드 하고 있다.

[개발] 주니어 개발자가 공부하는 방법

10개월 간의 학습을 통해 사이드 프로젝트등을 진행하고, 틈틈히 지식을 쌓아 올리는 모습을 엿볼 수 있는 글이었다. 끊임 없는 노력만이 결국, 결과를 만들어 가는 과정이라 생각 했다.

온디맨드 이미지 리사이징 (Ondemand Image Resizing) 원리 및 예제

온 디맨드 이미지 리사이징에 대해, Java, Node.js로 이미지 업로드, 다운로드, 이미지 리사이즈등을 직접 코드로 보여주며 설명하고 있는 글이다. 그런데, 왜? 온디맨드여야 하는지? 설명하는 이유가 개인적으로 정말 좋았다.

기술 뉴스 #144 : 20-02-15 :: Outsider’s Dev Story

아웃사이더님의 기술 뉴스 #144 : 20-02-15이고, 구글의 API 설계에 대한 결정 사항을 정리 한 문서가 좋았다. 생각 해보면, 구글은 공유를 좀 잘 하는 문화가 형성 되어 있는 느낌을 자주 받는다. "마켓컬리 기술 블로그를 다시 디자인하며"라는 글을 보면서 종립님이 주도 하고, 그로 인하여 다른 이들에게도 영향을 끼치는 그 첫 시작에 대한 태도가 참 부러웠다. 그리고, 그 많은 사람들이 동참을 해준다는 것에 나는 부러움을 느꼈다. 다른 분들도 어떤 시작에 대한 용기를 품었으면 좋겠다. 나의 올해 목표가 무엇이라도 내가 먼저 시작하는 것이 목표이다.

💻Java/Back-End

JPA 선호하는 패턴 - Yun Blog | 기술 블로그

JPA를 쓰지 않는 나로서도 관심을 갖는 이유는 언젠가? 도입 할 수만 있다면, 팀에 도입 해 보는게 난 좋다고 생각한다. 요즘 Query DSL이 좋기 때문에, 사실 굳이 안 쓸 이유도 없을 것 같다는 생각이다. 이 글은 JPA를 실제로 오랜 시간 써보고 자신만의 생각을 정립 한 글이라 읽으며, 많은 도움이 되었다.

💻JavaScript/Front-End

[2019] 실용적인 프런트엔드 테스트 전략

프런트 엔드 테스트에 대한 영상인데, 40분 정도이지만, 굉장히 알찬 내용들이 많이 포함 되어 있다.

ECMAScript ES2016~ES2020 정리

Optional Chaining, Promise.allSettled등 좋은 기능이 많이 추가 되어, 코드를 작성하기 더 수월 해졌다. 점점 JS도 Null Safe한 구문을 많이 추가 되지 않을까? 한다. (~~개인적으로 Kotlin이 요즘 좋더라~~)

yjs03057/33-js-concepts

33개의 JS 필수 개념이라고 하는데, 솔직히 나도 완전하게 알지 못하기 때문에, 해당 영역별로 공부를 좀 해야 할 듯 싶다. (영상 이런 건 좀 빨리 봐도 이해는 하지 않을까?)

React Internationalization wit i18n - RWieruch

React로 다국어 처리를 어떻게 할까?의 궁금증이 있었는데, i18n 모듈이 있었다. 이 블로그에서 어떻게 처리를 하는지? 코드로 설명을 하고 있으니 입문 정도의 구경을 할 수 있을 것이라 생각 한다. (~~그런데, 도통 쉽지 않을 듯 하다.~~) 백엔드의 구성도 중요하지 않을까? 싶다.

🙌🏻일반적인

‘회사 일’이 아닌 ‘내 일’을 해야 하는 이유

결국, 회사 일만 하는 것은 바보 같은 일 아닐까? 라는 생각을 가끔 하게 된다. 회사가 매년 연봉 인상률을 기본 10-15%를 보장하는 것도 아니니까. 그리고 애초에 연봉 상한선이 있는 대한민국에서 월급쟁이로 살기엔 팍팍하다. 그럴려면, 결국 회사는 회사 일로 끝내야 맞다. 요즘 그런 생각을 자주 하게 된다. “항상 나의 일을 만들어서 준비 해야 하는 시간도 필요하다고..”

조직을 유지하는 힘, 동기부여 방법 3가지

결국 직원이 바라는 것은 많은 것이 아닌, 정당하게 일 하고 정당한 보수를 받는 것과 적절한 목표 설정 그리고, 기회를 주는 것이다. 내가 생각 할 때는 그 정도인데, 무능한 사람들이 높은 보수를 받고, 무책임한 행동을 많이 보게 될 때마다, 좌절 하는 것 아닐까? 하는 생각을 하는 편이다.

모험, 동경, 꾸준함에 관하여

결국 꾸준함이라는 것이 성장 동력이 된다는 믿음이 예전에는 그저 그랬는데, 요즘에는 확신한다. 어떤 재능보다 중요한 무언가를 선택하라면, 꾸준함이다. 결국 꾸준히 하는 것이 대단함을 만들어 내는 것 같다.

성공하고 싶다면, 20대에 생각할 일

성공이라는 것은 멀리 있는 것은 아니라는 생각을 요즘 들어 한다. 사업이라는 것도 사실 작게 보면, 내가 월급 받아 삶을 꾸려 나가는 것도 어쩌면, 삶의 사업이듯이, 내가 가진 아이디어, 자본등으로 돈을 벌어 경제적인 소득을 얻는 것도 유사하지 않을까? 라는 생각을 한다. 모든 방향성에 깨어 있는 것이 좋다고 생각 한다.

좋은 책 고르는 법 5가지

나만의 책 구입 철학은 표지가 이쁜지? 제목이 와 닿는지? 광고에서 자주 보이는가? 사람들이 많이 읽는가? 혹은 유명한 이가 추천한 서적인가? 주변인이 추천 하는지? 정도 였는데, 글을 읽으면서 생각해보니 나름 나만의 철학이 투영 된 책 고르기였다.

워런 버핏에게 배울 7가지 비밀

확실히 투자의 귀재가 된 이유가 있다. 물론, 시대적인 배경으로도 도움을 어느 정도는 받았으리라 생각 한다. 그 부분을 제외 하더라도, 워렌 버핏은 투자의 전문가이다. 다량의 정보 속에서 원하는 지식을 쌓아, 엄청난 판단력을 통해 움직이고, 나의 것이 아니면 투자 하지 않는 철칙이 있었는데, 그 철칙은 일반인이 갖기 어렵다. 그의 재능이라 생각하는 영역이다. (코인 붐일때, 돈 잃은 사람이 더 많다.)

⚡성장에 대한 의문, 의문에 대한 성장

Sat, 15 Feb 2020 09:53:00 GMT

신입 개발자 때부터 쓰던 글들이 어느덧 신입 개발자를 지나 4년 차 개발자가 되었습니다. ~~깨알 홍보~~

가끔 일을 하다가 나도 모르게 신입 개발자 티를 못 벗은 태도를 갖출 때도 있어,

이따금 부끄러워질 때가 있었습니다.

그런데, 요즘 들어 굉장히 다양한 기술들, 그리고 개발자 성장에 관한 이야기들에 곰곰이 고민을 많이 하는 시간을 가졌습니다.

그러고 보니 작년 한 해에는 많은 글쓰기를 하지 못했습니다. 이유는 성장에 대한 집착이 있었고,

그로 인한 두려움이 나를 옭아 매어 오히려 성장을 더디게 하는 시간이었습니다.

놀라게 되는 순간들.

많은 시간들이 지나고서야,

“나도 성장이란 걸 안 한 줄 알았지만, 성장했구나!”라고 깨닫는 순간도 경험했죠.

물론, 그 시기엔 이미 많은 마음을 내려 둔 상태였습니다.

그래서 그때 더 깨닫게 되었을지도 모릅니다.

작년 한 해, 팀원들이 많이 들어오고,

유능한 개발자를 팀원으로 맞이 할 수 있어서 영광이기도 했고,

좋은 경험이 되는 시간들이었습니다. 그런데, 잘못 생각을 하기 시작했습니다.

왜? 나는 성장하지 못할까?

이 정도면 더 빠르게 분석도 하고,

코드도 더 깔끔하게, 빠르게 테스트 코드도 짜고 그래야 할 것만 같은데,

그렇지 못했습니다.

📖기술의 반란 그 사이.

쿠버네티스는 나오고, 리액트는 빠르게 진보하고 있었습니다.

내가 할 줄 아는 것보다 다른 개발자분들의 블로그를 보고

공부하면서도 “아, 내가 너무 나태했구나” 하며. 시간을 보냈습니다.

그렇게 느끼다 보니, 아주 나락으로 떨어지기 시작 했습니다.

😬조급함, 불안함 그 언저리 어딘가.

왜 내가 하는 것마다 QA에서 번번이 버그가 나오고 하는 것인지.

야속하게도 전환 프로젝트나, 서비스 리뉴얼을 하면서 그 괴리감이 나날이 발전했습니다.

다른 팀원은 이렇게나 빠르게 적응하고, 잘해가는데, 왜? 나는 가만히 서 있는 것인가? 에 대한 의문이었습니다.

위클리 뉴스를 매주 해야겠다. 이거라도 해야지.✍️

주말에 코드도 작성 안 하잖니? 스스를 채찍질했습니다.

그리고, 좋지 않은 일들이 지난 뒤에 많은 생각을 했습니다.

나 스스로도 이 것을 왜 하는지? 하는 이유가 무엇인지?

그 전에는 이유가 없었습니다. 그냥, 경쟁이라 생각했습니다.

생각해보니 협업이라는 큰 틀 안에서 개발자들은 살아가고 있습니다.

업무도 마찬가지였습니다.

“지금 누가 누구보다 더 많이 알고, 도구도 더 잘 쓰고 하는 것들이 중요한 게 아니구나.

내가 무엇을 지금 하고 있는지? 앞으로의 이 지식이 계속 쓰일 리 없다.”라는 사실을 망각하고 있었습니다.

결국, 개발자는 사람과 일 해야 하는 직업이구나.

그럼, 무엇이 더 중요한가? 내 성장에 의문을 품지 말자.

“시간이 갈수록 결국 성장하고 있다.”

그 길이 천천히 가는 길일지? 빠르게 가는 길일지? 는 알 수 없지만, 결국 성장하고 있다.

과정에 집중하면 결과는 항상 긍정적이구나.

그리고, 새로운 것들에 대해, 기존에 알고 있던 것들에 대해 많이 고민하고, 생각하는 시간을 가졌습니다.

“나도 새로운 것들 좀 써보고 싶다.”

새로운 것을 써 봐야하는 마음에 대한 의문들도 사라졌습니다.

“새로운 기술을 바라보는 것은 관점을 바꾸는 일이라 어려운 일이구나.”

늘 하던 대로, 늘 생각하던 그대로 생각하면 안 된다.

물론, 기존의 내가 가진 기술도 마찬가지다.

하던 대로 하면, 늘 하던 그 수준에 머무른다.

그리고, 왜 이렇게 레거시가 계속 쌓여가는 거야?라는 의문에는 또 답이 생겼습니다.

어딜 가나, 레거시 코드는 있고, “오늘 내가 작성한 코드는 내일모레 즈음 레거시가 된다.”

~~유지보수라는 업무를 해보지 않은 개발자랑은 별로 일을 “안” 하고 싶다는 생각도 하게 되었습니다.~~

유지보수라는 업무가 굉장히 중요하다는 생각을 하게 되었고, 이것도 잘하는 것은 성과구나.

~~(회사는 생각이 다를 수도)~~

새로운 것만이 “성장”일리 없다.

레거시, 사이사이 기존 스펙과 추가해야 할 스펙 사이를 오고 가는 시간이 나에게는 필요하다.

나도, 계속 이렇게 레거시 사이를 누비는 시간을 보내오고, 새로운 것들을 적용하는 시간도 보내고 있다.

성장이라는 물음에 대해서는 진짜 무엇인지에 대해서는

내 생각에는 어쩌면, 긴 시간이 필요할 수도 있다.

여기, 이 위치에서 질문에 대한 나의 자문자답은 여기까지.

늘 내 생각이 정답 일리 없고, 항상 문제가 생길 수 있는 요소를 고려해야 한다.

“항상 겸손해야 하고, 감정은 빼고, 일 하는 것이 중요하다”

2020년 올해, 매일 아침 출근하면서 생각하는데, 매일매일이 어렵다.

Ansible Error 경험을 털어 놓아 보자.

Sat, 08 Feb 2020 23:22:00 GMT

예약어를 변수명으로 썼을때 이슈

예약어가 존재하는데, 예약어를 변수명으로 쓰면 arguemtns를 넘겨줘도 값 대입이 안된다.

ex)
host_vars/main.yml
role: “{{ role_name}}”

해주고, -e “role_name=test” 했더니 값에 role에 해당하는 이름이 계속 들어가서 알게 됨.

ansible -m shell 모듈 관련 (help)

ansible -m shell로 tomcat을 실행하는 쉘 스크립트를 동작하게 모듈을 실행 하고 난 뒤에, 끝나면 꺼지는데, nohup을 같이 줘야 하는 이유는 왜일까…?

shell script file자체가 deamon 구동으로 실행 하도록 &를 주었는데도 막상 앤서블로 실행 하면 모듈 실행 이후 process가 꺼지고 만다.

이 부분은 검색을 해야봐야 할 것 같은데, 막상 문의를 해보아도 뚜렷한 답을 잘 모르겠다. 이 부분때문에 logstash를 모두 서비스로 등록 해서 써야 할 위치에 놓여있다. 큰일이다. 쉬운 방법 없을까?

roles 하위 role에 remote_user 지정 경고

[DEPRECATION WARNING]: Using 'remote_user' as a role param has been deprecated. In the future, these values should be entered in the `vars:` section for roles, but for now we'll store it as both a param and an attribute..
This feature will be removed in a future
release. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.

단, ansible_user로 셋팅하면 동일하다. 그리고 ansible core 소스를 까봐도 동일하다.

ansible 요약

https://gist.github.com/andreicristianpetcu/b892338de279af9dac067891579cad7d

typo error

단순하지만, 삽질을 오랜 시간 만드는 예약어 오타 이슈이다.

{"msg": "The conditional check 'setup is defiend' failed. The error was: template error while templating string: no test named 'defiend

도대체 에러가 왜 나는 것인가? 계속 찾아 봤는데, 에러 메세지 속에 힌트가 있다. 오타였다.

when에 들어 갈 수 있는 예약 키워드를 잘 기억 해두자.

ref. https://docs.ansible.com/ansible/latest/user_guide/playbooks_conditionals.html

is not defined
is defined
is undefined
is succeeded
is skipped
is failed

헷갈리지 말자.

그냥 저냥 #위클리뉴스 #64

Sat, 08 Feb 2020 23:10:00 GMT

💻개발자들이 읽어보면 좋을

SSH 프로토콜과 Tunneling 이해하기

SSH 프로토콜과 터널링에 관한 자세한 글인데, 읽어 보면 좋다. SSH 프로토콜이 MAC알고리즘을 쓰는 건 처음 알게 되었다.

Git Workflow | Atlassian Git Tutorial

팀원분이 공유해준 git workflow에 관한 글인데, 상당히 자세하게 써있고, SVN과 GIT을 비교하며 설명을 하고 있다. 물론, 현재는 Git을 정말 많이 쓰고 있다. SVN을 모르더라도, 읽어보면 좋겠다.

UIUX가 서비스 기획을 망쳤다!

확실히 이 글에 대한 주장도 맞는 말이지만, 내 생각에는 항상 옳다고 생각하는 고정관념적인 부분들이 기획을 망친다고 생각한다. UI/UX가 서비스 기획을 망치는 것이 아니라, 전반적인 문제를 잘 포착해야 하는 것이 더 필요하다고 생각한다. UI/UX가 뛰어나다고 서비스가 잘 되거나, 트렌디함을 갖는 것은 아니라고 생각 한다. 결국서비스의 중요한 부분을 잘 파악 하는 것이 좋다고 보고, 따라 하지 않음의 미학도 좋다고 생각 한다.

Writing Safe Shell Scripts

쉘 스크립트를 작성 하다보면, 참 작성하기가 여간 까다롭다. 역시 다 방법은 있었다.

인터넷이 동작하는 아주 구체적인 원리

인터넷이 작동하는 TCP socket이 지나가는 네트워크, DNS, HUB, Router에 대한 설명이 자세하게 쓰여 있다.

[NDC16] Effective Git

솔직히 진짜 너무 정리가 잘 되어 있어서, 감탄 했다. 특히, bisect는 몰랐던 기능 중에 하나인데, 실제로 실무에서 build CI를 통과 했는데, 정상적인 실행에서는 오작동을 일으키는 커밋이 들어간 적이 있다. 그 커밋을 찾는데, 정말 많은 노력을 했다. 이번에 본 건 worktree인데, 상황상 쓸일이 정말 많았는데, 항상 stash를 썼다. 공부 해 봐야겠다.

RESTful API 설계 가이드

RESTful API에 대한 설계 가이드 글인데, 자세하게 나와 있어서 참고 하기 쉽다.

Avoiding burnout as an ambitious developer - Stack Overflow Blog

번아웃 현상을 피하기 위해 다른 개발자들도 이렇게 했으면 하는 마음에 글쓴이가 적어 본 글인데, 굉장히 좋은 구절이 많다. 결국 일은 무엇 때문에 하는지? 무엇으로 나는 하루를 보내는지? 제일 중요한 것 같다. 잊지 말자. 긴 여정을 하는 것인데, 빨리 뛰어갈 필요는 없다. 내 속도를 유지 하자. 기술 학습에 대한 불안감을 가진 당신에게 꼭 필요한 글이다.

CTO로 한해를 보내며 2019 회고

CTO가 되면서, 그리고 겪으면서 느낀 여러가지 생각과 고민들의 회고가 포함된 내용이라 너무 중요한 내용이라고 생각 하고, 정독 했다. 근데 보통 이렇게 깨닫기 쉽지 않은데 정말 많은 노력을 하신 게 글 속에 녹아 있어 읽으면서 대단하다는 생각을 계속 했다.

Scaling to 100k Users

사용자가 10만명이 될때까지의 시스템 설계에 관한 이야기인데, 아주 쉽게 잘 설명하고 있고, 어느 부분이 더 필요한지? 해당 Layer가 필요한 이유를 잘 설명한 글이다.

스타트업 개발자 혼자 빠르게 싸게 서버 구축하기 - 1편 | Popit

클라우드 보다 서버 호스팅이 더 저렴하구나를 깨닫게 되었다. 옛날에는 보통 많이 했던 방식인데, 클라우드 서버가 훨씬 싸다고 생각 했었다. 근데, 클라우드의 목적이 없다면 굳이 클라우드를 쓸 필요가 없구나를 또 한 번 생각하게 되었다. 기술을 사용하는 데에는 이유가 있어야 한다는 나의 개똥철학을 깜빡 했었다.

클라우드 디자인 패턴 - Azure Architecture Center

클라우드 환경에서의 디자인 패턴인데, 사실 클라우드 디자인 패턴에 대해 나는 잘 알지 못한다. 회사에서 제공하는 플랫폼을 사용하고, 팀에서 인프라를 전담하고 있긴 하지만 모르는 분야다. 그럼에도 이렇게 MS에서 입문자를 위한 글들을 많이 제공 해주고 있어서 너무 좋다. :) 솔직히 가이드는 MS 개발자들이 최고..👍🏻

확장성을 가지는 시스템을 디자인 하기 위한 방법들은 무엇이 있을까? 그런 주제들이 정말 잘 정리 되어 있는 페이지이다. 요즘은 안티 캐싱 디자인에 대해 관심이 많다. 흔히 캐싱을 쉽게 생각하는데 오히려 병목이 될 수도 있다는 생각을 하는 요즘이다.

Container

Diving Deep Into Kubernetes Networking: Docker와 k8s 네트워크 분석

도커와 쿠버네티스의 네트워크에 대해 잘 정리 되어 있는 글이다. 사실 네트워크에 대한 기본 지식이 있어야 글을 읽는데 이해가 쉽다고 생각 한다.

🛠Java/Back-End

Spring Batch와 Querydsl - 우아한형제들 기술 블로그

Spring Batch에서 지원 하지 않는 QuerydslItemReader를 만들어 가는 부분을 보여 주는 글인데, 없으면 만들어 사용하는 jojoldu님의 경험기 공유 글이다. (JPA를 안 써본 나로써는 사실 좀 어렵게 느껴지기는 하지만, 요즘 안 쓰는 곳이 거의 없다지…) 관심이 있다면 읽어보면 좋겠다.

캐치딜 백엔드 개발이야기 : 좌충우돌 서버운영 이야기

서버를 어떻게 구성 할지? 그리고 어떤 프레임워크를 선정 하는지에 대해서도 고민 하는 흔적을 엿볼 수 있었고, AWS 상에서 Ruby on Jets를 쓰면서 발생한 어떤 어려움이 있었는지? 잘 써 있다.

서버 사이드 테스트 자동화 여정 - 1. 테스트 자동화를 시작한 계기와 그 첫 발걸음 - LINE ENGINEERING

테스트 자동화와 더불어서 설정 테스트를 하는 것은 신선한 시각이라고 생각 한다. 보통은 설정 테스트를 하진 않는다. 생각해보니 가끔 문제가 되는 경우가 있었다. 확실히 설정도 코드 관점으로 생각해보면, 테스트 하는 게 맞구나! 결론으로 도달.

🖱JavaScript/Front-End

개발자를 위한 새로운 SameSite=None; 보안 쿠키 설정에 대비하기

크롬 80에서 보안 쿠키 관련한 설정이 추가 되는데 이에 대한 설명 글이다. 아마 거의 대부분의 사이트에서 대비를 해야 한다…😭

bradtraversy/vanillawebprojects

바닐라JS로 구성된 웹 프로젝트 리스트인데, 데모 영상까지 다 있기에 활용 하기 좋아 보인다.

qkraudghgh/clean-code-javascript-ko

클린 코드를 JavaScript에 접목시켜 한글로 예시 코드와 함께 쓰여 있는 글이다. 사실 클린 코드 책을 읽지 않아 어떤 내용이 있는지 몰랐는데, 이 글을 읽으면 어떤 내용이 있는지? 어렴풋이 알게 되지 않을까? 생각 했다.

google/gts

Google TypeScript Style Guide가 나왔다. 보통 Airbnb의 스타일을 많이 사용했는데, 이제 구글 스타일 가이드가 나오게 되어 어떤 걸 쓸지? 고민하면 될 것 같다. 뭐가 더 좋은지는 고민스럽다.

🛠Tool

사용중인 VSCode(Visual Studio Code) 확장 플러그인 목록

VS Code editor Plugin에 대한 추천 글인데, 굉장히 잘 정리 되어 있다.

그냥 저냥 #위클리뉴스 #63

Fri, 31 Jan 2020 23:53:00 GMT

⏰개발자들이 읽어 보면 좋을

서비스 가용성 확보에 필요한 Rate Limiting Algorithm에 대해 | Mimul Tech log

서비스 운영을 하다 보면, 이런 저런 상황이 많이 발생하면서 실제 사용자들이 제대로 서비스를 받지 못하게 될 수 있는데, 이럴때 속도 제한(Rate Limiting Algorithm). 음, 웹 서비스라고 가정하면, 요청 제한 알고리즘이라고 이해 하면 좋겠다. 요청 대비 처리량을 어떻게 잘 제한을 하면서 서비스 할 지에 대한 고민의 해답이라고 생각 한다. 이런 제한이 필요하다고? 생각할 수 있지만, 서비스가 커지면 필수적으로 고려해야 할 요소 중 하나이다. 그렇지 않으면, 장애 요소가 될 수 있다.

기술 부채도 자산인 이유

기술 부채가 정말 나쁜 것인가?에 대해 “그렇다”라고 쉽게 말할 수 없다. 오늘의 코드는 내일 모레 레거시가 된다. 고로, 내가 아무리 레거시 코드를 청산 한다고 해도, 청산 하는 속도만큼 레거시가 또 생겨나는 것이다. 결국, 기술 부채는 항상 있기 마련, 얼마나 기술 부채의 적정량을 유지 하느냐?가 관건 같다. 그래서 주기적인 시스템, 코드의 부채를 점진적으로 갚는 노력을 하는 방법이 좋다고 생각 한다. 그렇지만, 큰 규모에서는 그게 쉽진 않지만, 결국 관리자의 몫과 함께 코드 주인인 개발자의 노력이 필요하다. 팀 마다 부채 청산 룰을 정하는 것은 좋다고 생각 한다.

퇴사자를 대하는 태도

링크드인이라는 회사의 퇴사자를 대하는 태도에 대한 글인데, 굉장히 놀랍다. 사실 쉬운 일은 아닌데도 그러한 문화를 유지 하고 있다는게 대단하다는 생각을 했다. 국내 기업에도 이러한 문화가 도입 되면 좋겠다. 사실, 그럴려면 나부터 열린 마음으로 대하면 되는 거겠지? 🙏🏻

난생 처음으로 개발로 발표해보았다! (Feat. ip블로킹, activeX크롤링하기)

크롤링을 주력으로 하시는 분 같았는데, 총 2가지의 난제(ip block, active x)를 해결하면서 얻은 경험기 공유입니다. 10분정도의 라이트닝 발표이다 보니 굉장히 짧아서 아쉽긴 하지만, 다양한 방법으로 해결 하려는 노력을 엿볼 수 있습니다. (그런데, 공공기관의 경우, 정보 공개에 의한 법률로 제정이 되어 있을지라도, 악의적인 크롤링은 금물입니다. 일반 서비스도 마찬가지 :)

📺Java

What is Spring Boot ? | Examples Java Code Geeks - 2020

스프링 부트가 무엇인지? 사실 정확하게 딱딱 가리기가 어려운데, Spring Boot에 대해 잘 정리가 되어 있다.

📖JavaScript

Interviewing at Facebook - On-Site JavaScript Technical Interview Questions

페이스북의 온 사이트 인터뷰에서의 JavaScript 문제이다. 총 4문제이고, 쉬움, 중간 2개, 어려움으로 구분 되어 있다. 직접 풀어 보진 않았지만, 조만간 풀어 봐야겠다.

자바스크립트 성능 향상 방법

여러 가지 성능 향상 방법이 있는데, 그 중에서 객체를 캐싱 하는 방법은 유용하지만, 때로는 오동작의 위험이 있으니 조심 해야 하지 않을까? 하는 생각이 들었다. HTTP 프로토콜 캐시는 대부분 사용하는 곳이 많을 것 같고, 서비스 워커 혹은 스토어 데이터 캐싱 관련해서는 확인을 잘 해야 한다. 스토어 캐싱 전/후 (오류 상황)에 대한 테스팅을 잘 해야 하지 않을까? 생각 한다.

어떻게 하면 안전하게 함수를 합성할 수 있을까?

생각 보다 쉽게 읽을 수 있을만한 내용은 아니였다. 사실 함수형 프로그래밍에 관심을 많지만, 개념을 이해하기가 쉽진 않다. 카테고리 이론이나, 펑터나 모나드등 써 보면 헤어나올 수 없다는데, 단점은 그 코드를 보는 모두가 이해해야 한다는 단점이 있다. 내용을 모르면 제대로 알 수 없다. 그래서 실무에서는 솔직히 제한적으로 쓸 수 밖에 없지 않을까? 하고 생각 했다.

블랙박스 테스트 기법으로 테스트 케이스 설계하기

블랙박스 테스트에 대해 설명하며, 4가지의 블랙박스 테스트를 소개 하고 있다. 사실, 이렇게까지 테스트 코드를 짜는가? 생각 해보면, 나는 전혀 아니다. 그치만, 팀원 중에는 정말 꼼꼼하게 작성 하시는 분들이 있다. 동등 분할, 경계값 분석, 결정 테이블, 상태 전이 각각 알 수 있어서 좋았고, 여유가 된다면 나도 이런 방향으로 작성 하도록 노력 해야겠다. 역시 테스트 코드는 진짜 습관화를 해야 하는 게 맞을 것 같다.

🛠Tool

Building personal search infrastructure for your knowledge and code | beepb00p

Emacs와 ripgrep을 이용해 컴퓨터 내의 검색 엔진을 만들어 보는 건데, 사실 따라 하다가 실패했다.

개발 생산성을 올려주는 VSCode의 소소(?)한 기능들

VS Code를 요즘에는 WebStorm 보다 많이 사용하는데, 사실 WebStorm의 3-way diff merge 기능만 빼면, VS Code로 거의 코딩을 하고 있다. VS Code에는 좋은 기능들이 숨겨져 있는데, 이 글을 보면서 내가 안 쓰던 기능을 익힐 수 있어서 좋았다.

💡일반적인

최고 수준의 기획자는 어떻게 되는가

나이별로 잘 정리 되어 있으나, 가장 중요한 것은 내가 기획 하려는 것의 본질을 명확하게 그리고 있는가? 아닐까? 목적 없이 기획 하는 경우가 많다.

IT 프로젝트가 처음이라면 꼭 알아둬야 할 5가지 툴

생소한 툴들이 좀 있는데, 모바일 테스팅 툴 같은 경우는 솔직히 필수적인 솔루션이라고 생각 한다. 테스트 없이 사용자에게 언제까지 테스트를 맡길 것인가? 사용자의 이탈은 시작 하면 막기 어렵다.

잘 쉬는 것에 대하여

메마름의 시대 같기도 하다. 나조차도 일 하다가 팀원들과 말하다가 어? 모르던 툴인데? 모르던 라이브러리인데? 하는 생각이 들면, 불안해진다. 그런데, 작년까지는 그랬다가 요즘은 머리가 커져서 그런가. 내려 놓게 되었다. ”모르면 오, 이런게 있구나 하고 알아 가면 된다.”는 마인드가 장착 되기 시작 했다. 부지런히 쉬자. 그래야 부지런히 일 할 수 있다.

그냥 저냥 #위클리뉴스 #62

Tue, 28 Jan 2020 09:04:00 GMT

코드의 변질 - 레거시 코드는 왜 늘 개떡같을까?

글의 마지막이 인상적인 문구가 있는데, 정말 많은 공감을 한다. 레거시 코드는 왜 항상 변경이 어려울까?라는 고민을 해 보았다면, 많은 공감을 받을 수 있는 글이다.

개발자가 안된다고 했을때의 진짜 이유 - dobiho on HCI

이 분이 생각하신 개발자가 “안 된다”라고 말하는 이유 3가지에 대해 정리 해 주셨는데, 내가 생각 하는 부분과 약간의 차이가 있다.
“할 줄 모른다”의 경우는 사실, 대부분 그냥 말 하는 경우가 없다. 할 수는 있지만, 어떤 부작용이 생김에 대해 말하는 개발자가 많다. 그러나, 대개 기획 쪽에서 다른 곳은 이렇게 하는데, 왜 여기는 안되나요? 라고 묻는 사람들이 굉장히 많다. 이런 상황에 있어서는 예의의 문제이다. 내가 할 줄 몰라도 문제지만, 그렇게 서로 말하는 순간 사람과 사람간의 문제가 발생 한다. 그리고 할 줄 모를 수도 있다. 서로 인정을 해야 한다. 좋은 예시는 전문가를 데려 오는 방법이다. 해법은 많다.
“시간이 부족하다”의 경우는 항상 사람을 붙인다고 해결 되는 문제는 아니다. 그리고 더군다나 처음 스펙 리뷰 단계에서 이러한 스펙이 필요로 하니 미리 언급을 해주어야 개발자들의 충격 완화가 덜 하다. 이는 애초에 커뮤니케이션 미스라고 생각 하는 편이다. 갑자기 고사양의 스펙을 들고 와서 해달라고 하면, 개발자들은 마법사가 아니다. 사람을 더 붙여서 해결 할 수 있는 일이 있고, 오히려 더 붙으면 생산성이 떨어지는 경우가 있다. 고로, 사람을 더 붙인다고 모든 일의 만능이 아니다. 그렇게 생각 하는 관리자, 기획자, PM이 있다면 그 팀에서는 일 하기 어렵다.
“하기 싫다”의 경우는 대부분 개발자들이 이 작업을 왜 해야 하는지? 설득이 부족한 경우라고 생각 하는 편이다. “지표 상으로 이게 필요하다. 내가 보기엔 이게 더 좋다.”라는 니즈가 있을 수 있는데, 개발자들은 이해하기 어려울 때가 있다. 스펙에 대한 명확함이 부족도 이유가 된다. 그럴 때 "하기 싫다" 그렇기 때문에, 어떠한 설득력은 개발자도, 기획자도, PM도 필요로 하다. 업무에 대한 설득력이 떨어지는데, 일의 완성이 글로벌한 품질을 가지기는 어렵다.

카카오페이지 글로벌 웹 개발 후기

인도네시아 서비스를 개발하면서 겪은 후기담인데, 겪었던 이슈나 사용 했던 기술 스택이 잘 정리 되어 있다.

[번역] 개발 배우기가 정말 어려운 이유

이 글을 통해 왜 개발은 배우기가 어려운지? 자세하게 알 수 있다. 물론, 요즘 코딩 열풍이다 싶을 정도로, 패스트캠퍼스, Java 교육으로 워낙 유명한 비트교육센터, 클래스101등과 같은 코딩 교육을 온/오프라인으로 하는 곳이 많고, 뭐 하면 연봉 5천 무슨 엔지니어는 연봉 7천이다 라는 자극적인 글, 유투브 홍보 영상들을 보고, 많은 사람들이 또는 어떤 동기에 의해 개발자를 하려고 하는데, 생각보다 쉽지 않다. 클론 코딩은 단순히 그냥 클론 코딩으로 생각해야 한다. 내가 인스타그램 클론 코딩 했다고 해서 인스타그램에 취직 할 수 있는 것은 아니다. 단적으로 확실한 니즈가 있는 사람, 어떤 호기심을 꾸준히 관리 할 수 있는 사람이 개발을 배우면 적합한 생각을 많이 하는 편이다. 어설픈 개발 익히기를 통해 다 할 수 있는 영역이 아니다. 시작은 좋다. 하지만, 시작을 했다면, 글에서 정말 자세하게 소개하는 지루한 영역도 지나고, 꾸준하게 익힐 수 있는 능력을 잘 키우는 것이 정말 중요하다.

With Great Tech Comes Great Responsiblity

모질라 재단에서 기술 산업의 윤리 문제에 대한 PDF를 무료로 배포하고 있다. 11페이지 정도라 그렇게 많은 분량은 아니라서 시간 날 때 읽어보면 좋겠다.

Introduction

Bash shell에 대한 정리가 정말 잘 되어 있는 글이다. 사실 맥과 리눅스를 쓰다 보면 Bash shell, Bash script를 통해 편리한 작업을 한 번에 해결 할 수 있는 경우가 많다. 그래서 공부를 틈틈히 하면 정말 좋다고 생각 하는 편이다. (물론, 쉘 스크립트의 달인이 될 필요는 없다.)

블로그 새단장 후기

블로그를 정말 깔끔하게 만드셨는데, 만드시면서 고려한 요소들을 소개 하고 있다. 생각해보니 나는 Styled-component를 써보지도 않았는데, emotion, TailwindCSS을 적용 하셨다. 개인 프로젝트에서 써봐야 뭘 알텐데, 사실 CSS를 직접 작업 하지 않기 때문에 개인 프로젝트에서 쓰기도 좀 모호하다. 개발보다 CSS에 더 공을 들여야 하는 경우가 훨씬 많았다. 그럼에도 올해는 좀 도전 해봐야 하는 영역이라 생각 한다.

Introduction | Remote Work 2020

원격 근무에 대한 내용이 총집합 되어 있는 글인데, 원격 근무에 대한 설문조사 결과도 포함 되어 있고, 원격 근무가 잘 맞는 사람이면, 사무실에 가서 일 하는 것이 원격 근무 하기 전보다 더 어려울 수 있겠다는 생각을 하게 되었다. 특히, 생각보다 “커피숍에서 일을 많이 안하는 구나”를 또 알게 되었다.

HTTPS에 대해 알아야 할 것들 | Mimul Tech log

점점, 모던 브라우저들이 HTTPS 사용을 강제 하려고 하는 움직임(크롬의 경우 안전/비안전 표시)이 많은데, 관련해서 잘 정리 되어 있는데, 특히, 라이브러리들의 버그들과 해결 방법들도 잘 정리 되어 있어서 참고하기 좋다.

Browse good first issues to start contributing to open source

대다수의 개발자들이 오픈 소스 프로젝트에 어떻게 기여 하면 좋을지? 고민이 많은데 첫번째 이슈를 시작하는 좋은 방법에 대해 소개를 하는 글이다. 요즘 오픈 소스 프로젝트들에 보면 good first issue가 라벨링 되어 있다. 특히, 오픈 소스 프로젝트의 기여자들이 이전에 작업 했던 이슈들을 잘 살펴 보는 것도 좋은 가이드가 될 것 같다.

JavaScript

You Must Understand These 14 JavaSript Functions

유용한 JavaScript의 함수를 직접 구현 하면서 이해 할 수 있게 코드와 실제 예시를 통해 설명 하는 좋은 글이다. 직접 함수 하나 하나 입력 해보고, 어떻게 구동 하는지? 원리를 이해 하면 실력에 좋은 도움이 되지 않을까? 하는 글이다.

Tool

Kubernetes 커맨드 라인 툴

쿠버네티스를 쓰다 보면, 명령어를 자주 입력 해주어야 하는데, 이런 방식을 적용하면, 생산성이 올라 가기 때문에 자동 완성이나, 다른 콘솔 모니터링 도구들을 쓰는 건 정말 편리하다. 물론, 회사에서 쓸 수 있을지는? 고민을 좀 해 봐야겠다.

Roam: Why I Love It and How I Use It - Nat Eliason

Roam 이라는 노트 어플리케이션인데, 왜 좋은지? 소개 하는 글이다. 참, 신기하게 노트들의 네트워킹 구조를 만들고 그 구조를 레이아웃으로 볼 수 있다는 점이 다른 노트 앱들과는 다른 점 같다. (약간, RDBMS의 테이블 구조라고 할까..)

Mirage JS * An API mocking library for frontend developers

API mocking 라이브러리인데, 굉장히 유용하다는 생각을 하게 되었다. 사용할 일이 생기면 꼭 써 봐야겠다.

Working with Vim

vim 튜토리얼에 대한 글인데, 사실 영어라 온전히 이해하기가 쉽지는 않지만 따라 하는 느낌으로 읽으면 도움이 많이 된다.

일반적인

아마존에서 고객평가 최고상 받은 ‘일기장’

습관 일기장을 통해 아마존에서 엄청난 성장을 하고 있는 제품이 있는데, 6가지의 일기장을 판매 한다고 한다. 사실 계기는 아무래도 대표의 습관 만들기에서 회사 창업까지 오게 되었다고 한다. 번역된 일기장이 한국에서도 출시 되면 좋겠다. (내가 영어로 쓸 순 없으니까..)

그냥 저냥 #위클리뉴스 #61

Mon, 20 Jan 2020 10:35:00 GMT

개발자에게 좋은 내용

내 맘대로 위클리 뉴스 - 2020년 02주(2020.01.05 - 2020.01.11)

Node.js에서의 메모리 누수 추적 하는 방법을 소개하는 글, Java에서 메모리 누수의 일반적인 원인과 감지 하는 글이 가장 나에게는 도움이 되었다.

[B급 프로그래머] 1월 3주 소식(빅데이터/인공지능, 읽을거리 부문)

이 글을 읽고 나니, 신문 구독률이 최저가 되는 시대가 되었구나라는 새삼스런 깨달음과 함께 구글 크롬에서는 User-agent, 제 3자 쿠키 지원 중단을 발표 했던 글들을 포함한 유용한 글 묶음.

nginx no live upstream 에러 이해하기

정말 간과하기 쉬운 부분 일 수 있지만, 잘못하면 엄청난 장애를 유발 시키기도 하는 에러이다. max_fails, fail_timeout을 기억 해야겠다. 그리고 실제 업무에서 사용하는 환경설정을 좀 확인 하는 시간을 가져야겠다.

2019년 개발자스럽다 회고

꾸준히 어떤 서비스를 유지한다는 것은 쉽지 않은데, 4년간 유지 하셨다는 게 엄청난 노력이 있다고 생각 했다.

프로그래머를 지탱하는 3가지 성분

어떻게 보면, 지난 발자취의 회고 같지만 읽다 보니 선배 개발자가 후배 개발자에게 할 수 있는 조언이 아닐까?라는 생각이 들었다.

Java

스프링 부트로 멀티모듈 셋팅하기

멀티 모듈이 추세인 시대가 된 느낌을 많이 받는데, 요즘의 트렌드이다. 과거에는 모놀리틱 아키텍처였다면, 이제는 MSA를 추구하는 시대이다. 보니, 경량화 하고, 응집도가 가능하다면, 모듈로 구성하는 것이 방법이다. 그런데, 미리 다 할 필요는 없다고 생각 한다. 멀티 모듈로 구성하는 방법에 대해 정말 자세하게 예제코드로 설명을 해주셨다. Maven으로 구성 해주셨는데, Gradle로 변경해도 좋지 않을까? 싶기도 하다.

React

Goodbye, Clean Code

정말 좋은 글이라고 자부할 수 있는데, 팀 협업이란 포인트로 성장하는 글이기도 하고, 자신의 실수를 수 많은 이들에게 공유 할 수 있는 점 자체가 놀라운 사람이라고 생각 한다. "Let clean code guide you. Then let it go." 좋은 말이구나.

My Decade in Review

10년의 회고록인데, 착각한건 Dan이 러시아 사람이라는걸 처음 알았다..:-)

What Are the React Team Principles?

React Team의 생각을 알 수 있었던 이야기이고, 읽어보면 도움이 많이 되는데, 확실히 플랫폼을 만드는 조직은 생각하는 바가 다름을 느꼈다.

On let vs const

let과 const 둘 사이에 무엇을 더 쓰면 좋을까? 고민한 적이 거의 없었는데, 이 글을 보면서 많이 느끼게 되었다.

What Is JavaScript Made Of?

JavaScript에 대한 설명이 있는 글입니다. 이미 아는 내용이라도 읽어 보시면, 좋습니다.

React Conditional Rendering - RWieruch

object로 만들어서 []로 선택적 렌더링을 하는 부분은 참 좋은 것 같다. 생각해보니 switch를 진짜 많이 쓰긴 했는데, 항상 가독성이 별로라는 생각을 하게 된다.

일반적인

‘리디셀렉트’는 나의 새로운 독서 루틴으로 자리 잡을 수 있을까?

리디 셀렉트 초기 모델에 써보고 이제는 잘 안쓰는데, 확실히 리디 서비스를 정말 잘 쓰고 있기 때문에 추후에는 결제를 해서 쓰게 되지 않을까? 하는 고민을. 이 글을 읽고 진지하게 하게 되었다.

‘마스터클래스’는 어떻게 사용자들을 사로잡았을까?

감정기복과 자기혐오에 대하여

혹시라도, 요즘 그런 감정 기복이 심하거나 마음의 여유가 부족한 분들이 읽었으면 하는 기사이다.

상사가 되면 ‘하지 말자’ 10가지 다짐

상사가 아니더라도 알아야 하는 10가지의 조언이라고 생각 한다.

그냥 저냥 #위클리뉴스 #60

Tue, 14 Jan 2020 22:11:00 GMT

2019년 개발 이야기

도커와 쿠버네티스 관련 글을 정말 잘 써주셔서 유명하신 subicura님의 2019년 개발 회고이다.

웹 개발자의 지옥, 이메일 폼 개발하기

이메일 폼 관련한 개발의 팁들을 잘 정리 해주셨다.

레거시 운영개발팀을 수습하다.

확실히 중요한 부분은 관리자의 입장에 팀원들의 사기 체크는 굉장히 중요한 요소라고 생각 된다. 일단, 사기가 바로 생산성에 직결 된다. 우리는 생산성을 높이기 위해 정말 많은 노력을 하지 않은가? 그런데도 불구하고, 팀원들의 사기에 대해서는 높이는 생각을 잘 하지 않는다. ?! 아이러니 하게도 그렇다. 이 글을 읽으면서 정말 많은 내용들이 공감 되었다.

소프트웨어 개발자, 신입사원 교육. 어떻게 해야할까?

신입사원 교육에 대한 깊은 고뇌가 있는 글인데, 꼭 시니어 개발자나 다른 연차가 높은 분들이 읽어주셨으면 좋겠다.

상품상세페이지 개선해 성과내기

상품 상세 페이지를 개선하는 히스토리를 잘 남겨 주셨는데, 어떻게 해야 더 좋은 사용성과 사람들이 많이 사용하는지?에 대해 고민 하는 모습이 담겨있다.

2019년 회고

rinae님의 회고 글인데, 읽어보면 참, 단순하기도 하지만, 어떻게 하면 더 좋은 코드와 프로덕트를 만들지 고민하는 개발자의 고민이 담겨 있어서 나에게도 많은 깨달음을 주었다.

2019.log

velopert님의 회고글인데, 복학을 안하시고, 라프텔에 잔류하여 개발을 더 하시기로 하셨다고 한다. 그리고, 여러가지로 정말 많은 활동을 하시는데, 대단하신 것 같다.

2019 회고

박성범님의 회고글이며, 해당 글에서 정말 여러가지로 많은걸 하고 계신다는 느낌을 받았다. 과거에는 훈련소 들어갔을때, 외부 기사를 읽으려고 인터넷 편지를 이용해서 받아보려고 했던 부분들? 아마 뼈개발자를 이런 사람을 두고 말하는 것 같다.

Same-Origin Policy 동일 출처 정책과 CORS 에러

SOP와 CORS에 대해서 알아 볼 수 있는 글이다.

CORS(Cross-Origin Resource Sharing)이 나오게 된 배경 이야기

왜 CORS가 발생 하는지에 대해서는 알고, 어떻게 해결 하는지는 알지만, 왜 탄생 하게 되었는지는 모르는데 알 수 있는 영상이라 도움이 된다.

따릉아! 문제는 UX/UI야!

따릉이 앱의 문제는 무엇일까? 고민에 대한 문제 해결 히스토리 글인데, 정말 잘 써주셨다. 요즘 UX/UI의 중요성이 너무 없어지는 느낌이라 이 글을 재밌게 읽었다.

개발자로 살며 가장 치열했던 2019년을 돌아보며…

2019 회고록인데, 실리콘 밸리에서 일하시기도 하시니까, 관심을 갖고 글을 읽었고, 많은 부분을 느끼게 되었다. (아, 이래서 고수는 다르구나.)

코드 가독성에 대해 - 1. 도입과 원칙 - LINE ENGINEERING

코드 가독성이 높아야 하는 이유에 대해 소개하는데, 발표자료가 영어여서 그리고 다른 스크린 캐스트로 공유 되어 있어서 글 읽기가 어려웠다. (고로, 영어 부족)

Free Programming Books; HTML5, CSS3, JavaScript, PHP, Python…

주제별로 무료 전자책이 제공 된다. 받아서 틈틈히 보도록 하자.

수학전공자가 추천 하는 유튜브 수학 강의 목록

수학을 유투브로 배울 수 있다? 이렇게 빠르게 동영상 검색 기반의 삶으로 들어온 게 몇년 안 된 느낌인데, 이제는 거의 텍스트 기반에서 이미지 정보 공유에서 이제는 동영상 기반의 정보 공유의 시대가 되었다.

[번역] 10가지 소프트웨어 아키텍처 패턴 요약

흔하게 접할 수 있는 패턴도 있고, 아닌 패턴들이 있는데, 간략하게 설명이 딱딱 잘 되어 있어서 보기에 좋다.

도커(Docker) 컨테이너는 가상 머신인가요? 프로세스인가요?

이 글을 읽다보니 아래의 3개의 글타래 링크들이 나오는데, 모두 중요한 정보라 꼭 읽어보면 좋겠다. 그리고 이 글은 정확한 표현으로 도커 컨테이너가 가상 머신인지? 프로세스인지?를 이해시키고 있다.

만들면서 이해하는 도커(Docker) 이미지: 도커 이미지 빌드 원리와 OverlayFS

컨테이너 기초 - chroot를 사용한 프로세스의 루트 디렉터리 격리

컨테이너 기초 - 정적 링크 프로그램을 chroot와 도커(Docker) scratch 이미지로 실행하기

정말 친절하게 컨테이너 기초와 도커 이미지에 대해 설명을 하고 계시는데, 꼭 읽어보자!

Conventional Commits

커밋 관련한 메시지 규율 같은 느낌인데, 물론 잘 쓰려고 노력 해야 하고, 나중에 남는 것은 커밋 메시지이다.

React

My Top React Techtalks of 2019

2019 리액트 관련 발표 영상들의 모음인데, 다 이해하면 좋겠지만, 어느 부분만 이해해도 좋은 영상들이 많다.

Introduction to abortable async functions for React with hooks

hooks api를 이용해 중단이 가능한 비동기 함수를 만들어 예제를 보여주는 글인데, 굉장히 신기한 경험이었다. 나름, 좋은 예시가 되어 실무에서 잘 써먹을 수 있을 것 같다.

Replacing Redux with React Hooks and Context: A small concrete example with reactive-react-redux

React Context + Hooks api를 이용해 redux를 대체 하기 위한 시도를 실 예제로 보여주는 글인데, 실제 reactive-react-redux 라이브러리를 만들고 있다. 물론, 이게 정답은 아니겠지만 나름의 좋은 방향성이 된다고는 생각 한다.

JavaScript

lydiahallie/javascript-questions

JavaScript 관련 질문/답변에 대한 모음집인데, 생각보다 틀리게 된다. 역시, 기초를 잘 아는 것은 중요하구나 생각에 된 계기가 되었다.

🚀⚙️ JavaScript Visualized: the JavaScript Engine

JavaScript를 시각화 해주면서 엔진에 대해 설명을 해주는데, 굉장히 좋은 글이다. 강추!

goldbergyoni/javascript-testing-best-practices

요즘 들어 Test를 거의 안하고 있긴 했는데, 다시 되돌아가야겠다. 프론트 관련 일을 하고 있다면, 해당 글을 꼭 필독 하면 좋겠다.

Tool

klaussinani/taskbook

터미널로 관리하는 할일 관리 툴이다. 신기해서 설치 해보았는데, 그날그날의 간단한 업무 task를 관리 해볼까?도 생각 했지만, 이미 things로 관리를 잘 하고 있어서 설치해서 가지고 놀고만 있다.

hostname과 nginx server domain mapping 삽질(찬조출연: ansible)

Wed, 08 Jan 2020 22:45:00 GMT

왜 이런 삽질을 시도 했나?

회사에서 개발 서버들은 모두 VM(Virtual Machine)을 사용하고 있다.

그런데, 이것도 사실 비용이기 때문에, 여러 개발 서버를 모두 띄우기 쉽지 않다. (물론, 요즘은 도커를 이용하는 방법이 있다.) 다만, 배보다 배꼽이 더 큰 환경 설정이 필요로 하다.

그럴때는 그냥 가상 머신이 제일 간편한데, 보통은 서버수는 적게 받아 가상 호스트를 이용해 개발 서버를 여러대인 것 처럼 사용한다.

대다수의 서버들을 환경 설정 자동화를 하곤 했는데, 서버가 몇 없는 개발 서버만 유독 수작업을 해줘야 했다. (사실 찾아보기 귀찮았다.)

그래서 가상 호스트 도메인과 호스트 네임을 이용해 nginx server의 server_name을 설정 하는 방법을 찾았다.

(예전에는 왜 이런 단순한 방법을 생각 못했는지 모르겠지만, 점점 ansible의 야매기술이 늘어난다.)

ansible에서 template으로 처리하기가 어려운데, jinja2의 문법을 통해 얼추 하드 코딩하여 처리 했다.

nginx.conf.j2 파일을 다 보여줄 순 없지만, 아래 처럼 도메인을 셋팅 했다. (하나의 도메인을 고정 시켰다.)

nginx.conf.j2 (기존)

server_name  dev5.seungdols.com;

만약에, 다른 서버의 경우 서버 네임을 바꿔주어야 했는데, 해당 서버 이름은 직접 접속해서 수정 해주고, nginx 재시작 하곤 했다.

물론, ansible server에서 일반 ansible -m command -a를 이용해 파일의 서버 이름 찾고, command sed 같은 걸로 굳이 접속 하지 않고도 바꾸고, 서버 설정 반영(nginx -s reload)도 가능하다. 물론, 그 타자 치는 것보다 서버 접속 해서 수정하고 설정 반영 하는게 더 빠르다.

그래서 현재는 아래와 같은 방식으로 한다.

nginx.conf.j2 (현재)

{% if '001' in ansible_hostname %}
server_name  dev.seungdols.com;
{% endif %}
{% if '002' in ansible_hostname %}
server_name  dev1.seungdols.com;
{% endif %}
{% if '003' in ansible_hostname %}
server_name  dev2.seungdols.com;
{% endif %}
{% if '004' in ansible_hostname %}
server_name  dev3.seungdols.com;
{% endif %}
{% if '005' in ansible_hostname %}
server_name  dev4.seungdols.com;
{% endif %}
{% if '006' in ansible_hostname %}
server_name  dev5.seungdols.com;
{% endif %}

위와 같이 해도 되고, 배열 변수 하나에 넣고 loop를 돌려도 된다. 사실 그게 제일 깔끔한데, 안타까운 점은 우리는 도메인 이름이 dev - dev5까지 총 6개를 쓰는데, 1번부터 6번이 아니다. 그래서 1번 서버의 경우 서버 이름에 1을 넣으면 안되는데, 그 처리 하기가 너무 귀찮았다. 그거 처리 하는 시간에 아래를 복사해서 vi에디터로 복사 해서 숫자값만 바꿔주면 쉽게 끝난다.

결국, 아래의 값만 바꿔주면, VM에 여러 호스트를 태워서 쓰는 분들이라면 나름의 꿀팁이 될지도 모르겠다.

{% if 'hostname 구분 할 수 있는 숫자' in ansible_hostname %}
server_name  dev.seungdols.com;
{% endif %}

당연히 해당 템플릿을 실행하는 task의 playbook은 gather_facts의 옵션을 참 값으로 셋팅해야 한다. 그래야 상위에서 참조할 ansible_hostname변수의 값을 활용 할 수 있다.

그럼, 역시 짠내나는 ansible 깨알 팁 끝. :)

2019 하반기 그냥 저냥 회고

Sun, 05 Jan 2020 14:35:00 GMT

하반기의 회고를 무엇을 쓸까? 고민을 많이 했다.

무엇을 적을지? 고민을 하다가 그냥 내 생각을 정리 해야겠다 싶었다.

그냥 저냥 하반기 회고

회사 이야기

끊임 없는 전환 작업

2018년도 10월부터 이어진 서비스 전환이라는 큰 개편을 이후로 지속적인 개편을 이어 왔다.

2018년 10월 부터 시작한, 2019년 1월에 오픈한 주요 페이지 중의 일부 기능을 맡았고,

2019년 상반기에는 주요 서비스의 하나를 React/Node라는 시스템으로 개편을 하는데, 여러 부분에 동참을 했다.

전반적인 어려움은 API를 무조건 만들어서 써야 한다는 점이 컸다. 초기 컴포넌트를 찢어, 마크업 개발자분들에게 요청하고 다시 합칠 부분들은 합치는 작업 하고, 데이터를 가져와야 하는데, API는 어떻게 규칙을 정할지부터 난관이긴 했다.

상반기에는 그러한 일들을 주로 했고, 바로 이어서 해당 서비스 페이지의 리뉴얼을 하게 되었다.

리뉴얼 작업

기획조직에서는 어느 정도 시간을 할애 해주고, 우리가 시스템 전환하는데에 기다림이라는 열매를 주었다.

그리고, 우리는 한 차례 일정 연기 끝에 원하는 스펙과 추가적인 스펙을 포함한 신규 플랫폼으로 서비스를 오픈 하였다.

React/Node 시스템으로 전환하고, 난 뒤 바로 몰려드는 기획 조직의 서비스 페이지 리뉴얼 프로젝트에 동참 하게 되었다.

사실, 하반기에는 리뉴얼 작업을 하다 보니 내 삶을 제대로 관리 하지 못했다는 생각을 했다.

그렇게, 무너지는 멘탈을 붙잡고 2019년 12월에 정상적으로 오픈을 할 수 있었고 오픈은 밤을 새가면서 진행 했다.

회사에서 29시간이나 있었고, 다음날 7시에 퇴근을 할 수 있었다.

인프라 관리

인프라는 생각 보다 잘 관리 하는 것이 쉽지 않다. 서비스의 가용성을 높이는 첫번째는 인프라적인 장애가 없어야 한다. 어플리케이션의 장애는 사전에도 관리하고, 알람이나 기타 로그를 통해 관리 하지만, 인프라 적인 장애는 무관심 하기 쉽다.

그렇게, 내가 속한 팀에서 인프라를 주로 관리하는데, 주요 프로젝트 중에 하나는 Apache server를 벗어나는 것이었고, Nginx 로 이전하게 되는 부분이었다. 현재 팀에서 관리하는 서버만 200여대가 넘는다. 연말까지 틈틈히 진행 하다 보니 12월 31일부로 모든 서버가 nginx를 이용해 최전방에서 트래픽을 받고 있다.

혼자 관리 하는 것이 쉽지 않은데, 예전에 입사 이후부터 관리 했기에 어느 정도 자동화를 위해 Ansible 이란 툴을 사용하고 있다.

물론, Docker + k8s를 통해 서비스를 하고 있는 부분도 있지만, 전면 적용은 아직 적절한 시기가 아니기 때문에 물리적인 서버를 주로 사용 한다.

그렇다 보니, Ansible을 사용하는 스킬이 점점 늘었다. 물론 그렇다고 여전히 잘 하는 부분은 아니다. 모르는게 더 많다.

이래서 개발자의 학습은 끊임 없다는 말이 사실이라는 생각을 몸소 느끼고 있다.

앞으로는 물리 서버 환경에서 컨테이너 기반의 인프라 관리를 좀 하고 싶다. 올 해는 그 부분에 초점을 맞추려고 한다. 그렇다고 내가 Ansible을 포기 하진 않을 것 같고, 둘 다 가져가면 편리한 부분은 분명 있다고 생각 한다. 도대체 얼마나 더 해봐야 좀 안다고 할 수 있을지는 모르겠다. 여전히 레벨은 1인 느낌이다.

개인이야기

멘탈 관리에 대한 중요성

멘탈 = 마음을 잘 관리 하는 것은 중요하다고 생각 한다. 작년부터 이어진 무수히 많은 일정들을 소화 하랴, 개인적인 일정을 소화 하랴, 너무 성장 하는데 노력을 하지 않는 것 같아 시작 하게 된, 그냥 저냥 위클리 뉴스까지.

의도적으로 따라 하다 보니 스트레스가 많아졌다. 일주일에 하나씩 올리려고 수 많은 글들을 읽어야 했다.

내가 마음 관리를 실패 했던 이유는 내 신체|마음 건강을 신경 쓰지 못했다. 주말에 하루쯤은 지루하게 집에서 쉬어야만 하는 집돌이 습성임에도 불구하고, 그렇지 못했다.

그리고, 작년 한 해는 회사에서 일 하는 모든 행위 자체가 부담스러웠다. 2년 간 지속 되는 부서의 변화, 시시 각각 변화 하는 물결에서 버티는 것도 생각보다 큰 스트레스의 중압감을 견뎌야 했다.

사실, 포기 하면 편한데, 내가 속한 팀만은 뭔가 팀원들의 합이 좋게 유지 하고 싶었고, 물론 내 노력만으로 그렇게 되는 것은 아니지만, 많은 목소리를 내려고 노력 했다. 내가 그렇게 할 역할 레벨도, 역량도 없었지만 나의 욕심이긴 했다.

그렇게 욕심을 부리다 보니, 체하게 되었고 일년 내내 짜증과 화를 달고 살았던 것 같다. 그렇다고 누군가에게 말 하기도 애매하고, 이해 할 수 있는 부분도 없었고 말이다.

이제와 생각 해보니, 작년에는 발견의 시간이었다. “예민한 사람이구나.”라는 포인트를 알게 되기도 했지만, 다시 생각 해보니, 야근을 하니까 무슨 작은 말에도 감정적으로 순간 증폭 되기 쉽다는 힌트를 회식을 하다가 알게 되었다.

나는 예민한 사람인가? 라는 물음이 새로운 새해의 화두가 되었고, 나는 예민한 사람이라기 보다는 지속적인 관리를 해야 하는 마음을 가지고 있는 사람이구나 생각 하게 되었다.

그리고 나는 내가 진짜 힘들 때, 왜 포기 하거나 잠시 쉬어 가는 시간을 갖지 않는지? 확인 하는 습관을 들이는 계획을 세웠다.

별일 아닌데, 짜증이 나는 경우
별로 상처 받는 말이 아닌데, 상대방의 말이 이해가 안되어 상처 받는 경우
출근 하면서 오늘 하루는 또 어떻게 버틸까? 라는 생각을 할 경우
퇴사하고 싶다는 말을 자주 하게 되는 경우
요즘 왜 이렇게 안 행복하지? 라는 생각을 하게 되는 경우

등등, 이 모든 것들이 결국 마음의 여유가 부족해서 생기는 탓이라고 정리 했다. 결론을 내렸고, 그에 대한 대비책을 강구 해야 하는 시기라고 생각 했다.

그래서 요즘은 모든 것을 내려 놓고, 쉬면서 어떻게 하는 것이 행복한 길인지? 고민 하고 있다.

그렇게 서른을 맞이 하면서 또 다른 사춘기를 겪는 중이구나 싶었다. (나만 그런가…)

태도를 굽힐 줄도 알지만, 펼 줄도 알아야 한다.

회사 일을 하다보면, 어떤 논쟁이 생길 때에 이상한 포인트를 잡고 논쟁을 이어나가는 것은 좋지 못한 태도이다.

어떤 의견이 상반 되는 경우, 나는 이런 상황이니 하지 않겠다 vs 이미 하기로 했으니 하자. 라는 등의 의견이 충돌할 때, 나는 어떤 태도를 보이는 것이 좋은가? 그런 고민을 많이 하게 되었다.

적절한 포인트에서는 다수의 의견과 내 의견을 동조하며 이어나가는 것도 좋지만, 가끔은 “내 의견도 좀 생각 해주세요.” 라는 순간을 표현 할 줄도 알아야 하는 개발자가 좋다고 생각 한다.

결국, 회사의 일이든, 나의 개인적인 일이든지 결국 내가 이해하고 행할 수 있으려면, 납득이 되어야 할 수 있다.

모든 일은 의지의 문제지만, 회사의 일도 협력이라는 중요한 틀 안에 있다보니 가끔은 납득 하기 어렵지만, 또 반대 의견을 듣다 보면 납득 하게 되는 경우가 있기 마련이다.

그래서 사람은 굽힐 줄도 알아야 하지만, 펼 줄도 아는 사람이어야 한다는 게 작년의 생각이었고, 올해의 생각도 유사하지만, 여기서 중요한 것은 태도가 중요하다. 그래서 2020년도는 그 태도를 잘 갈고 닦는 한 해였으면 하는 소망이 있다.

잘 한 일

명상과 등산이라는 취미를 갖기 시작 했다. 그리고, 카메라를 잘 샀다. (새로운 취미 추가요)
독서 리뷰, 영화 리뷰, 드라마 리뷰를 에버노트 (노션)에 한 해 동안 잘 정리 했다.
그냥 저냥 #위클리 뉴스를 매 주마다 쓰진 못했지만, 2018년도 보다는 많이 발행 했다.
쓸데 없이 말을 많이 하는 습관을 버려야겠다고 다짐했다.

못 한 일

독서를 많이 하지 못했다.
어영 부영 토이 프로젝트는 시작도 못했더라.
의미 없는 시간을 아끼지 못했다.
마음의 여유를 관리 하지 못했다.
leetcode를 많이 풀지 못했다.
스터디 진행 했던 내용을 github에 다 정리 하지 못했다.

2020 목표

해외 여행을 가고 싶다. (현재의 계획은 동유럽)
정말 작은 기능이지만, 개인적으로 서비스를 하고 싶다.
React/Java/Kotlin 이 3개는 꼭 좀 더 공부 하고 싶다.
- webpack, spring boot도 포함.
튜터링(전화영어) 끊지 않고 1년 유지 하기.
취미의 고도화? - 어느 수준은 달성 하도록 연마하기.
- 사진/보정 공부 하기
10개의 산 오르기.
기술 포스트를 작성 하자. (2주에 한 번이라도, 예제 코드 및 내용 포함)

그냥 저냥 #위클리뉴스 #59

Sun, 05 Jan 2020 10:25:00 GMT

개발자에게 도움이 되는

The Rust Programming Language

확실히 요즘 러스트의 이야기를 많이 듣게 되는데, 러스트도 좋은 대안의 언어라고 생각한다. 나름 학습이 쉽진 않지만, 엘릭서나 러스트 정도는 재밌게 배울 수 있을 것 같다. 올해의 목표로 생각 하고 싶지만, 여력이 많이 없다.

체대 출신 개발자의 2019년 회고

확실히 노력을 하면 길이 열리는구나를 깨닫게 된다. 물론, 쉬운 길은 아니겠지만, 꾸준함과 정보력을 바탕으로 노력하면 되는 문제라고 생각하게 되었다. 꼭 읽어 보시길 바란다.

훌륭한 팀원의 조건 - Strong Views, Weakly Held

결국은 다양한 관점을 익히려는 태도를 가져야 하고, 유연한 태도를 위해 노력해야 한다는 아주 단순한 글 같지만 실제로 현실에서 그런 캐릭터가 있다는 것과 그 캐릭터와 같이 일할 수 있다는 것은 엄청난 장점이다. 왜냐하면 정말 드물기 때문이다.

Y2019 개인 회고

나는 사실 거의 팬? 수준에 오른 박미정님의 팬이다. 과거에는 lucy.park님의 블로그를 정말 열심히 탐독했다. 그 이후 박미정님을 어쩌다 파이썬 발표 자료를 보고 난 뒤에, 알게 된 이후 올라오는 글들을 정말 잘 읽었다. 왜? 팬이 되었느냐? 라고 생각하면, 일단은 글속에서 느껴지는 분위기는 참 재밌게 일 하시는구나. 그리고 되게 열심히 기술 리딩을 하시는 구나 싶었다. 두 가지의 이유였고, 부러움도 좀 있었다. 나도 뭔가 저런 에너지를 발산하는 개발자면 좋겠다? 라는 희망이 내포 되어 있다. 그리고 그냥 멋있다. 회고 글을 통해 나도 무언가 많은 고민을 하게 되었다.

2019 회고 모음

누군가 회고 모음을 정리 해주셨다. 많은 분들의 회고가 적혀 있다.

2019 회고 모음

깃허브로도 연간 회고를 누군가 모아 주셨다.

조금은 무거운 2019 회고

태태태님의 회고, 읽을 수록 엇? 나는 무엇을 성장을 한 것인가? 라는 부끄러움이 몰려왔다. 그래서 사실 회고글은 읽으면서 나를 항상 부끄럽게 만드는 것 같다. 그런 점에서 순기능이 있지 않을까? 싶기도 하다. 서비스 개발자의 고민은 항상 존재 하게 되는 것 같다.

2019 하반기 회고

정말 오래 전부터, 보던 이동욱님의 블로그이자, 2019 하반기 회고글이다. 이제는 책도 내시고, 개발 파드 리드까지!!! 하시는 주니어 개발자의 빛이 되신 것 같다. 우아한 세미나 - 스프링 배치에서 발표하실 때, 직관도 나름 했었다. 이렇게까지 열심히 하시는 원동력이 좀 궁금하기도 하고, 시간 관리를 정말 잘 하셔서 대단하시다는 말 밖에 안 나오는 개발자 중에 한 분이다. (박미정님 외의 또 다른 나에게는 개발 연예인 같은 분)

Back

GET이냐 POST냐 그것이 문제로다

뭐가 좋은지 아닌지는 모르지만, 중요한 부분은 근본적인 핵심에 초점을 맞추는 것이다. 글 속에 나오는 말이 핵심이라고 생각하게 되었다. API는 결국 약속이라는 의미 이기에 무엇이 더 나은지는 상황 마다 약속할 문제! 라고 생각 하면 편하지 않나? 라는 생각이다.

메인 데이터베이스 IDC 탈출 성공기 - 우아한형제들 기술 블로그

이 글을 읽으면서 참, AWS가 좋다는 생각을 하게 되었다. 결국, 서버의 관점에서의 IDC는 점차적으로 사라지게 되고, 모든 관리를 이제 S/W적으로 하게 되는 시기에 도래 했다는 생각 하게 되었다. 본문 속에 나오는 글에 크게 공감이 갔던 부분은 코드에 주인 의식을 갖는 것과 프로젝트 범위에 레거시 제거 또한 포함 되어야 한다는 부분이다. 생각처럼 쉬운 일은 아니지만, 메인 데이터 베이스에서 탈피하여, 작게 쪼개진 형태의 DB를 관리하여, 서비스를 한다는 것은 또 다른 어려움이 있을 것 같은데, 그 다음 이야기도 궁금하다. MSA가 될 수록 결국, 네트워크 효율화가 더 필요 해진다는 점도 고려 포인트 일 것 같다.

Front

Infinite Scroll with Intersection Obsever API

Web API를 이용해 무한 스크롤을 구현하는 예제를 담고 있다. 물론, 라이브러리를 사용하는 것이 간편하고 효과적이지만, 원리를 아는 것도 좋은 방법이라고 생각 한다.

로컬에서 CORS policy 관련 에러가 발생하는 이유

개발 하다 보면 겪는 당황스런 부분인데, 처음 만나면 당황하기 쉽다. 그에 대한 의문을 잘 정리 해주신 글입니다.

자바스크립트 엔진에 대한 오개념과, Inline cache

이해하기 어려운 내용이긴 하지만, 알려고 노력할 수록 훗날 다시 보면 이해하기 쉬워 지는 때가 오지 않을까?라는 생각으로 JavaScript Engine 관련 글을 읽습니다. 물론, 지금 설명해보라고 하면, 잘 모릅니다. 그래도 읽으면 좋더라구요. (경험상)

읽으면 좋은

그냥 저냥 #위클리뉴스 #58

Sun, 17 Nov 2019 18:00:00 GMT

위클리뉴스 한달 정도 쉬었습니다. :) 다시 시작 해볼게요.

그 동안의 좋았던 글들 위주로 과거 먼쓸리 뉴스로 이번주는 대신 합니다.

개발자에게 도움이 되는

당신의 커리어가 서쪽으로 간다면 (1)

당신의 커리어가 서쪽으로 간다면 (2)

당신의 커리어가 서쪽으로 간다면 (3)

평범한 개발자 그 이상이 되기 위한 야생 학습 비결 | Popit

더 나음으로 가는 방법을 무엇일까? 궁금 하다면 읽어 보면 좋을 그런 글이다.

대학생이 신입 개발자로 공개 구직한 후기

이렇게 공개 구직을 통해 자신을 선보이는 방법도 좋은 것 같다. 나때는 생각지도 못한 방법이었는데, 내가 찾아 가는 것도 좋지만, 나는 이런 개발자인데, 어때요? 라고 제안을 하는 느낌이다.

기술 뉴스 #137 : 19-11-01 :: Outsider’s Dev Story

기술 뉴스 #138 : 19-11-16 :: Outsider’s Dev Story

팀을 맡고, 한 달 동안 가장 공을 들인 일

읽다가 뼈 맞은 기분이었는데, 가장 중요한 포인트만을 설명하고 계셨다. 함께 돕고, 성장하자. 즉, 함께 자라기였다. 그리고, 일을 기다리지 말자. 정말 좋은 포인트라고 생각 한다.

월간 개발자스럽다 #48

“10월의 월간 개발자스럽다” 한 동안 지난 친 글들이 많은데, 참 좋은 글이 많았다. 읽어보자. 다 볼 필요는 없다.

외국인과 Remote 환경에서 협업하기 - 잔디 블로그

리모트 근무라는 부분은 사실 좀 어렵다는 생각을 하곤 했는데, 이 글을 읽으면서 마냥 어려운 일은 아니겠구나라는 생각을 하게 되었다. 역시 노력과 의지의 문제일까?

개발하기 바쁜데 글까지 쓰라고? (글쓰는 개발자가 되자.)

개발자 글쓰기에 관한 주제 글인데, 바쁜 와중에도 토이 프로젝트로 매일 아침 메일로 전해주는 개발자들의 이야기에 항상 감사함을 느낀다. 블로그는 자기 자신을 성장케 하는 수단이다. 사실, 귀찮음이 큰 작업이지만, 그럼에도 친절하게 한 걸음 한 걸음 방식으로 글을 써 주시는 개발자분들에게 항상 감사하다.

내 맘대로 위클리 뉴스 - 2019년 44주(2019.10.20 - 2019.10.26)

Java / JS / Python등의 글타래 모음인데, 꼭 읽어 주셨으면 하는 개발 뉴스이다. Spring 관련해서 HTTP message를 변경 해야 하는 예시 글이 있는데, 도움이 많이 되었다.

AWS에서의 5년… 글로벌 회사에서 배운 것 :: Channy’s Blog

AWS 테크 에반젤리스트 윤석찬님의 글인데, 회고글의 성격으로 글로벌 회사에서 배운 점들에 대한 부분과 한국 기업에서 일 했을 당시의 과거 경험의 비교가 있다. 물론, 어느 부분이 더 좋다 나쁘다는 없지만, 글로벌 회사는 기록을 잘 남기는 부분과 어느 상황에서도 일 할 수 있도록 구성 된 원격 근무 환경이 좋다고 생각 한다.

https://evan-moon.github.io/2019/11/16/the-way-to-control-anxiety/

에반님의 글이 좋은 이유는 누구나 고민할 법한 내용을 정말 과감하게 다 써내려 간다는 점이 아닐까? 대다수 사람들이 자신의 약점이나 고민들을 털어 놓지 않는데, 개발자로써 경험할 수 있는 고민과 불안함에 모두 써주셨다. 아마 읽어보시면, 많은 공감을 하게 되지 않을까? 싶었다.

http://woowabros.github.io/techcourse/2019/11/15/techcourse-level3-retrospection.html

다른 분들의 “꿈꾸는 프로그래머” 이야기는 너무 좋다. 내가 좋아하는 주제이자, 술 마시면 하는 이야기들이다.

https://krksap.tistory.com/1640

싱가폴 이직에 관심이 있으시면, 읽어 보시면 도움이 되는 자료 😀

JavaScript

2019년과 이후 JavaScript의 동향1

2019년과 이후 JavaScript의 동향2

2019년과 이후 JavaScript의 동향 시리즈인데, 항상 양질의 정보와 사견을 추가 해주셔서 읽기도 너무 좋고, 편리하다.

코드스피츠85 1회-(1) JavaScript Now

코드스피츠85 1회-(2) Runtime때 일어나는 일들

코드스피츠85 2회-(1) 자바스크립트의 동시성

코드스피츠85 2회-(2) 동시성 모델을 직접 구현하며 이해하기

코드 스피츠 S85 스터디에 참여하시고, 강의를 정리한 내용 + 스스로 학습하신 내용을 추가하여 정리 하신 글인데, 퀄리티가 높기 때문에, 해당 스터디에 참여 하지 않더라도 블로그를 통해 정보를 습득 할 수 있다.

Tool

https://johngrib.github.io/wiki/my-mac-os-terminal/

기계인간님의 MacOS 터미널과 친해지는 방법에 대한 소개✍️인데, 어떻게 터미널과 친해졌는지 목차별로 상세하게 정리를 해주셨다. 꿀팁이 정말 많다. 😀

일반적인

“세상에는 더 많은 이야기꾼이 필요합니다”

왜 공학이 인기인가? 공학만이 정답일까? 문과에 대한 길도 필요로 하다. 우리는 이성적인 사람이 아닌 감성을 지니기도 하기 때문인데, 사실 기술력이 뛰어나기만 한다고 시장을 선도 하진 않는다. 결국 행동하게 만드는 것은 감성이 아닐까? 이 부분을 잊지 말아야 한다고 생각 하는 편이다.

책은 읽는 것보다 사는 게 더 재미있다

진짜 나의 이야기라 공감한다. 예전에는 사실 스마트폰에 늦게 입문한 편이라 그 전에는 3G 사용자라 책을 읽는게 진짜 재밌었는데, 요즘은 24시간 내내 재미난 영상, 글들을 볼 수 있다. 그러다 보니 읽는 속도가 진짜 못따라 간다. 그렇지만, 결국 그럼에도 불구하고 독서를 하려면, 책을 사야 한다. 언젠가는 읽는다. 태리야끼 배우님이 말했다. “3장만 읽어도 그 책의 값어치는 다 한겁니다.”

‘노션병’에 걸리지 마세요

노션이 항상 최선은 아니다. 나 또한 노션과 에버노트 둘 다 쓰고 있다. 선결제 하지 말고, 먼저 써보고 생각 해보자.

나를 지치게 하는 관계와 거리 두기

거리 두기의 연습을 적절한 시기마다 하는 것을 추천 하는 편이다.

그냥 저냥 #위클리뉴스 #57

Sun, 13 Oct 2019 19:47:00 GMT

개발자에게 도움이 되는

2019년 중간 점검

item4님의 중간 점검인데, 보통은 에세이 느낌으로 쓰거나 하는데, 이 분은 각 항목에 정량적인 평가를 위한 점수를 부여하며, 점검하는 모습이 인상적이었습니다.

내가 Toss를 탈퇴한 이유 - tebica story

Toss 앱을 삭제하고, 탈퇴하는 이유에 대해 정리한 부분인데, 결국 어떤 서비스는 목적에 맞게 쓰는 것이 제일 좋은 생각이 든다. 그 목적이 사라지면, 사실 의미가 없다.

[B급 프로그래머] 10월 1주 소식(개발/관리도구, 고성능 서버/데이터베이스 부문)

B급 프로그래머님의 10월 1주 소식인데, 닉네임만 B급이고, 소식도 항상 A급이었는데…이제는 가끔 직접 쓰시는 글들이 건빵의 별사탕처럼 기다려진다.

내게 실용적이었던 프로그래밍 공부 방법들

학습 하는 방법이나 자신에게 좋았던 유투브 강의 혹은 싸이트들을 소개하고, 클론 코딩등을 공유 해주셨는데, 개발자를 꿈 꾸는 이들에게는 정말 좋은 자료라 생각 한다.

10 software development cults to join

데코레이터 패턴(Decorator Pattern)

데코레이터 패턴을 왜 사용하고, 왜 필요로 한지? 그리고 책들의 예제와 실제 Java.io를 소개 하며, 실제 예시를 통해 자세하게 설명한 글이다.

논문 읽기 - 대학원생 때 알았더라면 좋았을 것들

논문 읽기에 관한 꿀팁과 논문의 형식에 대해서 소개를 통해 논문 읽기가 그렇게 엄청나게 어려운 것은 아니라는 것을 소개 하고 있다.

개발자를 위한 OS X(>= Catalina) 설정

Mac 사용자라면, subicura님의 맥 설정에 이은 상곤님이 쓰신 이 글을 통해 설정 해보면 어떨까? 뭐…각자 환경이 다르니, 직접 커스텀 해보는 재미도 있을 것 같은데, 잘 모르고 보편적인 설정을 하려고 한다면 한번쯤 따라하면 좋다.

[입 개발] redis-cli 에서 -rdb는 주의해서 사용하셔야 합니다.

redis cli에서 쓸 수 있는 옵션을 사용하다 발생한 오류에 대하여 소스 코드 레벨에서 설명해주신 글입니다.

널 오브젝트 패턴 (Null Object Pattern)

기계인간님께서 널 오브젝트 패턴에 대해 정리 하신 글입니다. 신입 개발자 시절에 본 Null Object Pattern을 이해 못했는데, 물론 지금도 정확히 이해하고 쓸 줄 아는 것은 아니지만, 확실히 적절하게 사용하면 "좋은" 느낌을 받게 된다.

JavaScript

[React] 커스텀해서 제어하기 :: 마이구미

form과 같은 영역에서 뒤로 가기를 눌렀을 때의 상황처럼, 어떤 행위에 대한 페이지 이동을 막고 싶을 때가 있다. 그런 경우를 네비게이션 가드라고 한다고 한다. 그에 대한 글이다.

Improving V8 regular expressions

2019-09-30: React 16.10.0, Node.js 12.11.0(worker_thread), 네트워크 요청과 UI 갱신의 경합(race)

주요 모듈들의 업데이트 정보 및 JS 관련 아티클들이 수록 되어 있습니다.

React 전, 7가지 배경지식 다지기

React를 배우기 전에 7가지의 배경지식을 쌓아 보면 좋겠다는 의미로 글을 써 주셨지만, 제 생각에는 크롱님이 언급 해주신 그 7가지가 정말 중요한 프론트엔드 개발의 포인트 같다는 생각도 하게 되었습니다.

JavaScript Naming Conventions - RWieruch

JavaScript와 React 관련 포스팅을 많이 써주는 개발자로 유명한데, 이번에는 네이밍에 관해서 글을 써주었는데, 읽어보면 정말 좋다. (내가 왜 이렇게 썼을까? 하는 후회도 살짝 하게 된다.)

[번역] useEffect 완벽 가이드

Dan Abramov가 작성한 글을 rinae님이 번역 해주신 useEffect 완벽 가이드 글입니다. 리액트를 이용해 개발을 하는 이라면, 꼭 읽어 보셨으면 합니다.

Java

Java Optional 바르게 쓰기

항상 궁금한 Optional을 잘 쓰는 방법이었는데, 딱 찾게 되었다. 이 글은 Java를 쓰신다면, 꼭 읽어 보길 바란다. 필요한 점만 콕콕 알맞게 설명이 되어 있다.

ZGC, The Z Garbage Collector

Java 11에서부터 실험적으로 등장하게 된 GC 중에 하나인 ZGC인데, 정말 궁금한 내용이었는데, 기계인간님께서 잘 정리 해주셨다.

String equalsIgnoreCase() Java Example

A Programmer’s Guide to Agile Implementation

System.out.println vs Loggers

항상 습관적으로 logger 대신 sout이라는 단축키를 통해 println으로 값을 보거나 하는데, 대다수 사람들이 왜 로거를 쓰라고 할까? 에 대해 궁금하다면, 이 글을 보면 좋겠습니다.

What is null in Java

도대체 null을 왜 쓸까? 생각하지만, null을 프로젝트 레벨에서 완전히 걷어내는 것이 가능할까?에 대한 궁금증이 좀 있다. 아무리 생각해도, 쉽진 않다. ;;;;

Graceful Shutdown of a Spring Boot Application | Baeldung

Spring container가 termination 되기 전, setAwaitTerminationSeconds 옵션으로 일정 시간을 두고, connection을 해제 하거나 하는 작업을 지정하여 container가 내려갈 즈음에는 외부 통신에 해당하는 모든 것들이 종료 된 이후이니, 안전하게 종료 할 수 있으니 설정 해 두면 이득이 될 수 있겠다 생각 한다.

[Java] forEach와 for each 의 차이점은?

카페에 올라온 질문에 대한 Java8과 iterable이라는 인터페이스의 설명들을 토대로 질문자의 코드에 있는 forEach와 for each의 차이를 설명하고 있다.

Become a Master of Java Streams - Part 1: Creating Streams

stream을 잘 쓰려면, 결국 다른 사람들은 어떻게 stream api를 활용하는지 보면 좋은데, 각 소제목에 맞는 stream 사용에 관한 짧은 글이다.

일반적인

회사에서 오래 버티는 사람들의 특징

이 글을 읽으면서 어느 면에서는 부합하는 게 있다가도, 아닌 것 같다가도…잘 모르겠다. 근데, 회사에서 오래 버티는 사람들은 '버틴다'라고 하지 않고, '흘렀다'라고 표현하지 않을까? 생각 한다.

스웨덴은 어떻게 강력한 ‘복지 정책’에도 ‘경제 성장’이 가능했을까?

경제학이니 하는 것은 내게 항상 어렵지만, 재미 있는 주제이긴 하다. 어쩌다 읽게 된 글이지만, 마지막의 초중등 교육은 중요하다는 결이 내게는 큰 울림으로 다가왔다.

서초루비 10월 밋업

Thu, 10 Oct 2019 20:00:00 GMT

Why What Elixir - JSON ?

엘릭서 창시자가 얼랭을 보고 개념은 좋아 했지만, 문법이 마음에 들지 않았다. Erlang + Ruby = Elixir가 되었다.

대다수 개발자들이 Rails를 쓰다가 요즘은 Elixir를 쓰게 되었다.

Phoenix Framework

사용하기 편하지만, 속도, 유지보수성에서 좋다.
슬랙, 핀터레스트, 디스코드등등 회사에서 사용 한다.
금일 오픈한 달빛 조각사 게임이 엘릭서로 개발 되었다.

Elixir

Concurrency
- Actor model (erlang으로 부터 기원됨)
- No mutable data
- No Lock
- No Blocking
Efficiency
- pinterest 30대의 Java -> 15대의 Elixir
- paperduty -> rails -> phoenix framework로 변경하는데, 1주일정도 소요됨.
Scalability
Reliability
Functional / Concurrency / Fault Tolerance / Metaprogramming의 언어이다.
엘릭서의 메타프로그래밍 방식이 루비보다 훨씬 좋다.
메타 정보를 엘릭서 언어로 만들기 때문에 엘릭서 자체에서 사용이 가능하다. (클로저의 매크로랑 비슷한 것 같다.)
엘릭서 현재 버전이 1.9인데, 이미 세부적인 모든 기능 개발은 거의 끝났다. (이미 얼랭에 필요한 기능을 거의 문법을 바꾼 느낌??? 문법적인 포팅한 수준으로 이해하면 될듯..?)

syntax

pattern matching
module
namespace
railway oriented programming
tuple
pipe operator
elixir school
phoenix

기타

document가 정말 잘 되어 있다.
커뮤니티가 좀 작긴 해서, 필요한 모듈들이 모두 있는가?에 대해서는 좀 … 부족한 느낌
ecto라는 데이터를 처리 하는 툴이 있는데, ORM은 아니지만, ORM처럼 데이터를 처리 하는 툴이 있다.
- https://hexdocs.pm/ecto/Ecto.html
- 해커톤을 했는데, 16살 된 개발자가 만들어냈다고 한다.

서비스 중단 없이 루비 버전 2.6 업그레이드 하기 - 정창훈

History

2017년 - 루비 2.2 -> 2.3

2019년 - 루비 2.3 -> 2.6

왜 업데이트를 해야 하는가?

Capistrano 배포가 점점 잘 안됨.
Ruby 버전 업도 너무 어려움.
잘 안되니까 하기 싫어짐

Docker 도입

1대만 배포해서 테스트 하기 쉬움. (그 전은 어려웠…)
1대만 적용해보고, 장애나면, 빼면 되니까…

Change log를 체크

각 버전에 별거 없어서 … 업데이트 해보자.

bundle update

하는 순간 버전 업데이트 폭망의 지름길

bundle update rails —conservative

최소한의 업데이트를 하도록 설정

테스트

진정한 테스트는 프로덕션에서 …
- (이 말은 진리이다.)
개발 서버에서 해봤자 다 잡히지 않는다.
이전 대비 CPU 10%의 절감을 보게 되었다.

rails error 정보에 stack trace가 안됨.

binding_of_caller version도 rails와 같이 올려주어야 한다.

rails 4.x -> 5.x 버전 업 도전

Bigquery gem이 반환하는 데이터 형식이 바뀜.
Rails 5.2에서 암호화 알고리즘 변경
Rails 4부터 쿠키도 암호화…
Sidekiq 설정 하는 위치 변경
레일즈 5.2에서는 사이드 킥 없이 웹 서버 하나로 액티브잡 처리가 된다.
Rails 6에서 멀티 데이터 베이스 지원 …

기타

채팅 기능 같은걸 굳이 레일즈에서 개발 해야 하나?
- 그래서 고랭으로 새로 개발.
새로운 기능이나 사업은 새로운 레일즈 프로젝트로 생성…
MSA를 위한게 아니라, 어쩔 수 없이 쪼개어 만들게 되어 가는 것 같다.

질문

전체 배포 얼마나 걸리는지?
- 지금은 8분 정도 소요
다른 젬 업데이트 했던 경험이 있는지?
- 따로 특수하게 꼭 필요 했던 젬 업데이트는 없었다.

그냥 저냥 #위클리뉴스 #56

Sat, 05 Oct 2019 17:53:00 GMT

개발자들에게 도움이 되는

ixy-languages/ixy-languages

왜 Rust가 C보다 조금 느린가?에 대한 글인데, 짧은 글이라 읽어 보기 좋다. 러스트 이야기는 많이 들어 봤지만, 실제로 코드를 작성 해본 적은 없다. 결국 러스트는 ”C보다 안정성이 있고, Wrapper Object를 위한 DMA buffers를 필요로 한다”로 이해를 했다. 물론, 아직 러스트에 대해 잘 모르기에 더 찾아 보아야 한다.

The Death of Agile and Beyond

애자일의 죽음과 그 너머에 대한 이야기인데, 사실 애자일이 왜 죽었을까? 왜 문제가 되는지? 어떻게 해야 하는가?에 대한 고민이 있었는데, 우연히 찾게 되었다. 그런데, 중요한 것은 엄청 길다.

How to become a better Software Developer

어떻게 하면, 더 나은 개발자가 되는가?에 대한 글이다. 좋은 부분은 ”Code every day“이다. 결국, 개발자는 매일 코드를 작성하고, 어떻게 나아가야 하는지? 고민하는 직업이 아닐까? 생각하는 편이다.

블로그 개설을 망설이고 있는 사람들에게

블로그를 어떻게 해야 할까? ,어떤 글을 남길까? 고민하는 개발자들에게 도움이 되는 글이다.

파이콘 2019 후기

파이콘 2019에 참여 했던 sangkon님의 후기 글입니다. 여러 가지 의견이 서술 되어 있지만, 중요한 부분은 지역 모임에 관한 자신만의 고찰을 공유 해주셨는데, 결국 파이썬을 대부분의 회사가 Major language로 채택 하진 않는다. 그리고, 대부분 ML로써의 파이썬에 집중 한다는 것이다. 물론, 나도 파이썬을 쓰진 않지만 아쉬운 모습이긴 하다. 끝 무렵에 써주신 것처럼 다양한 사람들이 모여서 자신만의 이야기를 하는 모임도 생겨나면 좋겠다.

이상한 모임 세미나 - 99CON 참석 후기

99콘 참석 후기를 남겨주셨는데, 각 세션에 핵심만 잘 추려서 정리를 해주셔서 가지 않았던 분이라면, 읽어보면 좋겠다.

오버엔지니어링과 언더엔지니어링의 경계

설계는 어떻게 해야 하는 걸까? 매해 고민 스럽다. 이렇다 할 정답을 잘 모르겠다. 그래서 huns님이 남겨 주신 글을 보고 어느 정도 갈피를 찾았는데, 설계에 관한 고민이 생긴다면, 이 글도 한번 참고 해보자.

내 맘대로 위클리 뉴스 - 2019년 39주(2019.9.15 - 2019.9.21)

여러가지 글이 있지만, "Modern Best Practices for Testing in Java"라는 글을 추천 해 주셨기에, 읽어 보았는데, 항목 별로 참 좋은 부분이 많았다. 다른 분들도 읽으면 도움이 많이 되지 않을까?생각 한다.

당신의 커리어가 서쪽으로 간다면 (1)

당신의 커리어가 서쪽으로 간다면 (2)

한번쯤 읽어보면 좋은 내용이다. 왜 나의 커리어가 내 마음대로 흘러가지 않을까?에 대한 물음을 조금이나마 알 수 있다. 물론, 이 글의 내용이 항상 정답은 아닐 것이다.

JSCONF KOREA 2019 돌아보기 - amati.io

JSCONF를 가고 싶었는데, 생각보다 비싼 비용이라 회사 지원을 받지 않고 가기에는 이미 나는 Google I/O를 다녀왔기에 조금 눈치가 보였다. 아마 다음번, 다시 재도전을 할 수 있지 않을까? 생각을 한다. 세션 내용의 핵심 요약만 보았는데도 좋은 내용이 많아 가서 듣지 못한 부분이 아쉽다.

내가 겪었던 번아웃, 그리고 극복했던 경험

일일 1커밋도 아닌 일일 10커밋을 4년간 진행해오고, 일을 엄청나게 하면서 겪은 번아웃 그리고, 극복한 개발자분의 이야기이다.

『나는 LINE 개발자입니다』: 라인이 말하는 개발자를 위한 9가지 문화

실제로 지금 책을 읽는 중인데, “라인”이라는 회사가 참 재밌게 일 하는 구나 싶기도 하다. 라인은 어떻게 일 하는지? 궁금 하신 분들, 평소에 라인이라는 회사를 매력적으로 생각 하신다면, 읽어보면 좋겠다.

월간 개발자스럽다 #47

개발자스럽다의 월간편인데, 재미난 내용이 많으니 꼭 시간 내어 읽어보면 좋겠다.

2019년도 개발자 에코시스템의 현황 인포그래픽

Jetbrains에서 조사한 결과를 인포 그래픽으로 보여주는데, 질문도 참신하고, 인포그래픽을 잘 활용한 예시로 볼 수 있다. (시각화는 재밌는 요소인 것 같다.)

기술 뉴스 #135 : 19-10-01 :: Outsider’s Dev Story

여러가지 정보가 있지만, 이번에는 tmux 관련 부분과 HTTP/3과 관련된 아티클이 좋았습니다. 그리고, 우아한 형제들의 TF팀장으로 일하며 겪은 일들에 대한 부분을 간접적으로 경험할 수 있는 글이 재미나고, 고뇌와 기획 관점의 업무 진행에 대해 알 수 있었습니다.

내 맘대로 위클리 뉴스 - 2019년 40주(2019.9.21 - 2019.9.27)

kotlin을 접하면 항상 듣는 시퀀스나 코루틴에 대한 아티클이 올라와 있어 읽게 되었는데, 좀 어렵지만 좋은 글이라 참고하는데 도움이 많이 된다. 물론, 파이썬 관련 내용도 좋은 내용이 많다.

Java

Using Java Optional Vs. Vavr Option - DZone Java

Java 8의 Optional 과 Vavr library의 Option의 비교이다. 생각 해보면, 거의 유사하기 때문에 사실, Java 8 표준안을 쓰는 것이 더 낫다는 생각이 들었다.

Unit Tests for Spring’s WebClient - DZone Java

WebClient를 위한 unit test 설명 글인데, 혹시라도 RestTemplate이 아닌, WebClient를 쓰는 환경이라면, 꼭 따라 해보자.

우아한 스프링 배치 테크세미나 정리 및 후기 (by 우아한 형제들)

지난주 우아한 스프링 배치 테크 세미나가 있었는데, 태태태님이 직접 세미나에서 듣고 본 것에 대해 상세하게 정말 잘 정리를 해주셨는데, 가지 않은 분이라면 꼭 참고하시면 좋은 내용이 많다.

Spring Batch의 멱등성 유지하기

우아한 스프링 배치의 테크 세미나를 발표하신 동욱님의 블로그 인데, 스프링 배치에서 멱등성을 유지 하는 방법에 관한 이야기이다. 정말 흔하게 있을 수 있는 일이라 공감이 많이 된다.

Optional.orElse() Vs. Optional.orElseGet() - DZone Java

orElse(),orElseGet()을 잘 쓰고 쉽지만, 이렇게 간단하게 비교 해주니 좋았다. 더군다나, orElseGet()을 쓰면, 상황에 따라 성능 면에서도 유리 하다. orElse()는 Optional<T>가 null이든, 아니든 항상 실행 된다. orElseGet()은 Optional<T>가 null이면 실행 한다.

JavaScript

Reasons to learn Redux as a JavaScript Developer - RWieruch

JavaScript 개발자들이 Redux를 배워야 하는 이유에 대해 설명한 글인데, 읽다 보면 생각보다 약간 Redux 뽕에 취할 수 있다. 리덕스의 모든 것이 명확한 목적이 있으며, 불변성을 기조로 작동 하고, 순수 함수를 지향한다. 그리고, ES6 문법과의 유사성, 단방향의 데이터 흐름을 지니고 있다 등등…

JavaScript Weekly Issue 456: September 27, 2019

JavaScript weekly를 이메일로 받는데, 사실 잘 보지 않다가 열어 보았고, 이번에는 좀 재미난 기사들이 많았습니다. 효율성을 위한 V8 최적화라던지? 여러 이슈를 재밌게 볼 수 있었다.

패턴 매칭(Pattern Matching) in JavaScript

Scala나 Kotlin에서도 사실 비슷한 문법을 볼 수 있는데, Pattern Matching이란 개념은 사실 코드의 가독성이나 생산성을 높여주는데 도움을 주기 때문에, JS 세계관에서도 맛볼 수 있으면 좋겠다. Pattern Matching에 관한 설명글이다.

Don’t Sync State. Derive It!

React에 관한 이야기인데, 상태를 동기화 하지 말라는 글인데, 어떤 상황일 때, 문제가 되고 그에 대한 해결 방법에 대한 글이 담겨 있다. 그리고 상태를 파생 시키라는 말은 사실 좀 와닿지는 않는다.

Data

데이터 분석을 위한 머신 러닝 기초 - 1

데이터 분석을 위한 머신 러닝 기초 시리즈 글의 첫번째 글이며, 데이터 분석에 관한 내용이 요즘은 좀 관심이 가기 시작한 분이라면 읽어 보길 추천 한다. 머신 러닝의 맥락을 알 수 있다. (요즘 관심이 가는 분야이기도 한데, 이유는 웹 개발자 보다 뭔가 머신 러닝에 대해 혹은 데이터 분석에 대해 어느정도 인지를 하고 있으면, 실무에서 써먹을 일이 많기 때문이다.)

일반

한국 사회가 청년들을 ‘책 읽지 않게’ 만들고 있다

너무나 바쁜 일상에서 우리는 우리가 좋아하는 책을 얼마나 많이 그리고 자주 읽을까? 나는 기술서를 일반 책보다 훨씬 더 많이 보고 접한다. 그게 약간 좀 슬픈 일인게, 나는 원래 일반 서적을 자주 읽는 편에 속했다. 못해도 1년에 30여권은 읽었는데, 이제는 기술 서적 보느라, 기술 문서 보느라 시간이 없고, 야근 하고 집에 오면 컴퓨터 자체를 보기가 싫다. 그런 맥락에서 이 기사가 나의 공감을 이끌어 냈다.

좋은 팀장에게는 이 세 가지가 있더라

팀원들이 바라는 팀장이 갖추어야 할 능력이 무엇일까? 그 부분에 대해 고민을 해본 사람이라면, 이 글을 읽어보면 공감을 많이 하게 된다.

09화 어리석은 일잘러의 슬픈 착각 13가지

심심하다면, 읽어 볼 법한 내용 같지만, 위트와 통찰력을 가지고 설명 하고 있다.

[3화_행복한 직장을 만드는 관계의 조건] 사장님이 사표를 8번 쓴 이유? 지금 알고 있는 걸 그때도 알았더라면!

CEO 세 분이 모여 관계에 대한 이야기를 해 주시는데, 역시 오래 된 경험을 지니신 만큼 관계에 관한 좋은 방향에 대해 이야기 해 주시는데, 시간이 난다면 보는 것을 추천한다. (나름 재밌다.)

직장인 출근길 비애: 그래도 내일모레면 월급날이잖아

한때, 2시간 넘게 통근을 1년을 했는데, 정말 죽는 줄 알았다. 현재는 자취를 하는데, 정말 편해졌다. 심지어 10분 거리인 지금도 여름날 걸어가면, 땀이 비 오듯 내린다. 정말 직장인 출근길은 모두가 공감하는 주제인 것 같아서 혹시나 옛 기억을 추억하는 사람들을 위해 가져왔다.

그냥 저냥 #위클리뉴스 #55

Sat, 28 Sep 2019 11:39:00 GMT

개발자들에게 도움이 되는

VisBug 기여 이야기 - 1

rinae님이 글로벌 전문 개발 지원사업의 활동에 참여하는 겸 오픈 소스 개발에 기여 하고자 활동한 경험기에 대해서 써주셨는데, 어떻게 처음 시작 했고, 오픈 소스 기여에 대한 팁을 공유 해주셨다.

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

정말 많은 양질의 자료를 개인 위키에 정리 하시는 걸로 유명하신 손권남님의 “이랬으면 어떨까? 혹은 직접 경험 하신 스토리의 각 소제목을 붙여 “에피소드”형식으로 정리 해주셨는데, 글도 정말 잘 쓰시는데, 현업에서 가장 중요하고, 장애가 많이 나는 포인트들만 콕! 콕 찝어 설명 해주셨습니다. (읽으면서도 놀랐다는…)

[B급 프로그래머] 9월 3주 소식(개발/관리도구, 고성능 서버/데이터베이스 부문)

많은 양질의 주제를 각 주마다 정리 해주시는데, (이번주는 머신러닝은 아니여서) 내가 관심 있는 분야가 많았다. 그 중에서도 Cost of JavaScript 2019라는 글의 소분류 내용인 The cost of parsing JSON의 글이 좋았다. 물론 Rust 관련 글이나, 역 인터뷰 질문 번역글도 좋았다.

JavaScript

The cost of JavaScript in 2019

Code caching for JavaScript developers

Blazingly fast parsing, part 2: lazy parsing

v8 엔진 개발자들이 직접 작성하는 블로그가 있는지 처음 알았다. 그런데, 정말 양질의 글이 많이 올라와 있는데, The cost of JavaScript in 2019, Code cashing for JavaScript developers, Blazingly fast parsing, part 2: lazy parsing 위 3가지의 주제는 꼭 읽어보면 좋겠다.

CRA(Create React App)에 tslint, eslint, prettier 적용하기

토이 프로젝트에 tslint,eslint, prettier를 적용하면서 남긴 공유 글이다. 그런데, tslint 진영이 eslint로 합쳐지고, 기존 tslint는 deprecate 되기 때문에, 둘 중 하나만 설정 해도 되지 않을까? 생각 한다. 참고: Roadmap: TSLint -> ESLint

Typescript와 NodeJS를 이용한 간단한 목킹 서버 띄우기 02

TypeScript와 Node.js를 이용해 API 서버를 만드는 튜토리얼을 작성 해주셨는데, step by step으로 잘 정리 해주셨다.

Java

ConstraintValidator을 이용해서 효과적인 검증 -Yun Blog | 기술 블로그

Spring WebMVC framework에서 Controller로 넘어온 요청 값 검증을 효율적으로 하기 위한 글을 정리 해주셨다. reqeust로 들어온 parameter를 검증 하기 위해 조건문을 controller에 덕지 덕지 바르곤 했었는데, 사실 Spring WebMVC framework를 주먹 구구식으로 배우다시피해서 어설픈 부분이 있었는데, 이번 글을 통해 요청 값 검증에 대한 부분에 대한 궁금증은 좀 해소 된 기분이다.

marchof/java-almanac

Java의 언어의 변천사에 대한 부분을 모두 정리 해둔 Repository인데, 아마 지속적인 업데이트 될 가능성이 많다. (만든이가 Java 히스토리를 공유 하고 싶어서 만든 느낌)

CSS

잘 알려지지 않은 유용한 CSS 속성들

안희종님이 잘 써보지 않았던 CSS 속성들에 대해 소개와 직접 설명을 하는 글인데, 설명이 자세하기에 도움이 많이 된다. 다만, 정말 본 적 없는 속성들이다. CSS 세계도 정말 광활하게 넓은 들판처럼 무궁무진한 세계라는 생각을 하곤 한다. 물론, 나는 프론트팀에서 프론트 개발을 하고 있지만, CSS를 직접 손대지 않는다. 그래서 약간의 아쉬움이 있긴 한데 틈틈히 보려고 한다.

우아한 형제들 9월 세미나 - 우아한 스프링 배치

Thu, 26 Sep 2019 19:30:00 GMT

기본편

배치 애플리케이션 ?

배치 애플리케이션은 도대체 무엇인지? 질문을 많이 받는다.
- 위키 페이지 용어 설명을 참고 해보면, 배치 애플리케이션은 결국 사용자와 상호 작용하는 애플리케이션이 아니다. 결국, 요청이 한 번 이루어지고, 모든 처리가 배치 애플리케이션에서 처리 되고 끝난다.
일반적인 웹과 무슨 차이가 있는가?
- 후속처리가 주로 이루어지고, 절대적인 속도로 이루어진다.
- QA가 어렵다.
- 테스트 코드를 무조건 작성 해야 한다.

Spring batch vs Quartz

Quartz는 스케쥴링 프레임워크이다.
Spring Batch는 Batch 프레임워크이다.

당연히 둘의 차이가 있다. 비교 대상 하는 것 자체가 다른 역할을 하는 프레임워크이기에 어렵다.

배치가 필요한 상황

일정 주기로 실행 되어야 하고, 실시간 처리가 어려운 대량의 데이터를 처리 할 때
대용량의 데이터 처리가 절대적인 요구사항

메모리에 올려서 ?

Paging 혹은 Cursor로 pagesize만큼 읽어오고, chunkSize만큼 commit한다.

Job / Step / Tasklet

Job > Step > Tasklet > Chunk
wrtier/reader가 따로 움직이는 개념은 아니고, ChunkOrientedTasklet의 위주로 움직인다.

@JobScope / @JobParameter

step에서는 @JobScope를 줘야 JobParameter를 받을 수 있다.
tasklet에서는 @StepScope를 줘야 한다.
Enum/Date(LocalDate)/LocalDateTime와 같은 경우는 형변환(String)을 해주어야 한다.
이러한 제약을 해결하기 위해 JobParameter 순수 클래스를 만들어주고, @Value로 넣어줄 수 있도록 @Bean으로 만들어주고 해당 값을 실제 스텝에서 호출해서 사용하기만 함.
@JobScope, @StepScope는 Lazy loading(Late Binding으로 설명해주심)이다.

Lazy Loading으로 쓴 이유는 결국 해당 스코프가 늦게 로딩 되는 걸로 이해하면 편할듯..

활용편

관리 도구

Cron
Spring MVC + API Call
Spring Batch Admin (Deprecated)
Quartz + Admin
CI Tools(Jenkins/Teamcity etc)
Spring Cloud Data Flow

여러가지 중에서 어느 정도 인지도도 있고, 노하우를 쉽게 얻을 수 있는 Jenkins를 선택 한다. (혹은 Spring Cloud Data Flow를 쓰는 방식이 좋을 수 있다.)

Jenkins 공통 설정 관리

GC 설정
어플리케이션 이름
어플리케이션 Profile

위 정보들이 배치마다 설정을 입력 해주어야 한다.

Environment variables를 설정 할 수 있기에 해당 정보를 입력을 해주면, 모든 Job에서 사용할 수 있다.

무중단 배포

AWS를 쓴다면, 테스트 및 빌드 후 S3에 업로드 한 뒤에, CodeDeploy로 요청을 넣어서, 스프링 배치를 배포 하게 된다.
- 혹은 CodeDeploy를 안쓰면, SCP를 활용한다.
readlink를 활용하여, app.jar -> v1.jar / v2.jar을 보도록 한다. (배치에서는 실제 v1.jar를 보고 Batch job을 실행한다.)
이미 돌던 Batch job은 v1.jar에서 수행을 하고, 원본 파일이 새로 배포 되면, 새로운 Batch Job은 v2.jar에서 새로운 Job이 실행 된다.
Jenkins Environment variables에서 설정을 하되 실행을 하는 $()는 변수로 뺄 수 없다.

파이프 라인

순차적으로 연결 되어 Batch Job이 실행 되어야 하는 경우
테스트 - 빌드 - 개발 서버 배포 - 스테이지 배포 - 운영 배포를 각 각 분리 되어 있는데, 순차적으로 실행 하거나 병렬로 실행하여 자동화 하고 싶은 경우
여러 작업이 순차적으로 실행 되어야 하는 경우 Step으로 쪼개지 말고, 각 각 분리 시킨다.
- 스텝으로 쪼개고, 순차적으로 실행 되어야 한다면, 파이프 라인으로 연결 지으면 된다.

멱등성

new Scanner / LocalDate.noe()와 같은 경우 멱등성이 깨진다.
- 어제 실행 하거나 오늘 실행 하거나 주어진 파라미터가 같으면, 멱등성을 지켜야 한다.
- 변경 가능한 값인 경우는 모두 JobParameter로 올려서 해당 배치를 실행할 시점의 값으로 실행 할 수 있도록 한다.

그럼 어떻게 오늘 일자를 yyyy-MM-dd형식으로 배치 실행에 파라미터로 넣어 줄 수 있을까? 고민

그래서 Plugin(Date Parameter)을 만듬.

테스트 코드

@ConditionalOnProperty를 활용 한다.
@TestPropertySource를 활용하면, Jenkins처럼 테스트를 돌릴 수 있다.
테스트 코드가 1200개인데, 그 중 370개가 정산 시스템 테스트 그런데, 배치 테스트 속도가 너무 느리다.
원인은 @ConditionalOnProperty가 범인인데, 스프링은 전체 테스트가 수행 될 때마다, Environment가 변화 하면, Spring Context를 재시작 한다.

Environment변화 하는 이유

@MockBean, @SpyBean 사용
@TestPropertySource로 환경변수 변경할 때
@ConditionalOnProperty로 테스트 마다 Config가 다를때

`@ConditionalOnProperty`, `@TestPropertySource`를 제거 하자.

모든 Config를 Loading 한 뒤, 원하는 배치 Job Bean을 실행 한다.
genBean()으로 Job name으로 조회 한 뒤에, 테스트 대상에 포함 시킨다.
위와 같은 작업을 할 수 있는 JobTestUtils로 미리 launcher를 만들어 둔 뒤에, Job Test 코드에서 해당 유틸에 Job 이름을 넣어주고 테스트를 실행 한다.

JPA & Spring Batch

JPA N+1

@oneToMany관계에서 하위 엔티티들을 Lazy Loading으로 가져 오면, 조회 쿼리가 계속 발생
- Join Fetch 사용하되 일시적인 해결 (하위 엔티티 2개 종류 이상에서 걸게 되면, Exception 발생)
- default_batch_fetch_size로 해결 (하이버네이트 설정)
- 위 옵션은 JpaPagingItemReader에서는 작동 하지 않고, HibernateCursorItemReader에서는 가능하다.
- JpaRepository에서도 사용할 수 있는 기능이다.
- 현재는 PR이 리뷰 대기 상태라고 한다.

JPA Persist Writer

entityManager.merge에서 처음 데이터가 저장 될 때도, update 쿼리가 항상 실행 됨.
- 그래서 persist만 하는 JpaItemWrite를 똑같이 만들어서 쓰는데, 4.2에서 릴리즈 되면 수정된 버전이 나온다.

추가 정보

The Definitive Guide to Spring Batch 출간
2020년 상반기 정상혁님, 이동욱님 공동저서 출간 예정

그냥 저냥 #위클리뉴스 #54

Sat, 21 Sep 2019 17:31:00 GMT

개발자에게 도움이 되는

기술 뉴스 #134 : 19-09-15 :: Outsider’s Dev Story

여러 유익한 정보들의 축약이 되어 있는데, 양질의 글들을 잘 정리가 되어 있다. 그 중에서도 나는 github가 rails 6.0으로 github를 서비스 하는 글이 좋았다. 여전히 rails를 좋아하고, github라는 개발자의 소스 코드 집합소라는 관점에서 좀 다른 언어를 사용 하면 좋겠다 싶었는데, 여전히 rails라 좋다. (이유는 모르지만 Java, Node.js가 아니라서 안심이다.) 그리고 우아한 형제들의 신입 개발자분의 파일럿 프로젝트 진행 경험기가 좋았고, 나도 신입 때 이렇게 step by step으로 성장 할 수 있는 여건이 있었다면 좋았겠다. 라는 생각을 하게 되었다. (회사에서 안 해주면, 나 혼자라도 했어야 했는데…)

내 맘대로 위클리 뉴스 - 2019년 38주(2019.9.07 - 2019.9.13)

JavaScript에서 활용 하기 좋은 Array.from에 관한 글과 React 16의 best pratice를 소개 하는 글이 유익 했다.

설계의 중요성을 설명하기가 왜 어려웠을까?

설계의 중요성이란 정말 많은 부분에 있어서 중요하다는 생각을 하곤 한다. 다만, 단점은 우리가 흔하게 해보지 않은 것에 대해서 설계를 완벽하게 하기란 어렵다. 어느 정도 경험은 있어야 한다. 결국 쌓고 부수기의 반복 같다. 어쩌면, 설계의 중요성은 코드를 덜 부수기에 해당 할 정도로 막강한 영향력을 행사하는 부분이다. 그래서 우리는 설계를 가능 한도 내의 튼튼하게 해야 하는 이유 아닐까 ? 그렇지만, 회사에서 이러한 부분을 얻기란 쉽지 않다. 나 혼자 일 하면 가능한 것들이 여러 사람과 여러 역할이 모일 때는 쉽지 않다. 그리고 결국 어떤 이들의 설득을 하려면, 나의 영향력을 키워야 한다. 정말 그게 맞다는 것을 많이 느꼈다. (오리지널스란 책을 보면, 쉽게 이해 할 수 있다.)

컨플루언스 모바일 - SLiPP::위키

카프카의 개념에 대한 정리 글입니다. 마지막 부분에는 RabbitMQ와 비교하는 벤치 마크 인용이 있습니다. 실무에서 Kafka를 정말 잘 쓰고 있기 때문에, 카프카 안 쓰는 서비스가 없다고 할 정도로 표준이라는 생각을 한다.

Java

JDK 13 둘러보기

JDK13에 굵직한 기능에 대한 정리 글이다. Switch Expression이 preview에서 벗어나 정식으로 들어오면 좋겠다. yield 키워드가 들어오다니..신세계다. 나름 ZGC가 궁금하긴 한데, 실무에서는 아직 못 올리고 있다. (어떤 환장 파티가 생성 될지 아무도 모르기 때문에)

React

[React] 1. Development Environment Setup

[React] 2. Redux Architecture

[React] 3. React Architecture

시리즈로 연재 되는 JBee님의 글인데, Front-End 개발을 하는데 만약, React를 활용한다면, 이 글을 통해 하나의 가이드 라인을 제시 해주고 있다고 생각 한다. 물론, JBee님만의 특화된 상황이나 여건이 있을 수 있는 것들도 있다고 생각 한다. 그럼에도 불구하고, 위 글들은 정말 많은 고민과 좋은 내용이 많기에 무조건 추천하는 글이다. (없으면 만들어서 쓴다는 장인 정신 멋집니다.)

Kotlin

[kotlin] 바닥부터 배우는 코루틴 #1

Hika님의 코루틴에 관한 이야기인데, 사실 읽어보면 알 수 있겠지만, JS를 통해 Continuation을 설명 하는 부분이나 Java의 CompletableFuture을 통한 설명으로 결국 Continuation,CPS, Suspend의 개념을 설명하면서 Coroutine을 설명 해주시는 글인데, 내게는 조금 어려웠다. 물론, 내가 요즘 공부를 너무 안한 탓도 있겠지만 말이다. 어쨌거나 JS의 Asynchronous Iterators도 사실 써본? 경험이 없기에 다소 생소 했고, yield를 더 더욱 써보지 않았다. 그래서 조금 어려웠는데, 여러번 읽어보니 이해가 조금은 되었다. 다들 꼭 읽어 보길 추천 한다. 글 하나에 정말 많은 지식이 담겨 있다.

일반적인

심심하면 볼 만한데, 마윈은 정말 이미지 메이커구나 싶었다. A.I.에 아무것도 모르는 구나 싶은 생각이 들었고, 대담자로써는 좋은 태도를 지니고 있지 않다.

조직 내의 팀 그리고 협업에 관한 생각

Sun, 15 Sep 2019 15:12:00 GMT

요즘의 저는 이러한 생각을 하며 지냅니다.

협업 그리고 팀내 역할의 다양성

어떤 테크니컬한 기술적 성장보다 팀이라는 곳 안에서 능력을 배로 올려주는 것은 팀 협업이 아닐까? 고민하면서, 팀 내에서 미스 커뮤니케이션으로 의도치 않게 충돌을 막는 역할이 중요하다는 생각이 들었다. (충돌을 무조건 막는 것보다 잘 정리 하고, 앞으로 나아가게끔 하는 게 중요하다.)

핵심은 결국, 충돌 속에서 그 해결책을 잘 찾아 가는 것이 중요하고, 서로의 마음이 상하지 않고 앞으로 나아가는 것이 제일 중요하다는 생각이 들었다.

회사라고 감정을 배제 해야 하는 것은 아니다. 개발자이기 전에 우리는 모두 사람이다.

기술적 성장은 무조건 회사에서 해야 하는 것은 아니다. 모든 것이 일치 되면 좋겠지만, 그렇지 않아도 된다.

결국 팀 내에 감독, 코치, 매니저, 선수의 역할 레벨이 고루 고루 섞이고, 때에 따라 유동적인 느낌으로 잘 순회가 되는 팀이 최고이다.

그럴려면, 나는 어떤 역할을 쌓아갈지 고민이 되는데, 이는 해보면서 잘 하는 것을 택하면 된다. (내가 잘 하는 부분에서 팀 동료들의 시너지를 올려주면 된다.)

"실리콘 밸리를 그리다"라는 책에서도 코드 리뷰를 잘 하는 사람이 다른 일 보다 좀 더 그 시간을 많이 할애하는 것과 같다. 코드를 작성 하지 않는다고 그 역할을 가진 사람을 보고 “일을 덜 하네!”라고 생각 한다면, 그 생각을 가진 사람과는 같이 일 하기 힘들다.

내 생각에는 팀내의 페이스 메이커와 가이드 러너의 역할을 잘 키우는 것이 중요하다. 그리고 작은 단위에서 부터 의견을 위로 올라가야 한다. 그러한 문화를 만들어 가는 것이 좋다.

어떤 의견이든지 "~ 좋은 의견이네요."라고 말하는 습관을 가져 보는 것도 좋지 않을까? 그리고 실패에 칭찬하는 것도 좋은 방법이다. 우리는 대부분 “실패”에 너무 두려워 한다. “성공은 실패의 어머니”라 배워 놓고, 정작 실패를 두려워 한다. 그 마인드에서 벗어나게 하는 것도 팀내의 문화에 따라 달렸다.

그리고 커뮤니케이션은 결국 대화의 방법을 떠나, 상호 존중과 말투(어투) 그리고 종합적인 언어에 따라 달렸다. (~~음성 언어는 실제로 많이 차지 하지 않음.~~)

내가 바라보는 권한을 가진 사람의 덕목

그리고 작은 결정 권한을 가진 이는 그에 맞게 블라인드 사이드를 항상 조심 하고, 빠르게 인지 하여 벗어나는 것을 연습 해야 한다.

내가 항상 쓰던 오른손으로 공을 들었을 때, 나의 왼편 시야는 마비 된다. 이를 미식 축구에서 Blind Side라고 한다.

결국, 항상 하던 방식을 고집 하는 것은 팀 내의 한 부분을 보지 못하게 할 수 있으므로, 그러한 권한을 지녔다면 조심스레 인지 하는 시간을 주기적으로 가져야 하지 않을까..

“급할 수록 돌아가라”는 말이 있듯 모든 일은 순서가 있다는 것을 기억 해야 한다.

개발자는 어떤 문화가 좋을까?

일단 내 생각에는 성장 할 수 있는 어떤 매개체들이 많아야 하는데, 각 경험치가 비슷한 사람들이 팀 내에 2-3명씩은 포진해 있어야 좋다고 생각 한다.

일단은 무엇을 하든지 열려있어야 하는 부분이 좋다고 생각 한다. 그것이 어떤 라이브러리의 도입이라던지? 툴의 도입이라던지를 떠나 모든 의견에 열려야 한다고 생각 한다.

하지만, 안정성도 고려 해야 할 포인트이고, 새로운 어떤 것을 도입 함에 있어서 모든 의사결정이 Bottom up approach 즉, 상향식으로 올라가야 하지 않을까?

결국에는 개발 조직은 어떤 유기적으로 스스로 잘 동작 해야 한다. 스스로 성장하고, 스스로 나아가는 어떤 시스템이 구축 되어야 한다고 생각 하는 편이다.

다른 개발자분의 블로그의 글을 보고 느끼는 바가 많고, 공감이 많이 생겼다.

개발자가 조직문화에 대해 관심을 가져야 하는 이유의 글을 읽고 나도 공감 많이 하게 되었다.

개발자는 왜 개발 문화를 만들어 가는데 관심이 없는가? 결국에는 내가 속한 팀에서 어떤 행복도가 소프트웨어 품질에도 영향을 미치고, 일정이나 다른 모든 것들에 영향을 끼친다고 생각 하는 편이다.

그래서 나는 해피아워를 참 좋게 생각하고, 중요하다고 생각 한다.

내가 생각하는 조직 문화는 어떤 모습이어야 하는걸까? 하는 고민을 항상 하곤 한다.

어떤 사람들은 그냥 개발만 하면 되지 무엇이 필요하느냐? 라는 말을 하곤 한다.

그리고, 생각해볼 문제로는 다음과 같은데, 어떤 물질적인 것들이 있어야 개발자 문화가 좋은 것인가? 아니면 비물질적인 것들이 있어야 문화가 좋은 회사이고 팀인 것인지 모호할 때가 많다.

일례로 개발 장비에 대해 금액 없이 지원 하는 경우라면, 개발자에게 마냥 좋은 조건인가? 사실, 이 부분은 기본적인 업무 환경에 해당 한다고 생각 하는 부분이다. (~~하지만, 많은 회사가 잘 모른다.~~)

일단 개발자가 속한 곳의 문화가 좋아지려면, 다양한 사고를 가진 개발자들이 많아야 하고, 그들이 어떠한 말이든지 논할 수 있는 환경적인 요소가 준비 되어야 한다.

어떤 주제에 대해 긍정/부정의 의견이 서로 오고 가야하고, 우리는 생각보다 결정하는 방식에 대해 서투르다고 생각 한다.

긍/부정의 모든 의견이 다 중요한데, 왜 안좋은 말만 하느냐?며 치부해버린다면, 부정 의견을 낸 이는 아마 앞으로 의견을 내지 않을 것이다.

여러 가지 생각을 가진 개발자들이 모인 집단에서 의견이 없거나, 부정의 의견이 없다는 것은 그 대부분의 사람들이 보통 소수의 리드하는 사람의 의견을 따라간다는 말이다.

한 번 생각 해보자.

나는 일 하면서 어떤 의견을 주로 내는지? 그리고 그 의견들은 팀원들이 어떻게 생각하고, 받아들이는지? 그리고 조직내에서 누가 주로 의사결정을 결정 하는지?

가끔 팀원 모두 다 같이 생각해볼법한 문제라고 생각 한다.

우리는 지금 올바른 방향으로 잘 가고 있는지?
계획했던 일들은 잘 지켜지고 있는지?
부담스러운 일을 어느 한 사람만 하고 있지는 않은지?
일정이 너무 빡빡한 것은 아닌가?
등등..

위와 같은 일들이 대해서 일주일이나 주기적으로 생각해보는 시간을 갖으면 좋겠다. (지속 가능한 행복 지수 체크라고 해야 할까?)

그리고, 정량적으로 판단 할 수 있도록 체크를 하는 것은 어떨까? (너무 귀찮은 일일까?)

내가 좋아하는 책 중에 한 권인데, 프로그래머로 산다는 것이란 책이고, Deview 2013에서 발표도 하셨다.

이 책들은 주니어 개발자들만 읽는 것보다는 팀 내에서 꾸준히 한 해마다 읽는 것도 좋지 않을까? 생각 하곤 한다.

이러한 사색 같은 정답 없는 이야기들도 잘 나눌 수 있어야 하는 문화가 준비 되어 있다면 좋겠다.

내가 나아가야 할 방향

나는 아무래도 리누스 토발즈가 되긴 글렀고, 나는 개발자인척 하는 직장인이 되기 싫다.

그래서 내가 할 수 있는 만큼의 한 걸음씩을 가고 싶다. 내가 어떤 언어로 개발을 하던지, 내가 하고 싶은 일들이나 해야 하는 일들은 잘 소화해내는 그런 팀원이자 개발자이고 싶다.

나는 다른 이가 저 친구는 개발 참 잘해! 라는 말보다, "저 친구랑 일하면, 뭘 하든 재밌고, 같이 또 하고 싶어!"라고 말 할 수 있는 사람이고 싶다.

요즘은 그런 재미난 일들을 찾기 위해 아이디어를 정리하고 있다.

이 글을 쓰는 도중 재미난 사이드 프로젝트가 생각 났다. 잘 구상을 해보고, 시도를 해보면 재밌을 것 같다는 생각을 했다.

이 긴 글을 읽으신다면, 저와 비슷한 생각을 하지 않았을까? 하는 마음이 무럭 무럭 자라납니다. 재미난 일이나 궁금한 이야기 어떠한 이야기도 좋습니다. 저와 소통을 해주시면 좋겠습니다.

그냥 저냥 #위클리뉴스 #53

Sat, 14 Sep 2019 22:50:00 GMT

개발자들에게 도움이 되는

커밋 히스토리를 이쁘게 단장하자

브랜치 전략은 정말 어려운 점은 팀 간 그리고 조직 간의 합의가 잘 되어야 한다. 물론, 조직 전체가 같은 Repository를 사용한다면, 강력한 Rule을 적용 해야 한다. (사람이 많을 수록 더 조심해야 한다.) 팀의 경우에도 알맞는 브랜치 전략을 사용하는 것이 좋고, 그런데 결국 그나마 보편적인 전략은 git flow라고 생각 한다. 그리고, Commit History를 어떻게 관리 할지?의 Rule도 잘 정의를 해 두어야 꼬이거나 복잡하게 히스토리가 유지 되지 않는다.

git이 저장하는 방식

push 할 때 나오는 delta와 snapshot의 구조를 사실 잘 몰랐는데, 해당 설명이 잘 되어 있는 글이다.

협업이 힘들었던 개발자의 특성

협업하기 힘든 개발자의 특성을 나열 했는데, 무접점 개발자, 자신의 코드를 사랑하는 개발자, 주방장 개발자, 공유하지 않는 개발자 등으로 사실 어떤 특성을 가진 건지 읽어 보면, 충분히 이해 할 수 있는 특성이다. 읽어 보고, 자신은 어떤 특성을 조금이라도 가진 것인지 생각해보면 좋겠다. (~~물론, 나도 문제가 많다..~~)

CloudWatch 이상 동작 탐지 기능 사용하기 #1

CloudWatch의 이상 동작 탐지 기능을 활용하여, Slow log를 수집하여 패턴 변화등을 감지하고 해당 이상 패턴을 시각화 한다.

MSA에서 메시징 트랜잭션 처리하기 | Popit

사실, MSA, Event Sourcing들이 요즘의 트렌드가 아닐까 싶을 정도로 이야기가 많이 나오고 있다. DDD는 이미 거의 표준처럼 이야기를 하고 있다. 그 안에서 어떻게 하면, Message Transaction을 처리 할까?에 대한 해결책이 이 글이 아닐까 생각 한다. 그렇지만, 기존 방식에 익숙하신 분들은 사실 생소하기 짝이 없으리라 생각 한다.

검색엔진과 DB Like 검색의 결과가 다른 이유

애초에 접근 방식 자체가 다르다고 이해해야 하지 않을까? 생각한다. 사실 ES를 잘 쓰기는 무척 어렵다고 생각 하는데, 이미 ES가 표준으로 자리 잡는 수준까지 와 있다고 생각 하는데, 검색 엔진과 DB의 like 검색의 차이를 설명하는 짧은 자료이다. 하지만, ES를 써보지 않았다면, 이해 하기는 어렵다.

if kakao 개발자 컨퍼런스 2019

if kakao의 컨퍼런스 영상과 발표 자료가 모두 올라 왔다. 그래서 만약 직접 가서 듣지 못하신 분들은 해당 영상과 자료를 통해 학습하시면 도움이 됩니다.

기술 뉴스 #133 : 19-09-02 :: Outsider’s Dev Story

GraphQL에 관한 글이 인상적인데, front-end의 상태 관리의 역할까지 해내는 기능에 대한 설명을 하는 글이 좋았다. 물론 수 많은 다른 좋은 글들이 있다. (추천)

내 맘대로 위클리 뉴스 - 2019년 37주(2019.9.01 - 2019.9.07)

Spring framework에서 정말 많이 사용하는 테스트 라이브러리인 junit5를 이용해 Spring MVC controller 테스트 방법에 관한 글을 추천 해주셨는데, 나도 꼼꼼하게 다시 읽어 봐야겠다고 생각했다. (추천)

2019년 상반기 회고 (3월~8월)

zxzl님의 상반기 회고록인데, 실제 업무를 어떤 것을 하면서 겪은 일화와 어떤 일들을 했는지 알 수 있다.

[B급 프로그래머] 9월 2주 소식(빅데이터/인공지능, 암호화폐/블록체인, 읽을거리 부문)

JavaScript

Typescript를 이용한 NodeJS 개발기01

TypeScript로 서버 개발을 하기 위한 소개를 하는 시리즈의 첫 글입니다. 왜 시도 하는가? 그리고 어떤 것들이 필요한지를 설명합니다.

Network

네트워크 모니터링이 궁금할땐 ? Packetbeat !

자신이 운영하는 서비스의 outbound를 확인 하여, 어떤 작업이 제일 느린지? 찾는 것을 분석하기 위해 고군분투한 글이다. (ElasticSearch, Kibana, filebeats를 활용 하셨다.) 꾸준하게 토이 프로젝트를 위해 노력 하시는 모습이 보기 좋았다.

ElasticSearch

Elasticsearch 버전 업데이트 썰 (Nori 형태소 분석기 shallow dive)

ElasticSearch 버전 업데이트를 하면서 겪은 경험기 공유이다. 사실 생각보다 많은 이슈가 생기곤 한다. 버전 업데이트가 빠른 대신 버그가 많다. (Major 버전은 그래서 한 두달 건너 뛰고 사용해야 하지 않을까? 생각 해보기도 합니다.)

Container

Kubernetes 로 내부 시스템 이전하며 겪은 일들 - 임찬식

k8s 클러스터를 구축 한 사례와 해당 구축을 통해 내부 시스템을 이전한 경험기이다. 보면서 느낀 점은 와 우리 사내 시스템과도 매우 유사한 점이 있다고 느꼈습니다. (다들 비슷하게 구축을 하는 것인지…)

Java

biggwang의 개발 블로그

Spring을 학습하면서 궁금한 IoC, DI에 대한 부분을 스스로 이해하고, 설명하고자 쓴 글입니다.

Java 버전별 변경점

Java의 버전별 변경을 정리하는 Section인데, 현재 진행형이다.

Spring WebFlux와 Kotlin으로 만드는 Todo 서비스 - 1편 | Popit

Spring WebFlux와 Kotlin으로 만드는 Todo 서비스 - 2편 | Popit

요즘 WebFlux와 kotlin에 관심이 많아져서 보고 있던 차에, 샘플 예제를 만들어 볼 수 있는 글을 찾았다.

Folding Things With Functional Programming - DZone Java

Fold Function에 대한 글인데, FP와 연관 되어 있다. 그런데, Reduce와 Fold와의 차이를 설명한 부분이 제일 인상적이다.

Java Joy: Combining Predicates - DZone Java

filter를 쓰다보면, predicate를 조합해서 사용 하고 싶을 때가 있을때, 활용하면 좋을 예제이다.

Java GC 튜닝

Java GC 튜닝의 글인데, 대부분 영어이긴 하지만, 시간이 지나면 종립님이 요약을 해주실 것만 같다.

JDK 8에서 Perm 영역은 왜 삭제됐을까

사실 내가 가장 궁금했던 부분인데, 잘 정리 해주셔서 나도 궁금증이 풀리게 되었다. 중요한 부분은 어떻게 이런 발상을 했는지가 제일 신기한 부분이고, 이렇게 Perm영역을 제거 했을 때의 이슈나 장단점이 궁금 해졌다. 찾아 봐야겠다.

일반적인

1990년대생의 퇴사를 막고 싶다면

90년생이 온다 라는 책이 있듯이 그에 대한 이야기를 말하는데, 결국은 교육적인 부분이 회사에서는 항상 걸림돌이 된다. 새로운 사람에 대한 교육이 제일 해결이 되지 않는 부분 같다. 그리고 메뉴얼의 부재가 제일 크지 않을까 싶다. 메뉴얼을 정확하게 작성하지 않는 부분도 있을 테고, 사실 이미 업무에 능숙한 사람이 메뉴얼을 작성하다 보면, 대다수의 내용이 빠지기 마련이다. 그렇기 때문에 중요한 부분이 누락 된 메뉴얼이 많다. 이러한 고민을 하는 회사, 조직 일수록 좋은 회사 아닐까? 생각 한다. 1990년생은 능력 향상을 위해서라면, 모든 것을 다시 시작 할 수 있는 용기를 가졌기 때문이다. 당신은 이를 요즘것들의 “끈기 부족”이라고 얕잡아 보지만, 우리가 봤을 땐 자신의 시간을 미래를 위해 현명하게 투자할 줄 아는 합리적인 선택일 뿐이다.의 구절이 참 좋았다.

그냥 저냥 #위클리뉴스 #52

Mon, 09 Sep 2019 20:42:00 GMT

개발자에게 도움이 되는

curioe

내가 진짜 대단하다 생각하시는 분 중에 한 분이신데, 여자들의 멤버십 커뮤니티 헤이조이스 개발자 모임에 대담자로 참석하신 경험기를 남겨주셨다. 워낙 유명하시고, 이 분의 커리어 패스는 나에게는 신선했지만, 재미나게 일 하시는 분으로 (나혼자) 생각 한다.

Google Engineering Practices Documentation

Review · Soojin Ro

구글 코드 리뷰에 대한 가이드 글인데, 해당 글을 요약 번역 해주신 분이 있다. 코드 리뷰 관련해서는 읽어 보면 내가 실제로 얻는 부분이 많다.

멍개님의 블로그 : 네이버 블로그

Github actions에 관해서 차례 차례 설명을 해주신 글이다. 앞으로 github가 어떤 툴로 발전 할지 기대가 되는 기능 중에 하나이고, Registry 또한 신선했는데, actions는 진짜 힙한 느낌이다.

JavaScript

[2019 IBM Developer Day] 미우나 고우나 내새끼: Reusable Custom Component 만들기 A to Z (by 진유림)

[js] await 뒤에 동기함수가 오면?

await 뒤에 동기 함수가 오고, 해당 함수가 promise를 리턴 할지? 일반적인 값을 리턴 할지? 그런 상황이 있을까? 싶지만 생각보다 많이 겪는다. await이 뒤에 있는 함수를 Promise.resolve로 감싸는 지는 확인을 해 봐야겠다.

Babel, Mocha, Karma and Webpack with coverage in order

JavaScript에 관한 보일러 플레이트를 구축하는데 이렇게 세세하게 남겨준 자료는 많이 보지 못했는데, 각 기능에 맞는 툴들에 대한 부분을 정말 자세하게 잘 설명 해주셨다.

ElasticSearch

https://www.notion.so/Elasticsearch-ES-383e17bf4cf1408cb1dcf78aae1fcff6

ES cluster 구축을 하기 위한 카카오의 노력을 엿볼 수 있다. 실제 발표 자료를 볼 수 있으면 좋겠다 생각 했다.

그냥 저냥 #위클리뉴스 #51

Sat, 31 Aug 2019 15:18:00 GMT

개발자들에게 도움이 되는

온라인 코딩 테스트 준비하기

결국에는 이직을 하려고 한다거나 하면 준비 해야 하는 과정이 경력자에게도 온라인 코딩 테스트는 중요하다. 내가 속한 회사도 경력직 채용에 코딩 테스트를 실시하고 있고, 우연히 며칠 전 문제들을 봤지만, 쉽진 않았다. 그리고 요즘은 대다수가 코딩 테스트 서비스를 제휴 맺어서 사용하기에, 공간 복잡도, 시간 복잡도, 실제 외부 사이트들과 답안의 유사도도 분석한다고 봤다. 결국… 연습만이 살 길이고, 영어 해독 시간도 중요한 이슈가 된다. (부지런한 개발자라면, 이렇게 영어 공부 하고, 알고리즘 잘 풀고 하다 보면 외국 회사 가지 않을까?)

사람들이 잘 안알려주는 GitHub 팁

suggestion의 기능은 몰랐던 건데 알게 되어 좋았다. 기타 다른 팁들도 있으니 보면 좋겠다.

개발자가 공부로 살아남는 방법

개발자가 공부를 왜 해야 하는지?에 대해 시작하여, 어떻게 학습을 하고, 진행 했는지에 대한 부분을 자세하게 남겨 주셨는데, 공감이 많이 가는 부분은 무엇을 만들지 먼저 생각 해보자 라는 부분인데, 사실 뭘 새로 배우던지 언어의 문법이나 라이브러리 이런 걸 공부 하려면, 실제로 써 봐야 알 수 있는 내용들이라고 생각 한다. 결국은 무엇인가 만들어 봐야 한다. 그래서 작은 프로그램이라도 만들어 봐야 한다.

Git 사용 중 자주 만나는 이슈 정리

git을 혼자만 쓰다 보면, 이슈가 생길 일이 사실 크지 않는데, 사람들과 같이 쓰다 보면 이슈가 생긴다. 그래서 생각 보다 쉽지 않다. (잘 쓰는 것은 역시 뭐든 어렵다.) 그렇게 Git 사용 중 만난 이슈를 느낀 바를 정리 한 글이다.

내 맘대로 위클리 뉴스 - 2019년 35주(2019.8.18 - 2019.8.24)

JavaScript와 Node.js에서 활용 할 수 있는 테스트 기법에 관한 글이 나에게는 현재 상황상 가장 유익 했다. 그 외 파이썬 관련 글 타래도 좋은데, 내가 요즘은 파이썬을 전혀 안 쓰고 있어서 관심도가 떨어졌다.

진유림 - 패스트캠퍼스 인터뷰

진유림님의 인터뷰 영상이며, 이미 이쪽 업계에선 핵인싸시다. 해당 영상에서 가장 좋은 말은 처음 하면 모른다. 그게 당연하고, 하다 보면 알게 된다는 말이 공감이 많이 되었다.

인생의 방향

개발자의 고뇌가 담긴 글이다. 뭐랄까…? 구독 하고 있는데, 이런 글이 올라와 궁금해서 다 읽게 되었는데, 결국 우리는 사람이고 다 같은 고민을 하고 사는 구나 싶었다. 내가 생각 하는 방향성이란 결국에는 나만이 알고 있다. 대신 많은 사람들과 이야기를 해봄으로써 그 방향을 알게 된다. 그런 점에서 이런 고뇌 글도 좋다고 생각 한다. (아마 나뿐만 아니라 다들 느끼지 않을까? 생각한다.)

개발자의 공부하기

공부법에 관한 방법인데, Bside Soft의 Hika님이 강의 전에 해주신 말에 대한 이야기이다. 영상을 보기 어렵다면, 해당 글을 읽고 참고 해도 좋을 것 같고, 정말 많은 내용에 공감이 된다.

개발자가 조직문화에 대해 관심을 가져야 하는 이유

개발자가 조직문화에 대해 관심을 가져야 하는 이유에 대한 글인데, 내가 요즘 브런치에 쓰고 싶은 글이 이런 류의 글이다. 다시 한 번 예전에 읽었던 책을 다시 읽으면서 정리를 해봐야겠다고 생각 하는 요즘이다. 개발자가 조직 문화에 너무 관심이 없어도 문제가 된다. 왜냐하면, 조직 문화는 나와 나의 동료가 같이 만들어 가는 것이다. 그런데, 왜 혼자만 관심 없다고 노력 하지 않는가? 그건 협업에도 도움이 되지 않는 자세이다. 조직 문화를 만들어 가는 것도 하나의 노력이고, 하나의 업무이다. 꼭 읽어 보면 좋겠다.

Data

[입 개발] Redis 버그 - Dataset 사이즈가 200GB가 넘어가면 죽는다구요?

Redis의 버그에 관한 글인데, Dataset 사이즈가 200GB가 넘으면 Redis process가 죽는 이슈인데, 이에 대한 이슈의 원인과 해결 책에 대한 부분을 상세하게 정리 해주셨다.

Java

Composite Design Pattern In Java

요즘은 Java를 안 쓰다보니 보게 된 Composite Pattern인데, 사실 내가 이제까지 잘 써온걸까? 라는 생각이 들기도 하다. 이 글을 읽으면서 사색에 빠지게 되었는데, 요즘은 Java를 잘 쓰고 싶은 마음이 있는데, 쉽지 않은 것 같다. 아무래도 Java와 Object 공부를 해야겠다는 생각이 들었다. (이 글과는 관련 없지만, Hika님의 오브젝트 스터디 영상을 보면서 요즘 무릎을 탁 친다..)

Front-End

3 Essential Tools to Boost your React App’s SEO

SEO를 돕는 세 가지 (React-Router, React-Helmet, Google Search Console) 해결법이라고 소개 하고 있다. 중요한건 나도, React-Helmet은 잘 모르는데, 확인 해봐야겠다.

CSS in JS in real-life

요즘 드는 생각은 React를 작업하다 보니 내가 결국 마크업을 해야 비로소 완성 되는 느낌이 있다. (내가 마크업을 실무에서 하지 않으니 무언가 절반만 하는 듯한 느낌을 지울 수 없다.) 이런 류의 글을 읽다 보면 도대체 무엇이 정답인지는 상황 마다 다른 것 아닌가? 라는 생각이 든다. 그렇지만 최고는 JSS라는 것이다. 아직까지는 크게 와 닿지는 않고 있다.

How to automate versioning and publication of an npm package

나도 이런 고민을 잠시 했었는데, 이렇게 자동화 하는 방법은 정말 좋다는 생각이 들었다. 물론, 오픈 소스로 공개 하거나 할 일이 없는 회사 프로젝트라 이런 고민을 길게 하지 않았다. 그래서 고민을 하지 않았는데, 위 글을 사내 개발자분이 공유 해주셔서 읽게 되었다. 결국, 공개를 하지 않더라도 버저닝을 남기는 습관을 가지는 것이 좋지 않을까? 생각이 들었다. 물론, 수동으로 해도 된다. 그렇지만, 자동화가 뭐든 구색도 좋고 편리 하니까… (혹시 오픈 소스로 공개 할 수도 있으니까?)

우아한 형제들 세미나 - 우아한 멀티모듈

Thu, 29 Aug 2019 19:35:00 GMT

발표자료: https://www.slideshare.net/ssuser59a869/ss-167401606

회원 시스템

단일 모듈, 멀티 프로젝트

사람에게 의존적인 일관성으로 구성 되어 있었고, 세 프로젝트는 공유 되는 클래스들이 있었음. 내부 Nexus를 이용하고 있었고, 해당 세 프로젝트는 Nexus에서 일관성을 가지게 된다. 이렇게 구성 하는 것이 너무 복잡하고 개발 사이클이 복잡 하다.

내가 속한 환경에서도 생각해보면, 모듈 단위로 이미 구분이 잘 되어 있다. 만약 프로젝트 기준으로 나뉘게 되면, 너무 큰 범주로 작업 간 이동이 발생 하게 된다.

그런 환경은 내가 생각해도 개발 하기 쉽지 않다.

멀티 모듈, 단일 프로젝트

시스템으로 보장 되는 일관성을 얻고, 개발 사이클이 단순화 된다.

내가 속한 조직에서도 모듈 단위의 Role을 정의 해놓고, 그 규칙을 성립 해두었다. 그렇게함으로써 좋은 장점은 규칙을 위배 하지 않는 선에서 굉장히 깔끔한 구조를 가진다. 그리고, 양방향 의존성이 생기지 않도록 규칙을 가지고 있는데, 이 부분은 시간이 지날 수록 설계한 분의 엄청난 내공이 느껴진다.

MSA? 멀티 모듈?

멀티 모듈은 MSA와 비슷한 부분이 있더라.

설명을 들어보니, 결국에는 서비스의 구조를 단순화하고, 해당 구조를 조립하는 형태로 구성 하는 방식이 결국에는 유사한 모습을 띄게 된다고 생각이 들었다.

실패한 프로젝트

스파게티 코드

common에 문제가 생기면 각 도메인의 서비스에 문제가 생기게 된다.

의존성 덩어리

특정 의존성이 숨겨진 의존서을 가지고 올라 가는 경우가 많다.

공통 설절

공통 설정은 잘 구분해서 가져가는 것이 좋다. 그렇지 않으면, 해당 설정에 영향이 적은 서비스도 영향을 크게 받는다.

모듈화란?

내가 역할을 부여 하고 해당 역할만 지닌 모듈을 끼워 맞출 수 있다면, 그게 모듈화가 아닐까? 객체 지향 중심으로 모듈을 분리 한다. 그럼 결국 역할과 책임으로 구분 지을 수 있게 된다. 모호한 부분은 어떻게 나눌까에 대한 부분이 남았다. 그래서 오픈 소스의 라이브러리를 주로 염탐을 했다. 계층 하위로 역할과 책임을 주로 구분 지어 나누고, 계층과 계층끼리 이어질 수 있다. 다만, 라이브러리와 서비스의 경우는 기준이 다르다. 그래서 결국, 직접 나누는 것으로 결정 했다.

멀티 모듈

시스템: 하나의 서비스와 공유 인프라가 만나 하나의 시스템을 구성 하는 단위가 된다.
어플리케이션 비즈니스: 요청, 응답등..
도메인 비즈니스: 주문 데이터 생성, 가공, 처리

내부 모듈 계층

외부 통신을 담당 하는 모듈을 만들자.
- 요청, 응답 스펙 관리
- 예외 처리 추상화 수준 통일
- 환경별 시스템 Host, Header관리

위에서는 사실 가장 주요한 부분은 예외처리를 어떻게 추상화 할지?에 대한 부분이 중요하게 생각 하셨다고 한다.

좋은 점은 스펙 변경에 대해 변경 포인트가 단일점으로 바뀌게 된다. 사용 추적에 대한 부분도 쉬워졌다.

도메인 모듈 계층

infrastructure 대응을 위한 모듈
- DB관련, QueryDSL, connector관련 의존성을 가지고 있다.
multi domain
multi infrastructure
- redis / DynamoDB가 둘 다 필요할 수도 있지만, 하나만 필요할 수도 있다.

독립 모듈 계층

시스템의 의존성이 없다.
오로지 필요한 외부 의존성만 있음.

공통 모듈

Type, Util등을 정의 한다.
가장 큰 제약을 두었는데, 순수 Java 클래스만 작성 하도록 제한을 둠.

어플리케이션 모듈 계층

top-down 방식으로 구성을 하게 된다.

꿀팁

Application.java는 Project package에서 1 depth로 유지 하여, Scan 기능을 활용.
의존성을 숨기는 방법은 gradle에서 compile에서 implimentation으로 변경하면 된다.
- 보호 하거나 숨겨야 할 모듈을 위의 방법으로 제약을 주면, 코드상에서 참조가 되지 않는다.

그냥 저냥 #위클리뉴스 #50

Sat, 24 Aug 2019 15:59:00 GMT

개발자들에게 도움이 되는

Pycon kr 2019 keynote

네이버 파파고 TL이시면서 KoNLPy를 만들어 오픈소스로 공유하신 분이시다. 팀포퐁으로 활약하시던 시절부터 블로그를 통해 접하면서 많은 지식을 간접적으로 얻게 되었다. 이번 PyCon 2019 Day1의 키노트 연사로 발표를 진행하신 내용인데, 읽어보면 좋은 내용이 참 많다. 특히 가장 인상 깊은 단어는 아이디어는 working prototype으로 보여주세요. 라는 말인데, 참 많은 생각을 하게 되었다.

주니어, 미드레벨과 시니어 개발자의 차이점

주니어 개발자와 미드 레벨 그리고 시니어 개발자 사이의 갭 차이를 설명하는데 일반적인 수준에서 정확하게 표현하고 있다고 생각 한다. 분명한 것은 사실, 이렇게 구분 짓지 않아도 된다는 생각을 가끔 하게 된다. 주니어든 미드레벨이든, 시니어든 같이 협업을 통해 시너지를 극대화 하는 방법이 중요하다. 얼만큼 융합을 잘 하는지가 제일 중요하다.

오픈소스 세계에 기여하는 개발자가 되어보자

어떻게 오픈 소스 세계에 기여 할 수 있을까? 를 고민 하는 사람이 있다면, 읽어 보길 추천한다.

클린 아키텍처 번역을 마치며… | Popit

요즘 오브젝트 이후로 핫한 책이 클린 아키텍처라는 책인데, 굉장한 내용이 담겨져 있다고 한다. 물론, 원서를 읽으면 저자의 어조와 느낌을 바로 이해할 수 있지만, 원서는 이해하기 쉽지 않다. 그래서 번역서를 보게 되는데, 번역이 잘 된 책이라고 많이 언급하셔서 리딩 리스트에 추가 했다.

PyCon 2019 스프린트 후기 :: Outsider’s Dev Story

사실 스프린트란 느낌을 잘 몰랐는데, 명확하게 알게 된 계기의 글이다. outsider님은 mocha의 메인테이너로 스프린트에 참여 하시면서 느낀 부분을 후기로써 남겨 주셨다. 읽으면서 신기한 부분은 “메인테이너더라도 모든 것을 알 수 없다.” 부분이었다. 생각해보니 아무리 오픈소스 메인테이너로 승격 된다 하더라도 자신이 만든 것이 아니고 다 같이 만든 부분이니 알 수 없겠구나..라는 생각을 했다. 결국 꾸준함이 오픈소스 기여를 만들어 내는 것이 아닐까? 라는 생각을 했다.

인턴이 되어 돌아오다

구직 중이란 글을 올리시고, 제안을 받으신 뒤의 이야기인데, 인턴이 되셨다고 한다. - 축하 드립니다 :) 이 글을 읽으면서 나도 벌써 만 3년차 개발자가 되었다. 도대체 어떻게 하면 지속적인 학습 루틴, 나의 근본적인 니즈가 무엇일까?를 고민하는데, 비슷한 고민을 하는 구나. 생각이 들어 오랜만에 나의 인턴 시절을 되돌아 보게 되었다.

Clean Coder Blog

제목만 보고 사실 나중에 읽어 봐야지 하고 가져 왔다. 왜 클로저인가? 라는 제목이라 무슨 내용 일지 궁금하다.

야놀자를 떠나며… (feat. 레저큐)

개발자의 이직기인데, 굉장히 여러 회사에 지원하고, 절차 과정과 어디까지 합격을 했는지? 그리고 자신만의 강점이 무엇인지? 회고하는 부분이 참 좋았다.

[B급 프로그래머] 8월 3주 소식(개발/관리도구, 고성능 서버/데이터베이스 부문)

개발/관리 도구 및 서버/DB 관련 주제별로 나뉘어 있는데, Tech Interview Handbook 링크가 굉장히 알차다. (알려 주셔서 감사합니다.)

Python

추천시스템 이제는 돈이 되어야 한다.

카카오 웹툰에서 일 하는 분들이 어떻게 하면 추천 시스템을 이용해 개인에게 꼭 맞는 웹툰을 추천하고, 사람들이 좋아 할 만한 (유료)웹툰을 어떻게 추천하는지?에 대해 고민한 부분이 많이 녹아 있다.

Why is Python 3.7 fastest

왜 파이썬 3.7은 더 빨라졌는지?에 대한 발표인데, 잘 모르는 부분을 알고 싶어서 강제적으로 발표자로 나선 부분이 흥미롭기도 하고, (용기가 부럽다.) 중요한건, C로 다시 짜면 빨라지는 부분이 참 재밌기도 하다. 역시 성능은 C레벨인가? 싶기도 하다. 그렇지만 보면서 잘 모르는 내용이지만 재미 있었다. 특히나, 파이썬이 커뮤니티로 성장하는 모습이 재밌다고 생각 했다.

Web

Fast load times | web.dev

web.dev에는 참 좋은 내용이 많은데, 이번에는 사용자가 이탈 하지 않도록 당신의 사이트를 빠르게 로드 될 수 있는 방법들을 소개하고 있다. 각 목차별로 중요하고, 내용도 짧막하게 정리가 잘 되어 있다. 틈틈히 읽어보면 훗날 성능 최적화나, 로드 타임 최적화에 도움이 되지 않을까?

웹 프레임워크 Svelte를 소개합니다.

Preact와 Svelte는 Google I/O에서 웹 성능 관련 세션에서 처음 들었는데, 그 중 Svelte의 튜토리얼인데, 요즘 핫한 Virtual DOM을 사용하지 않고, 컴파일 타임에 최적의 성능을 내는 코드로 컴파일 해준다고 한다. 그런데, 의문은 컴파일러가 정말 성능이 좋아야 Virtual DOM을 능가하는 최적화 코드를 만들어 주지 않을까? 생각하게 되었다. 아마, 최근의 컴파일러의 성능이나 효율성 같은 최적화 부분에서 컴파일러 성능은 워낙 좋으니 사용하는게 큰 문제가 되지 않을 것 같기도 하다…(물론, 생각만 해보았다.)

JavaScript

goldbergyoni/nodebestpractices

Node.js에 관한 글인데, 참 좋은 내용이 많은데 사실 나는 내가 작성 하는 코드가 잘 작성하는 것인지? 애매할 때가 있다. 사실, 그럴때는 이런 글을 보면 도움이 된다.

goldbergyoni/javascript-testing-best-practices

JavaScript의 Test에 관한 best practice 방법을 소개 하는데, 내용이 상당하기 때문에 필요한 부분의 코드만 보거나, 코드만 쓱 보고 어떤 내용인지만 알고 지나가도 좋다.

Typescript가 두려운 당신에게

사실 TypeScript는 타입 형 지원만 생각해도 JavaScript 개발에 있어서 생산성 향상을 준다. 이는 틀림 없는데, 깊은 문법을 사용하다 보면 문제는 팀원 모두가 해당 문법을 다 익혀야 한다. 그렇지만, 차근 차근 하나씩 써가며 익히는 방법도 좋다고 생각 한다.

DB

LINE Manga 데이터베이스 샤딩 - 데이터베이스 엔지니어 편 - LINE ENGINEERING

MySQL을 사용하면서 데이터베이스에 샤딩이 필요한 시점에 대한 부분이 담겨져 있다. 어떻게 운영을 하면서 샤딩을 하는지? 어떤 방법이 있는지 체크하고, 진행 하는 모습이 정말 자세하게 써 있다.

Java

Spring 5.2 와 Spring boot 2.2 추가된 Test 기능들

요즘은 스프링 프레임 워크를 실무에서 그 전보다는 덜 쓰고 있어서 많이 까먹고, 5.x를 안쓰고 있지만, 그래도 무엇이 바뀌고 새로 추가 되었는지는 알아야 하기에 읽어 보게 되었다.

Git

Git 커맨드라인 환경에서 GUI 부럽지 않게 사용할 수 있는 몇가지 팁

CLI에서 GUI 못지 않게 사용할 수 있는 팁을 공유 해주셨는데, fzf | peco를 활용 하신 부분이 참신한데, 나는 왜 두 툴을 사용 중인데도 불구하고, 이런 생각을 못하는지 약간 좌절 하게 되었다. (애용해야겠다!!)

일반적인

똑똑하게 일하는 사람들의 5가지 특징

5가지를 가져야만 똑똑하게 일 하는 사람이 되는 것은 아니지만, 대부분 이런 점을 가지고 있더라…!라는 느낌으로 읽어 보면 좋다. 특히, "함께 일 하는 사람에 대한 신뢰"가 제일 중요하다고 생각 한다.

2019 상반기 회고

Wed, 21 Aug 2019 08:29:00 GMT

끊임 없는

2019년 1월은 정신없이 지나가게 되었다. 이유는 작년 10월부터 기존 작업 끝내고, 들어 가긴 했지만.. 아니다. 거의 11월 즈음부터 시작하게 된 신규 플랫폼 전환 프로젝트에 일부 담당 하게 되었고, 일부는 인프라 적용을 하게 되었다.

12월은 가히 최악이라고 기억한다.

생각보다 쉽지 않은 작업이었다. 개발 서버 환경부터, 운영 서버 환경까지 모든 것이 바뀌어야 하는 변경 작업이었다. 변경 작업이라는 것은 결국, 기존의 서버도 원활하게 동작해야 하지만, 신규 서버도 원활하게 동작해야 한다는 전제 조건이 달려 있었다.

거기에, 어쭙잖은 지식을 빠르게 학습한 것도 아닌, 머릿속에 꾸역꾸역 넣어 그럼에도 불구하고, 아름답게 리액트 컴포넌트를 만들어내려고 노력 했다. 두 가지 다른 업무를 같이 하려니 나는 솔직히 좀 힘들었다.

기존에 있는 것과 동일하게 만들어야 하고, 동작은 오히려 더 좋게 해야 했다.

새로운 지식이 더 많아졌다. 어떠한 전문성을 키울 것인가? 나는 서버 개발자인지? 프론트 개발자인지? 헷갈리기 시작한 부분도 신규 플랫폼 전환을 하면서 더욱 가속화 되었다.

레거시 운용과 신규 플랫폼의 운용은 생각보다 쉽지 않았다. 매일 매일 레거시를 걷어내려 해도,일정이 허락치 않아 쉽지 않고 우리는 서비스 개발이기에 새로운 기능을 추가하거나, 데이터 개편, 사용성 개편등을 통해 항상 과도기를 겪는다.

그렇게 팀사람들의 엄청난 시간 투자로 우여곡절 끝에 문제 없이 서비스 오픈을 할 수 있었다.

그리고, 오픈 이후 자잘한 버그를 수정 하느라 1월, 2월이 지나갔다.

또 다시

이번에는 주요 서비스 중 하나인 부분을 또 다시 개편하기 시작 했다. 그리고는 다른 업무인 k8s 적용도 같이 받았지만, 동시에 진행 하기는 어려워 보였다.

이 부분을 설득하기 위해 나름 말을 했으나, 영향력이란 것이 참 중요했다.

영화 ‘엑시트’에서 조정석이 “옥상으로 대피하라”는 말을 해도 TV를 확인 하는 가족과 같았다.

개편과 k8s 적용은 쉽지 않은 업무이다. 결국 나는 개편하는 것을 진행했고, 다른 업무는 팀 동료인 다른 분이 정말 깔끔하고 완벽하게 준비 해주셨다.

그 사이 내 첫 해외 여행인 미국을 가게 되었고, 미국 가는 내내 마음이 불편했다. 내가 개발 해야 하는 부분의 영역이 사이즈가 작지 않은데, 데이터는 준비가 되지 않았고, 나는 부랴부랴 다른 부분부터 개발을 해야 했다. 그리고는 돌아 왔을 때도 정상적인 데이터가 준비 되어 있지 않았다.

첫 해외 여행(미국)

미국에서 느끼는 바는 참으로 신기 했다. 첫 한주는 분리 수거를 안하는 모습에 “과연 여기가 선진국인가?” 싶었다가 “분리 수거”의 업무도 나름 누군가에게는 돈벌이의 수단으로 여겨진다면, 그것을 없애는 것 또한 문제다. 싶었다.

그리고, Daly city라는 역을 지날 때, 보이는 풍경은 최악이었다. 아파트가 많은 서울, 분당에도 저렇게까지 집 마다 간격이 좁지는 않았는데, 정말 엄청 나게 집이 붙어 있었다.

그리고, 생각보다 홈리스들이 많았고, 냄새가 심했다. 샌프란시스코의 시내는 정말 심했다. 특히, 몇몇 동네는 낮에도 우범지역이었고, 밤에는 시내 유명한 도로를 제외하고는 걸어 다니는게 위험해 보였다. (사실, 그래서 밤에 나가지 않았다.)

아쉽게도, 첫 한주는 그냥 무의미하게 보냈던 것 같다. 첫 해외 여행의 두려움 + 시차 적응의 실패였다. 그럼에도 나름 계획 했던 것들을 많이 했다.

피셔맨워프에서 자전거를 대여하고, 금문교부터 소살리토까지 자전거를 타고 갔다. 물론, 돌아올 때는 페리를 타고 되돌아 왔다.

자전거를 타고 가면서, 오후 2시였는데 어떤 사람들은 운동을 하고 있었다. 물론 회사를 다니는 사람 같은데, 도대체 어떻게 자유롭게 퇴근을 할 수 있는 건지 신기했다.

정말 아쉬운 점은 고프로가 있었으면 좋았을텐데, 하는 아쉬움이 컸다. 일단 영상으로 남기는 것은 중요하다는 생각을 했다. 사진으로만 찍기에는 너무 불편했다. 잠깐씩 자전거를 세워서 사진을 찍는건 정말 힘들다. 참고로, 금문교는 다리 길이만 2km정도이다. (수도 없이 자전거를 세웠다.)

가는 길은 정말 힘들었다. 하지만, 금문교를 지나고 소살리토로 가는 길은 내리막길이다. 소살리토는 조용한 부촌 마을이었고, 한 음식점에 가서 피자와 어떤 음식을 시켰는데, 피자는 한국 피자가 맛있었다.

유명한 아이스크림 가게에서 아이스크림을 하나 사먹고, 페리 시간을 확인 하고, 페리 선착장 근처 벤치에서 기다렸다. 그렇게 페리를 타고 돌아와서 자전거를 반납하고, 다시 숙소로 왔는데 거의 초죽음이었다. (강철 체력이 아니면 추천하지 않는다.)

정말 큰 돈을 들여 했었던, 요세미티 국립공원 투어는 정말 재밌고, 좋은 기억이 남는다. 겨울에 한 번 또 가고 싶다.

요세미티란 이름이 Mac을 생각 나게 했다.

더군다나, 엘 캐피탄을 직접 바라보니 장난 아닌 규모였고, 단일 화강암 중 세계 최대 크기라고 했다. 암벽등반 하는 사람들이 많았고, 맨손으로 오른 사람이 있었다고 하는데, 그 모습을 영화로 만들었다고 한다. (맨손이라니…) “프리솔로”라고 하는데 봐야지 했으나, 아직 보지는 못했다.

그리고, 라스베가스를 가게 되었는데, 캐리어에 보조 배터리를 넣고 수화물을 부쳤는데, 아무일도 일어나지 않았다. 혼자, 여기 저기 물어봤는데, 보통은 그냥 버린다고 한다. 나만 혼자 설레발 쳤었다.

라스베가스는 확실히 홈리스가 없었고, 동네는 깨끗한데, 샌프란시스코는 사실 여름이라지만, 그늘만 가도 춥고, 바람 불면 추웠다. 그에 반해 라스베가스는 뜨거웠다. 습도는 없지만 정말 사막이구나 싶었다.

그렇게 한인 게스트 하우스에 묵었는데, 노는 것을 좋아하는 사람들이 가서 묵으면 좋은 것 같다. 같이 구시내?! 같은 곳에 가서 맥주를 먹고, 나는 먼저 돌아와 잤다. (다음날 그랜드 4대 캐년 투어 예약)

새벽에 일어나 짐을 싸고, 리프트를 타고, 집합 장소로 갔다. 그리고, 사람들을 만났는데, 나만 혼자였고, 부부 아니면 친구들끼리 왔었다.

그래도, 그랜드 캐년 가는 길 내내 잠들지 않고, 깨어 있었고, 눈이 시원한 광경을 많이 봤다. 아마 살면서 그렇게 멀리 무언가를 쳐다본게 얼마만인지 모르겠더라. (가시거리가 70km 정도라고 한다.)

그랜드 캐년 투어를 하면서 진짜 멋있는건, 홀스슈밴드는 정말 장관이긴 했다. 드론이 있었다면, 드론으로 사진을 찍었을 텐데 아쉽긴 하다.

엔텔롭캐년은 원주민 지역이라 원주민이 직접 가이드를 해주고, 사진을 찍어준다. 물론 나중에 팁을 줘야 한다.

그랜드 캐년은 정말 넓고, 광활하게 수 천, 수 만년의 세월이 고스란히 녹아 있다. 보자마자 놀라움이 금치 못한다.

그리고, 색감이 정말 신비롭게 아름답다. 시간이 많다면, 6대 캐년 투어로 꼭 가보길 추천하는데, 미국 여행을 갈 때마다 가보고 싶다.

그리고, 한국으로 돌아오는 비행기에서 옆자리에서 만난 할아버지/할머니가 해주신 영어공부 방법에 대한 부분이 제일 인상 깊었다.

화장실을 지나가거나, 기내식을 받고 할 때, 영어로 물어보셔서 한국어를 못 쓰시는 줄 알았다. 얼떨결에 내리기 한 시간전, 얼떨결에 한국어로 물어봤는데, 한국어를 너무 잘하셔서 깜짝 놀랐다. 그렇게 시작된 이야기는 미세먼지 이야기부터 시작해 50년 전에 미국으로 건너가신 계기등 이야기를 듣다가 내가 질문을 하나 했다.

“영어 공부를 어떻게 해야 할까요?“

할아버지가 답하셨다.

“방법을 하나 알려줄게요. 비행기에서 내리면, 책방에 가서 중학교 1학년 영어 교과서를 하나 사세요. 그리고 그 책에 나오는 모든 문장을 외워요. 그리고, 다음 학년으로 올라가세요. 이 방법으로 1년만 하면, 영어로 말하는데 문제는 없을겁니다.”

하지만, 아직 그렇게 하진 않았고, 대신 내가 가지고 있는 영어 기본 회화책을 외우려고 한다. 다른 영어 공부 방법에도 책 한권을 외우는 방법을 소개 한다.

언어도 어느정도 암기가 기본 바탕이라고..

Google I/O 2019

생각 보다 행사가 조촐하게 진행 되는 느낌을 받았다. 물론, 정말 신기한건 CEO와 사진 찍는 박막례 할머니를 직접 봤다는 점이다. 그리고 또 중요한 점은 티켓이 120만원에 육박하는데, 선물이 하나도 없다는 사실이… 안타까웠다..

영상도 어차피 유투브로 생중계 되는데 굳이 와서 직접 봐야 하는 이유는 무엇일까? 단순히 세계에 퍼져있는 개발자들을 만날 수 있는 유일한 기회이기 때문일까?

생각보다 행사가 잘 진행 되는 점은 준비를 정말 잘 했다는 점이고, 나는 회사 사람들과 저녁을 먹거나 같이 다녔기에 그렇게 다른 외국인이랑 말할 기회가 없긴 했었다.

그렇지만, 몇몇의 외국인과 이야기를 했는데, 생각보다 버전업이나 그런것에 별 관심이 없고, 되게 작은 회사에서 일 하는 사람들이 많았다. (스타트업?)

그리고, 회사의 규모를 항상 궁금해 한다. 특히, 풀스택 개발을 한다고 하니까 기술 스택에 대해 굉장히 많이 궁금해 했다.

특히, 영어 실력이 급격하게 늘어난 것은 이 행사 때문인데, 행사 때문이라기 보다는 행사를 가기 위해 탔던, 우버/리프트 운전자와 이야기 하느라 영어실력이 정말 급격하게 늘 수 있었다.

생각보다 인내심 있게 내 이야기에 귀기울여 주고, 이해하려고 노력 하는 점이 멋있었다. 특히, 은퇴하고, 아르바이트로 일하는 할머니께서 좋은 이야기 많이 해주셨고, 구글에 입사를 하게 된다면, 자신을 초대해달라던 운전자도 기억에 남는다. (물론, 내가 구글에 입사할 일이 없겠지만, I wish if로 생각 하는 걸로..)

좋은 이야기를 많이 해주었다. 그래서 기억이 오래 도록 남는다.

후회스러운 점

아쉽게도 미국 여행에 준비를 너무 못했다. 사실 계획은 2달 전부터 영어를 좀 연마하고, 더듬 더듬 말하더라도 다른 사람들이랑 이야기를 하고 싶었는데, 야근으로 제대로 준비도 못하고, 부랴 부랴 짐 챙겨서 떠난 여행이 되었다.

시간 관리를 생각보다 많이 못했다. 위클리 뉴스는 그래도 신년 목표인 한 주에 하나씩은 올리려고 노력하고 있다.

다만, 그 외의 블로깅을 전혀 못하고 있다.

기술적인 블로깅을 좀 하고 싶었는데, 생각보다 시리즈로 연재하거나 특정 예시 코드를 보여주면서 글을 작성하기가 어려웠다. (업무 문서화만으로도 벅찬 느낌…)

그렇지만, 점점 기술 블로그로 변화 시키려는 노력을 하고 있다. 그리고 기술 관련, 포스팅을 할 때에는 정확하게 깊이감 있게 찾아보고 글을 써야겠다.

그렇지 않으면, 나중에 다른 블로거한테 털린다는 사실을 깨달았다. (경험담)

하고 싶은 일

제주도 여행
기술 관련 시리즈 연재
사이드 프로젝트 시작
기술 관련 발표
기술 서적 5권 읽기 / 일반 서적 10권 읽기
영어 공부

사실 하반기에 하고 싶은 일은 크게 6가지인데, 잘 할 수 있을지 모르겠다. 그래도 이 중에서 하나는 9월 정도에 완료 할 수 있다.

사이드 프로젝트가 제일 문제다. 매년 하자 하자 하는데, 도대체 뭘 하고 싶은지 생각이 나지 않는다. 다른 사람들은 아이디어를 어디서 얻는 걸까?

기술 서적은 참, 처음부터 끝까지 읽는게 쉽지 않다. 그렇지만, 하반기까지 5권은 꼭 읽고 싶다.

영어공부는 꾸준히 하는게 정말 어렵다. 꾸준히 하루에 한 강씩 들으면서 따라 해야하는데, 쉽지 않다. 회사 지원을 받아서 튜터링 결제를 해서 회화를 더 많이 할 수 있게 나를 노출 시키려고 생각 중이다. (야근을 하면, 모든 것이 쉽지 않다.)

가을 제주도는 항상 옳다. 그래서 가보고 싶고, 또 내가 못 가본 오름을 올라 가보고 싶다. (제주도의 오름은 350여개가 넘는다고 한다.)

기술 관련 연재 시리즈는 아무래도 Ansible을 하게 되지 않을까? 생각 한다. 물론 내가 잘하는 건 아니지만, 그래도 내가 경험한 삽질을 누군가는 할지 모르니, 꿀팁 공유 느낌으로 글을 써야겠다.

그냥 저냥 #위클리뉴스 #49

Sat, 17 Aug 2019 15:01:00 GMT

JavaScript

Nuxt에서 TypeScript로 개발하기

Nuxt에서 TypeScript를 이용해 개발 하는 것에 대한 소개이다. TypeScript는 사실 Angular 진영에서만 필수이다. React, Vue쪽에서 개발 하는 때에는 그냥 JS를 가지고 개발 해도 아무 상관 없다. 그렇지만, 생산성이 조금 다르다. 타입 제약이 생겨 초반에는 생산성이 저하 되는 느낌이지만, 실행 전에 에러를 잡을 수 있는 만큼 잡는 것은 전체 생산성을 높여 준다고 생각 한다…꼭 쓰는 게 좋다..(물론, 아직 완전 하진 않다.)

I wrote a customizable CSS engine in JavaScript

JavaScript를 이용해 CSS 엔진(CSS 파서라고 해야할지..)을 만든 글이다. 어떤 구조로 만들게 되었는지 설명 되어 있다. 여러 관점에서 생각하는 자세라고 해야 할까? 그런 점이 부러웠고, 중요한건 일단, 무엇인가 만든다는 점에서 박수를 치고 싶다.

로우 레벨로 살펴보는 Node.js 이벤트 루프

실제 이벤트 루프의 동작 원리에 대해 설명하는 글이다. 이 글은 번역글인데, 어떤 한국 개발자분이 직접 코드를 해석해서 설명 한 글도 찾아보면 나오는데, 두 글을 비교하면서 읽어보면 좋겠다. 사실 이해하기는 쉽지 않다. 얼핏 생각해보면, 이벤트 루프라는게 엄청나게 추상화가 잘 되어 있다는 사실 하나와 OS의 느낌을 받게 되는데, 기분탓인지 제대로 이해를 못한 탓인지 애매하다.

r/programming - Why is the result of (‘b’+‘a’+ + ‘a’ + ‘a’).toLowerCase() ‘banana’?

아주 재미난 글인데, 흥미롭게 읽어 보았다. 언어 특성을 이용한 유희?라고 생각하면 된다. (프로그래밍계 언어유희)

자동등록방지를 위해 보안절차를 거치고 있습니다.

huns님의 Express.js 서버는 왜 304를 반환 할까?에 대한 글인데, 일목요연하게 정리가 되어있고, Etag를 생성하지 않도록 하는 방법도 소개 하고 있다.

React

Create a Custom useModal() React Hook

React Hook을 쓰다 보면, 좋은 Hook 모음을 보고 싶을 때가 있는데, Modal에 관한 Hook이다. 직접 가져와서 사용해도 좋고, 자신만의 특수성을 추가해 변형해서 사용해도 좋을 것 같고, Custom hook만드는 데에도 실제 코드를 보다 보면 도움이 되지 않을까? 생각 했다.

How Does the Development Mode Work?

Development / Production Mode의 작동에 관한 고찰과 같은데, 아마 신선한 방법을 우리에게 또 전해주지 않을까? 다음 글이 기대가 되는 문제 제기에 대한 글이다. 읽다 보면, JavaScript 생태계 역사도 간혹 나오는데, 이해하기 어려웠다.

개발자에게 도움이 되는

5주간 개발자 영어 스터디 참여한 후기 (feat.WWCode Seoul)

개발자끼리 모여 영어 스터디를 참여 하고, 해당 스터디에 대한 회고 글이다. 참 좋은 부분은 마지막 결에 해당하는 부분인데, 내가 말하는게 틀리면 어쩌지? 라는 두려움에서 벗어나 “나는 한국인인데 영어도 쓸 줄 안다.”라는 ****마인드로 변화 한 부분이 제일 좋다고 생각 한다. 나도 트위터에서 스터디가 모집 되면, 공부를 좀 해봐야 겠다는 생각이 들었다. (모각코…?)

대규모 Kubernetes 클러스터 구축기 - LINE ENGINEERING

요즘의 대세이자 앞으로의 서버 운용을 바꾸는 기술이 바로 kubernetes이다. 생각해보면, VM이 훨씬 더 고급 기술이 아닌가? 생각을 하지만, VM의 경우 고급 기술이긴 하지만, 사용성에 제약이 있다. OS 레벨까지 패키징을 해야 하는 이슈가 있다. 그리고 무엇보다 느리다. 트래픽이 급증 할 때, 빠르게 확장 하여 대응을 해야 하는데, 이슈가 있기 때문이다. 그래서 나온 Docker에 이어 수 많은 컨테이너를 관리 하기 위한 쿠버네티스이다. 확실히 중요한건, 배워 놓는다면 써먹을 곳이 정말 많다고 생각 한다.

기술 뉴스 #132 : 19-08-15 :: Outsider’s Dev Story

기술 뉴스에 좋은 내용이 많았는데, 아래 두 링크 또한 여기 기술 뉴스에 있는 글이었다. outsider님의 기술 뉴스를 읽고 뭔가 지식의 지평이 넓어진다고 해야 할까? 내가 정리한 것보다 훨씬 더 많은 분야의 글을 읽고 정리 해 주신다.

좋은 git commit 메시지를 위한 영어 사전

이 글은 정말 너무 좋아서 가져 왔는데, 이 git commit 메시지를 위한 영어 사전은 정말 참고하기 너무 좋다. 아예 외워서 써먹으면 좋겠다 싶었다.

How I side project.ink

사이드 프로젝트에 대한 이야기인데, 상당히 자세하게 쓰여져 있으며, 어떻게 시도를 했고, 어떤 생각으로 진행 했는지 사이드 프로젝트에 대해 자세하게 써 있다. 중요한 건, 하고 싶을 때 하고, 하기 싫을 때는 중단 했다가 다시 실행 하는 것이 아닐까? 생각 하게 되었다.

데이터를 보는 사람에게 추천하는 교양서

꼬젯님의 데이터를 주로 보는 사람들이 읽으면 하는 추천서적이다. 꼬젯님의 추천 도서는 여러 사람들에게 인기가 있는 편이니 읽어보면 좋은 부분이 있을 것이라 생각 한다. (그래서 팩트풀니스 주문…했다.)

[B급 프로그래머] 8월 2주 소식(빅데이터/인공지능, 암호화폐/블록체인, 읽을거리 부문)

이번 주는 빅데이터와 인공지능이 주를 이루는 글타래가 많았다. 그 중에서 바보야, 데이터가 문제야라는 기사가 참 흥미롭기도 하면서 항상 내가 말하는 원인의 핵심이였다. 다른 재밌고, 중요한 글들이 많은데, 많아 다 보지는 못했다.

그래픽 시스템을 만들자 -1-

그래픽 시스템을 만들자 -2-

Hika님의 글이나 영상을 좋아하는 이유가 이해하기 쉽게 설명해 주신 다는 점이다. 사람에 따라 쉬울 수도, 어려울 수도 있지만, 읽어보면 언젠가 이해하는 날이 오지 않을까? 그래픽 시스템에 관해선 나는 사실 별 지식이 없지만, 이렇게 읽다 보니 이미 알고 있는 지식이 조금씩 있어서 신기 했다. 결국은 혜안이 있는 자가 눈높이에 맞게 설명을 한다는 말이 사실이다.

내 맘대로 위클리 뉴스 - 2019년 33주(2019.8.4 - 2019.8.10)

JVM(Java), Python, JavaScript에 관한 내용이 각각 있고, 읽어보면 좋다. 특히, Node.js가 이벤트를 처리 하는 방식에 대한 기사는 두고 두고 읽어보면 좋다고 생각 한다.

Kubernetes

jamiehannaford/what-happens-when-k8s

kubernetes 에서 어떤 일들이 벌어지고, 어떤 녀석?!들이 동작 하는지에 대해 궁금하다면, 읽어보면 좋겠다. 읽는 중인데, 상당히 자세하게 쓰여져 있고, 좋은 내용이 많아서 참고 하기 좋다. 혹은 목차 별로 필요한 부분만 먼저 읽는 방법도 도움이 된다.

Ansible

1. Ansible (앤서블) 로 전체 서버 사용자 추가하기 - 호스트 연결하기

2. Ansible (앤서블) 로 전체 서버 계정 추가하기 - CLI로 계정 추가하기

3. Ansible (앤서블) 로 전체 서버 사용자 추가하기 - 플레이북으로 개선하기

Ansible을 정말 좋아하지만, 나는 사내 시스템 제약에 맞게 사용하는 방법만 알고 있는데, 슬슬 AWS나 다른 환경에서 활용하는 방법을 공부 해봐야 같은데, 딱 시기 적절하게 jojoldu(창천향로)님이 정리를 해주셨다.

Test

와탭 블로그 | Selenium IDE와 Grid로 웹 애플리케이션 테스트 자동화

Selenium을 직접 코드를 짜기는 쉽지 않은데, (할 수는 있지만 굳이…) 자동 녹화 툴들이 많은데, 해당 프로그램을 이용하면, 녹화 한 대상의 테스트가 코드로 변환되어 나오는데, 생각보다 이런 부분을 자동화 하면, 장애 상황이나, 페이지 오류를 빠르게 확인 할 수 있다.

일반적인

나는 스타벅스를 좋아할 당신이 검소하게 살기를 바란다.

은행원의 잔소리는 아니고 조언에 가까운 글이지만, 일련의 예시로 스타벅스에 투자하는 비용이 잦을 수록 생각보다 큰 지출이 된다는 의미이다. 결국, 고정비를 줄이는 방법이 제일 중요한 소비 습관이다. 역시 기본인가 보다.

그냥 저냥 #위클리뉴스 #48

Sat, 10 Aug 2019 15:18:00 GMT

개발자에게 도움이 되는

2019년 상반기 회고

서버 개발자들의 핵인싸로 불리는 이동욱님의 상반기 회고이다. 여전히 다양한 활동을 많이 하시고, 회사 일도 바쁜데, 책 집필과 외부 세미나 참여, 잡지 기고등을 많이 하셨던 상반기의 회고록이다. (그런데, 도대체 연애까지 어떻게 다 하는걸까? 결론은 창천향로님은 헤르미온느다..)

[B급 프로그래머] 7월 5주 소식(빅데이터/인공지능, 암호화폐/블록체인, 읽을거리 부문)

딥러닝에 관한 글들은 항상 이해하기 어렵지만, 조금씩 보다 보면 어느 정도 트렌드는 인지 할 수 있어서 좋다고 생각 한다. 트위터나 페이스북이 딥러닝 연구를 하는 이유는 무엇 일까? 그런데 생각 해보면, 아주 작은 부분에서부터 연구를 시작해 서비스 적용을 아주 잘 하고 있다는 점이다. 그럼, 국내 IT회사들의 인공지능 연구는 얼마나 잘 되고 있는 것 일까?

아파치 로드밸런싱으로 여러 WAS 운영하기

서버의 자원을 효율 적으로 사용하고자 한다면, 여러 tomcat instance를 두는 것도 방법이다. 물론, 나도서버를 운용 하면서 2개의 Tomcat을 mod_jk 모듈을 통해 apache httpd 서버와 연동 했으나, 특수한 상황이 생겨 WAS서버 외의 다른 서버 까지도 서빙을 해야 하는 이유가 생기게 되었다. 그래서 modjk로는 연동을 못하지만 다른 방법을 통해 로드 밸런싱을 설정 하여,apache httpd외 서버 내에 총 3개의 서버들이 동작하도록 설정 해 두었다. `modjk` 모듈이 사용하기는 좋지만, 해당 모듈을 지원 하지 않으면 쓸 수 없다. 그런 것들을 미리 찾아 보는 것이 좋겠다.

💻 당신의 사이드 프로젝트를 위한 10가지 팁

사실 첫 마디가 제일 인상 깊다. 중요한 것은 꾸준히 사이드 프로젝트를 하는 것이 중요하다고 한다. 일주일에 한 시간씩이라도 내 프로그램을 만들어 보는 것은 중요하다고 생각 한다. 올해는 뭐라도 시작 했으면 좋겠다는 생각을 하게 된다. 간단하지만 유용한 웹 서비스를 하나 만들고 싶긴 하다. 물론, 사이드 프로젝트가 코딩에만 국한 되는 것은 아니다. 나의 주간 위클리 뉴스도 사이드 프로젝트이다.

API

REST

RESTful API라는 말을 들으면 대부분 URI에 신경을 많이 쓰는데, 해당 아키텍처의 개념 중 극히 일부에 불과하다는 것을 논문을 읽어보면 알 수 있는데, 해당 로이 필딩의 논문을 직접 읽고 정리 한 기계인간님의 정리 글이다.

JavaScript

‘When to useMemo and useCallback’ 를 읽고

요즘 들어 느끼는 것이지만, useMemo와 useCallback을 언제 써야 하는지에 대한 고민은 항상 된다. 이 글을 읽고나면 어느 정도 감이 오긴 온다. 그래서 무언가 자신만의 기준을 두는 것이 좋다고 생각이 되었다.

[번역] GraphQL은 어떻게 Redux를 대체하는가

React + Redux의 구조에서 어떻게 Redux를 걷어내게 되었는지에 대한 글인데, Apollo + GraphQL을 통해 Redux의 스토어 구조가 필요 없어지고, 대체 하게 된 이유를 설명 한 글이다.

Absolute path in VSCode with TypeScript, CRA, Jest (feat. craco) · Issue #60 · JaeYeopHan/tip-archive

Jbee님의 글인데, 깨알 꿀팁 글의 Repo인데, VS Code에서 TypeScript, CRA, Jest를 사용할 때 절대 경로를 사용 하는 것에 대한 꿀팁이다.

React의 렌더링 이해와 최적화에 대한 글인데, 요즘 정말 대세라 생각 한다. 그런데, 무분별하게 컴포넌트를 만들다 보면 성능이 나오지 않을 때가 있다. 그렇다면, 이 글을 따라 최적화가 되어 있는지 확인 해보자.

데이터의 변화를 알아내고 변화 과정을 추적 하는 ListDiffer

Daybrush님은 요새 많은 라이브러리를 만드시는데 죄다 좋은 라이브러리를 만들고 계신다. 특히나, 요즘 주류의 렌더링 라이브러리/프레임워크를 모두 지원 하도록 만드는 점이 나는 참 멋있다고 생각 한다. 해당 라이브러리는 데이터의 변화를 포착하고, 추적 하는 라이브러리라고 한다. (사용할 곳이 어딜까 고민을 좀 해봐야겠다.)

JavaScript 비동기 처리를 위한 promise 이해하기

Promise를 제대로 이해 하지 못한다면, async / await를 잘 못 사용하게 될 가능성이 높다. 그래서 Promise를 잘 이해하는 것이 비동기 처리를 잘 할 수 있는 기본이라고 생각하는데, 해당 기본에 대해 잘 정리 된 글이다.

TypeScript Deep Dive

TypeScript를 점점 안 쓰는 곳이 없을 정도로 요즘은 정말 많이 사용하는 언어 중에 하나인데, 물론 컴파일 타임에 대한 불편이 있을 수는 있다. 물론, 쓰지 않는 것도 방법이지만, 정적 타이핑이 버그를 줄이는데 보통 20%를 컴파일 타임에 잡을 수 있으니, 쓰는게 더 좋다고 생각한다. 그럴려면, 잘 배워야 하는데 해당 페이지에 설명이 정말 잘 되어 있다. (영어)

NAVER D2

2019 JavaScript 동향인데, 상당히 자세하고, 각 라이브러리/프레임워크 별로 구분하며, 과거와 앞으로의 미래에 대한 방향성을 잘 정리 한 글이다.

SCSS

프론트 개발은 하지만, 정작 마크업 개발은 하지 않기에 궁금증이 많긴 했다. 어떤 부분은 프론트 개발자가 해야 하고, 어떤 부분은 마크업 개발자가 해야 하는 영역일까? 그래서 요즘 css, scss에 관심이 많아졌다. 조금씩 개념이라도 익히려고 찾아보았다. SCSS에 대해 기본적인 설명을 잘 해둔 글이다.

일반적인

회의에서 똑똑해 보이는 10가지 기술

좋은 내용도 있지만, 그다지 의미가 있는지 잘 모르겠는 내용도 있었다.

Java

테스트 코드 작성에 대한 나름의 고찰 - Yun Blog | 기술 블로그

Test에 대한 부분은 정말 개발자마다 다르다. 어떤 이는 Mock을 엄청 사용하고, 어떤 이는 Action의 값에 대한 검증을 주로 하고, 보통 파도 나뉜다. Classicist vs Mockist 정답은 없지만 중요한 핵심은 내가 작성한 코드가 잘 동작하는 지를 확인 하는 것에 초점을 맞춰야 한다. 그게 중요하다.

SpringBoot기반 Redis Cache 활용법

아마 Spring Data Redis의 라이브러리를 이용해 저장하고, 가져오고 해도 되지만, 어노테이션 기반으로 잘 만들어진 라이브러리가 있다면 사용하는 것은 나쁘지 않다고 생각 한다. 물론, Spring Data Redis vs Spring Boot Data Redis Starter 차이는 어떤 점이 있는지 궁금하긴 하다.

about

Sun, 04 Aug 2019 16:29:13 GMT

🙌 Hi,

I’m SeungHo Choi but I use seungdols of nick-name. I love that study language, framework, and then programming. I like Java, JavaScript, Ruby, Python Kotlin etc.

Nowadays, I interested in Go language and k8s (container), IaC(Infrastructure as Code), ansible, unit test, documentation. One more thing, I love happy hour other developers.


Github	https://github.com/seungdols
twitter	https://twitter.com/seungdols
tistory	https://seungdols.tistory.com
E-mail	seungdols0822@gmail.com

💼 Work Experiences

LinePlus Corporation


Period	2022.08 ~ ing
Position	Back-End Engineer
Description	Develop E-commerce system for line shopping service at Shopping Search Team
Projects	Develop of shopping order, point-back, benefit Work

Naver Corporation


Period	2016.09 ~ 2022.07
Position	Full-stack Engineer / Back-End Engineer Tech Lead (2021.05 ~ 2022. 07)
Description	Develop Web Page and API, Batch, Admin tool for Shopping Search pages at Shopping Search Team
Projects	Migrate outlink shopping mall fee from legacy system (kotlin / spring boot)
Projects	PM/VM machine management and migration to K8S
Projects	reorganization of the catalog (PC, Mobile), migrate from legacy(Java, Spring WebMVC) to NextJs/Node.js(koa)


Period	2016.07 ~ 2016.08
Position	Full-stack Engineer Internship
Project	Abuse detecting System Design

✍️ Blog

Tech Blog: https://seungdols.dev
Blog: https://seungdols.tistory.com

Project

RocketFuel alfred workflow

Ref: https://github.com/seungdols/RocketFuel_alfred_workflow

This repository is that using alfred workflow for RocketFuel app. It’s very simple and just toggle for RocketFuel app.

STIL

Ref: https://github.com/seungdols/stil

This repository is a repository of what I have found while studying, and tips I have learned while working.

Activities

Presentation

Naver Showroom Meetup

Ctrl + c/v vs Ansible: IaC어쭙잖게 맛본 썰: Share the experience IaC (with Ansible)

Django Girls December Meetup

meetup slide: Share the footsteps of junior developers

Tree algorithm for study

Tree algorithm: I learned about tree algorithm and made the announcement.

Summary of cyber genome technical papers for malicious code

slide: I learned about malicious code, investigated the corresponding technology for the malicious code, and published the paper.

Network Virtualization

slide: I learned about network virtualization, and I talked about what these technologies are.

Compare SOAP vs RESTful

slide: I learned to compare SOAP services with RESTful services, and to announce the differences.

Sort algorithm for study

sort algorithm: I learned about sort algorithm and made the announcement.

그냥 저냥 #위클리뉴스 #47

Sat, 03 Aug 2019 23:13:00 GMT

JavaScript

5 ES2019 features you can use today - LogRocket Blog

ES2019에서 신규로 추가 되는 기능에 관한 설명인데, 아마 대다수분들이 Google I/O 2019 세션에서 확인하셨다시피, flat(), flatMap()함수가 추가 된다. 이 밖에도 다른 기능들이 추가 되니 확인 하여, 실제로 사용 해보면 좋겠다.

Washing your code: avoid conditions

JavaScript을 사용하는 데에 있어서 불필요하게 조건을 사용하는 경우를 바꿔 보다 가독성과 JavaScript 언어 특성에 맞게 작성하는 방법을 알려주는 글이다.

Washing your code: avoid loops

JavaScript를 사용하는 코드의 반복문에 관한 코드를 좋게 만드는 방법에 관한 시리즈 글인데, 일반 반복문을 사용하는 방법과 Array의 함수들을 이용하는 방식을 비교한다. 그러나, 매번 반복문을 사용하지 않는 것도 문제가 있다고 설명한다.

How to use redux-saga

redux를 사용한다면 보통 thunk or saga를 많이 선택해 사용을 하는 편인데, 요즘은 또 Saga 관련한 글이 많고, 더 명확하다는 평이 많아졌다. 그 Saga를 어떻게 사용 하는지에 관한 글이다.

React에서 root import하기

폴더 기준의 루트로는 사용해 본적이 없는데, 이런 글이 있어서 괜찮다는 생각이 들었다. 보통은 하위 src 디렉토리 기준이나, 특정 기준의 상대경로 혹은 절대경로를 많이 사용하는 편이지 않나? 생각을 했다.

React에서 Typescript 사용하기

리액트에서 TS를 적용하는 방법에 대한 소개글이다. 한 번 시간 내어 따라 해보고, Next.js도 적용 해보면 어떨까 싶기도 하다. 요즘은 또 Next.js가 대세니.. 써보고 싶긴 하다.

Algebraic Effects for the Rest of Us

React팀에서 무언가 이야기 하다 나온 주제 같은데, 뜻을 풀어 보면 대수학 효과라고 할 수 있는 건데, 사실 정확하게 이해하지 못했다. 그렇지만, 함수형 프로그래밍에 관심이 많은 분이라면, 읽어보면 좋겠다.

How to test React components with Jest & Enzyme - RWieruch

React Component를 어떻게 테스팅 할까? 고민이 많은 분들이 참고하시면 좋은 Enzyme과 Jest를 통한 리액트 컴포넌트 테스트에 관한 글이다.

JavaScript Visualizer

JavaScript의 주요 개념들(Context, Hositing, Closure, Scope)을 시각화 해주는 툴이다. 재미나게 써 볼만하다.

Java

가비지 컬렉션(Garbage Collection)

Java 환경에서 서비스를 처리 하다 보면, 겪을 수 있는 문제는 STW(Stop-The-World)로 해당 시간 동안에는 Application이 아무런 응답을 해줄 수 없는데, 이 시간이 굉장히 짧아야 한다. 만약, 성능 튜닝의 실수 혹은 옵션을 잘못 주는 순간 장애로 이어질 수 있다. 그래서 개념을 이해하는 것이 중요한데, 기본 개념부터 G1 GC까지 설명을 잘 해준 글이다. 물론, 최근에는 ZGC가 등장 했다. 나도 물론, CMS, Parallel GC, G1 GC정도만 사용 해 봤기에, ZGC는 잘 알지 못한다.

Server

GraphQL에서는 어떤 HTTP status code를 사용할까?

graphQL의 HTTP status code 값이 굉장히 궁금하기도 했는데, 마침 동일한 궁금증을 가진 분의 글을 읽게 되어 궁금증이 해결 되었는데, 결과적으로는 200 ok를 리턴 한다. 결국, 모든 response에 대한 체크가 필요로 하게 된다는 것으로 이해를 했다.

개발자에게 도움이 되는

흔한 2019년 상반기 회고

요우님의 상반기 회고글인데, 여러가지 고뇌와 히스토리가 잘 남아 있는데, 특히, r2curl 모듈을 만드셨는데, 많이 이용하는 것 같아 뿌듯해 하셨는데, 내심 읽으면서 좀 부러웠다. 나도 언젠가 npm 모듈을 올리리라 다짐을 하게 되었다.

대안을 이야기하라

내가 항상 생각하던 바가, "내가 못하면 시니어 개발자분들이 하시겠지." 라는 사고였다. 그런데, 이는 단단히 착각 속의 생각이다. 사실, 개발 하는 데에 있어서 주니어, 시니어 구분이 무엇이 필요하겠는가?라는 생각이 점점 더 들게 되었다. 그리고, 시간이 지나면서 더 확실히 느끼게 되었다. 내가 잘하는 부분이 있을 수도 있다. 시니어 개발자라고 다 잘하는 것은 아니다. 모든 역할에는 각자 책임이 있고, 각자 해내야 하는 부분이 있다는 것을 깨닫게 되었다. 이 글을 읽으면서 많은 것을 느끼게 되었다.

Git reset에 대해서 알아보자 - dydtjr1128’s Blog

매번 입력하는 git 명령어이기는 하지만, option에 관해서는 얄팍하게 인지하고 있었는데, 이 글을 통해 이해가 쉬웠다.

[후기]MSA, K8S를 이용한 대륙의 서비스 개발 사례 | Popit

인상 깊은 부분은 자체 개발을 통해 k8s의 관리 도구를 만든 점인데, 보통은 스스로 만들진 않고, 오픈 소스 형태로 있는 부분을 활용하는데, 직접 만들어서 쓰는 점이 놀랍다. (직접 만든 것도 쉬운 일은 아니다.) 우선, 직접 만들게 되면, 내부에서 기민하게 처리가 가능하다는 점과 특화가 가능하다는 점이 좋다고 생각한다. 그런데, 글의 링크에도 있는데 광군제는 정말 대단한 1년 중의 하루 같다. 그 많은 트래픽을 어떻게 버티는 건지…

[B급 프로그래머] 7월 4주 소식(개발/관리도구, 고성능 서버/데이터베이스 부문)

여러 개발/관리 도구, 고성능 서버/데이터베이스 주제에 맞는 아티클이 주제에 맞게 분류 되어 있다. 특히, AWS가 이미 너무나 획기적인 Stack으로 변화하여, 사내 시스템만 쓰는 나로써는 잘 모르는 분야이다. 그런데, 리디에서 예약 인스턴스를 활용하여 비용절감 한다고 한다. 쉽게 말하면, 일부 서버군을 이 정도는 기본적으로 쓰게 되는데, 어느 적정 규모의 서버군에 대해 기간 약정을 하여 요금 할인 혜택을 받는다는 것 같다. 확실히 AWS를 공부하는 것도 도움이 된다고 생각 하게 된다.

일반적인

당신의 시야를 넓여줄 TED 영상 BEST 15

살아남아라! 직장인: 사수 없이 성장하기

그냥 저냥 #위클리뉴스 #46

Sat, 27 Jul 2019 19:09:20 GMT

개발자에게 도움이 되는

흔한 주니어 개발자의 VueJS 책 집필기 | 책을 집필하려는 또다른 초보 개발자를 위하여 | Martin

책 집필은 어려운데, 보상이 생각 보다는 적구나 라는 것을 이 글을 읽고 깨달았다. 아무래도 책은 소비가 점점 줄어 들고 있고, 책은 또 다양하게 출판 되기에 경쟁이 쉽진 않다고 생각 한다. 그럼에도 불구하고 저자의 기술 서적 콜렉터의 총평으로 기존에 출판 되는 서적들의 약점을 포함하지 않았을까? 하는 기대심이 생겨서 vue.js를 배울 겸 해당 책을 사야겠다.

코딩 절대 배우지 마라

코딩을 절대 배우지 마라고 했지만, 나는 약간은 다른 생각을 지니고 있다. 그런데, 코딩은 배우는 것보다 스스로 학습 하는게 좋다고 생각한다. 스스로 찾을 때, 어떤 지식을 배우는데 의미가 있다고 생각 한다. 여러 분야들이 있지만, 코딩은 더 그런 측면에 부합한다고 생각 하는 편이다.

(번역) 2019년 7월 2일 Cloudflare 장애 보고서

전 세계 cloudflare의 장애에 관한 타임라인 형식의 포스트 모텀이다. 대부분의 회사에서 이렇게 상사하게 포스트 모텀을 하는 경우가 있을까? 싶기도 하고, 그런 사람들이 있는지 모르지만, 대부분의 회사에서는 이렇게 자세하게 하는 경우는 많이 없다. 물론, 심각한 장애에 관해서는 타임라인 별로 정리를 하기는 한다. 다만, 외부에 이렇게 공개하는 것은 더더욱 어려운 일이다. 내부의 일들을 자세하게 쓰는 것은 회사 비밀도 포함 되기에 순화하거나 어느 정도는 공개 해야 하기 때문이다. 읽어보면 도움이 된다.

jlevy/the-art-of-command-line

커맨드 라인을 잘 다루기 위하여 알아 두면 좋을 내용을 잘 정리를 해둔 글의 번역글이다. 글쓴이는 linux, window, macos 항목으로 분리 하여 설명을 했고, 사실 적은 내용의 window, macos를 제외 하면 모두 linux에 해당 하는 명령이다. 그래서 알아두면, 서버 관련 작업 시에 정말 좋다. 읽어 보니 내가 모르는 명령어가 90%이다.

200번의 채용 인터뷰를 통해 얻은 것들

채용이라는 것을 진행하면서 어떤 심정으로 인터뷰를 진행했고, 어떻게 적응을 하게 되었는지 알 수 있는 글이다. 물론, 한국이 아닌 미국이라는 채용 프로세스를 설명하기에 미국 진출을 꿈꾸는 분들에게도 도움이 된다고 생각 한다.

직원 만족도 100% 회사는 무엇을 신경 쓰고 있을까

‘직원들의 만족도가 100%가 가능한 이야기 일까?’ 신기해서 읽게 되었는데, 진짜로 있었고, 많은 회사들이 진원 만족도가 굉장히 높다는 것을 알 수 있었다. 그런데, 왜 한국에서는 회사 내 직원들의 만족도가 낮은 회사가 더 많을까? 이유가 궁금하기도 하다. 그런 차이만 줄일 수 있다면, 한국을 탈출 하지 않고도 좋은 삶을 살 수 있을 것만 같은데…라는 생각을 하기도 했다.

개발 속도를 증가시키는 기획의 팁!

이 글의 제목을 참 좋아하게 되었다. 사실, 서비스 기획자의 초기 기획서는 좀 많이 이상에 가깝다. 그래서 악영향으로 개발 일정이 여유있게 잡을 수 없다. 내가 경험해본 바로는 대부분이 비즈니스 구조를 이해하지 않는다. 물론, 일반화의 오류 일 수 있지만, 대다수가 그랬다. 비즈니스 구조를 이해 하는 기획자와는 일 하기 편하고 좋았다. 서로 서로 양보도 해가면서 업무를 잘 소화 할 수 있는데, 전혀 모르고 오로지 화면, 새로운 기능만을 원하는 기획자들과는 일하기 버겁다. 솔직히, "기획서를 작성 할 때, 비즈니스 구조를 잘 이해하고 작성 된다면, 개발 일정은 여유롭게 지켜질 수 있을텐데"라는 생각을 하곤 했다. 물론, 개발자들의 능력 부족 일 수도 있다. 특히, 나 같은 개발자들은 일정이 더 필요로 하다. 그런데, 때때로 기획자와의 협업을 잘 하는 방법을 누군가 알려 주기만 한다면 내가 사비를 들여서라도 강의를 들어 볼 의향이 있다.

Data Science

Foundations of Data Science - Microsoft Research

Data Science의 기초에 관한 400여 페이지에 달하는 pdf를 공개 했는데, 빅데이터 처리, 인공지능에서 사용하는 개념과 알고리즘에 관한 설명이 있다. (물론, 내용이 쉽진 않다.)

Ansible

Ansible 2.8 설치하기 그리고 idrsa.pub , authorizedkeys 등록없이 사용하기

실무에서 ansible을 잘 쓰고 있는 편인데, 벌써 2.8이 나왔다니 놀랍다. 이미지를 통해 설명은 간단하게 되어 있다.

API

처음 만나는 GraphQL

GraphQL이란게 사실 어떤건지 몰랐는데, 짧게나마 정리 된 설명을 읽어 보니 얼추 알게 되었다. 그래도 실무에 바로 적용하는 것은 조금 어렵지만 그래도 적용하면 좋은 점이 많지 않을까? 하는 생각이 들었고, 적용하면 현재 구조 보다는 도움 된다는 생각을 했다.

mod_rpaf 모듈을 ansible로 설치 하기

Sat, 20 Jul 2019 20:06:00 GMT

mod_rpaf 모듈이 필요한 경우

apache 2.2.x를 사용하는데, proxy server를 거치는 경우 client-ip가 바뀐다. 그럴때, 해당 모듈을 사용하면 되는데, apache 2.4.x에서는 mod_remoteip.so가 아마 있어서 해당 모듈을 사용하면 된다.

apache httpd 2.2.x를 사용하는 경우 설치 (with ansible)

ansible-playbook을 기준으로 하는데, 보통 role을 구성해서 사용하는 편이다.

그러나, 해당 작업은 apache setting과의 의존이 있기 때문에 하나의 task로 분리해서 만들었다. 원래는 role을 구성하는 것이 더 좋다.

ansible-playbook을 어떤 것인지 모르겠다면, ansible document를 참고 하면 된다.

간략하게 설명 하자면, 하나의 디렉토리를 구성하고, inventory/,group_vars/, host_vars/, role/등을 구성 한 뒤에 각 영역에 맞게 정보를 yaml형태로 파일을 만들어서 넣어주면 된다.

tasks/setup_mod_rpaf.yml이라고 하나 만든다.

---
- name: download package of mod_rpaf
  unarchive:
    src: 'https://github.com/gnif/mod_rpaf/archive/v{{ rpaf_version }}-rc1.tar.gz'
    dest: /home/seungdols/apps/
    owner: seungdols
    group: seungdols
    remote_src: yes
  tags:
    - mod_rpaf
    - download

- name: make install mod_rpaf
  make:
    chdir: '/home/seungdols/apps/mod_rpaf-{{ rpaf_version }}-rc1'
    target: install
  tags:
    - mod_rpaf
    - make_module

- name: finish libtool
  command: libtool --finish /home/seungdols/apps/apache/modules/
  args:
    chdir: '/home/seungdols/apps/mod_rpaf-{{ rpaf_version }}-rc1'
  tags:
    - mod_rpaf
    - libtool

vars/main.yml에는 rpaf_version을 넣어주면 된다.

---
rpaf_version: 0.8.5

원래는 role을 이용해 새로 구성하는 것이 좋긴 하지만, apache httpd 셋팅 구성과 함께 해주는 것이 좋기 때문에, 하나의 task로 구성 했다.

그런데, 위의 경로 같은 부분들은 아무래도 각자 상황에 맞게 입력 해주어야 한다. 위의 예시는 회사에서 만든 파일에서 회사 서버들의 경로를 노출 하기가 좀 꺼림칙하여 변경했으므로, 해당 경로는 각자 서버 디렉토리에 맞게 설정을 해야 한다.

그냥 저냥 #위클리뉴스 #45

Sat, 20 Jul 2019 18:59:20 GMT

개발에 도움이 되는

Python HTML 문자열을 마크다운으로 변환하는 html2text 라이브러리 알아보기: 요즘 티스토리 데이터를 백업해서 markdown으로 바꾸고 싶다는 생각을 했는데, python에 이런 툴이 있었다. 역시, 반복하지 말라는 명언을 기억하고, 검색하자.
Alfred에서 iTerm 명령어 바로 실행하기: Alfred에서 터미널 명령어를 바로 실행 할 수 있도록 하는 applescript를 어떤 이가 만들었는데, 이를 소개하는 글이다.
2019 상반기 회고 + 하반기 다짐 (feat. 글또): 프론트 개발자분의 상반기 회고록인데, 여러가지 활동을 많이 하시는 것 같았다. 그런데, 도대체 시간관리를 어떻게 하시는지 궁금하기도 하다.
[B급 프로그래머] 7월 1주 소식(개발/관리도구, 고성능 서버/데이터베이스 부문)
기술 뉴스 #130 : 19-07-15 :: Outsider’s Dev Story
- dockerfile 작성 하는 best practice 아티클이 인상 깊었다. 요즘은 또 도커를 손 놓고 있었는데, 확실히 용량을 작게 만드는 게 가장 중요하다. 빌드 타임 진짜 헬이다.
여러 개의 JDK를 설치하고 선택해서 사용하기 - 개발수양록
- JDK를 설치하고 관리하는 방법에 대한 소개를 각 tool별로 잘 소개 해주시고, 정리를 딱 해주셨다. 그런데, jenv가 쓰다 보니 불편한 점이 좀 많다. 일단 충돌이 잦아서 다른 도구를 쓰려고 하는데, 이 글을 보고 하나를 새로 설치 해보려고 한다.
Firefox 68: BigInts, Contrast Checks, and the QuantumBar - Mozilla Hacks - the Web developer blog
- BigInt가 Firefox 68에 추가 되었다고 한다. 아마, 곧 표준 JS에도 반영이 될 부분이라 그런지, 없데이트가 빠르다고 생각되는 건 내 기분 탓 일까?
Kafka and Friends (ko)
- Kafka Manager + kafka-webview를 같이 쓰고 있는데, 여기서 더 추가적으로 부족하다거나 하는 것은 아직은 없다.

JavaScript

JavaScript Closure by Example - RWieruch
- closure의 예시를 코드로 보여주면서 설명을 하고 있는데, 면접이든 실제 코딩을 하든 JS에서의 Closure 개념을 알고 있는 것과 모르는 것은 굉장히 차이가 크다.

TypeScript에 뒷통수 맞은썰(Promise.all)

Sat, 13 Jul 2019 09:41:00 GMT

Promise.xxx는 인자의 수 제한이 있다?

이 글이 갑자기 순간적으로 리트윗이 되면서 이야기가 많이 오고 갔네요! 잘못된 부분과 설명의 차이를 인지 하는 게 중요하다고 생각합니다.

JS에서의 Promise.xxx는 iterable로 처리하기 때문에 실질적인 인자 개수의 제한이 없습니다.

MDN-Promise.all

Promise.all(iterable);

그런데, TypeScript를 사용하게 되면, 이야기는 달라집니다. (이 설명은 아래에 수정이 있습니다.)

TypeScript lib.es2015.promise.d.ts를 보시면 알 수 있습니다.

all<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10>
all<T1, T2, T3, T4, T5, T6, T7, T8, T9>
all<T1, T2, T3, T4, T5, T6, T7, T8>
all<T1, T2, T3, T4, T5, T6, T7>
all<T1, T2, T3, T4, T5, T6>
all<T1, T2, T3, T4, T5>
all<T1, T2, T3, T4>
all<T1, T2, T3>
all<T1, T2>
all<T1>

위와 같이 총 10개의 all type이 있습니다.

그래서 TS에서의 Promise.all에 인자로 10개이상 전달 할 수 없습니다. (이 부분에 대해서는 우리가 아무것도 할 수 없이 10개 이상은 전달 할 수 없다는 것은 아닙니다. seulgi.kim님이 남겨주신 글에서 참조 하여 10개 이상을 위해서는 직접 정의해서 사용하면 됩니다. )

이 부분을 제가 망각 하고, 프로그래밍 하다보니 문제가 생겼는데, 전 당연히?! 인자 개수때문은 아닐거라 판단 했습니다.
그런데, 인자 개수 제한이 맞았습니다.

위에 대한 부분은 반은 맞고, 반은 틀린 설명이었네요! https://blog.seulgi.kim/2019/07/promise-all-tuple.html

링크에서 설명 해주신 것처럼 iterable 타입의 Promise.all도 있다고 설명을 해주셨습니다. (@seulgi.kim님 조언 감사합니다.)

그런데, 실질적으로 코드 확장이나, 타입 가드를 사용하지 않고, --lib옵션으로 따로 주지 않을 경우에는 es2015.promise.d.ts에 있는 T1...T10에 해당하는 all function의 오버로딩을 볼 수 있습니다. (이에 대한 부분에 제가 뒷통수를 맞았다고 글을 썼습니다.)

누군가는 이 글을 보고 이상하다고 할 수도 있겠고, 누군가는 오! 나도 이런 일을 겪었는데! 라고 말 할 수 있을 것 같아서 제 생각에는 나름 황당한 경험이었기에 글을 썼습니다.

왜냐하면, JS 언어의 iterable인데, 이를 라이브러리의 의존성을 분리하기 위해서 promise.d.ts에는 최대 10개의 function overload를 , iterable.d.ts에는 iterable로 넣어둔다는게 아직은 쪼렙이라 잘 모르겠더군요. 누군가는 삽질 할 수 있는 포인트이기에 글을 써두었습니다.

참, 물론 10개 이상의 Promise를 묶는 것은 좋지 않은 Anti-pattern 일 수 있습니다. 그러나, 세상사 내 맘대로 되는 일 업고, 서비스 개발도 내 맘대로 되지 않습니다. 물론, 초고수가 와서 나에게 방법을 알려주면 좋겠군요. (우리팀으로 와서 저를 혼내셔도 됩니다. 코드로 보여주세요.)

물론 아래에 써둔 것처럼 블루버드를 마냥 찬양하는 것은 아닙니다. 우연히 보았을 뿐…(물론 iterable.d.ts를 못봤다.)

그 밖에

그런데, 찾다보니 Blubird라는 라이브러리에서는 iterable로 구현을 하고 있습니다.

BlueBird에서는 API doc에서도 확인 할 수 있듯이 iterable입니다.

http://bluebirdjs.com/docs/api/promise.all.html

Promise.all | bluebird

그러나, TypeScript에서 iterable인지는 직접 돌려봐야 알 것 같습니다.

https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/bluebird/index.d.ts#L857

위의 부분이 정확한 실제 링크입니다. 다섯개까지는 동일한 구현이네요. 하지만, Types에도 아래와 같이 명시 되어 있습니다.

  /**
   * Given an array, or a promise of an array, which contains promises (or a mix of promises and values) return a promise that is fulfilled when all the items in the array are fulfilled.
   * The promise's fulfillment value is an array with fulfillment values at respective positions to the original array.
   * If any promise in the array rejects, the returned promise is rejected with the rejection reason.
   */
  // TODO enable more overloads
  // array with promises of different types
  static all<T1, T2, T3, T4, T5>(values: [Resolvable<T1>, Resolvable<T2>, Resolvable<T3>, Resolvable<T4>, Resolvable<T5>]): Bluebird<[T1, T2, T3, T4, T5]>;
  static all<T1, T2, T3, T4>(values: [Resolvable<T1>, Resolvable<T2>, Resolvable<T3>, Resolvable<T4>]): Bluebird<[T1, T2, T3, T4]>;
  static all<T1, T2, T3>(values: [Resolvable<T1>, Resolvable<T2>, Resolvable<T3>]): Bluebird<[T1, T2, T3]>;
  static all<T1, T2>(values: [Resolvable<T1>, Resolvable<T2>]): Bluebird<[T1, T2]>;
  static all<T1>(values: [Resolvable<T1>]): Bluebird<[T1]>;
  // array with values
static all<R>(values: Resolvable<Iterable<Resolvable<R>>>): Bluebird<R[]>;

생각해보면, 왜 10개로 제한 했는지는 알 수 없다. 이건 MS에서 TS 개발자들이 생각하기에 성능 이슈를 판단해 10개로 제한 한 것인지는 모르지만, 표준 JS 스택을 지키지 않는건 문제가 있다고 생각한다.

반대로, 왜 promise.d.ts에는 10개의 overload를 지정해두었을까? 궁금하다. iterable.d.ts에는 iterable이라면… 왜 굳이..MS 형아들에게 물어보고 싶구나.

그냥 저냥 #위클리뉴스 #44

Sat, 29 Jun 2019 18:52:00 GMT

ElasticSearch

Elasticsearch의 색인 별명 활용 팁
- 최근 서비스 개편을 진행함과 동시에 특정 데이터의 개편 또한 같이 변경 되어, ES의 색인과 Query등에 급작스럽게 공부하게 되었다. Index alias를 변경 해야 하는데, QA를 진행중이라 접근이 끊기면 안되기 때문에, atomic 하게 변경이 되어야 했다. 찾아보니, add, remove를 같이 action으로 넣어 주면 끊기지 않고 정확하게 잘 동작하게 된다고 한다.
Elasticsearch from the Bottom Up, Part 1
- ElasticSearch의 기본이 되는 Index인 Inverted Index, Building Index, Indext Segments에 관한 설명이다. 시간이 나면 조금 더 기본적인 원리를 찾아서 이해하고 싶기는 하다.
Elasticsearch from the Top Down
- ElasticSearch의 기본인 Cluster, Node, Routing, Coordinators등에 관해서 소개 하고 있는 글이다. Coordinator와 Primary, Replica와의 관계에 대해 알 수 있다.

개발자에게 도움이 되는

Merge 기념일 - Cho Eun - Medium
- 조은님의 Merge 회고라고 생각하면 좋은데, 마크업 개발자가 FE로 나아가는 회고 글이라, 많은 분들이 읽어보면 좋겠다 싶었다. 내가 아는 것과 모르는 것을 잘 인지하고 있어야 하는 점과 모르는 부분은 알아가는 노력을 하는 점이 멋있다고 생각한다.
「프로그래머의 배움」 발표자료 공개
- 안희종님이 GDG 행사에서 발표하신 내용인데, 좋은 내용이 참 많았다. 프로그래머의 배움이라는 주제와 팀원에 대한 이야기가 주로 많았는데, 정말 중요한 내용은 혼자서 하는 일이 아니라는 부분이 제일 공감이 간다.
Git 계정 여러 개 동시 사용하기 :: Outsider’s Dev Story
- Git 계정을 여러 개 쓰는 일이 없을 것 같지만, 회사에서는 Github Enterprise를 쓴다면, 훨씬 복잡해진다. 물론, 아예 컴퓨터를 분리하면 속 편하긴 하다. 다만, 인생은 계획 대로 되지 않는다. 개인 컴퓨터로 회사 일을 해야 할 때가 있고, 하다 보면 서로 commit 정보가 뒤바뀐 채로 commit 되는 일이 빈번 해지는데, 그러한 것을 잘 관리 하고 싶다면, 읽어보면 좋다.
React Hooks + TS + functional = 아름다움
- React의 Hooks에 대한 소개와 클래스 컴포넌트와의 비교를 코드로 소개하기에 굉장히 쉽게 이해 할 수 있다. 특히, useState(() ⇒ func())를 해주면, 최초 한 번만 수행 한다는 점도 알고 있어야 삽질을 줄일 수 있다.
UX빼면 시체, 프런트엔드
- Jbee님의 발표 자료인데, 굉장히 많은 공감을 하는 내용이 있다. 내가 프런트 서비스를 개발 하면서 느끼는 점은 왜 하나 같이 UX에 관해서는 하나도 신경 쓰지 않는지? 서비스 개편을 일 년에 두 번씩은 최소한 하는데, 그때마다 사용자 경험이 왜 무시 되는지 이해가 가지 않았다. 이는 기획자, 디자이너, 개발자가 모두 해당 서비스를 안 쓰기 때문이다. 라는 결론에 도달 했다. FE를 책임 지는 개발자라면, UX를 신경 써야 하는 건 정말 맞는 말이다.
‘React, TS, Electron Application 개발하면서 내가 실수한 것들’
- QueryPie라는 툴을 만들면서 겪었던 이슈등에 대해 원인과 해결방안에 대해서 상세하게 정리 되어 있고, 실제 코드를 확인 해볼 수 있다. Electron.js를 사용하는 분들이라면, 관심 가지고 보면 좋겠다.
[우아한테크코스] 1주차 미션 리뷰 후기
- Java에 관한 미션을 진행 한 뒤에, 코드 리뷰를 받은 후기를 공유 해주셨는데, 나도 이런 코스가 있었다면, 무조건 했을 텐데.. 그게 좀 아쉽긴 하다. 내가 취업할 때만 해도 우아한 형제들은 경력직만 뽑았기에, 조금 아쉬움이 남는다. 좋은 가르침과 방향성을 일찍 경험 할 수 있다면, 빠르게 성장하는데 도움이 되기에 부럽기도 하면서 좋은 내용이 많아서 도움이 많이 되었다.

Container

분산 컨테이너 환경에서의 디자인 패턴 (1)
분산 컨테이너 환경에서의 디자인 패턴 (2)
분산 컨테이너 환경에서의 디자인 패턴 (3)
- 분산 컨테이너 환경을 활용하는 개발자들에게 필요한 컨테이너 디자인 패턴에 관한 번역글이다. 요즘은 또 클라우드 환경으로 서비스를 많이 하기 때문에, 활용하면 좋은 포인트들이 있다. 앰배서더 패턴등, 멀티 노드 서빙 패턴등 활용 하기 좋다.
[면접] 개발자 면접관을 감동시키는 면접
- 면접을 보게 된다는 것은 회사에 소개팅을 하러 가는 것과 같은데, 당시에는 탈락을 하더라도 좋은 인상을 남기게 되면, 추후에 다시 연락이 올 수도 있다. 사람의 연이 라는 것이 본래 그렇다. 그렇기에 최대한 좋은 인상을 남기는 것이 좋다. 가장 좋은 것은 내가 얼마나 협업을 잘 할 수 있는지? 내가 아는 지식과 모르는 지식을 잘 구분하고 있는지가 제일 중요하다고 생각한다.

Git

Git을 이용한 협업 워크플로우
- Git을 잘 쓰는 것도 굉장히 어렵다. 여러 사람들과 함께 사용하다 보면, 문제가 많이 발생한다. long-live branch를 master branch (stable branch)로 merge 하는 것과 stable branch의 내용을 지속적으로 long-live branch에 반영하는 것도 어렵다. 잘못하면, 꼬이기 쉽다. 그래서 협업 워크 플로우를 잘 정의 하는 것이 Git으로 인한 이슈 발생을 최소화 하는 지름길이다. (한 번 꼬이면, 해결 하기 정말 어렵다. 특히, 여러 부서가 같이 사용하는 저장소라면, 해결하는 것은 헬이다.) 그래서 최근에 가장 내 생각에 알맞는 것은 git flow를 통한 방법이 제일 깔끔해보인다.

그냥 저냥 #위클리뉴스 #43

Sun, 09 Jun 2019 22:55:02 GMT

React

setState를 바르게 사용하는 방법: 결국에는 Docs를 지속적으로 참조하는 방법이 가장 잘 활용하는 방법이라 생각을 하게 되었다. 버전별로 업데이트 될 때마다 다시 처음으로 돌아가 문서를 확인하자. 결국, 기본은 Document다.
컴포넌트 제대로 만들기: 가고 싶었던 부트캠프 강의 였는데, 강의 자료가 올라와서 읽다보니 깊고 자세한 내용이라 분명 나와 같은 React를 입문하는 사람들에게 도움이 있을 것이라 생각 되었다. 컴포넌트를 어떻게 구성해야 하는지? 실제 예시를 통해 설명하고 있는 글이다.
자바스크립트 테스팅의 기초
TDD의 소개
리액트 테스트의 소개
Enzyme 을 사용한 리액트 컴포넌트 테스트
react-testing-library 를 사용한 리액트 컴포넌트 테스트
react-testing-library 를 사용하여 TDD 개발 흐름으로 투두리스트 만들기
react-testing-library 의 비동기작업을 위한 테스트
velopert님의 테스트 시리즈 글인데 JavaScript 테스트부터, TDD의 소개, React의 테스트를 위한 Enzyme, react-testing-library를 설명과 함께 비교하고 있다.
redux-saga와 typescript 편하게 사용하기 redux-thunk를 사용했었는데, 사실 예쁘게 사용하는 것은 아직도 어렵다. 그런데, redux-saga가 요즘은 좀 더 이해하기 쉽다고 생각하는 사람들이 많아 졌다고 생각한다. redux-saga와 typescript를 사용을 위해 두 가지의 내용에 대해 소개하는 글이다.

Java

OKKY | 자바EE의 역사 및 스프링과의 관계 Spring Framework를 쓰는 사람이라면 들어본 적이 있을 EJB와 JavaEE에 관한 역사에 관해서 쓰여져있고, Spring Framework와 JavaEE와의 관계를 잘 설명한 글이다.
J2EE Development without EJB (1) - Why “J2EE Without EJB”? 위의 글과 비슷한 류의 글인데, Toby님이 쓰신 EJB 없이 J2EE 개발 시리즈의 글을 읽어보면 좋겠다. 나도 시간이 날때, 시리즈 전체 글을 읽어보려고 한다. 솔직히 이런 류의 내용은 오랜 시간이 지나도 이해가 가고, 앞으로 Spring 생태계를 이해하는데 도움을 많이 준다.
Spring Bean Scopes Spring framework의 Bean scope에 관한 내용인데, Singleton, prototytpe, request, session, application 총 5가지의 빈 스코프에 관하여 설명한 글이다.

JavaScript

선언형으로 대체 가능한 문법들 정리 요즈음 함수형 프로그래밍이라고 핫하지만, 결국 내포된 의미는 선언형에 가깝다고 해야 할까? 싶기도 하다. 그런데, JavaScript에서 흔하게 사용하는 Object, if-else, for/for-in 으로 표현된 부분을 map, reduxe, assign을 이용해 선언형 방식의 코드로 바꾸는 예시를 소개한다.
레거시 코드에서 이해하기 쉬운코드로 리팩토링 2 코드 냄새가 나는 흔하게 볼 수 있는 코드들을 이해하기 쉬운 형태로 바꾸는 것을 소개하고 있는데, 확실히 좋은 부분들이 많고, Object.assign을 활용하는 방법, 깊은 배열 탐색 하는 것을 some을 이용하는 방법들이 특히, 좋았다.

개발자에게 도움이 되는

월간 개발자스럽다 #43 여러 종류의 글이 올라오는데, 이번 달의 월간 아티클들이 모여 있고, 내 블로그에서 다뤘던 글들도 있어서 나는 조금 더 여유롭게 내가 접하지 못했던 글을 접할 수 있었다.
스터디 모임 방법 몇 가지 스터디 방법은 천차만별이고, 사람들의 니즈의 정도 차도 존재하는데, 그 속에서 어떻게 나는 학습을 할 것인가?에 대한 힌트를 주는 글이라 스터디를 자주 하거나, 할 예정이라면 참고하면 좋겠다.
내 맘대로 위클리 뉴스 - 2019년 22주(2019.5.27 - 2019.6.2) Java, Python, JavaScript에 관한 글이 올라오는데, 이번의 Java 항목에 해당하는 글 중에 가장 좋은 것은 Java8 - Java12의 feature가 정리가 된 글인데, Java를 주로 쓰는 분이라면 읽어보면 좋다고 생각이 들었다.
기술 뉴스 #127 : 19-06-01 :: Outsider’s Dev Story 개발 관련 여러 종류의 글이 올라오고, 유용한 프로젝트 소식, 라이브러리/프레임워크 버전 업데이트 정보도 공유를 해주신다. kube의 관한 내용도 있는데, MS에서 공개한 Kubernetes Learning Path라는 글이 좋은게, 50일 동안 kube의 어디부터 시작을 해야하고, 어떻게 공부를 해야 하는지 가이드 하는 글이 좋았다. 사실, 나도 배우고 싶은데, 이미 에코 시스템도 너무 많고, 어떻게 갈피를 잡아야 할지 모르겠더라. 그런 점에서 충분히 도움이 된다.
150일동안 내가 배운 것들 -1 - 소소로그 150여일동안 입사를 하여, 배운 소소한 내용으로 볼 수 있지만, 솔직히 이렇게 정성스럽고, 조심스럽게 접근 하는 동료라면 분명 꼼꼼하고 실수를 잘 하지 않는 분이지 않을까? 라는 생각이 들었고, 열정이 있는 분이라 과연 나는 이만한 열정이 있는지 자문하게 되었다. 특히, 문서화를 선택이 아니다. 라는 말이 인상 깊었고, 공감이 많이 되었다.
구글로 잘 검색하기 - 소소로그 위 글을 읽다가 같은 블로거의 다른 종류의 글인데, 특히 어떻게 원하는 것을 검색하는가? 라는 방법에 대한 해답이지 않을까?라는 생각을 하게 만드는 글을 찾게 되어 공유 한다. 이런 개개인의 노하우가 있는 것은 굉장히 중요하다. 꼭 줍줍하여 내 것으로 만들자.
[인터뷰] 경력 18년 차 개발자의 하루 일상은 어떨까요? - NBP 개발자 장창환 님의 인터뷰 -
[인터뷰] 열등생에서 네이버 클라우드 플랫폼 신입 개발자가 되기까지! - NBP 신입 개발자 정승주 님 인터뷰-

Kubernetes

NAVER D2 Telepresence를 이용해, kube 클러스터에서 실행할 어플리케이션을 로컬에서 개발하는 방법에 관한 글인데, 사실, 처음 kube를 접한다면, 어렵고 복잡한 내용일 수 있는데, 천천히 읽다 보면 예시를 가이드 하고 있기에 쉽게 이해 할 수 있다.

일반적으로 도움이 되는

지식의 가난에는 이자가 붙는다 지식의 가난에는 이자가 붙는 다는 말이, 참으로 무섭다고 느껴졌다. 요즘 나의 생각은 하나같았다. 나는 무엇을 잘하는 사람인가? 그런 생각이 들었는데, 이 글을 읽으면서 아! 나도 항상 느끼고 있던 부분이구나. 그런데, 나는 왜 행하는 것이 좀 부족할까? 그런 답을 얻었다. 결국, 내가 어떤 라이브러리 공부에 들이는 것도 비록 그 기술이 사라져도 남는 것이 있다는 깨달음이다. 특히, 원론적인 지식들, 영어/수학 등과 같은 것들은 무조건 나에게 남는다. 비록, 내가 일 하면서 쓰지 않을지언정, 언젠가 필요로 하다는 것이다. 나는 올 연말에 어떤 회고를 쓸지? 걱정이 되기도 하고, 기대가 되기도 한다. 아직 6개월이 남았으니까, 다시 작심삼일을 해보자. 작심삼일을 100번하면 일년을 넘게 노력하며 사는 것이라는 글도 보았다. 결국 행하는 것은 남는다.
직장인 자기계발에 관한 개인적 팁 직장인 자기계발에 관한 팁에 관한 글인데, 읽어보면 도움이 많이 된다. 시간이 없는 게 아니라, 시간을 내지 못해서 라는 말이 있다. 자기계발을 하려거든 결국 시간이 중요한데, 나의 하루 중 어떤 시간을 할애할 것인지?가 관건이지 않나? 라는 생각을 한다. 야근을 점차 줄여서 나도 훈련하는 시간을 지속적으로 만들어야겠다는 생각을 하게 되었다.

그냥 저냥 #위클리뉴스 #42

Sat, 01 Jun 2019 15:06:02 GMT

JavaScript

레거시 코드에서 이해하기 쉬운코드로 리팩토링: 카카오 i 오픈 빌더 프로젝트를 하면서, 어떻게 리팩토링을 해나갔는지? 소개하는 글입니다. JavaScript 관련하여 좋은 글을 많이 써주시고 계신데요. 실제 카카오 프로젝트 구조를 설명하고 계신 것 같아서 자세하게 써주셔서 이해하기 쉬웠고, 리팩토링에 관해서도 약간의 설명과 진행한 방향을 소개하고 계셔서 읽어보면 도움이 많이 됩니다. Angular는 데이터 흐름이 양방향이 가능한데, 이를 단방향으로 제한하여 리팩토링 한점 또한 생소하지만, 이유가 있어 한 번쯤 다들 생각해보면 좋겠다. 읽으면서 “컴포넌트들의 분리와 영역을 설정하고, 어떻게 응집도를 낮추고, 결합도를 높일 수 있는지에 대해 깊은 고민을 많이 하셨구나” 라는 생각을 했다.
PM2를 활용한 Node.js 무중단 서비스하기 - LINE ENGINEERING: 최근에는 Node.js를 이용하는 회사들이나 서비스가 엄청 많아지고 있다. 그래서 이를 잘 운영하는 것도 굉장히 중요한데, Process Management를 할 수 있도록 지원해주는 Tool들이 많이 있다. 그 중에서도 PM2가 최근에는 가장 핫하다고 볼 수 있는데, 이를 이용해 운영 하면서 무중단 서비스를 위해 알아야 할 점을 소개하고 있다. 특히, pm2 reload app을 통해 어플리케이션을 새로 동작 하는 방식은 처음 봐서 그런지 신기했다.
LINE Search UI 개선기 - LINE ENGINEERING: LINE의 UI 개선을 하면서 웹뷰 영역에서의 이미지 뷰어 처리에 대한 어려움이 어떤 점이었는지? 어떻게 해결했는지를 소개하고 있습니다. 다양한 샘플도 만들어보고, 실제 피드백을 받아 리뷰 반영을 함으로써 개선을 하는 프로세스가 참 좋다고 생각 합니다. 이미지 뷰어에 관련해서 실제로 작업을 해야 하거나 하시면, 참고 하시면 좋겠습니다.
Code Formatting 자동화 : Jbee님이 Code Formatting을 어떻게 자동화 하는지에 대해서 여러 tool과 함께 설명을 해주셨다. 자동화는 도움을 정말 많이 주는 것 같다. 코드 리뷰시에도 indent가 맞지 않거나, Format이 맞지 않는 것에 있어서 리뷰하는 시간을 줄여주기 때문이다. lint-staged라는 툴을 쓰고 있는데, 쓰고 있지 않다면, 한 번 적용 해봐도 좋을 것 같다는 생각이 들었다. 특히, 코드의 수정 사항에 대해서만 검사를 하기 때문에 훨씬 안전한 방지책이라고 생각이 들었다.
어댑터 패턴 Adapter Pattern : Aapter Pattern에 대한 설명인데, 사실 패턴은 알면 알수록 어렵다고 생각한다. 막상 이렇게 예시 코드를 보고 하더라도, 실제 프로젝트에서 쓰기는 어려운 건 나 혼자뿐일까? 패턴을 잘 쓰면 좋지만, 어렴풋이 쓰다가는 그 패턴을 버리는 게 더 어려울 때가 있어서 그렇다. 적용하기 쉽지 않은 게 패턴이라고 생각하는 편이다.

Java

도움이 될수도 있는 JVM memory leak 이야기 - 우아한형제들 기술 블로그 : 문제가 되는 부분을 찾기 위해 배포 이력을 조회하고, Memory Leak이 발생하는 부분을 [PinPoint](https://github.com/naver/pinpoint)을 통해 분석하고, 왜 발생했는지 찾고, 먼저 GC의 정책을 바꿔서 해결 해보려고 하셨다. 그럼에도 불구하고, 동일한 문제가 발생하자 Heap Memory Dump 파일을 분석해 원인을 찾는 모습을 진솔하게 써 주셨다. 어떤 문제가 생겼을 때, 어떻게 진단하고 어떻게 접근 해야 하는지 상세하게 흐름을 기술 해주셨다. 이런 일련의 흐름을 기술 해주는 것은 상당히 소중하다고 생각하는 편이다. 주니어 개발자들이 원인을 어떻게 찾아야 하는가? 에 대한 길잡이를 해줄 수 있으니 말이다.
우아한 feign 적용기 - 우아한형제들 기술 블로그 : Netflix에서 개발한 Http client binder라고 하는 feign을 적용한 후기를 남겨주었는데, 사실 처음 보았다. Spring Cloud에서 Netflix가 개발했던, zuul, ribbon, eureka 등은 많이 들어보고 어떻게 사용을 다들 하는지는 봤는데, feign을 처음 봤는데, 진짜 신기할정도로 간소화 되어 쉽게 Rest API를 사용할 수 있도록 해준다. 고로, 설정의 간소화가 있다면 비즈니스 로직에 정말 집중 할 수 있겠구나 생각이 들었다.
Webinar Recording: What’s New in JDK 12 - DZone Java : Java 12의 웨비너인데, 사실 나도 보지 못했다. Java 12에서 literal string이었던 기능이 제외되서 아쉽긴 한데, 다양한 기능이 추가 되는 걸로 알고 있다. 정말 빠르게 업그레이드 되고 있다. 이렇게 되다간 아마 8 이하의 버전에 대한 호환성을 끊을 수도 있지 않을까 생각이 들었다.
Double Dispatch in DDD | Baeldung : Double Dispatch에 관한 글인데, DDD(Domain Driven Development)에서 어떻게 적용하는지에 대함이다. 그런데, 사실 나도 Double Dispatch를 왜 써야 하고, 어떻게 써야 하는지는 감이 잘 오지 않는다. 해당 지식에 관해 모호함이 존재한다고 해야 할까? 그래서 매번 기억이 안날때는 토비님의 영상을 보곤 한다. 먼저, 이 영상을 보고 위 글을 이해하려고 노력 해보자.

개발자에게 도움이 되는

(자막)[NDC19] 좋은 로그란 무엇인가?: 좋은 로그를 위해 고려해야 할 것들
Facebook F8 2019 후기 #1 :: Outsider’s Dev Story : 아웃사이더님의 F8을 위해 샌프란시스코를 가셨던 경험기입니다. 위워크의 혜택이나, 자유로움이 놀랍긴 한데, 이용 해 본적이 없어서 아쉽다. 더구나, Postman의 업데이트가 빨라서 좋은 것 같은데, 요새는 주로 IDE에서 제공하는 Rest Client를 이용하거나, Plugin을 쓰고 있는데, 한 번 다시 설치 해봐야겠다.
Facebook F8 2019 후기 #2 :: Outsider’s Dev Story : F8은 해커톤을 신청하면, 비행기와 호텔을 지원해주는 것은 정말 좋다고 생각한다. 해커톤을 하면서 특색 있는 아이템들이 나올 수도 있으니 말이다. 그런 경험으로 빗대어 보면, 이렇게 해커톤을 통해서 다양한 사람과 다양한 프로그래밍 ? 경험을 쌓는 것도 좋을 것 같다는 생각이 들었다.
Kaleido 팀 : Naver Kaleido팀에서 일한 후기를 남겨주셨습니다. 분산 처리 환경에서 데이터 공유를 위한 플랫폼인데, 이를 직접 구현하기 위해 * CRDT :에 대해 직접 학습하시고, 구현을 하셨다고 후기를 남겨 주셨다. 나도 잘 모르는 분야였다. 검색을 해 보았고, 굉장히 어려운 분야가 아닐까? 라는 생각을 하게 되었다. Vector Clock이나, Gossip Protocol에 대해서는 잘 모르는데, 확실히 그런 느낌을 받긴 했다. "과연 나는 내가 모르는 분야에서도 논문과 지식을 잘 쌓아서 바로 바로 구현을 할 수 있을까?" 그럴려면, 아무래도 미리미리 기초를 잘 공부 해 둬야 할 것 같다.
내 맘대로 위클리 뉴스 - 2019년 20주(2019.5.13 - 2019.5.19) : Python, Java, JavaScript 관련한 아티클이 정리 되어 있는데, 이번에는 대부분 Google I/O의 아티클이 인기 였다. 그런데, 가장 관심 가는 부분은 Vue.js를 통해 jQuery를 대체 하고자 하는 분들에게 추천이라는 아티클이 인상적이었다. 개인적으로나마 Vue.js를 써보고 싶긴 한데, 시간이 정말 여유가 없어서 아쉽다.
(Troubleshooting) 레디스 사망일기 : 세션이 빈번하게 삭제 되면, 사용자의 불편함이 있긴 하겠지만, 너무 긴 만료 정책이나 불필요하게 적재 하다보면 큰 부담으로 떠안게 될 수 있으니, Redis를 운영하거나 할 때는 조심하는 것이 좋겠다는 생각입니다.
기획자와 개발자 간 절대 하지 않아야 할 말들 : 제목만 봐도 대강 무슨 내용인지 알 수 있겠지만, 실제로 저런 말들이 오고 간다. 그러니 절대 이러한 말들을 삼가도록 하자. “기획자와 개발자 사이는 개와 고양이라지만, 우린 사람이다. 서로 존중하면 틀어질 일이 없다고 생각한다. 물론, 상대방이 나를 존중 하지 않는데, 나는 존중 하기란 쉽지 않다.” 라고 생각 하는 편이다.
스포카에서는 어떻게 리모트, 플렉서블 근무를 할까 : 스포카에서는 Remote Working을 지원하기 위해 다양한 툴들을 통해 업무를 하고 있다는 것을 알 수 있었다. 특히, Slack Bot을 정말 잘 활용한 부분은 근무 봇들이 아침마다 공지로 누가 리모트 근무를 하는지 알려준다는 점이다. 그리고 Zapier를 잘 쓰고 있는 것 같다. 나는 IFTTT를 쓰고 있었는데, 훨씬 더 좋은지 경험을 하기 위해 한 번 써보고 싶다는 생각을 했다.

vim

Vim, 두 가지 관점 : 솔직히 나는 Hard한 Vim 유저는 아니다. 그렇게 VIM을 잘 쓰는 것도 아니고, 그냥 켜고, 끄는 법은 안다. 그리고 적당한 이동키를 아는 것뿐.. 물론, 좀 더 잘 하고 싶긴 하지만, 순수 VIM 유저도 아니고, SpaceVim을 주로 쓴다. 물론, NeoVim 기반이긴 하다. 그럼에도 불구하고, Vim을 잘 쓰고 싶은 니즈는 강하다. 물론, 요즘 일하느라 시간이 없어서 Practice Vim 책을 못보고 있어서 그렇지. 꼭 완독을 하고자 하는 목표는 있다. 그렇지만, 사용하게 되면 알 수 있는 Vim의 매력이 있다. 특히, 조금만 암기해도 응용 가능한 조합의 수가 정말 많다.
내게 실용적이었던 프로그래밍 공부 방법들 : 자신의 공부 방법과 어떤 사이트를 주로 활용 하는지를 소개 하고 있어서 다른 개발자들도 읽어보면 좋겠다. 그리고 자신들의 공부 방법과 어떤 사이트를 주로 참고 하는지도 공유가 잘 되면, 다른 개발자들도 공부하는데 도움이 되지 않을까? 라는 생각이 들었다. 나도 브런치에 개발력 높이는 세번째 글을 쓸 때가 온 것 일까?
Kafka Consumer Lag 모니터링, Burrow를 알아보자 (1) : Kafka의 Consumer Lag 모니터링 툴인 Burrow에 대한 소개글입니다. 아마, 카프카를 쓴다면, 컨슈머나 브로커의 실제 메시지의 데이터나, Lag의 모니터링을 하고 싶어하는 니즈가 생기기 마련인데, Consumer Lag을 모니터링 할 수 있는 툴이 있었구나 싶어 사용하기 괜찮구나 싶은 생각이 들었다. 그렇지만, 내가 속한 팀에서는 두 가지의 툴을 사용하고 있어서 아직까지는 괜찮다는 생각이다. Kafka manager를 보통 많이 쓰는데, kafka-webview라는 툴도 상당히 좋다. 실제 메세지의 데이터를 볼 수 있다.
입사 후, 벌써 1년 - 우아한형제들 기술 블로그 : 우아한형제들에서 1년간 일하면서 느낀 회고를 남겨 주셨는데, 기술에 대한 목마름이 있었고, 스스로 SI를 벗어나 기술 기반 회사로 가야겠다는 생각을 하신 점이 참 용기 있으시고, 자기 계발을 참 열심히 하신 분이 아닐까? 라는 생각을 했습니다. 읽으면서 많이 반성 했습니다. 물론 저도 모르는 기술이 많습니다. 앞으로 배워야 할 지식들이 산 더미 같군요.. :(
코딩 스타일에 대해 논쟁하는 이유 - Mimul’s Developer World : 코딩 스타일에 관해서 설명하고 있으며, 왜 논쟁 하는지? 에 대한 이유를 서술하신 글입니다. 사실 이 부분은 팀으로 합의가 되어야 하는 부분이 많기에, 개인적인 편의성 보다 어떻게 하면 협업을 잘 할 수 있는 코딩 스타일을 가져갈 것인지? 팀 내 합의를 어떻게 이룰 것인지?에 대한 부분을 잘 고려해야 한다는 것이 중요하다.

일반적으로 도움이 되는

연봉을 올리기 위한 5가지 준비물 : 그냥 가볍게 읽어보고, 나한테 적용해야 할 부분이 있다면 적용 해보는 것도 좋겠습니다…:) (많이 받으면 좋잖아요.)

React

React’s useReducer vs Redux - RWieruch : 어떻게 둘 사이가 다른지? 그리고 어떤 점에서 다른지를 설명하고 있는 글이며, 전반적인 흐름만 이해하셔도 됩니다.
What are Reusable Components in React? - RWieruch : Button을 예로 들면서, Button을 다른 컴포넌트로 뽑아내어, 재활용하는 방법을 설명하면서 어떻게 재사용 가능한 컴포넌트를 만드는지 설명하고 있습니다. (실제로는 이렇게 단순하지 않습니다.)
How to useState in React? - RWieruch : React에서 useState를 어떻게 사용하는지 설명하고 있습니다. 그런데, 사실 저도 어떻게 Hooks를 가능케 했는지 원리에 대해서는 궁금해하지 않았습니다. 생각해보니 16.x 에서 React는 정말 많은 발전을 했다고 생각이 듭니다. React에서 Hook을 어떻게 처리 하는지 한 번 찾아 봐야겠습니다.
What is preventDefault() in React? - RWieruch : preventDefault()가 무엇인지?에 대해서 설명하며, Form Element에서의 예시를 통해 preventDefault 가 어떤 동작을 의미 하고, 과거에는 왜 그렇게 사용 했는지? 현재는 어떻게 사용 하는지? 에 대해서 설명을 하고 있습니다.

그냥 저냥 #위클리뉴스 #41

Sun, 26 May 2019 21:14:00 GMT

그냥 저냥 #위클리뉴스 #41

Java

Jedis 보다 Lettuce 를 쓰자 : 이 부분에 있어서 동의하는 점이 많은게, Jedis는 일단 유지보수가 굉장히 느리고, 오픈소스이더라도 어떤 커미터들의 순환 구조가 있어야 하는데, 그게 좀 부족하지 않나 생각한다. 이슈에 대응도 느리고 해서 필요하다면, 프로젝트를 fork 해서 직접 수정해서 사용해야 하는 수준으로 업데이트 지원이 느리다. 그에 반해 Lettuce는 Spring project에서도 내부적으로 많이 사용하고 있고, 메모리 누수 이슈 문제도 빠른 업데이트로 대응 되고 문제점에 대해서 굉장히 빠르게 업데이트와 피드백을 준다.
자바의 GC 가비지 콜렉션 알고리즘 : Java의 GC의 방식들에 대해 요점만 잘 정리가 되어었다. 실제로 대부분의 웹 서버들은 G1 GC를 사용할 것 같은데, ElasticSearch에서는 G1 GC를 사용하면 제대로 효율이 나오지 않아, CMS GC를 사용한다고 본 것 같다. 그런데, 이제 ZGC가 나와서 JDK12를 사용할 때쯤에는 고려를 해볼 것 같다. 다른 분들은 어떤 옵션을 사용하는지 궁금하다.
[Java/Algorithm] 자바 JVM에 대하여 : Java의 전반적인 내부 흐름을 설명하면서, JVM, JRE등 용어에 대해서도 상세하게 설명을 하고 있어서 재밌게 읽었다. 그리고, GC와 관련해서 정말 자세하게 설명을 하고 있는데, 생각보다 어려울 수 있으니 주의할 것!
[IntelliJ] intellij 유용한 단축키 정리 - Heee’s Development Blog : Java 개발을 하는 사람들은 보통 2가지의 IDE를 사용하는데, IntelliJ를 요즘은 좀 더 많이 사용하는 추세이다. 나도 사용중인데, 정말 편하고, 특히 git merge가 정말 좋다. (3 way diff를 제공하기 때문에 정말 좋습니다.) IntelliJ의 단축키를 소개하고 계신데, jojoldu님의 인프런 강의를 보시고 정리해두신 것이다. 해당 IDE를 잘 쓰고 싶다면, 인프런 강의를 직접 보는 것도 정말 좋겠다.
Spring Security 아키텍쳐: 대부분 웹 개발을 하다 보면, 인증 관련해서 막막해질 떄가 오는데, 그럴 때, Srping Sercurity가 제일 강력하고 편하게 다가갈 수 있는 것 같고, 그럴때 필요한 내용이 바로 이 글이라고 생각 했다.
[OKKYCON: 2018] 박재성 - 의식적인 연습으로 TDD, 리팩토링 연습하기 : 세미나 영상을 들으면서 느낀 점은 결국에는 작게 시작하라는 말이 참 와닿는다. TDD를 안하다가 실제로 업무에서 하려고 하면 막막할 때가 있긴 하다. 테스트를 빠르게 작성할 수 있도록 테스트 설정이 잘 되어 있어야 한다는 점도 항상 느끼는 바이다. 그리고, 책 소개가 나오는데, 클린 코드란 책을 아직 읽어보진 않았는데, E-book으로 사서 봐야겠다. 그리고, 소트웍스앤솔러지라는 책도 괜찮은 책인 것 같다. 그나저나, 켄트벡의 TDD 책도 절반 보다 말았는데, 다시 정독을 해야겠다.
[OKKYCON: 2018] 정진욱 - 테스트하기 쉬운 코드로 개발하기: 테스트 하기 쉬운 코드와 테스트 하기 어려운 코드의 분리라는 중요한 포인트를 알게 되었다. 중요해보이지 않을 수 있지만, 결국 본질은 크게 다르지 않다는 것을 얻을 수 있었다. 부수효과를 없애는 방법도, 테스트 하기 쉽게 코드를 작성 하는 방법도 결국 한 가지의 목표를 통해 나타난 결과가 아닐까? 하는 생각을 하게 되었다. 테스트 하기 어려운 코드도 어렵다는 것이지, 불가능한 것은 아니다. 그리고 행위 테스트 vs 검증 테스트 둘 사이의 차이가 있다. 어떤 것을 우선 할지는 개개인의 방향에 따라 다를 것 같은데, Mockist vs Classicist 어떤 방향으로 갈지는 개인의 선택에 따라 좌우 될 것 같다.

Kube

쿠버네티스 시작하기 - 쿠버네티스란 무엇인가? : subicura님의 도커 관련 시리즈도 정말 재밌게 읽은 기억이 있고, 잘 정리를 해주셨는데, 이번에는 k8s의 시리즈를 시작 하셨다. 쿠버네티스가 어떻게 동작하는지? 어떠한 요소들이 있는지 정말 자세하게 설명하고 있다.

JavaScript

재사용 가능한 코드 개발: "재사용 코드 필요는 요구사항을 분석할 때 인지된다.", 재사용 코드는 인지가 되는 시점에 개발되지 않으면 중복 코드를 발생하게 된다.이 말이 가장 와닿는다. 결국에는 자신과의 싸움이다. 내가 이렇게 이번에는 넘어가고 다음에 리팩토링을 할 것인지? 아니면 재사용하도록 코드를 작성할지?의 갈림길에 놓이는 순간이 서비스를 하다보면 꼭 오긴 한다. 그럴때 어떻게 대처를 해야 프로가 되는 길일까? 고민이 생긴다.
async await 정리: 비동기 프로그래밍을 우리가 흔히 아는 동기식 코드로 바꿔 준 녀석이 바로 async/await 아닐까 한다. 기존 Promise pattern의 한계를 바꿔 개발자들에게 편리한 비동기 프로그래밍을 할 수 있게 해주었다. 사용해본 적이 없다면, 어렵지도 않고, 쉽게 케이스별로 코드로 설명을 하는 이 글을 읽고 사용해 보는 것도 좋을 것 같다.
[OKKYCON: 2018] 이혜승 - 테알못 신입은 어떻게 테스트를 시작했을까?: 확실히 중요한 부분은 테스트를 잘 작성해야 한다는 점이다. 이번에는 테스트 관련해서 세미나 영상을 많이 접했는데, 주요한 점은 단 하나이다. 결국에는 테스트를 위해서는 코드의 적절한 분리가 중요하고, 테스트 하기 쉬운 코드는 결국 읽기 좋은 코드가 된다는 점을 깨달았다. 그리고, 선순환의 습관화가 가장 중요하다!! 사실, 그게 TDD가 아닐까 한다. TDD에서 가장 중요한 점은 테스트와 개발자의 선순환 구조를 만드는 것을 습관으로 가지는 것이 아닐까 한다.
Lodash-es vs individual Lodash utilities: Size comparison: 요즘 업무에서 사용하고자 하려고 하는데, 용량이 생각보다 중요하다. Production에서 Bundling size는 서비스 전반에 걸쳐서 영향을 준다. 그래서 특정 라이브러리를 사용하는데, 용량을 많이 차지 하면, 좋지 않다. 그래서 최근에 뜨는 것이 lodash-es 로 벤치마크를 보면, 사용하는 유틸이 많을 수록 훨씬 유리하다.
The Correct Way to Import Lodash Libraries - A Benchmark : 위의 내용과 비슷하며, lodash babel plugin도 설명하고 있어서 lodash를 사용하신다면, 2개의 글을 읽어보시는 것을 추천 드린다.
[좌충우돌] 앗! 리액트 + 하이차트로 차트를 그렸는데 차트가 갱신이 안되네!?: highcharts 를 많이 사용하는데, 요즘은 오픈소스 차트 라이브러리를 많이 사용하기도 한다. 그런데, React 환경에서 하이차트를 사용해야 한다면, 어떻게 해야 할까? 문제는 없을까? 그런 고민을 하던 와중에 차트 갱신 오류 문제를 겪었던 분이 경험기를 남겨주셨다.

Python

청년 고득녕 (2014~) : 네이버 블로그: 왜 파이썬을 해야 하는지 소개한다. 그런데, 이 글의 내용을 정말 쉽게 전체 받아들이면 위험하다. 결국에는 목적성이 있어야 하는 건데, 다 하니까 나도 해야지라고 생각하기엔 우리들의 시간은 집중력 있게 학습 하는 시간도 부족하다.

개발자에게 도움이 되는

[번역] 빠른 개발을 위한 기술 - 1: 30분은 좋은정도지만, 2시간을 오롯이 집중하는건 아주 훌륭한 일입니다. 그 주에 따라 다르지만 저는 아마 매일 3~4시간정도 이런 시간을 가집니다.보통 오전 9시 30분부터 11시 30분까지 일이 잘 되더군요. 캘린더에 ‘집중 근무 시간’ 같은 일정을 등록해둘 수도 있습니다. 이런 생산성 관련한 글이 정말 좋다. 나도 항상 생각하는 거지만, 집중 하기가 어려운 환경에서 일을 하고 있다고 생각하는편인데, 그럼에도 우리는 집중력을 필요로 한다. 그런 관점에서 딥워크라는 책을 읽어보면 좋겠다 싶은 생각이 들었다. 그리고 내 개인적인 경험으로는 ASMR이라고 하는데, 핸드폰으로 자연관련 소리를 듣는게 집중력을 향상하는게 좋았다. 특히 Tide App이 좋았다.
[번역] 빠른 개발을 위한 기술 - 2: ‘수 년 동안 모든 브랜치에서 셀프 코드 리뷰를 하면서 80%는 무언가 고쳐야 할 부분을 찾아냈습니다. 보통은 동료가 금새 찾아낼 법한 바보같은 실수인데, 만약 동료가 PR에 코멘트를 남기면 저는 그 부분을 읽고 고친 다음, ‘fixed’ 같은 커밋을 한 뒤 동료들에게 다시 브랜치를 리뷰할 상태가 되었다고 알려야 하죠. 이런 실수를 직접 찾게 되면 엄청난 양의 시간을 절약할 수 있습니다.이러한 실수를 하지 않으면 좋겠지만, 생각보다 잦은 실수를 하는 때에는 내 경험상 휴식을 취하는 것도 좋았다. 나도 내일부터는 Self Review를 해야겠다. 특히 좋은 부분은오랜 시간동안 매일 처음 한 시간은 읽기에 투자하면서, 제가 제일 헤메던 부분에 대한 글을 중심으로 읽고 있습니다. 보통 오전 7시에 일어난다 치면 오전 8시까지 읽습니다. 빠짐없이요. 이 방법을 강력히 추천합니다. 문제를 해결하는 속도가 점점 빨라지는 것을 느낄 것이며, 계속 읽는 한 그 흐름도 이어질 것입니다.’ 나도 항상 느끼는 부분이라 요새는 아침 일찍 일어나서 활동 하려는 노력을 하고 있다. 한 달 정도 지나면, 아침에 일어나서 30분 정도 스펙을 읽고, 운동을 하고자 마음 먹었다! 아직 6개월이 남았기 때문에, 신년 계획을 수립해볼까 한다.
주니어의 짝코딩 경험기: 짝코딩에서는 가장 중요한 부분이 바로 이 부분이 아닐까 한다. "오랜 시간 집중 할 수 없을 수 있으니, 서로 상태를 체크해야 한다는 점이다." 지속적인 상태 체크로 짝코딩의 효율성을 증대하는 것은 가장 중요하다고 생각하는데, 나도 훗날 어느 정도의 실력이 쌓여 있을 때, 신입 개발자가 온다면, 한 달 정도는 짝코딩을 해보고 싶다. (물론, 상대가 싫어할 수도 있다는 점은 고려 해야 할 점이다.)
How to use redis well: Redis를 실제로 자체 구축해서 사용할 일이 거의 없을 수 있는데, AWS에서는 사실 쉽게 지원이 가능하기 때문이다. 실제로 구축해서 사용시에는 어떻게 구조를 가져갈 것인지? 부터가 정말 어렵다. 클러스터를 사용할지? Master-Slave 구조를 사용할지? 그런데, 강대명님 자료를 잘 찾아보면 유용한 자료가 참 많다. 그런데, Redis를 사용하기 위해서 사용하는 Client가 필요로한데, Redis v4.0을 jedis는 여전히 지원을 못하고 있다. lettuce는 Spring에서도 많이 사용하고 있기에 보장이 되고, 업데이트가 굉장히 빠르다.

그냥 저냥 #위클리뉴스 #40

Tue, 21 May 2019 01:04:00 GMT

그냥 저냥 #위클리뉴스 #40

일반적인

회사에서 인정받는 8가지 방법: 중요한 부분인데, 이 글에서 나온 부분을 내가 잘 못하고 있고 있는 것이 바로, “내가 했던 일들의 히스토리 남기기”이다. 과거에 내가 무슨 일을 했고, 어떻게 했는지를 잘 남겨두면, 나중에 내가 어떤 일들을 했고, 어떻게 했는지를 잘 남길 수 있는데, 그러한 것들을 잘 못했다. 그런 것들을 앞으로 좀 잘 할 수 있도록 해야겠다. 모든 사람에게 적용 될 만한 이야기라 직장인들이라면 읽어보길 추천한다.

Server

신입 개발자가 스타트업에서 AWS로 살아남는 이야기 - 조용진(모두의 캠퍼스): AWS를 아주 작은 범위로 서비스 하는 회사에 들어가 점진적으로 늘어나는 서비스에 대하여, AWS 스택을 늘리면서 많은 경험기를 담고 있으며, AWS Hacking에 대한 포스트모텀 후기까지 공유를 해주어, 많은 도움이 될 것이라 생각 한다. AWS를 잘 활용하는 것은 정말 편리하고 좋지만, 해킹 당하면 정말 위험하구나를 알려주어 경각심을 갖게 되었다.
마이크로 서비스 관련 글 총정리 : 이제까지 Popit에 올라 왔던 MSA 관련한 내용들의 집합인데, 주제별로 정리가 되어 있어서 참고하기 좋다.
KSUG 스프링캠프 2019 발표자료 - “무엇을 테스트할 것인가, 어떻게 테스트할 것인가”: 권용근님의 발표자료인데, 동영상이 올라오면 좋겠다는 생각을 하게 되었다. 하지만, 슬라이드만으로도 전달 하고자 하는 내용을 잘 알 수 있었다. 테스트에 관해서는 사실, 좀 “어렵다”라는 생각을 많이 가지고 있었다. 그렇지만, 이 자료를 보면서 알 수 있었던 사실 하나는 내가 주로 구현을 테스트 하고 있었다. 라는 사실을 깨달았다. 그리고, 테스트 가능한 부분과 가능하지 않은 외부요인들을 구분하지 않고 테스트 코드에 넣고 있었다는 사실을 깨달았다.
자바, 성능, 모니터링 테크세미나 정리 및 후기 (by 우아한 형제들) : 확실히 모니터링과 성능은 뗄려고 해도 뗄 수 없는 기생 관계라고 해야할까? 싶은 생각이 든다. Java 환경에서 APM 제품을 많이 알고 있진 않았는데, 굉장히 많은 제품들이 있다는 것을 깨달았고, 예전부터 관심 있던 Scouter의 기능이 생각보다 다양해서 Pinpoint의 기능보다 더 좋은 기능도 있다는 것을 알게 되었다. 물론,
웹 서버 개발의 Session 전략: Session에 관해서 보통은 잘 모르기 쉽고, 왜 메모리에 저장하는것이 문제가 되는지?, 파일로 저장하게 될 경우에는 어떤 문제가 있는지? 모를 수 있다. 하지만, 이에 대해서 잘 정리 되어 있어서 세션에 관해서 공부하기 좋다. 다만, 여러 환경이 있을 수 있기에 어떤 것이 정답인지는 알 수 없지만, 확실한 건 케이스 별로 잘 알고 있는 것이 중요하다.

Front

Why Performance Matters: 일단, “사용자들은 기다려주지 않는다.”는 말이 생각 났다. 실제로 통계적으로도 이탈률이나, 페이지 인입등에서 차이가 나기 시작한다는 것을 알 수 있다. 그러므로, 개발자들은 무엇을 할 수 있을지? 제안도 나열 되어 있다. 특히, React를 이제 막 써보는 입장이라 Preact에 관한 부분도 관심이 갔다. 대체제라면, 안 쓸 이유가 없기 때문이다.
[자바스크립트] 브라우저 렌더링: Browser가 어떻게 렌더링을 하는지에 대해서 단계적으로 설명을 하고 있으며, Reflow, Repaint이 어떻게 이루어지는지? 어떻게 하면서 Reflow 발생을 줄일 수 있는지에 대해서 설명하고 있다.

Java

cheese10yun/blog-sample: Java의 Checked Exception에 관한 글이다. Checked Exception에 관해서 설명을 하고 있으며, Unchecked Exception과의 비교를 통해 설명 하고 있다. 특히, Checked Exception은 Rollback을 하지 않는 다는 점을 기억하면 좋을 것 같다.
Wan Blog: Servlet Container에 관한 글인데, 읽다 보니 나도 잘 모르는 부분이 있었다. Spring Container가 구동 되는 시점에 이미 Bean으로 등록한 Object들이 생성 되는 점인데, 해당 부분은 모르던 내용이었다. 역시, Spring framework의 세계는 놀랍다.
Spring Boot - Logging, 20분 정리: Spring boot에서 logging에 관하여 궁금하다면, 해당 아티클을 읽어보자. Logback을 사용하는데, 요즘은 log4j2 또한 logback 처럼 성능이 좋다고 들었다. 그래서 log4j를 제외하고, logback, log4j2를 취사선택해 사용하면 좋을 것 같다.
쓰레드풀 과 ForkJoinPool: Thread에 관해서 읽어보면 어떻게 동작하는지? 쉽게 그림으로 그려서 설명을 하고 있습니다. 더불어 Java7에서 나타난 ForkJoin Framework에 대해서 상세하게 설명을 해주어, 쉽고 빠르게 이해 할 수 있습니다.

개발자에게 도움이 되는

괜찮은 프론트 개발자: 도대체 어떤 업무를 해야 하는가?에 대해 궁금한 사람이 많을 수 있다고 생각한다. 프론트 개발자는 어느 부분까지 일 해야 하는 사람일까? 그런데, 이 글을 읽고 생각해보자. 프론트의 영역은 어디까지 일까? 내가 직접 코드를 짜야 나의 영역이 아니라, 그 이상의 영역에도 기본적인 지식을 있어야 한다는 생각과 같은 분의 글이라서 재밌게 읽었다.
흔하지 않고 좋은 웹 개발자가 되는 방법: 정말 열정이 많으시고, 공유도 많이 하시는 Captain Pangyo님의 어떻게 하면, 좋은 개발자가 되는지에 대한 글입니다. 단계별로 설명을 해주시면서, 개인적인 경험 또한 녹아 있습니다.
문서화에 대해 아무도 말해주지 않는 것들 - 이상한모임: 이 글을 읽을 사람들은 대부분 API 명세를 작업 해봤거나, 작게나마 라이브러리를 만들었던 사람들이 읽으면 훨씬 더 얻는 게 많을 것 같다. 일반적인 문서화라기보다는 코드 관련한 설명을 해야하고, 초기 시작 문서등을 작성해야 하는 사람들이 읽으면 더 좋을 것 같습니다. 하지만, 시간이 난다면, 반드시 읽어야 하는 문서화의 가이드를 제시 하고 있는 글입니다.
101 Bash Commands and Tips for Beginners to Experts: Bash를 많이 쓰는 터라, 해당 글을 보자 마자 읽어 보았고, 제가 쓰던 기능들도 있지만, 알지 못했던 기능들도 있습니다. ncdu,htop, locate등 몰랐던 명령어들이 많습니다.
나는 왜 회사를 즐겁게 다니고 있나?: 읽으면서 좋은 점이 많은 문화를 가졌다고 생각했습니다. 아프면 쉬어야 하고, 코드 리뷰는 개인의 인격에 대한 피드백이 아니다.라는 점들, 그리고 각기 모두 전문성을 가지고 있다는 점 또한 보기 좋았고, 저는 어떠한 전문성을 가지고 있는지? 없다면, 앞으로 어떻게 키워야 할지? 미래를 그리게 되었습니다.나는 현재 회사에서 무엇 때문에 즐거운지? 글로 써보는 시간을 할애하는 것도 좋겠다는 생각을 했습니다.
devJang/developer-roadmap: 개발자 로드맵의 한국어 버전입니다. 물론, 이 로드맵을 따라가야 하냐? 라는 질문에 있어서는 답변은 ? 입니다. 정해진 왕도는 없습니다. 빨리 갈 수 있는 길도 없고, 다만 방향이 있을 뿐이라 본인의 관심과 맞다면, 한 번 학습을 해보는 것도 좋겠다. 정도로 받아들이시면 좋겠습니다.
여러 git 리파지토리 한꺼번에 git 명령어 적용하기: 여러 Repository에 Git command를 실행시키기 위해 xargs 명령어를 이용하는 점이 참신하다고 생각 했습니다. 역시 한 가지를 잘 알고, 그것을 잘 이용하는 것도 방법입니다.

JavaScript

코드리뷰를 위한 좋은 코딩 - Javascript 편 - amati.io: 이 글을 읽으면서 코드 리뷰에 관한 부분이 참 좋았습니다. "코드에겐 불친절하게, 사람에겐 친절하게…" 라는 구절이 특히나 좋았습니다. 이 글을 읽으면서 계속 연습 해야 하는 부분이 PR의 사이즈를 줄이는 것입니다. 코드의 뭉텅이가 너무 크면, 리뷰가 불가능합니다. 그리고, 리뷰를 받는 것도 시간적인 딜레이가 생기는 일인데, 코드의 양이 많다 보면 훨씬 더 많은 시간이 필요로 한다는 것을 체험으로 깨달았습니다. 읽어보면, 대다수의 사람들의 생각이 결국 코드 가이드 라인들로 정립이 되어 코딩을 하게 된다는 것을 느낍니다. 개발을 같이 하는 사람들끼리 공통된 코드 가이드를 잘 정립하는 것은 좋습니다.

자료구조

아는만큼 Search tree: Tree 자료 구조 탐색하는 방법에 관한 정리 글이며, BST, Self-balancing BST, AVL tree, Splay tree, Treap, B-tree, Red-black tree, B+tree 까지 어떤 특징을 갖는지 정리 한 글이라 자료구조 공부하는 분들에게 좋습니다. 그런데, 제가 몰랐던 것들이 많아서..“아! 언제 또 공부를 해야 하나”라는 생각을 하긴 했습니다.
Data Structure and Algorithms (DSA) Tutorial: 기본적인 자료구조와 알고리즘에 관한 설명과 해법이 있습니다. 자료구조와 알고리즘을 공부하시는데 도움 될 것 같습니다. 특히, 처음 입문 하시는 분들이 읽어보시면 좋을 것 같습니다.

그냥 저냥 #위클리뉴스 #39

Mon, 15 Apr 2019 02:16:00 GMT

그냥 저냥 #위클리뉴스 #39

개발자에게 도움이 되는

비동기를 사랑하는 오픈소스 개발자, 이희승 - LINE ENGINEERING: 전 세계에서 한국인이 만든 오픈 소스를 사용한다는 일은 정말 멋진 일이라 생각한다. 그런데, 정말 많은 오픈 소스 프로젝트를 만드신 개발자로 널리 알려져 있는 이희승님의 인터뷰이다. Network 관련한 지식이 정말 깊으시다는 생각을 하게 된다. 그리고, Java 언어를 다루는 실력 또한…NIO 관련해서도 잘 쓰시는 분이라 생각 했다. 약간 플랫폼 장인? 실은 나도 꿈꾸는 바가 개발을 위한 플랫폼 개발이 꿈이긴 하다. (현재는 아직 플랫폼 개발이란건 선망의 대상으로 생각하는 편이다.) 그래서 플랫폼 개발에 관해서, 이희승님에 관해서 궁금하다면 읽어보면 좋겠다. 채용도 하고 계시니 지원해보면 좋을 듯 하다!
개발자 인생 회고 #1: 우연히 보게 된 글이지만, 오래전부터 개발을 해오신 분들의 이야기는 무척이나 재밌다. 뭔가 무협만화를 보는 것만 같은 기분이 든다. (내공이 막 3천갑자 쯤 되어 보인다.)
개발자 인생 회고 #2
개발자 면접 질문을 공개합니다: 룩핀이란 서비스를 운영하는 레벨13의 개발자 면접 질문에 대한 이야기이다. 왜 면접에 대한 질문들을 공개 하는가?에 대한 이야기인데, 지난번 소개 했던 Rails 서버 개발자와 이어지는 이야기이다. 이 회사가 추구하는 바가 어떤 기술이고, 우리는 현재 이 기술을 사용하고 있으며, 우리는 이런 기술력을 가진 사람을 원한다고 공개 구혼?과도 같은 글을 써주셨는데, 나는 오히려 이런 글이 이 회사를 매력적으로 만든다고 생각하는 편이다. 항상 어느 회사든지 잘?! 하는 개발자를 구하고자 하는데, 채용 페이지, 채용 전략, 채용 철학에 대해서는 깊이 생각하지 않는다. 우리는 이런 기술 쓰는데, 우대 사항은 이거 이거 이거등등, 이것도 해보면 좋고, 저것도 해보면 좋다. 라고 써 있다. (근데, 내가 만약 그 모든 기술에 전문가라면 그 회사 안 갈것이다.) 대부분의 취준생들은 우대사항을 보고 지원 하길 꺼려한다. (대부분의 회사에 있는 채용 페이지에 나온 그 정도의 기술 수준을 가지려면 경력 5년차에 미친듯이 개발 공부를 했어야 가능할 것이라 나는 생각한다.) 그런데, 이 회사는 마치 우린 정말 이런 기술을 사용하는데, 같이 사용해볼 개발자분이 있다면, 지원해주길! 바라는 마음에 썼다는 것이 느껴진다. (다른 회사의 채용 페이지를 유심히 보고 한 번 생각해보면 좋겠다.)
기획자는 어떻게 SQL을 공부할까 - WTM 2019 발표후기 - 이상한모임: 발표 영상도 링크에 추가 해주셨는데, 40분이라 다 듣지는 못했다. 발표자료를 보면 역시 고수이심이 틀림이 없다. (고퀄) 그런데, 일단 대단하다는 생각을 갖게 되었다. 어떻게 직접 하실 생각을 했을까? (혹시 이런 생각도 편견일지 모른다는 생각을 갖긴 했다.** 그렇지만, 뭔가 어?! 하는 생각이 들었고, 결국 IT라는 집합안에서 해야 하는 일들은 결국, 시작도 디지털이고, 끝도 디지털이라는 생각이 든다. 그런데, 대부분의 회사에서, 업무 영역에서 왜 디지털을 빼놓고 생각을 하는 것인가?라는 생각을 작년에 많이 생각 했다. 왜? 기획자는 쉽게 말을 할까? 왜? 개발자는 기획자가 말한 것 마다! *안된다!\*라고 해야 하는 걸까? 하는 일련의 어떤 것들을 생각하곤 했는데, 많은 반성과 나조차도 편견에 휩싸인 사람이지 않았나? 되돌아 보게 된다.
[B급 프로그래머] 4월 2주 소식(개발/관리도구, 고성능 서버/데이터베이스 부문): 자신만의 리액트를 만드는 가이드라는 번역글이 참 좋았고, 다른 글들도 유익 했으나, 모든 아티클을 읽어보진 못했다. 특히 요즘은 도커 관련해서 공부중이라 그런지, 도커 실행을 위한 10가지 옵션에 관한 아티클은 페이지를 저장해두었다. 다른 아티클도 유용한게 많아, 천천히 읽어볼 생각이다.
vim:tips [권남]: vim을 쓸 수록, 깨알팁들이 많이 필요로 한 도구가 아닐까? 내가 딱 필요한 그 때, 이런게 있어 하고 알려주는 그런게 필요로 한데, 케이스별로 정리가 되어 있다.

k8s

[Tip] 기억하기 위한 여러 팁들: 도커와 쿠베관련한 팁이 정리 되어 있다. 아직은 모르지만, 훗날 유용한 팁이 될 것 같아서 가져왔다.
162. [Kubernetes] 1편 : 쿠버네티스 Ingress 개념 및 사용 방법, 온-프레미스 환경에서 Ingress 구축하기: Ingress관련한 설명과 예시 중심으로 소개를 하고 있어, 쉽게 이해 할 수 있다.

Java

Top 20 System Design Interview Questions for Java Programmers - DZone Java: 작은 개념의 시스템 디자인부터 큰 규모의 앱(어플리케이션)까지의 시스템 디자인에 관한 인터뷰 질문 모음이다. 생각해보면, 이런 질문들이 많이 오고가기 때문에 준비를 해두면 좋겠다. (Solution이 있는 질문도 있다.)
Spring Boot JPA MySQL Example: JPA를 써보지 않아서, 공부하고자 가져왔는데, 차례 차례 설명하고 있다. 쉽게 말하면, 튜토리얼이라고 생각하면 편하다. 글에서는 이클립스를 기준으로 설명하는데, IntelliJ를 사용한다면, Postman을 쓸 필요 없이 Idea에 있는 HTTP Request를 이용하면 좋겠다. :)
How Servlets Work in Java - DZone Java
10 Books Java Developers Should Read in 2019 - DZone Java: 올 해에 읽으면 좋을 책 10권을 소개하는데, 이펙티브 자바 3판을 무려 샀지만, 몇 개월째 읽지 못하고 있다. 그 책이라도 읽으면 올해 1/10은 한셈이지 않을까?
Java 8 Optional In Depth Example: Optional에 대해서도 뭔가 공부를 많이 해보고 싶긴 하다. 사실, 잘 써볼려고 노력하는 것 중 하나가 실무 프로젝트에서 null을 안쓰려고 하는데, 생각보다 쉽지 않았다. 해당 글은 Optional에 대해서 케이스별로 구분해서 예시 기반으로 설명을 한다. 그렇지만, 깔끔한 코드 베이스 상황에서는 사용하기 편리하지만, 기존 코드가 깔린 상황에선 사용하기가 난해하다. (아직 허접이라 그렇다.)

JavaScript

TypeScript and React: Hooks: 유요한 Hook들의 TypeScript 버전이라고 생각하면 좋겠다. 코드로 비교를 하기 때문에 위/아래 비교하면서 학습하면 좋을 것 같다.
[함수형 자바스크립트] 1.함수형 자바스크립트: 함수형에 관해서 소개를 하고, 설명을 하는 데, 함수형 프로그래밍은 사실, 분해와 합성의 상호 작용이라고 할 수 있다.라고 표현한 부분이 모호하던 함수형 프로그래밍에 정의를 내려주었다. 그리고 최대한 단순하게 만들자!는 것에 대해서는 정말 동의한다.
[함수형 자바스크립트]2. 고계 자바스크립트: 함수와 고계에 관한 설명을 해주는데, 간결하게 설명을 잘 해서 이해하기 쉽다.
[함수형 자바스크립트]3. 자료구조는 적게, 일은 많이: 함수형에서 많이 사용하게 될 함수이자 개념을 소개하고 있는데, map, reduce, filter에 대해 한국어로 잘 빗대어 표현 했다. 찰떡 같은 설명이었다.
Hello Nestjs: nest라는 프레임워크인데, 사실 너무 생소한 프레임워크라 잘 몰라서 공부해보고 싶은 생각이 문득 들었다. 애초 설계부터 프레임워크였고, 구조 자체가 스프링 MVC프레임워크와 유사해서 쉽게 배울 수 있을 것 같다. (간단한 경우 nest를 사용해볼까 싶은..?) 일단, 뭘 좀 써봐야 알 것 같다. 과연, Koa에 상응하는 수준일지 궁금하다.

React

React State with Hooks: useReducer, useState, useContext - RWieruch: 단점이 영어라는 것만 빼면, 좋은 Hooks와 상태에 관한 글인데, 나조차도 한번에 모두 이해하지 못했다. 그렇지만, 읽어보면 use__에 대한 함수들의 역할과 기능을 이해하는데 도움이 된다.
React Styled Components Tutorial - RWieruch: 아직 실무에서 써보진 않았지만, 사실 이 방법이 더 좋아보이긴 하다. 오히려 리액트와 잘 어울리는 개념이 아닐까? 생각하게 된다. 차례 차례 한 단계씩 설명하고 있고, 코드도 모두 포함 되어 있다.

Server

Hyeseong’s Blog - (번역) Thinking in GraphQL: GraphQL이 어떤 것인지? 감을 잡기 위해서는 이 글을 읽어보면 좋을 것 같다. 정말 몇년 전만 하더라도, 뜬구름 잡는다는 말을 많이 들었던 기술인데, 이제는 표준이 되려고 하고 있는 시대에 와 있다고 생각하고, 나조차도..REST는 실제로 구현하는데에 한계와 제한점이 많다고 생각하고, (네트워크 효율을 위한 모델이지, C-S 구조에서 효율성을 극대화했을 뿐, 유용성은 거의 제로에 가깝지 않나?라고 생각하는 편이다.) 대체제로 나온 기술인데, 한 번쯤 무엇인지 잠시나마라도 읽어보면 좋겠다.

일반적인

행복은 불행을 들여다보는 능력: “사회심리학자 바네사 부오트는 행복이 언제나 즐겁고 명랑한 상태가 아니라, 불행을 여러 방향에서 들여다보는 능력이라고 말합니다.” 이 말이 정말 확 와닿는 이야기였다. 행복이란 마냥 행복한 것이 아니고, 불행에서도 행복을 찾는다는 말을 보게 되니 진짜 행복이라는 것은 뭔가 연계성이 있는 것 같다는 생각이 들었다. 마음의 해상도를 높이고, 마음챙김을 함으로써 나의 행복감을 자주 찾을 수 있게 만들어주는 것이 삶을 살아가는데 정말 많은 도움이 될 것이라 생각 한다.
구글이 목표를 달성하는 방식 OKR: OKR이라는 것을 이용해 목표를 이루는 방식이고, 평가하는 것인데, 상당히 좋은 것 같아서 나도 이 책을 읽어볼까 싶기도 했다. (아직은 독서해야 할 책이 넘친다.) 그런데, 이 책을 읽고 나면, 더 빠른 목표를 이루는 방법이 될 것 같아. E-book을 찾게 되었다. 그 정도로 이 아티클에서 해당 주제를 잘 설명했다…(강제 독서행이 될 것만 같다.)
사업으로 돈 버는 방법에 관하여: 본인은 원천징수(프리랜서)와 세금계산서(개인사업자)를 병행하면서, 법인을 직접 관리하지는 않고 다른 안정적인 법인의 지분을 갖고 이사진으로 활동 이 방법이 최고라고는 하는데, 이 방법을 어떻게 하는 건지는 왜 안알려주는건가…하, 괜히 더 우울해졌다.

Data

새로운 데이터 분석가와의 랑데부를 위하여(2): 데이터 분석을 하기 위해 공부를 하고 계신 분들이라면, 꼬젯님의 블로그를 열심히 보다 보면, 많은 통찰력을 얻을 수 있지 않을까?라는 생각을 하게 된다. 이 글에서도 시니어 분석가의 이야기가 잠깐 나오지만, 신입들의 언급이 잠시 나온다?! 그런데, 이 부분이 신입들에게는 엄청 중요하지 않을까 싶다. 같이 일 할 사람을 잘 구하는 것은 어려운데, 이 글에서 얻을 수 있는 것은 데이터 분석가라는 직업 자체가 사실, 나 조차도 조금은 생소하며, 항상 이 업무 역할의 전문가가 같이 일 했으면 하지만, 진짜 하늘의 별따기라는 것을 알게 된다. 글 읽는 내내 뭔가 난 과연 같이 일하는 사람들과 랑데부가 좋은지?! 갑자기 또 우울한 고민에 빠지기 시작 했다. (일단, 개발자들도 읽어보면 도움이 되리라 생각한다.)

그냥 저냥 #위클리뉴스 #38

Sat, 06 Apr 2019 23:06:00 GMT

파일럿 프로젝트를 통한 배치경험기! - 우아한형제들 기술 블로그: 우아한 형제들에서 일하게 된 신입 개발자가 겪은 Batch 개발에 관한 이야기인데, 주니어 개발자들이 읽기에 좋다고 생각하는데, 그 이유는 유성님이 어떻게 개발해야할지? 잘 쪼개어둔 점을 볼 수 있다는 점이 좋다고 생각한다. 학생이신 분들 혹은 신입 개발자들이 Batch Job은 어떻게 구성해야 하는지에 관해서 알 수 있는 글이고, 쉽게 정리가 되어 있다.
일급 컬렉션 (First Class Collection)의 소개와 써야할 이유: Java 관련 글을 많이 써주시는 동욱님인데, 이번 글은 정말 필히 읽어야 한다고 생각하는게, 객체지향관점에서도 이렇게 프로그래밍 하는 것이 더 좋구나!를 느끼게 해준다는 점이다. 그리고 Java의 final은 재할당을 막는다는 사실을 다시 한 번 깨닫게 된다. (불변이 아니라는 것에 밑줄! 돼지꼬리 땡땡!) 나도 놓치고 있던 일급 컬렉션은 개발 할 때, 진짜 좋은 방법이라고 생각하게 되었다.
OKKY | 초보가 이해하는 스프링 시큐리티: 예전에 잠깐 살펴 본 느낌은 생각보다 적용하기 어려운 느낌을 받게 해준 스프링 시큐리티! 그런데, 잠만보라는 글쓴이분께서 정말 세세하게 설명을 해주시면서 어떻게 적용해야 하는지 정리 해주신 글이다.

Node.js

nodejs의 내부 동작 원리 (libuv, 이벤트루프, 워커쓰레드, 비동기): 노드의 이벤트 루프에 관한 이야기인데, 정말 세세하게 코드까지 직접 분석하셔서 쓰신 글이다. libuv와 같은 어려운 커널 함수관련해서 쉽게 설명하고 계신다. 그리고 실제 노드 소스코드의 코어부분을 말씀하시면서 파일시스템 관련해서도 진짜 비동기인지? 아닌지?에 대해 설명해주신다. (정말, 깊은 지식을 가지신 분이라 생각이 들었다.)

JavaScript

JavaScript(jQuery) - position sticky IE polyfill(폴리필) 방법: position: sticky에 관련한 내용인데, 손쉽게 적용하는 방법을 알 수 있고, ES6의 방법, jQuery를 이용한 코드도 소개하고 있다.

React

5 React Performance Tips: 이미 많은 사람들이 알고 있는 팁들이지만, React.Memo는 사실 잘 몰랐던 기능인데, PureComponent와 동일한데, 함수 컴포넌트로 생각하면 될 것 같다. 그리고, 그 외에 React.lazy가 인상깊다.

일반적인

토스, 유니콘에서 데카콘으로 가는 교차로에 서다: 가만히 생각해보면, 토스를 지휘하는 대표의 비전이 참 명확하고, 철두철미하다는 생각을 하게 된다. 쉽지 않은 상황이 있어도 꾸준하게 밀어 붙이고, 준비함으로써 송금의 편리성을 가져다 준 기업이자, 핀테크의 시발점을 만들어낸 회사가 아닌가?라는 생각을 하게 만든다. 그런데, 이제는 토스뱅크 컨소시엄을 구축한다고 한다. 과연 이 컨소시엄이 얼마나 큰 영향력을 행사하고, 또 다른 Bank Culture를 만들어나갈지 궁금해진다. 물론 토스가 디자인에도 관심을 많이 쓰고, 좋은 편리성을 가져다 주는 점에서 대표의 비전이 명확해서 토스라는 회사가 어떻게 앞으로 발전할지 궁금해진다. 토스와 토스 뱅크 모두 핀테크의 주춧돌이 되어 가지 않을까? 생각하게 된다.

개발자에게 도움이 되는

[번역] 웹 아키텍쳐 입문: 기본적인 아키텍쳐의 내용이고, 개발자라면 알아야 하는 지식이라고 할 수 있으나, 잘 모르는 지식도 분명 있다고 본다. Job Queue의 개념이라던지? CDN이라던지?하는 구조말이다. 읽어보면 도움이 된다.
SI 개발자, 불나방이 되거나 자토이치가 되거나: SI/SM에서 내가 일하느냐가 중요한것이 아니라 내가 어떤 사람으로 영향력을 행사할 수 있을까?에 대해 초점을 맞춰야 한다고 생각하는 편인데, 이 글을 쓰신 분과 동일한 생각을 가지고 있다. 이 본문에 나오는 말중에 결국 어디서 일하건 중요한 것은 여러가지 제약 사항속에서도 스스로를 갈고 닦고 부단한 노력을 통해 자토이치처럼, 네임드라 칭해도 될 만큼 뛰어난 개발자를 드물긴 하지만 봤다이 문장이 제일 중요하지 않을까 생각한다. 결국 내가 성장하는데 내가 속한 곳이 무엇이 얼마나 중요할까?라는 생각을 하게 된다. 특히나 주니어 개발자계의 네임드 창천향로님이신 이동욱님도 부단한 노력 끝에 지금 현재의 회사에서 일을 하고 계시고, 어떻게 이직을 했는지?에 대해서도 상세하게 글을 써주셨다. 간절함과 노력은 결코 당신을 배신하지 않는다.
알고리즘 공부, 어떻게 해야하나요?: 알고리즘 공부를 어떻게 해야 할지? 갈피조차 잡지 못하는 사람들이 읽어보면 좋을 글이다.
해외 취업 - 신입 웹 개발자의 싱가포르 상륙기: 본래 개발자가 아니셨으나, 개발에 관심이 많으셨던 이수진님의 개발자 해외 취업기에 대한 후기글이다. 수진님은 원래 블로그를 통해 개발 관련 영문서들을 많이 번역해주셨다. 그리고 이제는 개발자로써 일하시게 되었는데, 역시..영어를 잘하셔서 그런지..바로 해외 취업을 하셨다. 개발을 꼭 학교에서만 배워야 하는 것은 아니라는 생각이 들었다. 그저 노력과 관심도의 차이일뿐인 것이다.
개념 정리 - (7) 운영 체제편: 대학교의 운영체제 수업을 들어본 사람들은 많이 봤을법한 내용과 유닉스 프로그래밍 수업을 들으면 알 수 있는 내용까지 총망라하여 운영체제, 파일시스템등에 관한 내용을 상세하게 정리 해두 신 글이다.
캐시가 동작하는 아주 구체적인 원리: 글 쓰신 분이 상당히 유명하신 분인데, 글을 정리 한 것 또한 정말 기가 막히게 정리를 잘 해주셨다. 캐시에 관련한 컴퓨터 구조 관점에서의 정리 글인데, 캐시 히트, 캐시 미스등 용어설명과 어떻게 캐시가 동작하는 지에 대한 설명과 함께 그림으로 설명을 함으로써 쉽게 이해가 가능하다.
[번역]쉬운 테스트 주도 개발과 단위 테스트를 위한 5단계 방법론: 테스트 주도 개발은 생각보다 어려운 일이 아닐 수 있다. 우리가 프로그래밍을 하는 것을 작게 작게 빨리 피드백을 얻는 방법이라 생각하면 쉬울 것 같다는 느낌을 받았다. 고로, 테스트를 짜는 것을 시작하는 것이 TDD로 가는 것이라 생각하게 되었다. TDD를 어떻게 시작 해야 할지 모르겠다!라고 한다면, 이 글을 읽어보면 좋겠다.
D사 인터뷰 문제: 머신러닝에 관한 인터뷰 문제인데, 여러 관련된 지식 문제도 많이 있다. (영어)
소프트웨어 엔지니어가 되는 법: 자신만의 발자취를 알 수 있는 회고록 형태의 글이 많을 수록 앞으로 주니어 개발자가 될 사람들에게 많은 방향성을 줄 수 있기에 좋은 주제라고 생각하는데, 어떻게 공부를 시작하게 되었고, 어떻게 노력했는지를 알 수 있는 글이다. 그래서 꼭 읽어 보셨으면 하는 글이 이런 어떻게 엔지니어가 되었는지?에 대한 글이다.
소프트웨어 엔지니어 코딩 인터뷰 준비하기 (미국): 코딩 인터뷰에 관한 설명과 함께 종류를 상세하게 설명하고 있다. 그리고 어떻게 공부를 해야 하는지에 대해서도 정리를 잘 해주시고, 직접 화이트 보드 코딩 테스트를 어떻게 연습 하는지도 직접 연습사진을 찍어 설명을 해주셨는데, 정말 많은 연습을 하시는 게 느껴졌다. 나도 이직을 하게 되는 순간이 온다면, 이렇게 좀 절실하게 연습을 해야 이직?성공을 하지 않을까 싶다.

SQL

[SQL] WHERE 기능, 성능향상 팁 *: SQL을 왜 쓰냐? 아직도 쓰냐?라고 할 수 있지만, 뗄래야 뗄 수 없는 개발자의 기본으로 꼽히는데, 자주 봐야 까먹지 않는 것 같다. 그 중에서 성능을 향상하는데 중요한 열쇠를 가진 WHERE에 대해 궁금하다면, 이 글을 읽어보는 것을 추천 한다. 그리고 더 많은 검색을 통한 학습이 필요로 하다고 생각한다. (저에겐 SQL이 어렵기 때문에…)

그냥 저냥 #위클리뉴스 #37

Sat, 06 Apr 2019 13:18:00 GMT

JavaScript

javascript this 정리: JavaScript에서의 this는 굉장히 다양한 방법으로 동작하기 때문에 각각의 상황에서 어떻게 바인딩 되는지 알아두면 좋다. 그렇지 않으면, 내가 원하지 않던 바인딩으로 원친 않는 동작을 야기할 수 있기 때문인데, 케이스별로 정리를 잘 해주셨다.
(ECMAScript) ES2019(ES10)의 변화: 생각보다 큰 기능이 추가 되진 않았는데, 그 중에서도 flat관련한 함수가 추가 되었다. 그 부분에 있어서는 좋은 것 같다.
[JavaScript] Promise와 예외 핸들러…: 정말 궁금 했던 사실이면서 기본적인 이야기인데, 딱 찾게 되었다. await이 없이 반환할 경우, 비동기 요청만 되고, 아무런 문제가 없을까?에 대한 부분이 의구심이 있었는데, 명확하게 케이스를 설명 해주셨다. 그럼, await을 하지 않으려면, 직접 catch해야 한다는 사실이다. 함수 내부에서 reject된 경우 상위의 try-catch에서는 잡히지 않기 때문이라고 한다.
(번역) Shadow DOM은 무엇일까?: Shadow DOM에 대해서 알 수 있는 데, 생각보다 이해하기 쉽진 않다. 그런데, 중요한 점은 Virtual DOM과는 동작이 다르다는 것이다. 실제 DOM에 기생하는 역할이라고 보면 될까? 하지만, 그것도 뭔가 완전한 이해는 아닌 것 같은데, 얼마나 유용한지는 좀 더 찾아봐야 알 것 같다.
tc39/proposal-class-fields: class의 private variable의 표기를 #으로 하겠다는 제안이 나왔다. _를 사용하는 것은 이미 사용하고 있기에 #으로 만들자는 제안인데, 좀 모호한 측면이 있다고 생각 한다.

React

컴포넌트를 여러 컴포넌트로 나눠야 할 때: 이 글의 내용을 공감하게 되는데, 실제로 실무에서 컴포넌트를 미리 쪼개려고 생각하다 보면, 어떻게 추상성을 뽑아 내야 할지 모호할 때가 있다. 실은 미리 컴포넌트를 쪼개는 것이 아니라 하나의 컴포넌트로 구성한 뒤에 불편해지는 상황이 발생할때, 쪼개면 된다는 글인데, 상당히 동의하는 편이다. 추상화의 비용도 고려를 해야 한다.
리액트 훅(Hooks): 컨텍스트(context) API는 어떻게 되나요?: Context API가 어디 가는 것은 아니라는 사실이다. Hooks를 정말 많이 쓰게 되더라도 Context API는 편리함을 가져다 주었다. 물론, Hooks가 더 많은 편리성을 준다는 점은 무시할 수 없다.
React’s ⚛️ new Context API: React 16.3에서 새로운 Context API를 공개하였는데, 자세하게 알고 싶다면 해당 글을 읽으면 이해하는데 도움이 된다.
리액트 훅(Hooks): 제 테스트는 어떻게 되나요?: 테스트라는 것에 대해 사실 좀 어렵다는 느낌을 많이 갖고 있는 편인데, 이 글을 보면서 느낀 점은 결국 테스트는 구현 상세에 의존하지 않도로 작성해야 한다는 점과 리팩토링에 대한 부분을 다시 한 번 이해하게 되었다. 함수의 외연을 바꾸는 것은 결국 리팩토링이 아니다. 그리고, 컴포넌트를 어떻게 작성하던지 테스트를 통과하게끔 만들어야 한다는 것이 중요한 것 같다. 물론, 함수의 외연을 바꾸면 테스트는 실패해야 맞다고 생각한다.
리액트 훅(Hooks): 렌더링 프로퍼티는 어떻게 되나요?: 해당 아티클은 리액트에 관해서 입문자가 읽기에는 적합하지 않다는 생각을 했다. 물론, 쉬운 내용은 아니지만, 렌더링 프로퍼티 패턴은 생각보다 많은 사용처가 있다는 생각을 하게 되었고, 슬슬 나도 리액트에 깊게 알아볼 필요가 있다는 생각을 일하면서 많이 느끼곤 했다. 이렇게 자주 쓰는거면 뭔가 공통요소를 뽑아내고 싶다.등등 슬슬 패턴에 관해서도 궁금해진다면, 이 글을 읽어보면 좋겠다. 더불어 downshift의 예시를 보는 것도 좋다고 생각한다.
프로퍼티 내리꽂기 (prop drilling): 상태 전달에 관한 글로 이해하면 좋을 것 같다. 어떻게 상태를 전달하느냐?에 관해 정답은 없는데, 이 글은 프로퍼티를 어떻게 전달하는 방법에 관한 가장 손쉽지만, 커질 수록 관리하기 어려운 생각이 든다.
Learn to combine RxJs sequences with super intuitive interactive diagrams: Rx에 관해서 설명을 잘 해주고 있는데, 나는 사용하고 있지는 않아, 어떤건지 정확하게 감이 오지는 않는데, 서버쪽 API에서 사용하면 장점이 클 것 같다는 생각을 했고, 이벤트 기반이 많을 수록 장점이 클 것 같다는 생각을 하게 되었다.
RxJS and Reactive Programming - Animations and visual lessons: Rx에 대해 동영상으로 배울 수 있는 곳이다. 그런데, dev 도메인으로 바꾸고 현재는 연결이 안되는데, 고쳐질 것 같다.
Writing Resilient Components: Component를 탄력있게 만드는 방법에 관해 소개하는데, 결국 개별 상태를 갖고 있지 않는 것이 방법인 것 같다.
React Hooks: Migration from Class to Function Components - RWieruch: 리액트 컴포넌트 클래스에서 함수형 컴포넌트로 바꾸는 방법에 관한 글이다. 어떻게 Hooks로 옮기는가에 대한 글인데, 이전할 계획이라면 읽어보면 좋겠다.
React Function Components by Example - RWieruch: Function Components에 관한 예시 코드들이 나오는데, 참고해보면 좋을 것 같다.

Node.js

nodejs 테스트 도구와 방법론 (테스트의 중요성, 전략, mocha, chai, sinon, istanbul, 유용한 팁): 다양한 테스트 툴들을 소개하고, 어떻게 해야 하는지 팁과 함께 소개하는데, 알맞는 테스트 도구를 잘 선정하고 목적에 맞게 사용하는 것이 중요하고, 테스트 코드를 작성하는 것은 더 중요하다는 생각을 점점 더 갖게 된다.

k8s

kubernetes를 이용한 서비스 무중단 배포: 카카오의 쿠버네티스 배포 전략에 관한 글인데, 카카오는 이미 전사에 쿠베를 도입한 것 같다. 그리고 어떻게 하면 서비스 조직들이 편리하게 쿠베 시스템을 이용할 수 있는지? 어떻게 하면 무중단으로 배포 할 수 있는지? 세세하게 나와있는데, 결과적으로는 트렌드를 잘 반영하는 회사라 생각 한다. 더군다나 전사 플랫폼을 운영하는 부서가 정말 탄탄하다는 생각이 든다.
Maybe You Don’t Need Kubernetes | Matthias Endler: 생각보다 약을 파는 글이지만, 쿠버네티스를 도입하기 전에 고민해보면 좋을 것 같다. 과연 정말 필요할까?

http

QUIC과 HTTP/3 - 2. 기존의 성능 개선 기법 및 한계: 벌써 HTTP/3에 관해 이야기가 나오고, 2의 한계와 방법에 관한 설명인데, 그림으로 설명을 해주셔서 이해하기 쉽고, 정리가 깔끔해서 읽어보면 좋다.

개발자에게 도움이 되는

소프트웨어 엔지니어 코딩 인터뷰 준비하기 (미국)
내 맘대로 위클리 뉴스 - 2019년 12주(2019.3.18 - 2019.3.24): Kotlin은 Null을 언제 사용할까?의 아티클이 좋다. 그리고 그 외 아티클도 읽어보면 좋고, 특히 Vue관련 튜토리얼 프로그래밍 같은 류가 나 같은 이해가 느린 개발자들에게 좋은 것 같다.
게임 서버 개발과 웹 서버 개발의 차이 · Elky Essay: 게임 서버 개발과 웹 서버 개발의 차이를 써주셨는데, 어떻게 보면 같은 부분이 많은 것 같다. 물론 다른 부분은 극명하게 다르다.
DB도 형상관리를 해보자! : TOAST Meetup
TDD 해보니까 어때? (1): TDD를 왜 했고, 어떻게 했는지? 에세이 같은 글인데, 나는 왜 그간 TDD를 하지 않았는지 반성하게 된다. 물론 좋은 점은 분명하지만, 현실적인 어려움도 소개하고 있다.
흔한 개발자가 두서 없이 쓰는 글 #3 (완): 개발자로써 읽어보면 한 개발자의 지난 삶의 발자취를 읽어볼 수 있는 글인데, 주니어 개발자라면, 읽어보길 추천한다.

데이터 분석

새로운 데이터 분석가와의 랑데부를 위하여(1)

Java

데이터 기술 동향 < 정보마당 - 한국데이터산업진흥원: 웹서버와 JSP에 관한 설명인데, 스프링 프레임워크에 입문하고자 한다면 읽어보길 추천 한다.
springframework:webclient [권남]: webclient에 관한 설명이 있는데, 권남님은 정말 꾸준하게 학습하시고 기록을 많이 남기시는 것 같다. (하루에도 수십번 남기시는 것 같다.)
3월 우아한 Tech 세미나 후기 - 우아한형제들 기술 블로그: 신청을 했지만, 탈락하여 아쉽게도 가지 못했는데, 후기글이 올라왔다.
Java 12: Mapping With Switch Expressions - DZone Java
Sorting a HashMap In Java

tool

linux:tmux [권남]: 나는 주로 로컬 터미널에서도 tmux를 기본적으로 쓰는데, 이에 대해 알고 싶다면 읽어보자.

일반적인

회의록, 누가 쓰나요?

Ansible

26 GCP와 Ansible을 활용한 쿠버네티스 클러스터 한방에 구성하기 1편: GCP(Goolge Cloud Platform)과 Ansible을 이용해 한 번에 쿠버네티스 클러스터를 구축하는 연재의 글인데, GCP를 쓸 수 있는 환경이라면 읽어보면 좋겠다. (초기 구축이 어렵지, 활용은 정말 좋은 방법이다.)
Shell Scripts to Ansible: Ansible에서 sudo권한이 필요할 때가 많은데, 이것을 좀 편리하게 하는 방법에 대한 글이다.

그냥 저냥 #위클리뉴스 #36

Wed, 27 Mar 2019 23:40:00 GMT

개발자에게 도움이 되는

확장하기 쉬운 코드가 아니라 삭제하기 쉬운 코드를 작성하자: 다익스트라 알고리즘을 만든 사람이지만, 신박한 견해라고 생각했는데, 돌이켜보니 좋은 이야기였다. 소모된 코드가 바로 유지보수를 줄이는 작업이라는 관점 또한 신기했다. 그리고, 많이 작성하지 말고, 코드를 먼저 흔히 사용되는 코드라면 복사 붙여넣기 해보자는 것도 좀 재밌는 관점이었다.
[번역]개발자로 압박을 덜 받으려면 어떻게 해야하는가?: 제일 중요한 점은 내가 모든 것을 다 할 수 없다는 점을 인정하는 것이 중요하다는 생각이 든다. 그리고 올바른 학습 목표를 가지고, 계획하고 그것을 잘 실천하는 것이 중요하다는 점을 우리는 알지만, 때때로 잘 실천하기가 어렵다. 역시 꾸준함이 생명이라는 생각이 들었다.
수학인듯 과학아닌 공학같은 컴퓨터과학/알고리즘 기초: 흔하게 알고 있는 알고리즘에 대한 부분이 모두 정리가 되어 있어 참고하기 좋다. (한국어)
나는 코드를 쓸테니, 너는 인프라를 맡거라.: Lambda, S3, pytho, serverless등으로 무중단 배포/프로비저닝 배포등을 소개하는데, 정말 신기하고, 해당 인프라 생태계를 만든 AWS가 정말 놀랍다. serverless framework를 좀 공부를 해보면 정말 편해질 것 같다. 특히나, typescript지원이라니.. 실무에서 써보고 싶다.
리눅스의 페이지 캐시와 버퍼 캐시: 커널 2.4이전과 2.4이후의 페이지 캐시와 버퍼 캐시의 구조를 살펴 볼 수 있다. 생각보다 쉽게 쓰여져 있고, 흔하게 사용하는 cat명령어로도 페이지 캐시의 유무를 확인 할 수 있어서 재밌게 읽었다.

Backend

DDD 값 객체와 마이크로서비스 | Popit: 마이크로 서비스와 DDD의 값 객체에 관해서 설명을 해주고 있는데, 내가 사실 DDD에 지식이 그렇게 크게 없다 보니 DDD를 사용하지 않을 떄 보다 무엇이 좋은지를 잘 가늠하지 못하겠다. 역시 아는 만큼 보이는 것일까? 싶었고, 올해 안으로 DDD를 적용해보면 어떨까 싶기도 하다.
Spring 의 시작, 프레임워크의 구성요소와 동작원리: JBEE님이 스프링 프레임워크의 개략적인 구성 요소와 동작 원리를 정리를 써주셨는데, 깔끔하고 군더더기 없이 정리가 되어 있어 참고 해보면 좋다.
서버리스 Serverless 아키텍처 파헤치기: 서버리스에 대한 설명을 간략하고, 쉽게 잘 정리 해주셨고, 비주얼적인 설명이 참 와닿았다. 이제는 FaaS의 시대가 도래한 것 같다는 생각이 들었고, 쉽고 빠르게 처리 되는 로직의 경우는 확실히 람다에서 처리 하는 것이 좋은 장점이 될 것만 같다. 도입 해볼 수 있다면, 도입 해보는 것도 고려 해보면 좋겠지만, 쉽지 않다는 것이 크다. 자체 플랫폼을 써야 한다면 당연히 어렵고, AWS를 쓸 수 있는 업무 환경이 되어야 좀..편하게? 써볼 수 있지 않나 생각해본다.
[Spring/번역] 컨트롤러 테스트 가이드 in Spring Boot: 사실 얼마전까지만 해도 컨트롤러 테스트를 어떻게 해야하는지? standalone? MockMvc? 엄청 헤맸었는데, 부서내 경력직으로 오신 분의 테스트를 보고 찾아 보다가 얼추 알게 되었다. 사실, 현업에서 컨트롤러 테스트 코드가 있는 경우가 드물다고 생각하는데, 만약 있다면, 좋은 환경에서 일하는 것이라 장담한다. 물론 없다고 좋은 환경이 아닌 것은 아니지만, 선 가이드를 볼 수 있다면, 주니어 개발자에게는 좋은 환경일 수 있다는 것을 말하고 싶었다. 그런데, 이 글을 보고 나니 참, 정리가 잘 되어 있었는데, 이제야 찾게 되어 아쉬웠다. 많은 시간을 헤매지 않고도 컨트롤러 테스트에 대한 좋은 글을 볼 수 있을 거라 예상 한다.
Kotlin으로 가자: Kotlin으로 개발한 경험기에 대한 내용과 간략한 언어의 특징적인 점들에 대한 소개 글인데, 중점적인 부분은 언어 자체적으로 심플함을 추구한다는 점이었다. Lombok을 사용할 수 없다는 점이 좀 아쉽지만, 사실 언어 자체에서 그렇게 크게 불편하지 않기 때문에 만약 코틀린으로 간다면, Lombok을 걷어내야 한다.

Frontend

프론트엔드 Framework을 공부하는 방법: 총 3가지로 분류 하는데, 컴포넌트, 라우팅, 상태 관리로 나누는데, 사실 이 3가지를 단계별로 학습하는 것이 가장 깔끔하고, 군더더기 없다고 생각 한다. 리액트를 배우는데에 리덕스는 불편한 요소가 될 수 있다. 다른 서드 파티 라이브러리들도 마찬가지다. 핵심을 먼저 배우도록 하자는 것이 이 글의 핵심이다.
신입 프론트엔드 개발자를 위한 스킬셋: 요즘 채용 공고를 보면, 신입을 뽑는건지 아닌지 헷갈릴정도다. 그럼에도 불구하고, 신입에게 기대하는 바는 무엇인지?에 대해서 궁금하다면, 이 글을 읽어보면 좋다. 결국 중요한 점은 기본기인 프로그래밍적인 마인드일 것이라고 생각한다.

일반적인

이뤄지는 꿈의 특징: 우리는 모두 꿈을 가지고 있는데, 이 꿈에 관한 글인데, 읽어보면 좋겠다. 특히, 손정의 회장의 문구를 인용하셨는데, 참 와닿는다.

[후기] 블로깅과 테크니컬 라이팅 세미나

Sat, 23 Mar 2019 16:23:00 GMT

글 쓰는 개발자 모임(변성윤님, 데이터 사이언티스트)

6개월 간의 의도적인 글쓰기 모임 강제로 진행
현재는 1기를 지나 2기 진행
2주마다 글을 하나씩 쓰도록 가이드 함.
글 쓰는 것도 피드백을 통해 보완점을 찾게 한다.
다만, 서로 피드백을 주고 받는데에는 시간이 좀 걸리고, 서로의 친분이 좀 필요로 하다.
모임을 하다보니 여러 관심사가 맞는 사람들끼리 오프라인 모임을 진행하게 됨.

기술 블로그 생존 전략: 구글 시대의 글쓰기(김대권님, @44bits.io 운영자, @nacyot)

참고
- 좋은 기술 블로그를 만들어 나가기 위한 8가지 제언
구글 검색이 사이트의 인덱싱을 하는데에는 시간이 좀 필요로 하다.
신뢰성 있는 사이트로 판단하는 사이트 위주로 빠르게 반영을 한다.
좋은 제목이 중요하다.
중요한 두 가지
1. 문서
2. 구글의 검색(인덱스 기준)은 결국 문서 기반 검색이다. (크롤링 자체를 문서 기준으로 한다.)
3. 사이트
4. 신뢰성 자체가 높으면 검색이 잘 된다.
SEO의 핵심은 질 좋은 컨텐츠이다.
완성된 형태의 글을 쓰는 것이 사이트의 신뢰성을 높이는 중요한 포인트가 된다.
연구 결과를 보니 사람들이 7분 정도는 집중해서 읽더라.
- 5200자 정도의 분량이다.
- 1만자 이상의 글을 시리즈로 나눠서 쓰는 것이 좋다.
컨텐츠 관리가 가능한 도구를 사용하는 것이 좋다.
보존, 보존, 그리고 보존이 중요하다.

To. 지식 공유를 시작하려는 개발자 (홍연희님, LINE Developer Relations팀)

이상한 모임
파이콘
GDG DevFest
코딩클럽
글 쓰는 프로그래머 협회
트레바리

다양한 커뮤니티 활동을 하심.

분야는 IT
주변의 개발자가 많더라.
잘 하는건 컨텐츠 기획이더라…등등

그래서 LINE Developer Relations팀에 합류하게 되었다.

개발자 컨퍼런스 지원 / 개발자 밋업 지원 / 소셜 미디어 관리등

사내 개발자를 위한 Tech Talk / Lightning Talk

그래서 결국에는 컨텐츠, 이벤트, 기획을 함으로써 라인의 브랜딩을 만들어 가는 일을 하고 있다.

사용자를 외면하지 않는 릴리스 노트 (조은별님)

IT출판 편집자 6년 | 보안 회사 테크니컬 라이터로 근무중

테크니컬 라이터의 일

메뉴얼
릴리스 노트
API 문서
UI 용어/메시지
개발 계획서
테스트 계획서
기술 블로그
IT 도서

오늘의 이야기는 릴리스 노트를 어떻게 만들어 가는지에 대한 이야기!

릴즈 노트의 정의
- 문제를 정의하고 해결점을 기술한 문서
- 신규 기능
- 개선 기능
- 오류 수정
- 간결한 문장
게임 릴리즈의 경우는 게임 캐릭터 신규 출시에 관한 부분을 강조한다.
개발자를 위한 릴리즈 노트에는 대부분 버그 수정, 신규 기능, 개선 기능을 카테고리로 분류해서 작성한다.
- 정말 예쁘게 작성 된 릴리즈 노트를 찾기 어렵다. (Github)

릴리즈 노트 작성시 고려 사항

제품/사용자 특성
일관된 문서 포맷
세줄 요약

개발자는 왜 블로그를 해야하나요? (이동욱님)

jojoldu.tistory.com 운영을 하고 있음.
테마 구입
블로그 개선 - 댓글 (github)
markdown을 입력하면, 티스토리로 글을 쓰도록 Node.js 모듈을 만듬.

블로그 장점

수익
기고/집필 요청
세미나 초대권
인지도
인터뷰
이직
사내 기술 블로그

왜 블로그를 해야 하나?

나를 표현 할 수 있는 수식어가 있는가?
내가 누구에게나 표현할 수 있는 아이템이 있어야 함.
- 그게 나에겐 블로그이다.
블로그는 아이덴티티이다.

개발 관련 기술 블로그 운영하기(변정훈님, Outsider’s)

12년간 기술 블로그를 운영 중
3일에 1개의 포스팅 목표
글 1개 짧게는 2 ~ 4시간정도 소요됨.
글 1개에 길게는 2-3일 걸린다.
퇴고는 하지 않는다.

주제

개발하면서 적을 수 있는 건 전부
새로운 도구, 환경 설치/설정
알게 된 라이브러리, 도구의 사용법
트러블슈팅, 장애처리
IT이슈

방향

나보다 잘하는 사람도 있음
나보다 못하는 사람도 있음
누군가에게는 도움이 되도록 쓰는 편
Dayone을 이용해서 적는다. (Private Note)

왜 하는가?

처음에 글을 쓰게 된 이유

공부하는 것이나 글쓰는 것이 똑같음.
배운걸 자꾸 잊어버려서.
설정해본적이 있는데 기억이 안나서.
겪어보던 문제인데, 어떻게 했는지 기억이 안나서.
듣거나 알게 된 지식을 내 것으로 만드는 과정이라고 생각함.
무언가를 해도 내 것이 되는건 아니라고 생각해서 블로깅을 하다보니 내 것이 되는 것 같다.

글을 공개로 쓰면 좋은 점

누구나 이해할 수 있어야 한다.
글로 정리하려면 잘 알고 있어야 한다.
글로 정리하면서 다시 고민해 볼 수 있다.
나의 인지도가 조금 올라감.

글의 흐름

하고자 했던 일
경험한 문제 상황 정리(격리된 상황)
시도해 본 방법
왜 동작이 안되는지? 왜 동작 하는지?
문제 상황 재현
예제 코드
관련 링크
개념 설명

MCVE(최소한의, 완성된, 입증가능한 예제)

(Minimal, Complete, and Verifiable Example)

일 하면서도 글을 많이 작성한다. 글을 지속적으로 쓰는 방법은 딱히 없다. 어느 순간 도움이 된다는 걸 느끼게 되다보니 자연스레 쓰게 된다.

그냥 저냥 #위클리뉴스 #35

Mon, 18 Mar 2019 00:56:00 GMT

Java

What Is an IoC Container in Spring? [Video] - DZone Java
Functional Programming Is Just a Safety Restriction on Object Orientation - DZone Java
Quickstart: How to Use Redis on Java - DZone Java
Java 10 Immutable/Unmodifiable Stream API Collectors - DZone Java
Java 11 New Features Tutorial
어떻게 웹플럭스는 적은 쓰레드만으로 많은 요청을 처리할 수 있을까?: 결국에는 이벤트 기반과 큐를 이용한 방식이라는 사실을 생각해보면, 프레임워크의 트렌드가 이벤트, 큐라는 키워드로 이루어졌다는 걸 깨달았다. 그런 점을 이 글을 통해서 느꼈다.

Docker

Docker - 컴포넌트, 20분 정리: 지난번 효율적인 10분 정리가 채 가시기도 전에 20분 정리 글을 올려주셨다. 이번에는 Node.js + Express의 서비스를 도커 이미지로 만들고, 도커 컴포즈를 이용해, Redis와도 연동하는 방법을 차례 차례 설명을 해주셨다. 역시나 놀랍고, 그리고 압축형태의 도커베이스를 쓰지 않으면, 간단한데도 거의 1기가에 육박한다는 점이 놀라웠다..(경량화가 주요 포인트가 아니였나…? 싶은..)

개발자에게 도움이 되는

리뷰: 함께 자라기 - 애자일로 가는 길: 내가 이 책을 읽으면서도 느낀 점은 애자일은 ~ 블라 블라다. 라는 책이 아니여서 좋았고, 이 책을 읽으면서 애자일이 아! 이런 거구나. 아! 이게 애자일이구나. 우리 팀도 애자일 전체를 적용한 것은 아니지만, 일부 활용하고 있었구나. 등등 많았다. 개발자라면, 이 책을 읽어보길 바란다. 그리고 이 글에서 인상적인 문구들도 내가 공감 했던 부분과 일맥상통 했다.
[B급 프로그래머] (스택오버플로우) 구글이 JSON 응답에 while(1);을 붙여 보내는 이유는?: 정말 신기한 방법이었고, 구글은 정말 여러방면에서 창의적인 발상을 많이 하는 개발자들이 많구나 싶었다. 물론, 구글의 공식적인 답변은 아니지만, 스택오버플로우의 신기한 시나리오에 의함이었다. 역시나, 대단한 사람들이 많다.

내 맘대로 위클리 뉴스 - 2019년 11주(2019.3.11 - 2019.3.17): kotlin의 시퀀스와 일반 컬렉션의 차이를 보여주는 기사가 참 흥미로운 것이 시각화해서 설명한다. 모르는 정보를 학습할 때는 사실, 비주얼 기반 학습법이라는 점을 최대한 활용하면 이해가 쉽다. 그림만 봐도 얼추 이해가 되었다. 그리고 Vue.js 초심자가 보면 좋을 아티클이 있었다. 아무래도 2편도 나올 것 같다.

기술 뉴스 #122 : 19-03-15 :: Outsider’s Dev Story: python으로 Git을 만들면서 실제 내부 동작을 이해 할 수 있는 글이 참 좋았다. 시간 나는 주말에 한 번 직접 해봐야겠다. 솔직히 Git을 쓰면서도 내가 과연 잘 쓰고 있는지?에 대해 자문 하는 시간이 될 것 같다.
리멤버 지원자분들이 묻는 질문 Top 4: 리멤버라는 서비스를 만드는 드라마앤컴퍼니의 블로그에 올라온 지원자 분들이 많이 묻는 질문 4개를 추려서 답변을 한 내용의 글이다. 그런데, 취준생이신 분들이 얻어 갈 정보가 많다고 생각 했다. 왜 이런 기술 스택을 쓰는지? 성능이 다른 스택보다 좋지 않은데, 어떻게 생각하는지?에 대한 기술적인 관점을 알 수 있는 글이기에, 왜 다른 회사는 그 기술 스택을 쓸까?에 대해서 또 다른 고민을 할 수 있게 만드는 글이라고 생각한다. (이런 글 취준 입장에서 정말 좋습니다. :)
Advantages and Disadvantages of a Monolithic Repository: 단일 코드 저장소의 이점과 단점에 관한 구글의 논문인데, 다 읽어보지 못했다. :/
딥러닝을 이용해 상품 이미지에서 색상 속성을 추출하기: 상품 이미지에서 색상 속성을 추출하는 법에 관한 글인데, 굉장히 상세하다.(물론, 텐서플로 코드는 없다.) 중요한 부분은 어떻게 진행 했고, 어떤 문제점(배경색 제거)는 어떻게 했는지 설명하고 있다는 점이다.
나는 그동안 무엇으로 성장했을까?: 단순히 성장에 관한 글인 줄 알았지만, 생각보다 깊은 수준의 성장에 대한 고민과 해결책, 그리고 개발자로 사는 현실적인 고뇌가 담겨진 글이었다. 어떻게 하면, 좋은 제품을 만들 수 있을까? 무수히 많은 고민과 삽질 속에서 얻은 경험을 글로 녹여 주셨다. 함께 일하면 얼마나 성장을 하게 될까?
Tiny Tip Calculator 개발기: 스스로의 문제가 되는 부분을 해소하기 위해 직접 개발한 앱에 대한 회고록으로 생각하면 될 것 같다. (번역도 자주 해주시는데, 어떻게 이렇게 짬을 내어 만드셨는지…!) 이 글을 읽어보면, 어떤 기술 스택을 사용했고, 후보들은 무엇이 있었는지? 어떤 기회비용이 있었는지를 상세하세 설명 해주는 개발 경험기를 남겨주셨다.

JavaScript

Why I Was Wrong About TypeScript
A Complete Guide to useEffect
How Are Function Components Different from Classes?
Coping with Feedback
forEach, for in, for of 특징 및 성능 비교: JavaScript의 반복문에 대한 퍼포먼스 비교와 특징을 잘 정리 해주셨다. :D

기타

경력직 채용, 그 태도에 관하여: 채용에 관한 정말 긴 내용이 쓰여져 있는데, 정말 굉장히 상세하고, 여러 이론들도 빗대어 표현하여 읽어보면 좋을 것 같다. 물론, 요즘 채용에 관한 부분은 비단 인사 조직만의 문제가 아니다. 개발자 채용은 개발자를 뽑는 팀에서도 판단을 해야 하는 문제다. 그래서 채용에 대한 태도가 중요하고, 얼마나 많은 준비를 하는지? 스스로 되돌아 볼 필요가 있다. 채용을 운으로만, 느낌으로만 하진 않는지? 코드도 못미더워서 테스트 주도 개발을 한다는 데, 사람을 채용하는데 준비도 없이 맞이하고 있는 것은 아닌지? A가 되지 않도록 해야 하지 않을까? 과연 모든 기업들이 얼마나 많은 노력을 하고 있는지? 궁금하다. 그리고 채용은 뽑으면 끝!나는 업무가 아니라, 그 사람이 그 팀에 완전히 적응 할 때까지의 프로세스를 뜻하고, 그 팀과 맞지 않다면, 다른 팀으로 전배 시키는 일련의 적재적소 배치 프로세스를 해야 한다고 생각한다. 왜? 요리를 하고 나서 설거지를 미루는가? 요리사는 요리도 하고, 설거지도 같이 한다. 그럼 왜 우리는 반만 일하는 건지 자문해 볼 필요가 있다고 생각한다.

영어

Take off: 휴가 내고자 할 때, 사용하는 단어: 얼마전부터에 알게 된 블로그인데, 영어에 관한 포스팅이 자주 올라오는데, 예문과 뜻을 각 포스트 주제에 맞게 정리를 해주신다. 이런 꿀팁들이 진짜 중요하다.

DCEVM(Dynamic Code Evolution VM)을 적용해보자

Wed, 13 Mar 2019 18:16:00 GMT

DCEVM을 설치 해서 조금 더 빠르게 수정된 부분을 반영하여 Tomcat이 해당 수정 코드를 빠르게 반영 하고자 설치하려고 한다.

원래는 JRebel이라는 유료 툴을 이용하면, 빠르게 Hot Swap하여 수정 된 코드를 반영할 수 있다.

그러나 연간 $550정도로 구독 모델이 굉장히 비싸서 사용하기가 어려워서 대체제를 찾다가 발견한 것이 바로 DCEVM이다.

아래와 같이 설치를 따라해보도록 하자.

JDK version에 맞는 binary jar 파일을 받는다.
해당 파일을 실행 시키는데, sudo 권한이 필요로 하다.
sudo java -jar 명령어를 사용하면 된다.
그림과 같이 DCEVM binary 버전에 맞는 Directory를 선택 후 Replace by DCEVM 클릭, 이후 Install DCEVM as altjvm 클릭
이후 terminal에서 java version을 확인 해보면 된다.
java —version
아래와 같이 Dynamic Code Evolution 64-bit Server VM이 나오면 정상적으로 변경 된 것이다.
이후 IntelliJ Plugin 중에서 DCEVM intergration 을 다운 받고, 재시작 한다.

이렇게 설정 한 뒤에는 Tomcat이 다시 돌지 않고, 바로 바뀐 파일만 Hot Swap을 하게 된다. 그래서 속도가 훨씬 빠르다. 특히나, JRebel의 경우에는 바이트코드를 변환하는 방식이라 속도가 좀 느린데, DCEVM의 경우는 그렇지 않다.

위와 같이 설정 한 뒤에는 code를 수정한 뒤, update Application을 해주면 정상적으로 되는 것 같다.

참고

aragorn/home: DCEVM을 설치하는 데에 대한 부분이 정리가 되어 있고, DCEVM에 대한 설명이 있는데, 읽어보면 좀 재미가 있다. 클래스 파일을 바꿔치는 느낌? 파일의 바이트 코드를 바꾸는 방식이 아니라, 파일 자체를 Watch하는 수준의 Hot Swap을 진행한다고 서술 하고 있는데, 실제로 어떻게 동작 하는지는 더 찾아 봐야 할 것 같다.
DCEVM: DCEVM소개 페이지이다. 파일 다운로드도 가능하다.
dcevm/dcevm: DCEVM의 github page이다.

Weekly News #34

Tue, 05 Mar 2019 20:30:00 GMT

JAVA

LINE의 OpenJDK 적용기: 호환성 확인부터 주의 사항까지 - LINE ENGINEERING: Oracle JDK사용에 제약이 생기면서 앞으로 수 많은 Java기반 프로젝트에서 벌어질 것이라 생각한다. 근데 그렇다고 안바꿀 수도 없고, 적절한 시점에 안바꾼다는건 좀 기술 부채가 정말 빠르게 쌓이는 것이라 생각한다.

Java NIO Direct Buffer를 이용해서 대용량 파일 행 기준으로 쪼개기: 실제로 일을 하다보면, 만나는 상황인데, 엄청나게 큰 데이터 파일을 전송해야 하는 일이 생길 수 있는데, 이런 예시가 고급 예시가 아닐까란 생각을 하게 된다. Java 레벨에서 운영체제 메모리에 직접 접근하는 방식을 활용하는데, Direct Buffer 해제에 대한 부분은 좀 의구심이 든다. 왜? 상세하게 설명한 부분이 없을지에 대해서는 약간? 이상한 느낌이 들었다. 근데 나보다 큰 데이터를 처리 하는분들에게 쓸모가 있어보인다.

테스트 코드 없이 레거시 코드를 다 감수하시겠습니까? - 우아한형제들 기술 블로그: 레거시 코드에 신규 코드를 추가하면서 테스트는 과연 어떻게 진행해야 할까?에 대한 부분을 고민 해본 사람이 많을 것이라 생각하는데, 막상 실제로 테스트 코드를 작성하는 이는 드물것 같다. (일단, 레거시와 신규 코드가 제대로 연결이 잘 되어야…) 쉽지 않지만, TDD를 해보려고 노력한다면, 레거시 코드를 수정하면서도 버그를 미연에 찾을 수 있을 것 같다는 생각을 하게 되었다.

코드리뷰 적응기(feat. 파일럿 프로젝트) - 우아한형제들 기술 블로그: 정산 관련 서비스를 맡게 되면서 간략한 파일럿을 만들고, 해당 코드들의 코드 리뷰를 받고, 피드백을 적용하는 수순을 보여주고 있는데 굉장히 세세하게 설명을 써두셔서 코드 리뷰를 적용하는 곳, 앞으로 적용 하게 될 회사/팀은 참고하면 좋겠다.

NEWS

내 맘대로 위클리 뉴스 - 2019년 8주(2019.2.18 - 2019.2.24): Java Section을 필수적으로 확인 해보면 좋을 것 같다. Nullability에 대한 아티클, SOLID에 대한 아티클도 좋은 자료이기때문에 읽어주면 좋을 것 같다. 특히나, SOLID에 대한 아티클은 코드가 참 깔끔하다는 인상을 받았다.

월간 개발자스럽다 1902호: 인문학도, 개발자 되다라는 책을 읽은 뒤의 후기를 남겨주셨는데, 이 책에 대해서 약간은 호기심이 생기고, 궁금해졌는데, 과연 사게 되면 언제 읽을지 모르기에 고민을 해보고 구매해야겠다.

기술 뉴스 #121 : 19-03-01 :: Outsider’s Dev Story: 룩핀 서비스를 만드는 곳에서 Rails 개발자들의 면접 질문 리스트를 공개 했다고 합니다. 그런데, 공개한 이유가 참 재밌습니다. Rails관련 빼고도 ELK관련해서도 질문을 하는군요. (역시 기본 테크가 된걸까요…?)

VIM

VIM-GO를 이용한 Golang 개발환경 꾸미기: vim으로 go 개발하시는 분들이 있다면, 이런 방식으로 꾸며보는 것도 좋겠습니다. 간결하긴 하지만, 구현부 이동에 대해서도 설명을 해주고 있어서 사실 잘만 조합하면 훨씬 낫겠다라는 생각도 들긴 합니다. 아 물론..Go Land가 좋기 때문에 굳이 vim으로 하실 필요는 없습니다.

DOCKER

Docker - 이미지와 컨테이너, 10분 정리 - 이상한모임: docker관련해서는 정말 기초가 어렵다는 생각을 하게 된다. 그렇지만, 결국은 이미지, 컨테이너라는 키워드에 집중 하면 된다는 생각을 이 글을 보고 하게 되었다. 10분 정리라고 되어있지만, 정말 깔끔하게 정리가 되어 있어서 도커 관련해서는 이 글을 먼저 읽고 지나가자!

Network

[Book] HTTP 완벽 가이드: 웹은 어떻게 동작하는가 :: Outsider’s Dev Story: outsider님이 HTTP 완벽 가이드라는 책을 읽고 정리하시고, 후기를 써두셨다. 사실 요즘 이 책으로 회사에서 스터디를 하고 있는데, 웹 개발자에게 필수 지식이 HTTP라는 말을 파트 리더님께 듣게되었는데, 시간이 지날 수록 해당 조언에 격하게 공감을 하고 있다.

개발자에게 도움이 되는

(내맘대로 선정한) 프로그래머를 위한 필독서 두번째 · Elky Essay: 대부분 유명한 책이기때문에, 제목을 읽어봤을 책들이 많이 있었다. 특히나 해커와 화가라는 책은 나도 구매를 했지만, 아직 읽지 못한 책이다. 다른 책에서도 언급이 자주 되기 때문에, 좋은 책이라 생각하는데, 한 번쯤은 이렇게 가벼운 기술 관련 책들도 읽어보면 좋을 것 같다.

Weekly News #33

Sun, 24 Feb 2019 20:30:00 GMT

개발자가 읽어야 할

‘HTTP/3 explained’ 한국어 번역 :: Outsider’s Dev Story: outsider님이 번역해주셨고, 지금은 마스터 브랜치에 머지가 된 상태로, 다양한 확장자의 버전으로 HTTP/3예 대한 내용을 확인 할 수 있게 되었다. 개발자라면 네트워크도 빼놓을 수 없고, 더군다나 HTTP/3라면 무조건 봐야 할 내용이라고 생각하기에 이번에 HTTP 스터디를 하는 시간에 위의 내용도 공유하고, 스터디원들이랑 확인 해야봐야겠다.

[번역] UI는 좀 이따 생각해봅시다: 결론적으로 나는 이 글의 일부만 이해를 했는데, 중점이 되는 핵심은 내가 화면 개발을 비즈니스로 생각한다는 점이다. 그런데, 이 글에서 그러한 생각을 무자비하게 깨부숴버린다. 결국, 화면을 만드는 것은 사용자 인터페이스에 지나지 않는데, 어떤 라이브러리, 어떤 기술을 사용하건 비즈니스 프로세스와 사용자 인터페이스는 강하게 접착되어 있다면, 상태 관리를 위해 많은 비용을 지불 해야 한다는 말로 이해했다. 결론적으로 앞으로 회사에서 일 할때에도 어떻게 일을 하고 있는지 다시 한 번 생각 해봐야겠다.

[B급 프로그래머] 다음 자바스크립트 코드에서 오류는?: JavaScript를 좀 쓰는 편인데도 보고 바로 답을 맞추진 못했다는 사실에 반성을 하게 된다. 그럼에도 불구하고, 못 맞춰도 어떠랴! 결국에는 이런 교훈을 나도 잘 새겨놓고, 다음에 실수 하지 않으면 되는 것이라 생각했다. 그런데, 세미 콜론과 JavaScript관련해서는 또 정리 해두면 좋을 것 같다는 생각을 했다.

내 맘대로 위클리 뉴스 - 2019년 7주(2019.2.11 - 2019.2.17): java11을 사용하는데에 있어서 Jigsaw를 잘 활용하기 위한 아티클이 좋았고, Vue.js를 활용하는 기사도 요즘의 관심을 갖고 있는 주제여서 참 좋았다. 그 외 다양한 기사들이 소개 되었다.

[jenkins] pipeline, multi-branch, ocean 링크 모음: jenkins pipeline에 대한 링크를 잘 모아둔 건데, 요즘 회사에서도 이렇게 구성해서 사용하는 곳을 많이 봤다. 그리고 앞으로 jenkins를 pipeline의 형태로 사용하는 것이 좋다는 것이 내 생각이다. 훨씬 좋다… (기능도 너무 많기 때문에…)

[B급 프로그래머] 2월 3주 소식(개발/관리도구, 고성능 서버/데이터베이스 부문): git 사용을 하다가 만나는 이슈들에 대해서 잘 정리 해준 글이 있는데, 정말 좋은 내용이 많고, 매번 겪는 문제라고 생각하는 사례를 잘 정리 해주셨다. 그 외 다른 소식들이 많아서 읽어볼만 하다.

테마 스위치 기능 추가하기: 다크 모드를 지원함으로써 생기는 중복된 CSS 처리 코드를 어떻게 한 번에 해결 할 수 있는지? 블로그에 직접 적용해보고, 후기를 남겨주셨다. 역시 요즘은 SASS의 인기가 많아졌고, 리액트의 덕분이기도 한건가? 싶다는 생각을 하게 된다. 물론 리액트 이전에도 사용해왔다.

Shopify 아키텍처의 진화

vim 에서 python 개발을 위한 편집: 보통은 IDE를 많이 사용하지만, 그렇지 않고 터미널상에서 바로 개발해야 하는 상황도 있다. 물론, 그럴때는 vim만한 것이 없다. 그럴 경우에 해당 셋팅을 참고하여 python개발을 하도록 하자!

React

Intro: React 내부를 이해하기 위한 번역글이다. 어떤 시스템적인 로직으로 돌아가는지 궁금하다면, 이 글을 읽어보는 것을 추천한다. (영어를 잘 하신다면, 영어로 검색하면 많은 자료가 나온다.)

ML

이펙티브 텐서플로 2.0: 텐서플로 2.0의 번역본 링크가 있고, 해당 2.0에서는 어떤 것이 변화 했는지를 알 수 있도록 간략하게 요약 되어 있다.

Docker etc

Dockerfile을 이용해서 이미지 생성하기: docker file을 이용해서 이미지를 생성 하는 방법을 스크린샷도 남기며 친절하게 설명해주셨다. 그리고 유의사항까지 팁으로 남겨 주셨다.

Docker Compose - 여러개의 컨테이너를 설정하고 생성하기: 여러개의 컨테이너를 설정하는 방법을 하나의 yml 파일로 만들고, 해당 파일을 docker compose로 실행 시키면 여러 개의 컨테이너가 동시에 설정되고, 실행 되는 것인데, 예시로 살펴볼 수 있다. 그런데 결국은 공식 문서를 참고하는 것이 중요하다. 굉장히 많은 옵션이 지원 되기때문이다.

[Docker] 도커 기초 명령어 익히기: 기본적인 도커 사용에 관련하여 설명하고 있는데, 처음 입문한다면 이 글을 따라 해보는 것이 좋을 것 같다. nginx, terminal 사용등 좋은 예시가 많다. 나도 요즘 도커를 실무에 도입하고자 혼자서 보고 있는 중이다. 그런데, 참 도커는 매력적인 도구라는 생각이 든다. 도입하면 정말 편해질 수 있다는 생각이 든다.

[Docker] 도커 소개와 우분투에 Docker CE 설치하기: 실제 우분투 서버에 도커를 설치하는 방법을 상세하게 소개하는데, 도커를 설치할 수 있는 OS 버전을 꼭 체크해야한다.

[Docker] 인텔리제이에서 도커로 배포하기: spring boot 프로젝트를 데모로 만들고, 해당 데모를 jib 라이브러리를 이용해서 도커 이미지를 만들어내는데, 정말 간편해보인다. 물론, 로컬에서는 이렇게 하기가 어렵지만, 개발서버로에선 이런 방식을 활용 할 수 있을 것 같다.

[Ubuntu] 18.04 docker 명령을 sudo 없이 실행하기, systemctl restart: sudo 키워드 없이 도커 명령어를 실행하는 방법이다. 처음 셋팅을 이렇게 해두면 정말 편리하다. 작은 4글자지만, 매번 쳐야 하는 것은 정말 귀찮다.

개발자에게 도움이 되는

공감하고 공유하는 프로그래머: 모든 지식은 하나 : 네이버 블로그: 글쓴이의 엄청난 경험과 다수의 개발 경력으로 얻은 인싸이트를 토대로 5년차 개발자에게 추천하는 것들에 대함인데, 나에게 참 와닿는 말이 너무 많았고, 글쓰신 분이 얼마나 큰 고민을 많이 해오셨고, 그 고민들을 어떻게 해결했는지가 글 속에 녹아있다. 그리고 내가 코더로 사는 이유, 2018년, 내가 모르는 기술들라는 글을 읽어보시길 추천합니다.
It’s a Kind of Magic: Kinds in Type Theory - DZone Java: 타입 이론에 대한 내용인데, 생각보다 쉽지 않고 이미 타입 이론에 대한 정보를 알고 있어야 이해 할 수 있는 내용이 많아서 아직은 이해가 어렵다. 결국은 함수형 프로그래밍, 하스켈을 깊게 파면 팔수록 수학으로 귀결 된다는 말이 사실이라는 답을 얻었습니다. :/ 그럼에도 불구하고, 공부하는 개발자가 되려면, 놓칠 수 없는 내용이라 킵해두기 위해 가져왔습니다. (페이지의 일부만 이해함.)
Top 7 Soft Skills for Developers in 2019: 이 글을 한 번 번역해보고 싶다는 생각을 품었는데, 이번주에 번역할 수 있다면 해봐야겠다. 영어이지만, 읽어보면 좋은 내용이라 공유드립니다.

일반적인

작지만 확실한 하루를 보내기 위한 5가지 제안: 비교적 쉽게 활용 할 수 있는 5가지의 목표에 대한 이야기인데, 나는 항상 내 할일을 할때만 체크 하고, 하지 못했을 경우에는 어떤 이유로 못했는지는 체크 하지 않았는데, 어떤 이유로 못했는지를 체크 하는 방법을 배우게 되었다. 목표를 이루는데에 방해물과 하지 못한 이유를 상기 하는 것도 중요한 것이라 생각하게 되었다.
노션, 그리고 워크플로위: 워크 플로위는 제대로 사용해본적은 없고, 어느정도 사용해본 경험은 있는데, 나는 완전 하드한 에버노트 유저라, 원페이지에서 Depth가 깊어지는 관리를 잘 못하겠더라. 그런데, 생각해보면 사람의 생각이 꼬리에 꼬리를 무는 방식과 유사한 것과 같다는 생각을 이 글을 읽으면서 하게 되었다. notion을 과금해서 사용중인데, 코드를 작성하는 용도, 여행 관련 계획에 주로 사용하고 있다. 그런데, 점점 에버노트가 시시해지는데, 이 것은 Bear로 가야 하는건지 의문이 들었지만, 지금 사용하는 수준으로는 Notion + Evernote 조합이 좋다고 생각하는데, 여기에 업무를 위해서 워크 플로위를 사용해볼까 고민중이다.
요즘 ‘쿠팡’에서만 쇼핑하게 되는 이유: 쿠팡의 초기 모델인 로켓배송은 이미 다른 배송 서비스 사업자들도 진행하고 있는 아이템이었다. 그런데, 가격 이상이 되어야하는 로켓 배송의 단점으로 인해, 다른 앱에서 물건을 사거나 하곤 했는데, 이제는 로켓 와우의 등장으로 인하여 더 나은 로켓 배송이 되어 버렸다. 그러면서 배송비에 대한 자유로움이 쿠팡을 더 완벽케 만드는데 일조를 했다고 판단한다. 이 글의 글쓴이도 그렇게 설명하고 있으면서 네이버 페이에 버금가는 로켓 페이의 등장으로 물품을 사는데 몇 분이 소요되는 시대가 아니다. 이제는 고르고, 결제가 원스톱으로 이루어진다. 그런데 배송비까지 사라지게 만드는 구독 모델을 도입함으로써 쿠팡의 새로운 비즈니스 모델이 생겼다고 생각하게 된다. 그리고 손정의 회장은 절대 가치 없는 곳에 돈을 쓰지 않는다. 그는 돈을 의미 있는 곳에 투자한다. 쿠팡이 앞으로 보여줄 무언가가 또 남았는지가 궁금해진다.

Solve find missing argument to -exec

Sat, 16 Feb 2019 18:36:00 GMT

Solve find missing argument to -exec

어느날, 서버 작업을 하던 중에 쉘 스크립트를 하나 만들어야 했다. log rotate를 해야하는 상황이었다.

그래서 스크립트를 작성하는데, 계속 위와 같은 find missing argument to -exec오류가 발생했다.

내가 작성한스크립트의 일부가 아래와 같다.

/usr/bin/find $NGINX_LOG_ARCHIVE_DIR -name "access.$YESTERDAY.log" -exec /usr/bin/gzip -f '{}'\;

위 코드에서 계속 에러가 발생했는데, 해당 오류를 찾으려고 검색해보니 굉장히 쉬우면서 황당한 오류였다.

알고보니 -exec는 \; terminate operator가 필요로 한 건 맞는데, ‘{}’ \; 공백이 필요로 하다.

아래와 같이 수정하면 된다.

/usr/bin/find $NGINX_LOG_ARCHIVE_DIR -name "access.$YESTERDAY.log" -exec /usr/bin/gzip -f '{}’ \;

참고

find-missing-argument-to-exec

Weekly News #32

Sat, 16 Feb 2019 17:34:00 GMT

[번역] UnitTest: Martin Fowler - 이상한모임: Unit의 단위를 어떻게 할 것인가?에 대한 부분은 참 아무리 생각해도 어렵다. 쉽지 않은 주제이고, 테스트를 어떻게 잘 작성해야 하는지에 대한 부분도 항상 고려해야 하는 부분이라, 테스트를 작성하면서, 팀원들과 어떻게 테스트를 할지에 대한 토론을 하면서도 이야기 나누면 좋을 주제다.
Thinking in React(리엑트스럽게 생각하기): ReactJS를 접하면서 느낀 건데, 참 그 전에 내가 작업하던 스타일과 다르다. 스타일은 패러다임으로 이해하면 쉬울 듯 한데, 중요한건 패러다임을 바꾸면서 프로그래밍을 하기란 쉽지 않다. 그래서 React에 대해서 무언가를 잘 하고 싶다면, 해당 철학에 맞게 생각하는 것이 중요한데, 이런 아티클이 그에 대한 것을 도우리라 생각한다.
[천자 칼럼] 1만2500시간의 ‘의도적 휴식’: 개발자는 결국 훈련도 중요하지만, 휴식도 중요하게 생각해야 하고, 우리는 인간이기에 꾸준히 소비될 수 있는 열정을 관리 하는 것은 중요하다고 나는 항상 말한다. 물론, 나도 그것을 잘 지켜야 한다는 걸 잘 알고 있다.
Hello, React Hooks!: 사내 발표 하러도 오셨는데, 그 때는 맨 아래에 링크 건 TS 관련한 발표셨다. 물론 그때도 정말 좋은 경험기를 발표해주셔서 고마움이 컸는데, React Hooks가 발표 되었는데, 해당 내용을 잘 정리 해주셨는데, 중간 중간 참 쉽죠잉?이 음성지원 되는 듯하다. 그렇지만, 절대 쉽지 않다.
Emacs 2주 삽질기: Emacs는 오래된 에디터? 라고 할 수 있는데, 보통 Vim User들과 많이 비교를 하게 된다. 그런데, 중요한건 둘 다 굉장히 좋은 에디터 툴이자, 오래된 프로그램?!이라는 데에 있다. 근래들어서는 Vim 유저들도 Emacs로 넘어 오게 되었는데 그것은 바로 플랫폼의 한계라고 해야 할 것 같다. 실제로 Vim은 분명 좋은 툴이지만, 한계가 있고, 그에 반하여 Emacs는 정말 좋은 대안이 된다. 왜냐하면, Lisp기반이라 플러그인 형태로 어떠한 기능을 올리가 쉽다. 그래서 요즘은 Emacs + Evil 조합을 많이 쓰는데, 중요한건 나도 Vim을 좋아하지만, NeoVim + SpaceVim, Emacs + Spacemacs를 혼용하여 사용하고 있다. 급하다면, spacevim을 사용하고 그 외는 spacemacs를 사용하고 있는데, 정말 좋다. 역시, 무거운 플러그인은 나를 춤추게 한다. (기능빨 중요)
[B급 프로그래머] 2월 2주 소식(빅데이터/인공지능, 암호화폐/블록체인, 읽을거리 부문): 케라스가 상당히 떠오른 느낌을 받는 기사가 있는데, 이제 진짜로 텐서플로를 하더라도 첫 시작은 케라스 API를 통해 입문하게 된다. 왜냐하면, 텐서플로가 이미 고수준 케라스 API를 내장했기 때문이다. 머신러닝 입문자들은 케라스로 머신러닝, 딥러닝을 쉽게 공부할 수 있는 장점이 있다.
useHooks: React Hooks에 대한 예제 모음집 사이트로 이해하면 쉽다.
React as a UI Runtime: React에 대한 UI Runtime에 대한 글인데, 나도 정확하게 다 이해하진 못했다. 입문자가 읽기에 친절한 글이 아니라고도 써있다.
Under the hood of React’s hooks system - The Guild - Medium: React Hooks의 시스템에 관한 글인데, Dispatcher, hooks queue, fiber에 대한 설명이 있어서 React Hooks라는 시스템을 이해하는데 도움을 주는 글이다.
React hooks: not magic, just arrays - Rudi Yardley - Medium: React Hooks가 어떠한 마법이 아니고, 그저 Arrays로 상태 관리를 한다고 하는 글이며, 사실 자세하게 읽지는 못했다.
Why Do React Hooks Rely on Call Order?: 왜 React hooks가 호출 순서에 의존하는지에 대한 설명이다. 물론 쉬운 내용은 아니지만, React Hooks에 대해서 깊게 터득하는 데에는 좋은 자료이다.
facebook/react: ReactFiberHooks의 코드이다. 나중에 실력이 쌓이면, 분석해볼만 하다.
React를 Vue.js보다 선호하는 이유: 안희종님의 블로그에서 본 글인데, 왜? Vue.js보다 Reactjs를 선호하는지에 대한 생각과 정리 글인데, 한 번 읽어보는 것이 좋다. 물론, 나는 Reactjs를 사용하는 중임에도 Vue.js를 더 좋아하는데, 사실 두 기술에 대한 개발자의 호감도도 작용한다고 믿는다. 그럼에도 불구하고, 어떤 기술에 대해 비교하는 것, 개인적인 기술 견해 및 직접 사용해보고 비교해보는 습관은 개발자로써 배워야 할 태도라고 생각했다.
TypeScript와 Flow: 자바스크립트 개발에 정적 타이핑 도입하기: 안희종님의 발표자료인데, 왜 우리는 TypeScirpt를 써야 하는가?에 대한 것인데, 정독해보면, 왜 좋은지?를 알 수 있다. 물론 나도 이미 써본 (뽕을 맞은) 사람이라, TS를 사용하는 것이 더 이롭다는 것이 나의 후기이다.

Weekly News #31

Sun, 10 Feb 2019 00:16:00 GMT

2019-02-10 weekly news 31th

How to build massive service for advance: 강대명님이 대규모 웹 서비스에 대한 전반적인 아키텍쳐에 대한 설계에 관해서 자료를 만들어주셨는데, 이러한 자료는 사실 어떤 책을 읽어도 얻기 힘든 정보들이 많다. SPOF라던가? 무중단 배포와 같은 정보는 필수적인 요소인데, 이에 대한 내용들을 잘 녹여주셨다.
SoundCloud 아키텍처의 진화 | Looah: soundcloud 서비스를 나는 그렇게 많이 사용하진 않지만, 사용자가 급격하게 많아진 서비스 중 하나라고는 들었는데, 이에 대한 해당 서비스의 아키텍쳐 변화에 대한 번역글인데, 굉장히 좋은 정보가 많고, 캐싱 전략이라던가? 어떤 플랫폼을 사용했는지? 왜 사용했는지를 알아보면 좋겠다싶어 지난 글이지만, 가져오게 되었다. 요즘은 아키텍쳐 관련해서 많이 보게 되는 것 같다.
[번역] 웹 캐싱의 숨겨진 요소들 · mingrammer’s note: 캐싱에 관련한 대부분의 정보들을 요약해둔 자료인데, 읽어보면 좋다. 특히 웹 가속기가 신기한데, 사용하는 곳은 본적이 없는 것 같다. :D
SQL Server Story : 네이버 블로그: docker에서 사용하는 명령어들의 설명과 예시를 정리 해주셨다. 해당 글을 잘 참고해서 도커를 조금씩 사용해봐야겠다.
[B급 프로그래머] 2월 1주 소식(개발/관리도구, 고성능 서버/데이터베이스 부문): 여러가지 유용한 글들이 많은데, 해당 글중에서 블로그 저자분이 작성하신 Devops 인터뷰 문제에 관한 글이 굉장히 도움이 많이 되었다. 앞으로 해당 글에 대한 질문&답변을 잘 정리해보면 Devops관련해서는 어느정도? 정리가 될 것 같다는 생각이 든다.
RabbitMQ 동작 이해하기: 요즘은 아무래도 kafka를 많이 사용하지만, 여전히 레거시에서는 RabbitMQ를 사용하리라 생각하는데, 간단명료하게 잘 정리 된 글이다.
아이패드로 맥에 원격 접속하여 (프론트엔드) 개발하기: 아이패드를 사용하고, 맥북을 사용하지만, 아이패드의 단점은 간단하게라도 개발을 할 수 없다는 데에 있다. 그래서 아이패드 이외에도 맥북 에어가 절실하게 필요하긴 하다. 그런데, 글을 쓰신분도 아이패드로는 부족하지만, 급하셔서 그런것 같았다. 그렇지만…장시간 하기에는 해로울 것 같다.
내 맘대로 위클리 뉴스 - 2019년 5주(2019.1.28 - 2019.2.3): Node의 품질을 위한 글이 있는데, 해당 글을 잘 읽어서 실무에도 뭔가 적용해보면 좋을 것 같다는 생각을 했다. 유용한 글이라 가져왔다.
3년차 웹 개발자: 권용근님의 회고이지만, 나도 느끼는 바가 많다. 이 분이 작성하신 우아한 형제들의 블로그 글이나, 이동욱님의 부사수로 알고 있는데, 같은 회사로 이직을 하시고 좋은 시너지를 서로 주고 계시는 모습이 참 좋았다. 나도 이런 분들처럼 좋은 시너지를 낼 수 있는 자기계발을 꾸준히 하는 사람이고 싶다는 생각을 글을 읽으면서 생각했다.
추천 서비스를 말할 때 내가 하고 싶은 이야기: 데이터 사이언티스트 관점에서 볼때의 추천 서비스에 대한 내용인데, 관점의 이동이라고 해야할까? 읽어보면 참신하다고 할 수 있다.
Making setInterval Declarative with React Hooks
Filterer Pattern in 10 Steps: filterer pattern에 대해서 잘 몰랐는데, 10단계로 나누어서 설명을 해준다. 코드로 직접 따라해봐도 좋을 것 같다.
Amazon Corretto 8 - DZone Java: Java의 아버지 제임스 고슬링 아키텍트가 아마존으로 가서 만든 openJDK으로 아마존이 직접 배포한다는 점에서 무엇이 다른지? 찾아봐도 좋을 것 같다. corretto도 java11 버전을 지원하도록 업데이트 될 예정이라고 한다.
jcmd, Circa JDK 11: jcmd는 포괄적인 JDK tool이라고 하는데, 자세하게는 확인 하지 못했지만, 시간이 날때, 확인을 해봐야겠다.
삶에서 항상 붙들고 있어야 하는 세 가지 질문: 무엇을 하고 싶은가?, 무엇을 할 수 있는가?, 무엇을 해야 하는가?라는 질문을 문득 문득 자신에게 던져보면 좋은 질문이라는 생각을 평소에도 하고 있었는데, 기사를 보고 와닿는 점이 많아 가져오게 되었다.

Weekly News #30

Mon, 04 Feb 2019 00:18:00 GMT

그냥 저냥 #위클리뉴스 #30

JavaScript 코드 리뷰 - 코드 리뷰 문화: 코드 리뷰에 대한 글인데, 코드 리뷰에 대한 모든 면을 적어주었다. 그래서 읽어보면 좋겠고, 코드 리뷰를 하지 않는 팀, 회사라면, 다 같이 공유해서 읽어 보는 것도 좋겠다. 결국은 코드 리뷰는 비용이 들지만, 다시 되돌아 오는 복리라고 생각하면 좋다. 작게 자주 올리는 것이 좋다는 말에 격하게 동의한다.
자바스크립트 비동기 처리 과정과 RxJS Scheduler: 오래전의 글이지만, 자바스크립트 비동기 처리를 고민하다보니, 결국은 기본 엔진에 대한 공부를 하게 된다. Event Loop와 Queue 그리고, Microtask queue의 관계로 자바스크립트 처리 과정을 Step by Step으로 알려준다.
[WHY 시리즈 1] E.001 - mlab, API - Mijeong (Rachel) - Medium
[WHY 시리즈 1] E.002 - Monolith, 요구사항, Pull Request - Mijeong (Rachel) - Medium
[WHY 시리즈 1] E.003 - 단위 테스트, 개밥 먹기, 데이터 구조 정의 - Mijeong (Rachel) - Medium
[WHY 시리즈 1] E.004 - 서버 분리, 데이터 모델 관계, API Resource - Mijeong (Rachel) - Medium: 박미정님의 WHY 시리즈이다. 나는 이 글들을 곱씹어 보기 위해 모두 가져왔다. 분명 나에게 좋은 길라잡이가 되는 문장, 문단 등등 있을 것이라 판단한다. 미정님의 발표자료는 나중에 봐도 꼭 내가 얻을 것이 있었던 경우가 많았다. (사실 어느 순간 팬이 되었다고 한다.)
https://www.youtube.com/watch?v=UttzAcbuk5k&feature=youtu.be&fbclid=IwAR1bhFYu3tIKBhRpU63sF7v23XlF42xdVHowI90vretPtQSbouthIKnHw: 빨리 실패하는 것이 더 이득이다. 라는 말에 공감하게 된다. 오픈 이후에 버그를 찾는 것 보다 오픈 전 버그를 찾아 수정하는 것이 비용이 정말 싸다. 그렇기 때문에 TDD를 하는 것을 한다는 것은 좋은 일이지만, 팀내의 합의도 필요한 부분이라고 생각한다. 그러기 위해서는 개개인의 노력이 좀 필요하지 않나? 생각을 해본다. TDD에 대해서 조금 더 공부하고자 한다면, 이규원님의 블로그를 통해 학습하는 것도 좋다고 생각한다. 그리고, 이 영상을 보면서 느낀점이지만, 단위 테스트가 2500여개, 기능 테스트, Fake Service를 통한 통합 테스트까지 하는 걸 보면서 굉장히 Safety Driven이 되는 구나 싶기도 했다. 나는 얼마나 운에 서비스를 맡겼던 것인지 모르겠다.
https://www.youtube.com/watch?v=Fr3mKCxnp8Q&feature=youtu.be: - 요즘은 왜? 라는 질문을 많이 스스로 하게 된다. 예전에는 일정에 맞춰서 서비스를 내보내야 하니까. 버그 없는 기능을 위해서 개발을 하고, 많이 사용하는 기술을 채택 하고 개발을 했다면, 이제는 왜 이 기술을 사용하는지? 왜 이렇게 일을 해야 하는지? 묻는 편이 되었다.
[Querydsl] 다이나믹 쿼리 사용하기: Query DSL을 통하여 다이나믹 쿼리를 사용하는 방법인데, Mybatis랑 별차이가 없는 것 같아서 좋아보였다.
[Querydsl] 연관관계 없이 Join 조회하기: Query DSL에서 Join하는 방법인데, 버전이 업데이트 됨으로써 지원이 되었다고 한다. Jooq가 아니여도 좋은 대안이 될 수 있겠다.
Useful Git Commands: - 유용한 Git commands의 사례인데, 보고 좋은 것들은 alias 해두면 좋겠다 싶은게 몇 몇 있다.
내 맘대로 위클리 뉴스 - 2019년 4주(2019.1.21 - 2019.1.27): 코틀린의 Data 클래스의 대한 내용이 재밌었고, 파이썬의 루프와 재귀에 대한 내용이 상세하게 되어 있어서 읽어보면 좋겠다.
[B급 프로그래머] 1월 4주 소식(빅데이터/인공지능, 암호화폐/블록체인, 읽을거리 부문): 2018년도의 코세라 탑 10 강의 순위가 머신러닝이라는 것이 예상대로 였고, 아마 올해도 머신러닝은 끝없이 이야기가 나올 주제가 아닐까 생각해본다. 그리고 이제는 엔비디아에서만 딥러닝을 돌리는 시대가 아니게 되었구나. 라는 생각이 들었다.
데이터 베이스의 자동증가 값을 기본키로 사용할 수 없을때는? - 우아한형제들 기술 블로그: 우아한 형제들에서 JPA, Hibernate를 정말 잘 사용하는 회사인것 같아 부럽기도 하고, 내심 회사에서 쓸일이 없다면, 토이 프로젝트라도 해봐야 할 것 같은데..(막상 생각 나지 않지만) 레거시 환경에서 신규로 작업 하더라도 유지 해야 하는 상황 일 때, 위 방법을 참고하면 좋겠다.
How to Write Your Own Spring Boot REST Service - DZone Java: Spring Boot framework를 통해 REST service를 간략하게 Mock 처리하여 개발 하는 코드를 상세하게 알려준다. 스프링 부트를 처음 도입할 때, 이렇게 작은 규모로 작게 작게 연습해보는 것도 도움이 될 것 같아서 가져왔다.
기술 뉴스 #119 : 19-02-01 :: Outsider’s Dev Story: react-cache라는 라이브러리가 눈에 띄였다. 이건 솔직히 필요로 해보여서 시간을 두고 체크를 해봐야 할 것 같다. 실무를 하다 보면 비동기가 꼭 해법은 아니고, 동기식 동작이 필요 할 때가 있다. 그럴 경우 참 애매한데, 고생을 해봐야 동기 API가 생각나게 된다. 그 외 다수 좋은 아티클의 링크 및 요약 글이 있다.

Weekly News #29

Sun, 27 Jan 2019 20:30:00 GMT

개발

Tiny Tip Calculator 개발기: 번역을 정말 자주 해주시는데, 또 토이 프로젝트로 팁 계산을 해주는 ios앱을 만들어주셨다. 깔끔하고, 여행을 갔을 때, 써야겠다.
한 달 짜리 개인 프로젝트 (5) — 당신의 타자 실력을 알려주는 웹 앱: 프로그래머를 위한 타자 연습페이지를 모방하여, 한글 연습을 할 수 있는 웹 앱인데, 심심하거나 타자 연습을 진짜로 할 때, 좋다는 생각과 함께 항상 원하는 어플리케이션을 직접 개발하시는 모습이 참 존경스럽고, 만들어주신 스타웍스 또한 잘 쓰고 있는데, 해당 앱도 정말 자주 쓰게 될 것 같다.
[B급 프로그래머] Devops를 위한 인터뷰 문제: 실제로 devops라는 건 정말 어렵다. 추상적인 영역이고, 사이트 신뢰성을 얻기란 어려운 문제고 항상 모든 문제의 모호함은 존재하는데, 기본이 중요한 것 같다. Devops라는 Role에 따른 인터뷰 질문인데, 답하는 것은 좀 어렵다. 그런데, 해당 내용에 대한 좋은 방향점을 알려주는 글이다.
This Month I Learned - 2019년 1월: 하노이의 탑에 대한 부분이 공감이 된다. 어떤 익숙한 문제이더라도 막상 해결하려고 하는데에는 시간이 걸리고, 최적화를 스스로 하는 것은 굉장히 어려운 사실이라는 점이 공감된다. 그리고, UI 엔지니어링의 요소들에 대한 부분, 안정적인 서비스 운영이라는 정보도 굉장히 유익하다.
CURRENT TIME IN HH:MM:SS WITH JAVA 8+ AND DATETIMEFORMATTERBUILDER: Java8에서 날짜 관련 포맷 만드는 일이 많은데, 그럴때 참고하면 좋을 것 같다. 굉장히 명시적이라 가독이 좋은게 장점이다.
세상에서 가장 이해받지 못하는 영웅, 데이터 과학자 (3/3): 정말 중요한 점은 바로 데이터 과학자도 ML을 사용한다는 점을 설명하는 점이 정말 지혜로운 설명이었다. 기술에 대해 오해하는 지점이 생기는데, 모든 문제의 해결이 ML로 귀결되는 것은 아닌데, 오해하곤 한다. 조심해야 할 문제인데, 전혀 다른 내용의 아티클에서 해당 내용에 대한 답?!을 찾게 되어 나중에 이렇게 설명을 해야겠다.
Why Isn’t X a Hook?: React Hooks API를 첫번째로 릴리즈 한 뒤의 왜 다른 API는 Hooks가 되지 않는가?라는 질문들에 대한 토론에 대한 글인데, Hooks에 대한 내용을 좀 인지하고 있어야 해당 글을 이해하기 쉽다.
코랩 시작하기: 파이썬, 머신러닝, 딥러닝을 시작할 때에 환경 설정이 필요로한데, 해당 환경 구축을 클라우드 환경에서 사용할 수 있게 구글 클라우드 서비스를 이용한 방법에 대한 설명이다.
Manual Bean Definitions in Spring Boot: Spring Boot환경에서 수동으로 Bean 정의를 하는 방법의 글이다. 중간에 @EnableAutoConfiguration의 어노테이션을 사용하지 않는다고 가정하는 경우이다. 그런데, 나는 해당 어노테이션이 정확하게 어떻게 동작하는지? 알고 있는지 생각해보니 없었다. 무언가를 쓸 때, 어떻게 동작하는지는 알고 쓰는 습관을 들이는 게 좋다는 생각이 들었다.
[번역] 확장성 있고, 이식성 있는 도커 컨테이너 네트워크 설계: 도커 컨테이너라는 점에 대한 부분을 이해하기 어려운데, 해당 아티클을 읽기전에는 도커 개념과 도커 Swarm에 대한 개념을 알고 있어야 이해하기 쉽다고 한다. 물론, 해당 개념에 대한 링크도 제공하고 있다.

기타

네이버 가격 비교의 비밀을 알고 최저가를 노려보자: 네이버 가격비교와 관련한 상품의 최저가에 대한 상세한 비교글인데, 분석한 수준이 굉장히 높다. 읽어보면, 최저가에 대한 해답이 보일것이라 생각한다. 우리는 누구나 싸게 살 권리가 있으므로?! ^^
어떻게 지루함이 당신을 더 창의적으로 만들까요?: 좋은 지루함과 나쁜 지루함이 어떻게 도움이 되는지에 대한 글인데, 지루함에 대한 부분을 조금 다른 관점으로 생각하는 점이 흥미롭다.
[좋은 기술 블로그를 만들어 나가기 위한 8가지 제언](https://www.44bits.io/ko/post/8-suggestions-for-tech-programming-blog**: 좋은 블로그를 만들어 나가는데는 완성된 글은 온전한 문장들로 이루어져야합니다*라는 글을 보고 반성을 많이 하게 되었다. 좋은 글을 쓰고, 좋은 정보를 공유하고자 하는데, 과연 나는 잘 지키고 있는지에 대한 의문이 생겼다. 그리고 튜토리얼을 작성할 때는 동작하는 예제를 작성하라는 예시는 정말 공감 많이 했다.

Weekly News #28

Sat, 19 Jan 2019 15:52:00 GMT

한 달 짜리 개인 프로젝트 이야기 (3) - Dvorak과 이별하다 - HappyProgrammer - Medium: 많은 사람들이 사용하는 것의 편리함과 공용성에 대해 생각 해볼 수 있는 글이다. 많이 사용한다는 것이 어떤 의미가 있는 것인지?
나의 공부 방법: 정말 대단하신 분이라고 생각하는 개발자 중의 한 분이신 이종립님의 이야기인데, 공감이 참 많이 간다. 나도 중학교시절부터 책을 좋아 했는데, 그 이후 뭐랄까 좋지 않은 습관이 머리말부터 인쇄 판쇄까지를 읽어야 하는 습관이었다. 책은 목차가 있는 이유가 있다. 시간이 지나면서 여유가 생기고, 끝까지 읽지 않고 필요한 부분만 읽는 성숙함이 자연스레 생기게 되었고, 그 맛이 있다. 다른 이들도 책으로 공부하는 맛을 느꼈으면 좋겠다.
[B급 프로그래머] 동작하게 만들고, 제대로 만들고, 빠르게 만든다: 개발자의 최우선은 결국 동작하는 코드를 만들어 내는 것이다. 그리고 아름다운 코드를 만들어야 하는 미션이 있다. 그럼에도 가장 중요한 것은 동작해야 의의가 있다는 말이 참 와 닿는다.
내 맘대로 위클리 뉴스 - 2019년 2주(2019.1.7 - 2019.1.13): vue.js를 이용해 인스타그램을 clone한 형태를 만들어 보는 링크가 있는데 이건 시간 나면 꼭 해보고 싶다.
세상에서 가장 이해받지 못하는 영웅, 데이터 과학자 (1/3): 데이터 사이언티스트란 무엇을 하는 사람들인가? 라는 적절한 Role을 이해하기란 어렵다. 이해하는 데에는 관심과 시간만 있으면 될 것 같다.
#retrospection 2018년 회고: 색다른 언어를 공부해서 실무에 도입해보는 것도 좋은 선택이라 생각한다. Eilxir라는 언어로 사이드 프로젝트와 실무에서 사용을 해보셨는데, 평이 괜찮은 것 같다. 일단, 바쁜 와중에도 학습하는 모습이 인상적이라고 할 수 있다.
VS Code에 console.log shortcut 추가하기: 기계인간 이종립님의 나의 공부 방법이란 위의 링크에도 있지만, snippets를 구축하는 것도 좋은 방법이 되지 않나?라는 생각을 해보게 된다. 물론 개발 생산성도 높이 올라가고, MacOS App을 하나 질렀는데, 나도 거기에 차곡차곡 하나씩 쌓아 올려 보려고 한다.
코딩 시험과 TDD: 코딩 시험이란게 사실, 높은자를 뽑기 위함이라기 보다는 낮은 사람을 거르기 위한 용도라 들었다. 그런면에서는 인정하는 바이다. 그렇지만 너무나 수준 높은 알고리즘 인터뷰는 면접자를 정말 힘들게 할 수 있으니 적정 선을 지키는 것이 중요하다는 생각이 든다.
Node v11.7.0 (Current) | Node.js
How to create a REST API with Express.js in Node.js - RWieruch
Is it worth learning Golang ?: Go lang 관심은 많으나, 실제로 써보고 싶은데, 아직 시작을 못한 언어이다. 추후에 도움이 될 거라 생각한다.
(JavaScript) Error 객체에 관하여: JavaScript를 만지다 보면 자주 만나지만, 막상 깊게 본적은 내용이라 가져왔는데, 잘 정리 되어 있다.
2018년 돌아보기: 리액트, 타입스크립트로 많은 글을 쓰시고, 공유해주시는 이현섭님의 회고이다. 좋은 내용이 참 많다. 그리고 철학이 있는 개발자라는 생각이 드는 회고였다.
이력서 - 이현섭: 이현섭님의 이력서를 우연히 보게 되었는데, 너무 좋아서 가져오게 되었고, 나도 이렇게 하나 만들고 6개월 단위로 하나씩 업데이트를 해볼까 한다.
How to learn React.js in 2019 - RWieruch: 2019년에 어떻게 ReactJS를 배워야하는지에 대한 글인데, 상세하게 되어 있으므로 주의하자…영어를 많이 읽어야 도움이 되는 것 같고, 변화의 해가 되는 시기가 아닐까 한다. 특히, Hooks가 이제 곧 릴리즈 될 날이 머지 않았다.
Why React Hooks: ReactJS17에서 추가 될 API인데, 좀 더 고차원적인 고뇌가 담긴 API라고 생각하게 되며, 좀 더 편리하고,순수 함수를 통한 개발하는 것이 결국에는 프로그래머에게 도움이 되는 방향으로 가고 있다는 생각이 들었다.
Create-react-app Mobx, Router 환경 구성 - 주노준호 블로그
Dockerfile 작성부터 이미지 배포까지 간단 요약: 안도형님의 도커 파일 작성부터 이미지 배포까지 하게 된 일련의 프로세스를 순서정연하게 정리해주신 글인데, 참고하면 좋을 것 같다.
Beginning Javascript Iterator and Generator
2019.01.10. 기술문서 번역 모임 참석 후기(Review of Technical document Translator Conference in Seoul, Korea)
루비(Ruby) 2.6 릴리즈 및 주요 문법 변경 사항 소개
2018년 하반기 회고: 내가 좋아하는 이동욱님의 회고이다. 이 분의 꾸준함과 노력을 따라갈 수 없다는 생각이 들었다. 정말이지…노력을 많이 하시는데, 항상 글에는 겸손과 자세 낮춤이 묻어나는 분이시다.
[개발]가능한 지키려하는 개발 원칙
OOP를 빨리 잊으라는 글에 대하여…: 지난 번 말했던 이야기에 비판?이라고 할 수 있다. 그렇지만, 이러한 비판과 적절한 대안을 이야기 하는 것을 옳다. 비방만 하는 것은 문제가 있다고 생각 한다. 특히, 개념의 이해는 어렵지만 한 번 뿌리 내리면, 굳건하게 실력의 버팀목이 되어 준다는 생각을 하게 되었다.
개발자를 어떻게 학습시키는게 효과적일까?. 자기반성 모드: 프론트엔드 개발자이신 손찬욱님의 자기 반성의 글이다. 무엇에 대한 반성인가는 개발자를 효과적으로 학습하시는 것에 대함이었다. 김창준님의 함께자라기라는 책을 읽고 난 후의 피드백을 톨해 자신의 삶을 반영시켜 생각해보신 글이다.
React에서 Mobx 경험기 (Redux와 비교기) - 우아한형제들 기술 블로그: 나는 Redux에 회의적이었는데, Mobx를 알게 된 이후 부터이다. 그런데 생각해보면, 서비스 마다 특성이 다르고, 뭘 적용해야 더 나은지?는 가늠하기 어렵다. 그럼에도 불구하고, Mobx는 블랙박스처럼 무언가 무언가 많이 해준다. 그러나, 그게 마냥 은탄환은 아니라는 점에서 명심해야 한다.
2018년, 내가 모르는 기술들: 2018년 내가 모르는 기술들이라는 글의 번역인데, 읽어보면 누구나 아! 하고 느낄 수 있는 글이며, 시니어 개발자도 그 분야에 대해 전부 알지 못한다는 점에서 내가 신입 사원이었을 무렵의 질문들이 생각 나 부끄러웠다. 시니어 개발자가 되면, 모든지 아는 사람으로 생각했던, 생각이 어렸던 그떄보다 지금은 더 나은 걸음으로 가고 있다는 생각이 떠올라 부끄럽기도 하면서 글을 읽으면서 재밌었다.

Weekly News #27

Sun, 13 Jan 2019 21:23:00 GMT

Intellij Spring DevENV with Docker: IntelliJ에서 Docker를 활용해 Tomcat 이미지를 이용해 개발하는 방법을 설명하는데, 기본적으로 IntelliJ가 어떻게 톰캣을 실행시키는 점을 찾아볼 생각을 못했는데, 상세하게 잘 정리 해주셨다.
프론트엔드 기술 조감도 : Babel: 안희종님의 Babel에 대한 글을 써주셨다. 사실 Babel이 워낙 방대해지고, 학습하기가 정말 쉽지 않다. (Document만으로는 절대 무리다.) 특히 발전하면서 히스토리에 대한 지식이 필요하다는 생각을 했는데,Babel을 학습하기에 좋은 글을 남겨주셨다.
자바스크립트 엔진의 최적화 기법 (2) - Hidden class, Inline Caching: 자바스크립트를 이용해 코드를 작성하다 보면, 정말 생각보다 어렵다. 왜냐하면, Java기반에서 코드를 작성하다 JavaScript 기반에서 작성하다 보면 패러다임이 다른데, 정말 이상한 코드가 많이 나와 성능이 느려진다. 그래서 JavaScript에 맞는 코드를 작성해야 한다고 생각하는 편인데, 그럴려면, 엔진에 대한 이해가 필요하다고 생각한다.
[번역] OOP를 빨리 잊을 수록 여러분과 여러분의 소프트웨어에 좋습니다: 조금 생각해보면, OOP가 생각보다 이론적으로 생각만큼 객체지향스럽게 코드를 작성하기란 어렵기 마련이다. 매순간 추상화를 고려해야하고, 플랫폼 개발 측면이 아닌 서비스 개발측면에서는 OOP가 맞지 않는 프로그래밍 스타일일수 있다는 생각을 하게 된다. 그런 점에서 정말 이런 글들은 객체지향을 욕하는 것이 아닌 진짜 의미 있는 비판일 수 있기에 읽어보면 좋다.
크롬 개발자 도구 101: 크롬 개발자 도구를 매일 사용하지만 어떻게 더 잘 쓸까?라는 고민을 하긴 헀지만, 막상 찾아보진 않았지만, 정리를 정말 잘 해주셨다.
비둘기로 설명하는 HTTPS(HTTPS explained with carrier pigeons): HTTPS라는 것을 설명하기 위해 비둘기와 상자를 비유하여 설명하는데, 전반적으로 이해하기 쉽다.
사례 기반으로 한 소프트웨어 엔지니어의 공부법: 여러 사례들을 통해 어떻게 공부해야 하는지 정리 된 글이다. 이름을 들어본 분들도 많다.
2018년 회고 - adhrinae: 트위터에서 좋은 글을 공유 많이 해주시는데, 번역도 정말로 활발하게 하시는 분이시고, 수준 높은 글들도 많이 작성하시는 분이시다. 그보다 공부를 정말 많이 하시는 것이 정말 놀라웠다. 나도 반성을 많이 하게 되는 글이었고, 시간을 쪼개어 글을 많이 보고 많이 코드를 작성해보는 것이 남는 것 같다.
Today I Learned - 2018년 Best of Best: 위의 회고를 하신 안도형님의 매일의 배운 기록인데, 다른 분들처럼 github를 이용한 것이 아닌 Bear라는 App을 통해서 모두 기록해두셨다는 점이 놀라웠다. 역시나 많은 공부를 하시는 분답게 깔끔한 정리로 많은 기록을 남겨두셨다.
2018년 회고 - kodingwarrior : 투자를 위해 Notion을 구입해 사용하셨다는 글을 보고, 나도 Notion을 사용하고 있지만, 구입해서 사용하진 않았는데, 어떤 이점이 있는지 궁금해졌다. 예전에는 이 바닥에서 살아남기 위해 내가 가진 Skill set을 늘리는게 중요하다는 생각을 했었는데, 이제는 Skill set보다는 숙련도에 더 신경을 써야한다.라고 쓴 말이 참 공감이 가는 문장이다.
Jbee.log(2018): Front-End에 좋은 글을 많이 써주시던, Jbee님의 회고이다. 가장 공감가는 글은 계획하지 않기라는 말이다. 나도 계획은 정말 많이 했는데, 1년동안 계획한 일을 제대로 하지 못했다.
[회고] Review 2018: 치즈님으로 유명하신 서지연님의 회고이다. 서지연님은 본래 카카오에 계셨다가, Facebook으로 이직을 하셨다. 꾸준히 공부를 많이 하시는 편이고, 내가 가장 부러운건 영어를 잘 하셔서, MOOC 강의를 정말 잘 이용하신다는 점이다.
2018년 회고 - outsiders: 블로그에 꾸준히 수준 높은 글을 공유해주시는 outsider님의 회고록이다. 생각해보면, 정말 많은 시간을 공부하고 그 시간을 공유하는데 힘써주시는 분이라 항상 감사한 생각을 가지고 있다. 나의 롤모델 중 한분이시고, 정말 대단하다고 생각한다. 수면 시간이 4시간정도는 되야 저렇게 할 수 있을 것 같다.
내가 받은 최고의 커리어 조언: 이미 그 이상의 일을 하고 있는 사람이라는 말이 참 공감간다. 결국 누군가는 승진해야하고, 누군가는 맡은 역할(Role) 이상의 일을 하고 있는 모습을 본다. 그럼 그 사람이 그 팀을, 그 부서를 이끄는 것이 맞다.
[번역] 더 나은 개발자가 되는 8 가지 방법: 더 나은 개발자가 되는 방법이지만, 이미 여러번 봤을 듯한 문장도 있다. 그런데, 중요한 것은 결국 많이 보고, 많이 해보고, 많이 생각해보기라는 생각이 든다.
Vim에 매료되다. (Feat.Happy Hacking): 올 한해 목표가 Vim을 모든 영역에서 활용하는 것이다. 여전히 Practice Vim이란 책을 다 읽지 못했고, 뭐랄까? 옆에 껴놓고 하나씩 봐야할 것 같다. 1주일에 1 vim tips를 작성해보는 것도 좋을 것 같다. 시작해보자.
기술 업계의 독성 말투 문제, 고칩시다!: 말을 잘하는 것은 중요하며, 다른 이를 존중하는 것도 중요하다. 나는 잘하고 있었는지? 앞으로도 이 글의 내용을 잘 생각하고, 유념하고 말하고, 글 써야 한다는 것을 깨달았다.
프레임워크 공부를 멈춰라: 이 글을 읽으면서 나는 요즘 얼마나 프레임워크, 핫한 라이브러리를 공부하기 위해 힘썼는지 깨달았다. 그런데, 정말로 이 글의 내용이 맞다는 것이 핫한 기술들을 쓰면서 꺠닫는데, 적절한 시기에 뭔가 계몽할 수 있는 글을 읽을 수 있게 되어 좋았다.
내게 뒤쳐질 수 있는 행복을 허락하라: 개발자로 일하게 되면, 가장 착각하고, 스트레스로 작용하는 점은 항상 내가 무언가 공부해야하고, 앞서가야 한다는 점이 개발자를 괴롭힌다는 점이다. 생각해보면, 우리는 변화의 폭풍속에서 살아가는 직업인지 모른다. 그렇기에 항상 채찍질을 하는 직업인지도 모른다. 그래서 항상 마음 한켠에는 **공부해야 하는데 **라는 걱정속에 살아가는 개발자를 위해 공유하게 되었다.

Weekly News #26

Wed, 31 Oct 2018 00:40:00 GMT

그냥 저냥 위클리뉴스 #26

JavaScript

명령형 자바스크립트 클래스를 함수형 선언적 코드로 바꾸는 8단계: 원문도 출처로 명시되어 있고, 번역글이긴 한데, 번역이 정말 잘 되어 있다고 생각 했다. 그리고 코드로 표현되어 있고, 함수형 패러다임에서 주요한 합성함수, 순수함수, 커링등 개념들이 많이 나와 있어서 학습하기 좋다.
[NodeJS] nodejs는 single-thread가 아니다: 나도 그렇게 알고 있던 사실이었는데, CPU 관련 부하가 큰 경우는 다른 Thread에서 작업한다는 사실이 놀라웠다. 정말 몰랐던 내용을 쉽게 설명 해 준글.
TypeScript Generic: TypeScript의 Generic의 번연본인데, 사실, TypeScript가 interface, class를 만지다 보면, 굉장히 복잡하게 사용을 할 수 있다. 거기에 Generic의 내용인데, 이해하기에 난도는 높다.
reduce() 를 이용해 순차적으로 프라미스를 해결하는 방법은 어떻게 동작하는가?: 정말 유용한 글이라 생각한다. reduce를 이용한 Promise 사용은 사실 흔하게 사용하는데 어떻게 동작하는지에 대해서는 모를 수 있다. 그것의 궁금증을 해결해 줄 수 있는 글.
Redux vs. The React Context API: React 16.3 버전에서 추가 된 Context API와 Redux의 사용 비교한 글이다. 서로의 내용을 깊이 있게 참고할 수 있는 좋다.
Javascript Iterator: for-of의 설명과 함께, Iterator에 대한 설명을 하는데, 굉장히 자세하게 써있다.
Higher-Order Function 이란 무엇인가: HOF라고 보통 표현하기도 한다. React에서도 유사하게, HOC로 많이 쓰는 형태이다. 함수형 패러다임에서 없어서는 안되는 강력한 개념이다. 알아두어야 할 내용이다.
Async-await는 어떻게 구현하는가: async, await은 Koa를 사용하면, 바로 사용이 가능한데, Promise Hell에서 벗어나게 해주고, 비동기 처리를 동기식처럼 선형적인 코드로 만들어준다. 근래들어서 필수적으로 알아야 하는 개념 중 하나라 생각한다.
What are React Hooks?: React Hooks이라는 개념이 등장 했다. 릴리즈 된 건 아니지만, 리액트로 개발 하는 이들의 관심을 끌고 있는 컨셉이다. React Component 클래스를 사용하지 않고, 함수형 컴포넌트로도 React Hooks을 이용해 개발할 수 있도록 돕는다고 하는데, 정확하게 이해는 못했다.

Java

신규 포인트 시스템 전환기 #1 - 개발 단계
신규 포인트 시스템 전환기 #2 - 오픈 준비 단계
Installing OpenJDK 11 on MacOS
What Does it Mean to Be ‘Reactive?’: Reactive라는 의미를 어떤건지 알 수 있도록 쓰여져 있으나, 이해는 쉽지만 코드로 작성하기는 어렵다는 생각이 든다.
What Features Would You Want to See in Java 12?: Java12에서 Raw String literal이 제일 마음에 든다.
Preview Raw String Literals in IntelliJ IDEA 2018.3: Java12의 기능 중 하나인 Raw string literal을 Intellij 2018.3 사용할 수 있다.

Kafka

[Kafka] 콘솔 명령어 모음

Article

IBM, 오픈소스업체 레드햇 340억弗에 인수: IBM에서 레드햇을 인수 했다!!! 앞으로 어떻게 될지가 궁금해졌다!!!
태도가 지능보다 중요한 이유
좋아하는 일만 하며 사는 법
[B급 프로그래머] 초급 개발자가 알아야 하는 12가지 기술
[B급 프로그래머] 10월 4주 소식(개발/관리도구, 고성능 서버/데이터베이스 부문)
{ 고퀄리티⚡️개발 컨텐츠 모음 }

MacOS Tip

macOS에서 SSH Key 암호를 그만 요구 당하기

Weekly News #25

Sun, 07 Oct 2018 23:17:00 GMT

그냥 저냥 위클리 뉴스 #25

읽어보면 좋을 글

돈이 되지 않는 일을 할 권리 : 돈이 되지 않은 일이라는 것은 무엇을까라는 고민을 해본 적이 있었을까? 내가 하는 것은 회사에 가서 업무를 해내고, 그러한 활동만 노동이라고 생각했다. 그런데, 이 글에서 그 생각을 여지없이 부숴버리는 문장이 있다. “우리는 일 하지 않으면, 논다고 생각한다는 것이다. 그 이유는 우리에게 활동에 관련된 언어가 일과 놀이만 존재하기 때문이다.” 이 글을 읽으면서 무언가 쿵 하고 머리를 맞은 것 같았다.
적극적 소득 vs 소극적 소득 : 적극적 소득과 소극적 소득에 대한 이해를 할 수 있는 아티클이다. 사실, 매일 매일 좋은 글이 발행되는데, 내가 잘 찾아서 못봐서 그렇지 여기는 항상 좋은 글이 많은것 같다.

Java

Java 11 and IntelliJ IDEA: Java11이 드디어 릴리즈 되었다. 벌써 11이 되어 오다니, 7,8에서 업데이트가 늦은 만큼 빠른 릴리즈를 하고 있다. 대신에 중요한 포인트는 OpenJDK로 퍼블릭 업데이트를 하고, OracleJDK는 구독모델이 생겼고, 상업에서 사용하는 서비스들은 11까지만 사용이 가능하다. 확인한 바로는 그렇다. 그런데, 누구보다 빠르게 IntelliJ는 업데이트를 빠르게 진행해 Java11도 지원하게 되었다.
Understanding Spring Reactive: Servlet 3.1/Spring MVC Non-Blocking IO: Servlet 3.1부터 논블럭킹 IO를 지원했었으나, 실제로 대부분 그렇게 사용하지 않았다. 물론, 지금은 비동기 논블럭킹 IO를 사용 할 수 있다. 스프링 프레임워크 5부터는 MVC framework, WebFlux 둘 중 하나를 선택해 사용할 수 있다. 웹플럭스를 사용하기 이전에 논블럭킹 IO에 대해서도 공부 할 필요는 있다.
90 New Features and APIs in JDK 11 (Part 1): 우선 제일 신기한 점은 람다 표현식 내에서 로컬 변수를 만들어 사용할 수 있다. 이부분은 아주 유용하게 쓸 수 있을 것 같다. 더 대박인건 String클래스에 isBlank가 생겼다. 그 외에도 유용한 것들이 많이 생겼다.
90 New Features and APIs in JDK 11 (Part 2): ZGC의 개선이라고 해야할까? 그 부분도 놀랍지만, 나즈혼이 Deprecated 되었다는 점, 확인 해야 할 점이 늘었다.
The Second Edition of “Refactoring”: 마틴 파울러의 리팩토링 책이 두번째 판이 출간 되었다. 한국어로 나오기에는 시간이 좀 걸릴 것 같고, Safaribooks online에는 이미 올라와 있다. 이 책은 메인 언어가 JavaScript로 되어있다고 한다.
Debugging Java Streams With IntelliJ: IntelliJ에서 스트림에 대한 디버깅을 지원하는데, 잘 모르는 경우가 있다. 특히, 스트림의 처리는 내부 반복, 내부 파이프라인에서 처리 되므로 그냥 확인이 어렵다. 그러한 부분을 IDE가 해결해준다.
REST API Error Handling With Spring Boot: REST API에서 에러 처리를 어떻게 해야 할지? 고민이 되기 쉬운데, 많은 걸 봐야 감이 오는 것 같다. (여전히 REST API는 어렵다.)

JS

Dan Abramov: Beyond React 16 | JSConf Iceland 2018 : 각기 다른 컴퓨팅 파워, 네트워크 환경에서 어떻게 동일한 사용자 경험을 줄 수 있을 것인가?에 대한 물음으로 나온 아이디어 2가지를 소개한다. Time Slicing, Suspense라는 것으로 CPU, IO에 대응하는 기법이다. 뭐랄까. 그냥 천재다.
30 seconds of code - JavsScript: 자바스크립트로 목적에 따라서 구현된 코드를 소개한다. 물론, snippet으로 등록해서 사용해도 될 정도이다. 이렇게 구현된 코드로 공부를 하는 방법도 좋은 방법 같다. 왜냐하면, 이미 집단 지성으로 만들어진 코드이지 않을까? 그렇다면, 더할나위 없는 코드 공부가 된다.
React Global State without Redux
Create React App 2.0: Babel 7, Sass, and More: CRA가 드디어 2.0이 나왔고, 업데이트를 쉽게 할 수 있다. 일단 바벨7으로 올라 갔고, <></>와 같은 Fragment 또한 쉽게 사용이 가능해졌다.
How to prevent a rerender in React
Vue.js 참고 자료

ML

케라스를 이용해 seq2seq를 10분안에 알려주기 : 쉽게 말하면, 특정 시퀀스를 이미 학습하고 다른 시퀀스를 학습하는 형태인데, 해당 내용에서 말하는 것은 하나의 도메인에서 다른 도메인으로 시퀀스 변환학습 하는 것을 말한다.
지도/비지도학습과 강화학습 풀이법 : 기본적인 설명이지만, 어려움을 느낄 수 있다. 그 속에서 중요한 점은 강화학습은 보상이 포인트라는 사실을 알 수 있다.
딥러닝의 Hello World, Fashion-MNIST : 기본적인 예제이지만, 케라스를 통해서 딥러닝에 대해 공부 할 수 있다는 점에서 좋은 예제가 아닐까 한다. 원래 튜토리얼이 조금 어렵다고 느끼기 마련인데, 코드도 github에 있으니 더 좋다.

Weekly News #24

Sun, 09 Sep 2018 15:52:00 GMT

그냥 저냥 위클리 뉴스 #24

Java

CompletableFuture 비동기 처리로 성능 개선하기 : woniper님이 개인 프로젝트를 하시는데, 성능 관련 이슈가 생기니 스프링에서 비동기 처리를 하는 방식으로 바꿔서 효과를 보신 것 같다. 사실, 나도 이 부분에 대해서 이제서야 막 보고 있는데, JavaScript와 비슷하게 프로그래밍이 가능해졌다는 사실에 놀라고 있다. 대부분의 언어들의 비동기 처리가 비슷한 구조를 가져가는 것 같다.
카카오 개발자 컨퍼런스 2018 참석 후기! : 카카오로 합병 이후 컨퍼런스를 최초로 개최한게 아닐까 싶었는데, 사실 가고 싶었는데, 참가자로 선정 되지 못했는데, 창천향로님이 정리를 세세하게 해주셨고, 거의 당일 바로 올려주셨다. “고수들은 타자가 빠른 것 같다”라는 이상한 논제에 점점 부합 되는 분들이 많아지고 있다.
JDBC로 실행되는 SQL에 자동으로 프로젝트 정보 주석 남기기 : outsider님의 기술 뉴스를 보고 괜찮다 생각하고 본 글이다. MSA로 전환하면서, 과도기 시기에 사용하면 좋을 것 같고, MSA에서도 계속 사용하면 좋을 것 같다.

Node / JavaScript

Node v10.10.0 (Current) : Node v10.10.0이 릴리즈 되었다. vm.compileFunction이 추가 되었는데, 좀 봐야 할 것 같다. http2모듈이 이제 정식으로 지원 되는 것 같다. 그 밖에 os, process, child_process 등 모듈에 변화가 있었다.
Babel 7 Released : babel 7이 벌써 나왔다. 사실, 그간 프론트 엔드에 취중한 개발자보다 서버쪽 개발이다보니, 관심에서 밀렸는데, 벌써 7이 릴리즈 되었다. 선택적으로 설정이 가능한 overrides라는 옵션이 추가 된 것으로 보인다.
What’s Coming Up in JavaScript 2018: Async Generators, Better Regex : JavaScript2018에서 핫한 것은 정규식과 Async Generators로 보이는데, Async Generators는 push-pull model이라고 하는데, 정확하게는 찾아봐야 할 것 같다.
실무에서 사용하는 Vue.js 프로젝트 구조: 제가 항상 즐겨 찾는 블로그인데요. Vue.js 관련 책도 쓰신 것으로 알고 있습니다. (하지만, 제가 React를 하게 되는 상황이라) Vue.js는 마음속으로만 응원하고 있는데요. 언젠가는 제가 일 하는 업무에 실제 적용을 하고 싶긴 합니다. 사실 여전히 React < Vue.js에 마음을 더 두고 있습니다. 실제 실무에서 사용할 수 있는 프로젝트 구조를 소개해주는데, 소확팁이 아닐까 합니다. 프로젝트 구조가 뭐가 중요하냐? 이럴 수 있지만, 엄청 중요합니다. 소소한 것 같지만 확실한 꿀팁이라고 생각합니다.
타입스크립트, 써야할까?: 타입스크립트를 써야 하냐 말아야 하나에 대한 고민은 끊이지 않는 것 같습니다. 하지만, 동적 타입보다 정적 타입으로 프로그래밍을 하게 될 경우 버그를 미리 탐지가 가능하다는 점에서는 좋습니다. 물론 그러한 말도 있습니다. 타입 스크립트가 타입 관련 버그를 방지해줌으로 생산성이 올라가게 된다. 하지만, 이는 TDD로도 충분히 커버가 가능하다는 평도 있고요. 제가 생각 하기에는 생산성은 개개인의 차의 문제라 지표화하기 어렵다 판단 되나, 버그를 미리 탐지 할 수 있다는 점은 좋은 것 같습니다. 물론 Flow가 더 좋냐는 취향의 문제인 것 같지만, 요즘은 거의 대부분 타입스크립트를 도입하고 있는 것 같습니다.
AMD, CommonJS, UMD 모듈: 지난 포스트이긴 하지만, 너무 좋은 내용이라 첨부하게 되었습니다. AMD, CommonJS, UMD 도대체 뭐가 뭔지 모르겠다 하시는 분은 이 포스팅을 읽어보길 권합니다.

그 밖의 읽을 거리

[B급 프로그래머] 9월 1주 소식(빅데이터/인공지능, 암호화폐/블록체인, 읽을거리 부문) : B급 프로그래머 블로그의 빅데이터, ML, 블록체인등 위클리 뉴스 모음집이다. 이렇게 많은 자료를 계속 보시고, 정리 해주시는 것이 놀랍다. 나도 다양하게 하고 싶은데, 실질적으로 부족한게 사실인데, Python으로 시각화 하는 방법에 대한 포스팅이 앞으로 점점 더 내가 관심을 갖게 되는 부분인 것 같다. 너무 신기하고, Jupyter notebook과 연동하면, Python은 못할게 없는 수준이 되는 것 같다.
기술 뉴스 #109 : 18-09-01: 조직의 동의를 얻는 법이라는 글이 참 와닿는다. 확실히 조직에서 일하면서 닥치는 상황은 내 안건에 대해 아무런 의견도 없고, 반대만 있을 경우이다. 그 반대가 “귀찮음”에 귀결되는 근거라면, 되게 황당하기도 하다. 더 좋을 것 같으니 도입 하자는 의견에 “귀찮음”을 이유로 반대하는 것은 실로 황당한데, 이러한 상황을 여러번 거치면, 이런 글을 읽고 무릎을 타악! 하고 치게 되는 것 같다.

ansible-playbook file send to multiple directory

Fri, 10 Aug 2018 00:39:00 GMT

Ansible-playbook 여러 디렉토리 확인 후 해당 디렉토리에 파일 전송하기

상황을 간략하게 설명하자면, 이런 상황이 생길 수 있다고 가정했습니다. 예를 들어, 한 서버 (target)에 apache, tomcat을 사용한다고 생각해봅시다. 이 때에, tomcat은 인스턴스를 2개 사용합니다.

생각해보면, 한 물리 서버에 인스턴스 2개인 tomcat이 존재하는 겁니다. 이 때 tomcat을 업데이트 한다고 가정하겠습니다. 그렇다면, copy 혹은 template 명령어를 가지고 target 서버 내의 tomcat 두 디렉토리에 설정 파일을 전송해야 합니다. 어떻게 작성 할 수 있을 까요? 저는 아래처럼 작성 했습니다.

- name: set tomcat config
  template:
    src: 'roles/{{ host }}/templates/{{ item }}-server.xml.j2'
    dest: '/seungdols/dev/app/{{ item }}/conf/server.xml'
    owner: seungdols
    group: seungdols
    mode: 0644
    backup: yes
  with_items:
    - tomcat1
    - tomcat2

다만, 이렇게 될 경우에는 문제가 조금 발생합니다. 어떤 문제일까요? 사실 서버 관리를 하다보면, 수 많은 서버들의 설정을 하는데, 미묘하게 다른 경우가 있습니다.

여기서 저의 개발자적인 고민은 만약! target서버 내에 tomcat2 디렉토리가 존재 하지 않다면, 어떨까요? 만약 다른 설정은 같지만, tomcat 인스턴스가 하나인 서버인 예를 들고 싶습니다.

그래서 고민이 시작 되었습니다. Ansible의 심도 있게 공부한 사람도 아니기때문에 이러한 자그마한 난관도 크게 다가오게 되더군요.

고민의 답을 찾아 가는 과정을 적도록 하겠습니다.

- name: Check directory of tomcat1
  stat:
    path: /seungdols/dev/app/tomcat1
  register: tomcat1_dir

- name: Check directory of tomcat2
  stat:
    path: /seungdols/dev/app/tomcat2
  register: tomcat2_dir

그 첫 시작이 디렉토리 체크였습니다. tomcat1, tomcat2 디렉토리가 있다면, stat으로 체크 후 해당 값을 register로 저장하였습니다.

많은 서버들 사이에 tomcat 인스턴스가 2개가 올라간 서버와 tomcat 인스턴스가 1개만 올라간 서버를 동시에 조작하는 것을 목표로 하기 위해서였습니다.

그리고, 설정 파일을 보내야 하는데, 어떤 타겟 서버는 tomcat1, tomcat2 디렉토리가 존재하고, 어떤 서버는 tomcat1 디렉토리만 존재한다면, 제가 작성 한 위의 파일 전송하는 시나리오는 실패합니다.

- name: set variable for tomcat directories
  set_fact: tomcat_directory="['tomcat1']"
  when: tomcat1_dir.stat.exists

- name: set variable for tomcat directories
  set_fact: tomcat_directory="['tomcat2']"
  when: tomcat2_dir.stat.exists

- name: set variable for tomcat directories
  set_fact: tomcat_directory="['tomcat1', 'tomcat2']"
  when: (tomcat1_dir.stat.exists) and (tomcat2_dir.stat.exists)

그리하여, 디렉토리 존재유무에 대한 리턴 된 값을 이용하여, 특수한 변수를 만들게 되었습니다. 위의 생각을 하게 된 것은 stackoverflow의 글을 보고는 생각이 났습니다!

참고 - Is it possible to set a fact of an array in Ansible?

위의 글을 보고 앗! 왜 변수를 만들 생각을 못했을까 생각했다. 바로 set_fact라는 명령어로 변수 값을 만들 수 있다. 물론 Asnible 2.0부터는 loop_vars라는 것도 쓸 수 있다고 하지만, 저의 목적과는 달랐습니다.

그래서 위의 방식을 조합하여, template을 사용하는 것을 약간 변경하여, 저의 목적을 달성 할 수 있을거라 생각했습니다.

그런데, 변수가 제대로 안찍히는게 아닙니까! 저는 tomcat_directory라는 array내의 element 값을 사용하고자 했습니다.

- name: debug tomcat_directory
  debug: var={{ item }}
  with_items:
    - tomcat_directory

초기에는 이렇게 값을 찍어 봤으나, 자꾸만 tomcat_directory가 찍히는게 아닙니까…:( 그렇지만, 찾아보니 어떻게 값을 찍어야 하는지 찾게 되었습니다. 제가 원하는 대로 값을 찍으려면, 아래처럼 해야 합니다.

- name: debug tomcat_directory
  debug: var={{ item }}
  with_items:
    - '{{ tomcat_directory }}'

이렇게 해주어야 제가 원하는 array내의 element 값이 출력됩니다.

그래서 완성된 것은 아래와 같습니다.

- name: Check directory of tomcat1
  stat:
    path: /seungdols/dev/app/tomcat1
  register: tomcat1_dir

- name: Check directory of tomcat2
  stat:
    path: /seungdols/dev/app/tomcat2
  register: tomcat2_dir

- name: set variable for tomcat directories
  set_fact: tomcat_directory="['tomcat1', 'tomcat2']"
  when: (tomcat1_dir.stat.exists) and (tomcat2_dir.stat.exists)

- name: set variable for tomcat directories
  set_fact: tomcat_directory="['tomcat1']"
  when: tomcat1_dir.stat.exists

- name: set variable for tomcat directories
  set_fact: tomcat_directory="['tomcat2']"
  when: tomcat2_dir.stat.exists

- name: Set server.xml for tomcat
  template:
    src: 'roles/{{ host }}/templates/{{ item }}-server.xml.j2'
    dest: '/seungdols/dev/app/{{ item }}/conf/server.xml'
    owner: seungdols
    group: seungdols
    mode: 0644
    backup: yes
  with_items:
    - '{{ tomcat_directory }}'
  tags:
    - copy_tomcat_config

부족하지만, 사실 저는 이렇게 Ansible을 사용하고 있습니다.

handler도 자주 사용하진 않지만, 그래도 playbook을 여러개 만들고, 다시 합치고 하다보니 나름의 잔머리가 늘은 것 같습니다.

개발자에게도 유용하다고 생각합니다. 다만, 클라우드 환경에서는 활용하기가 훨씬 쉽지만, 사내 시스템 제약이 있는 경우에는 조금 어려운 것이 사용해본 후기입니다.

도움이 되셨으면 합니다. 저는 위의 내용을 위해서 중복 시나리오를 작성하는 경우가 굉장히 많았습니다. 플레이북의 리팩토링을 대거 할 생각입니다.

systemd guide

Wed, 04 Jul 2018 15:57:00 GMT

CentOS7 systemd 사용하기

RHEL7의 OS의 큰 변화로는 init 데몬에서 systemd 데몬으로 변경되었다.

service 파일은 크게 Unit, Service, Install 로 나뉜다고 생각하면 쉽다.

[Unit]
Description=Sample Service
Requires=local-fs.target
After=local-fs.target

[Service]
Type=simple
PIDFile=/var/run/sample.pid
ExecStart=/usr/sbin/sampled -d
ExecStop=/usr/sbin/sampled -k

[Install]
WantedBy=multi-user.target

출처: http://fmd1225.tistory.com/93 [fmd1225’s One day]

systemd 서비스 등록을 위해서는 서비스 등록용 파일이 필요로 하다.

해당 파일을 /lib/systemd/system/[service name].service or /etc/systemd/system/[service name].service 의 경로에 생성 해주어야 한다.

사실 위 파일에 들어가는 옵션은 아래에서 알아보고, 예시로 logstash를 서비스로 등록한다고 했을때, 아래와 같이 파일을 생성한다.

$ sudo vi /lib/systemd/system/logstash.service

예시) logstash.service

[Unit]
Description=logstash service

[Service]
Type=simple
User=logstash
Group=logstash
ExecStart=/home/seungdols/apps/logstash/bin/logstash -f home/seungdols/apps/logstash/conf/logstash-test.conf
WorkingDirectory=/
Nice=19
LimitNOFILE=16384

[Install]
WantedBy=multi-user.target

위와 같이 생성할 수 있으며 사용하기 위해서 파일의 권한을 변경해준다.

$ sudo chmod 644 /lib/systemd/system/logstash.service

시스템이 reboot되거나 할 경우에도 재시작을 하기 위해서는 아래와 같이 설정을 해준다.

$ sudo systemctl enable logstash.service

수동으로 시작하기 위해서는 아래 명령어를 입력하면 된다.

$ sudo systemctl start logstash.service #종료는 stop 명령어가 있다.

상태를 확인하는 방법으로는 status명령어로 확인 하는 방법이 있다.

$ sudo systemctl status logstash.service

Systemd option

해당 옵션은 potatogim wiki인 이곳에서 발췌하였습니다.

Unit

Description=

해당 유닛에 대한 상세한 설명을 포함한다.
Requires=

상위 의존성을 구성한다. 필요 조건으로서, 이 목록이 포함하는 유닛이 정상적일 경우 유닛이 시작된다.
RequiresOverridable=

“Requires=” 옵션과 유사하다. 하지만 이 경우 “사용자에 의해서” 서비스가 시작하는데 상위 의존성이 있는 유닛 구동에 실패 하더라도 이를 무시하고 유닛을 시작한다. (즉 상위 의존성을 무시한다.) 자동 시작의 경우 적용되지 않는다.
Requisite=, RequisiteOverridable=

“Requires=” 와 “RequiresOverridable=” 와 유사하다. 상위 의존성 유닛이 시작되지 않았다면 바로 실패를 반환한다.
Wants=

“Requires=” 보다 다소 완화된 옵션이다. 충분 조건으로서, 상위 의존성 목록에 포함된 유닛이 시작되지 않았더라도 전체 수행 과정에 영향을 끼치지 않는다. 이 옵션은 하나의 유닛을 다른 유닛과 연계할 경우 사용하게 된다.
BindsTo=

“Requires=” 와 매우 유사하다. 네트워크 카드가 물리적 장애가 발생한 경우와 같이 systemd의 개입이 없이 갑작스레 서비스가 사라진 경우 관련된 유닛도 같이 중지하도록 설정한다.
PartOf=

“Requires=” 와 매우 유사하다. 상위 의존성의 유닛을 중지하거나 재시작하는 경우 해당 유닛 또한 중지나 재시작을 수행한다. 하나의 서비스가 다른 하나의 일부로서 의존성을 만들어내는 경우 필요하다.
Conflicts=

베타적 관계를 설정한다. 만일 ‘유닛1’ 의 “Conflicts=” 설정이 ‘유닛2’ 로 되어 있다면 ‘유닛1’이 시작된 경우 ‘유닛2’가 중지되고, ‘유닛1’이 중지된 경우 ‘유닛2’가 시작한다. 이 옵션은 “After=” 와 “Before=” 옵션과는 독립적으로 작동한다.
Before=, After=

유닛 시작의 전후 관계를 설정한다. 해당 설정은 “Requires=” 설정과는 독립적이다. “Before=” 에 나열된 유닛이 시작되기 전에 실행하고 “After=” 은 해당 유닛이 시작된 이후 나열된 유닛이 실행한다. 시스템 종료 시에는 반대 순서로 동작한다.
OnFailure=

해당 유닛이 “실패” 상태가 되면 수행할 유닛 목록 (예 ”/” 파일 시스템 마운트 실패시 복구 모드 수행)
PropagatesReloadTo=, ReloadPropagatedFrom=

재구성(reload) 명령을 다른 유닛에게 전파하거나 혹은 지정된 다른 유닛으로부터 재구성(reload) 명령을 전파 받는다.
RequiresMountsFor=

절대 경로로 지정하여 유닛을 구동하는데 필요한 마운트 목록을 자동으로 구성하여 “Requires=”, “After=” 을 수행한다. 즉 필요한 마운트 경로가 준비되어 있는지 점검하고 마운트를 미리 진행한다.
OnFailureIsolate=[yes|no]

“yes” 인 경우 “OnFailure=” 에 선언된 목록과는 격리 모드(isolation mode)로 작동한다. 즉 해당 유닛에 종속성이 없는 모든 유닛은 중지된다. “OnFailureIsolate=yes” 인 경우 “OnFailure=” 옵션에 하나의 유닛만 설정 할 수 있다.
IgnoreOnIsolate=[yes|no]

“yes”인 경우 다른 유닛과 격리(isolation)할 때 중지하지 않는다.

Service

Type=[simple|forking|oneshot|notify|dbus]

유닛 타입을 선언한다.”simple” (기본값) - 유닛이 시작된 경우 즉시 systemd는 유닛의 시작이 완료됐다고 판단한다. 다른 유닛과 통신하기 위해 소켓을 사용하는 경우 이 설정을 사용하면 안된다.”forking” - 자식 프로세스 생성이 완료되는 단계까지를 systemd가 시작이 완료되었다고 판단하게 된다. 부모 프로세스를 추적할 수 있도록 PIDFile= 필드에 PID 파일을 선언해 주어야 한다.”oneshot” - “simple” 과 다소 유사하지만 단일 작업을 수행하는데 적합한 타입이다. 또한 실행 후 해당 실행이 종료되더라도 RemainAfterExit=yes 옵션을 통해 유닛을 활성화 상태로 간주할 수 있다.”notify” - “simple” 과 동일하다. 다만 유닛이 구동되면 systemd에 시그널을 보낸다. 이때 시그널에 대한 내용은 libsystemd-daemon.so에 선언되어 있다.”dbus” - D-Bus에 지정된 BusName 이 준비될 때까지 대기한다. 다시 말해서, D-Bus가 준비된 후에 유닛이 시작되었다고 간주한다.
RemainAfterExit=[yes|no]

유닛이 종료된 후에도 활성화 상태로 판단한다.
GuessMainPID=[yes|no]

이 옵션은 “Type=forking”이고, “PIDFile=“(빈 값)인 경우에 작동한다. systemd가 유닛이 정상적으로 시작되었는지 명확한 판단이 어려운 경우에 사용된다. 만일 여러 데몬 프로세스로 구성된 유닛이라면 PID를 잘못 추측할 수도 있다. 그로 인해 오류 검출이나 자동 재시작 등의 작업이 불가능 할 수 있는데, 이 옵션은 이러한 문제를 방지하는 기능을 한다.
PIDFile=

PID 파일의 절대 경로를 지정한다. 만일 유닛 타입이 forking 이라면 해당 설정을 추가해 주어야 한다.
BusName=

D-Bus의 버스 이름을 지정한다. Type=dbus 인 경우 필수 사항이다. 다른 Type 의 경우라도 D-Bus 버스 이름을 다르게 사용하는 경우 별도로 설정을 해주는 것이 좋다.
Environment=

해당 유닛에서 사용할 환경 변수를 선언한다. 또한 반드시 “Exec*=” 옵션보다 상단에 위치해야 한다. 예제는 아래와 같다.

Environment='ONE=one' 'TWO=two two'
EnvironmentFile=

해당 유닛에서 사용할 환경 변수 파일을 정의한다. 환경 변수 파일에서 ”#” 와 ”;” 로 시작되는 라인은 주석으로 처리된다. “Environment=” 와 같이 사용하는 경우 “Environment=” 옵션값이 먹게 된다. 또한 반드시 “Exec*=” 옵션보다 상단에 위치해야 한다.
ExecStart=

시작 명령을 정의한다. 실행 명령어는 반드시 절대 경로 또는 변수(${STRINGS}와 같이)로 시작해야 하며, 다중 명령어를 지원한다. 예제는 아래와 같다.

ExecStart=“commnad1”

ExecStart=“command2”

ExecStart=“command3”

혹은 ExecStart=“command1; command2; command3”
ExecStop=

중지 명령을 정의한다. 사용법은 “ExecStart=“와 동일하다. 중지 방식은 “KillMode=” 로 지정된다.
KillMode=[control-group|process|none]

중지 방법에 대해서 선언한다.”control-group” (기본값) - 해당 유닛의 그룹에 포함된 모든 프로세스를 중지 시킨다.”process” - 메인 프로세스만 중지 시킨다.”none” - 아무런 행동도 하지 않는다.여기에서 그룹은 어떤 유닛과 그에 종속성을 가지는 다른 유닛들을 말한다.
ExecReload=

재구성을 수행할 명령을 정의한다.
ExecStartPre=, ExecStartPost=, ExecStopPre=, ExecStopPost=

유닛 시작, 중지 등의 동작과 관련하여 수행할 추가 명령을 정의한다. 사용법은 “ExecStart=” 동일하다.
RestartSec=

재시작 명령을 수행할 때, 중지 후 다시 시작하기까지 대기(sleep)하는 시간을 설정한다. 기본값은 “100ms” 이다. 각각 “min”, “s”, “ms” 단위로 설정한다. 해당 설정은 Restart= 옵션이 있는 경우에만 적용된다.
TimeoutStartSec=

유닛의 시작이 완료될 때까지 대기하는 시간을 설정한다. 기본값은 90초(90s)이며, 만일 Type=oneshot 인 경우 해당 설정이 해당 설정이 적용되지 않는다. 만일 시작 완료에 대해 반환이 될 때까지 대기하려면 “TimeoutStartSec=0” 으로 설정한다.
TimeoutStopSec=

유닛의 중지가 완료될 때까지 대기하는 시간을 설정한다. 기본값은 90초(90s)이며, 위의 “TimeoutStartSec=” 옵션과 동일하게 “TimeoutStopSec=0” 으로 설정하면 반환이 될 때까지 대기한다. “TimeoutStopSec” 에 설정된 시간 안에 종료되지 않으면 SIGKILL 시그널을 보내서 강제로 종료시킨다.
TimeoutSec=

“TimeoutStartSec=” 와 “TimeoutStopSec=” 을 동시에 설정한다.
WatchdogSec=

유닛 시작 후에 주기적으로 생존을 감시하기 위한 질의(keep-alive ping)를 하는데, 이 질의가 반환되까지의 대기 시간을 설정한다. “Restart=” 옵션이 “on-failure”, “always” 인 경우 유효하며, 여기에 지정된 시간 안에 응답이 없다면 자동으로 유닛을 재시작한다. 기본값은 “0” 으로 유닛의 생존을 감시하지 않는다.
Restart=[no|on-success|on-failure|on-watchdog|on-abort|always]

유닛이 죽었거나 “WatchdogSec=“에 지정된 생존 응답 시간이 초과한 경우 재시작한다. “ExecStartPre=”, “ExecStartPost=”, “ExecStopPre=”, “ExecStopPost=”, “ExecReload=” 에 설정된 유닛의 경우에는 포함되지 않으며, 이 유닛에만 해당된다.”no” (기본값) - 유닛을 다시 시작하지 않는다.”on-success” - 유닛이 정상적으로 종료됐을 경우에만 재시작한다. 종료 시 “0”을 반환했거나, SIGHUP, SIGINT, SIGTERM, SIGPIPE와 같은 시그널 또는 “SuccessExitStatus=” 설정에서 지정된 반환 코드 목록에 따라 모두 성공으로 인식해 재시작을 하게 된다.”on-failure” - 유닛이 비정상적으로 종료된 경우에 재시작한다. 반환이 “0”이 아닌 경우나 비정상적인 시그널을 받고 종료된 경우, “WatchdogSec=“에 지정된 생존 응답 시간을 초과한 경우에 유닛을 재시작한다.”on-watchdog” - “WatchdogSec=“에 지정된 생존 응답 시간을 초과한 경우에 유닛을 재시작한다.”on-abort” - 지정되지 않은 반환을 받은 경우에 유닛을 재시작한다.”always” - 종료 상태에 관계없이 무조건 재시작하며, 수동으로 중지하더라도 다시 시작됨을 주의해야 한다.
SuccessExitStatus=

성공으로 판단할 시그널을 설정해 준다. 아래의 예를 참고하자.

"SuccessExitStatus=1 2 8 SIGKILL"
RestartPreventExitStatus=

재시작하지 않을 반환을 정의하며, 굳이 재시작하지 않아도 되는 반환이 있다면 유용하다.

"RestartPreventExitStatus=1 6 SIGABRT"
PermissionsStartOnly=[yes|no]

“User=”, “Group=” 옵션 등과 같이 권한 설정을 적용하여 시작한다. 해당 설정은 “ExecStart=“에서만 적용되며, “ExecStartPre=”, “ExecStartPost=”, “ExecReload=”, “ExecStop=”, “ExecStopPost=“에서는 적용되지 않는다.
User=, Group=

유닛의 프로세스를 수행할 사용자/그룹의 이름을 지정한다.
RootDirectoryStartOnly=[yes|no]

프로세스의 루트 디렉토리를 지정한다. chroot() 함수를 사용하여 구동된다. 해당 설정은 “ExecStart=“에서만 적용 되며 “ExecStartPre=”, “ExecStartPost=”, “ExecReload=”, “ExecStop=”, “ExecStopPost=“에서는 적용되지 않는다.
RootDirectory=

chroot() 함수로 변경할 디렉토리를 지정한다.
WorkingDirectory=

프로세스의 작업 디렉토리를 지정한다. 별도의 지정이 없으면 유닛은 최상위 디렉토리(”/“)를 작업 디렉토리로 사용한다. 특정 디렉토리 상에서 실행되는 프로세스에서 필요하다.
NonBlocking=[yes|no]

소켓 기술자에 O_NONBLOCK 플래그를 사용한다. yes일 경우 STDIN/STDOUT/STDERR을 제외한 모든 소켓에 O_NONBLOCK 플래그가 지정된다. 즉 사용되는 모든 소켓이 비봉쇄로 동작한다.
NotifyAccess=[none|main|all]

서비스 상태 알림 소켓으로의 접근을 제어한다. 해당 접근은 sd_notify() 함수를 사용한다.”none” - 유닛 상태에 대한 모든 정보를 무시한다.”main” (기본값) - 메인 프로세스에 대해서만 상태 정보 알림을 허용한다.”all” - 모든 유닛. 즉 컨트롤 그룹의 유닛 상태 정보 알림을 허용한다.”Type=notify” 혹은 “WatchdogSec=“가 설정된 경우 “NotifyAccess=“를 “main” 혹은 “all”로 설정하여 접근 가능하게 설정해야 한다.
Sockets=

유닛에서 사용하는 소켓의 이름을 지정한다. 기본으로 “<유닛명>.socket”으로 생성되지만 지정된 이름으로 소켓을 사용하는 경우 별도의 설정이 가능하다. 또한 하나의 유닛에서 여러 소켓 목록을 일괄적으로 관리하는 경우 “Sockets=” 옵션이 여러번 사용될 수도 있다. 만일 “Sockets=” 옵션이 아무런 설정 없이 단독으로 사용되는 경우 소켓 목록이 리셋되게 된다.
StartLimitInterval=, StartLimitBurst=

위의 두 설정값을 이용하여 제한된 시간에 너무 많은 재시작 (“Restart=”) 이 발생되는 것을 방지한다. 기본값에 따르면 10초 간격으로 5번까지 서비스 시작을 허용하고 이후에 재시작 이벤트가 발생하면 자동으로 재시작하지 않도록 설정한다. 유닛 재시작 이벤트가 무한으로 발생하는 것을 방지하며, 추후 관리자가 수동으로 복구할 수 있도록 한다.”StartLimitInterval=” 옵션의 경우 기본값 10초(10s), “0” 으로 설정할 경우 비활성화한다.”StartLimitBurst=” 옵션의 경우 기본값 5회.
StartLimitAction=[none|reboot|reboot-force|reboot-immediate]

만일 복구 재시도가 제한된 설정 (Service Recovery Limit > StartLimitInterval * StartLimitBurst) 내에 완료되지 않는다면 어떠한 조치를 취할 것인지 정의한다.”none” (기본값) - 아무런 조치도 하지 않는다.”reboot” - 시스템을 재부팅한다. (systemctl reboot과 동일)“reboot-force” - 메모리 상의 데이터를 디스크와 동기화한 후에 시스템을 강제로 제부팅한다. (systemctl reboot -f와 동일)“reboot-immediate” - 메모리 상의 데이터를 디스크와 동기화하지 않고 바로 시스템을 강제로 재부팅한다.
Nice=

해당 유닛의 프로세스의 nice 값을 지정한다. “-20” 부터 “19” 까지 정수형으로 등록한다.
OOMScoreAdjust=

OOM(Out Of Memory) killer 작동 시 프로세스 우선 순위를 미리 지정할 수 있다. “-1000” 에서 “1000” 까지 정수형으로 등록한다.
UMask=

umask 값을 선언한다. 별도의 설정이 없으면 기본값은 “0022” 이다.
SyslogFacility=

로그 시설을 설정할 수 있다. “kern, user, mail, daemon, auth, syslog, lpr, news, uucp, cron, authpriv, ftp, local0, local1, local2, local3, local4, local5, local6, local7” 등의 값으로 설정 가능하다.
SyslogLevel=

로그 수준을 설정할 수 있다. “emerg, alert, crit, err, warning, notice, info, debug” 등 설정이 가능하다.
TCPWrapName=

TCP 래퍼를 사용하기 위한 설정이다.
PAMName=

PAM 보안을 사용하기 위한 설정이다.

Install

Alias=

유닛의 별칭을 지정한다. “systemctl enable” 명령어를 통해서 별칭을 생성할 수 있다. 별칭은 유닛 파일 확장자(유닛 타입)를 가지고 있어야 한다.

(service, socket, mount, swap 등이 있다. 예: httpd.service 의 Alias=apache.service)
WantedBy=, RequiredBy=

“systemctl enable” 로 유닛을 등록할 때 등록에 필요한 유닛을 지정한다. 해당 유닛을 등록하기 위한 종속성 검사 단계로 볼 수 있다. 따라서 해당 설정은 [Unit] 섹션의 “Wants=” 와 “Requires=” 옵션과 관계 있다.
Also=

“systemctl enable”과 “systemctl disable”로 유닛을 등록하거나 해제할 때, 여기에 지정된 다른 유닛도 같이 등록, 해제하도록 할 수 있다.

출처

weekly-news #23

Sun, 20 May 2018 12:36:00 GMT

그냥 저냥 #위클리뉴스 #23

JS

자바스크립트에서 사용되는 this에 대한 설명 1 : 자바스크립트의 this를 공부하는 건 자바스크립트를 하는 사람에게는 넘어야 할 산이라고 생각한다. 그런데, 좋은 페이지가 있어서 나중에도 계속 보기 위해 위클리 뉴스로 가져왔고, ES5에서 나온 use strict;모드의 대한 차이가 존재하는 것까지도 설명을 해준다.
자바스크립트에서 사용되는 this에 대한 설명 2 : 1편에 이은 javascript의 this에 대한 시리즈 글로 상당히 상세하게 케이스별로 설명을 해주는데, 이에 대한 내용은 꼭 숙지해야 this에 대한 오해가 없을 것 같고, 의미없는 시간 낭비를 하지 않을 수 있을거라 생각한다.
이벤트 버블링, 이벤트 캡쳐 그리고 이벤트 위임까지 : 이벤트에 대한 버블링, 캡쳐링에 대한 이해도 상당히 중요하다는 생각을 요즘에서야 더 많이 쓰기게 되고 있습니다. 그에 대해 캡틴님 블로그에 잘 정리 되어있어서 가져오게 되었고, 자바스크립트를 좀 더 잘 쓰기 위해서는 이 개념들의 확실한 이해가 필요로 하다고 생각한다.

Java

Spring Batch의 동작 코드 #step 생성과 실행 : spring batch에 대한 시리즈를 쓰고 계신데, 기초적인 내용인것 같지만, 분석하시는 내용이 상당히 상세하게 되었기에 Spring batch에 관해서 처음 접하는 사람이라면 보면 좋을 것 같다.
Spring Batch의 동작 코드 #Job생성과 실행 : Spring Batch의 Job생성과 실행에 대한 부분의 설명글인데, 나는 Spring Batch에 대해서는 조심스럽게 접근 하는 편이다. 왜냐하면, 생각보다 작은 실수로 엄청나게 긴 시간을 헛되게 보낼 수 있다.
결제 시스템 성능, 부하, 스트레스 테스트 : 줌에서 일하셨던 것 같은데 어느새 우아한 형제들에서 일하고 계신 권용근님이 작성한 우아한 형제들 블로그의 포스팅인데, 요즘 내가 관심 갖는 주제이기도 하고, 스트레스 테스트는 정말 어려운 일이라 조심스럽기도 하다. 사실 어떤 변수에 의해 테스트는 정말 달라지기도 한다. 그럼에도 불구하고, 상세하게 해당 작업에 대해 써주셨다. 이런 일들에 대한 중요한 참고자료가 될 것이라 생각한다.

Web

기술 뉴스 #102 : 듀랑고를 했던 유저로써 반가운 글이 포함되어 있는 outsider님의 블로그 기술뉴스이다. 이번편에는 듀랑고 데이터 엔지니어의 로그 관련 포스팅이 가장 인상적이었다. 로그 시스템에 대한 부분은 중요하면서도 생각보다 설계 및 운용에 대한 부분들이 워낙 세세하게 고려해야 할 것들이 참 많다. 그럼에도 불구하고 아주 세세하게 자료를 남겨주신 전효준님께 감사 인사를 드려야 할 것 같다. 로그 시스템 구축이라는 것은 쉽지 않은 작업인데, 5초이내에 조회 및 시각화까지라니…(그저 놀라울따름..) 이런 것들이 가능한 것은 사스가 AWS의 힘도 톡톡히 보는 것 같다.
IntelliJ 무료버전에서 Spring 5 MVC프로젝트 구축 : Hika님의 회사 블로그인데, 정말 알짜 글들이 쏟아지는 블로그중에 하나이다. 오늘의 글은 스프링5 프로젝트 셋팅 방법인데, 이를 인텔리제이 무료버전에서 구성하는 방법을 소개해주셨다. 사실, 셋팅이 정말 중요하다. 익숙해지도록 하자.
오픈 소스로 만들어진 Mac app : 오픈 소스로 만들어진 여러가지의 유용한 Mac apps들을 모아둔 곳이다. 보니 해커뉴스를 바로 받아오는 앱도 있다. 여러가지 쓸모 있는 어플리케이션들이 있어서 유용한 것 같다.
[MSA] #1 Monolithic Architecture 란?
[MSA] #2 Microservice Architecture 란?
[MSA] #3 Circuit Breaker
[MSA] #4 API Gateway
[MSA] #5 Service Discovery
[MSA] #6 Spring Cloud Netflix

install jenv

Mon, 14 May 2018 22:08:00 GMT

java 여러개 버전 사용하기 (MacOS)

Jenv 및 java 설치

jenv 를 통해 Java environment를 관리 하려고 합니다.

$ brew install caskroom #미리 설치 되어 있어야 합니다.
$ brew install jenv
$ brew cask install java #가장 최신 버전으로 설치 됩니다.
$ brew cask install java8 #java8 버전 최신 릴리즈로 설치됩니다.

일단 위와 같이 실행을 하여 java를 설치해주시면 됩니다.

cask 오류 발생할 경우

❯ brew cask install java8
Error: Cask 'java8' is unavailable: No Cask with this name exists.

위와 같은 에러가 발생할 경우 아래와 같이 입력해주시면 됩니다.

brew cask install caskroom/versions/java8

설치된 java 확인

$ cd /Library/Java/JavaVirtualMachines
$ ll
drwxr-xr-x - root 14 5 21:42 jdk-10.0.1.jdk
drwxr-xr-x - root 27 4  2017 jdk1.8.0_131.jdk #기존에 사용하던 버전
drwxr-xr-x - root 14 5 21:45 jdk1.8.0_172.jdk

jenv에 java version 등록하기

$ mkdir -p ~/.jenv/versions
$ jenv add /Library/Java/JavaVirtualMachines/jdk-10.0.1.jdk/Contents/Home
$ jenv add /Library/Java/JavaVirtualMachines/jdk1.8.0_172.jdk/Contents/Home

등록이 잘 되었는지 확인을 해봅니다.

$ jenv versions

jenv로 java version 변경하기

global

$ jenv global 1.8.0.172
❯ jenv versions
  system
  1.8
* 1.8.0.172 (set by /Users/seungdols/.jenv/version)
  10.0
  10.0.1
  oracle64-1.8.0.172
  oracle64-10.0.1

local

~/dev/practice/java9 master*
❯ jenv local 10.0

~/dev/practice/java9 master*
❯ jenv versions
  system
  1.8
  1.8.0.172
* 10.0 (set by /Users/seungdols/dev/practice/java9/.java-version)
  10.0.1
  oracle64-1.8.0.172
  oracle64-10.0.1

rabbitmq 서버 터트리고 살리기 (akka. file discriptor가 문제다.)

Mon, 23 Apr 2018 22:00:00 GMT

파일 디스크립터 갯수 올리려다가 rabbitmq 터진 사건 파일 디스크립터 갯수가 1024개로 되어 있으나, OS의 파일 디스크립터 갯수는 81920개까지 사용 가능하다.

$ ulimit -n #명령어로 갯수 확인이 가능하다.

rabbitmq를 처음 셋팅하게 되면, 기본적으로 file discriptor 갯수가 1024개로 셋팅이 되는 것 같다. 그런데, rabbitmq-server를 재시작하면, OS 커널에 대한 옵션을 자동으로 가져오는 것 같다. (혹은 아닐 수도 있습니다.)

그래서 노드 1번을 냅두고, 노드 2번부터 stop_app으로 어플리케이션을 중지시키고, rabbitmq-server를 중지시켰다가 다시 시작 시켰다. 바로 file discriptor 갯수가 증가했다.

그 후 노드 1번을 증가시키고자 노드 1번을 내린 후 재시작을 해도 file discriptor가 증가하지 않았다. 이유가 무엇일까? (이에 대한 이유를 잘 모른다.)

[root@server sbin]$ sudo /sbin/service rabbitmq-server start
Redirecting to /bin/systemctl start rabbitmq-server.service
Job for rabbitmq-server.service failed because the control process exited with error code. See "systemctl status rabbitmq-server.service" and "journalctl -xe" for details.

위와 같은 에러가 나면, 일단 두려워 해야한다.

그렇게 파일 디스크립터를 위한 시작 > 재시작을 하다가 급 에러를 내뿜기 시작했다.

BOOT FAILED
===========

Error description:
   init:do_boot/3
   init:start_em/1
   rabbit:start_it/1 line 454
   rabbit:broker_start/0 line 330
   rabbit_plugins:setup/0 line 124
throw:{error,
         {cannot_delete_plugins_expand_dir,
             ["/var/lib/rabbitmq/mnesia/rabbit@hostname-plugins-expand",
               {cannot_delete,
                   "/var/lib/rabbitmq/mnesia/rabbit@hostname-plugins-expand/rabbitmq_management-3.7.0/include/rabbit_mgmt.hrl",
                   eacces}]}}
Log file(s) (may contain more information):
   /var/log/rabbitmq/rabbit@hostname.log
   /var/log/rabbitmq/rabbit@hostname_upgrade.log

그런데, 이것의 문제점은 rabbitmq서비스가 떠있는데 서버 중지조차 되지 않는다.

아래도 안먹힘

[root@hostname ~]$ sudo /sbin/rabbitmq-server stop
ERROR: node with name "rabbit" already running on "hostname"
$ sudo rabbitmqctl start_app #안먹힘
$ sudo rabbitmqctl stop_app #안먹힘

그런데 신기한 점은 rabbitmq-server 프로세스가 계속 떴다가 죽었다가 한다. /usr/lib64/erlang/erts-9.1.5/bin/epmd -daemon 이런 프로세스가 계속 떠있다.

죽었다가 한다.

/usr/lib64/erlang/erts-9.1.5/bin/beam.smp 이런 프로세스도 떴다가 죽는다.

$ systemctl status rabbitmq-server.service
rabbitmq-server.service - RabbitMQ broker
   Loaded: loaded (/usr/lib/systemd/system/rabbitmq-server.service; disabled; vendor preset: disabled)
 ~~~
 Process: 11561 ExecStop=/usr/sbin/rabbitmqctl shutdown (code=exited, status=69)
 Process: 10413 ExecStart=/usr/sbin/rabbitmq-server (code=exited, status=1/FAILURE)
 Main PID: 10413 (code=exited, status=1/FAILURE)

추측, epmd process와 비정상적으로 종료된 rabbitmq process가 충돌나는게 아닐까?

rabbitmq-server는 구동이 안되는 상태, stop하려해도 이미 동작중이라거나, start하려고 하면, plugin 관련한 에러로 rabbitmq broker가 제대로 실행되지 않는다.

그러나, rabbitmq 프로세스는 떠있음.

epmd -deamon이 살았다가 죽었다가 하면서, rabbitmq 프로세스를 살리는 것 같다.

해결 방안

추측에 근거 epmd -deamon과 rabbitmq-server process를 kill…

pkill -9 -ef process_name을 통해 미친듯이 종료시켜도 계속 실행됨.

결론적으로 무언가가 계속 무한 프로세스 생성이 되게끔 하는 녀석이 존재함.

어떻게 하지?

/var/lib/rabbitmq/mnesia/이 디렉토리가 하는 역할을 모르겠다. 다만, 분명한건 에러로그에 나오고 해당 디렉토리 하위의 plugin 관련 문제가 발생했다.

참고

그러던 중 rabbitmq-server fails to start on Red Hat Openstack Platform 7의 문서에서 Resolution을 따라보기로 했다.

rm -rf /var/lib/rabbitmq/mnesia/*를 하고, systemctl start rabbitmq-server를 하면 된다고 나오나, 이렇게 해봐도 동작하지 않았다.

$ sudo cd /var/lib/rabbitmq
$ sudo rm -rf mnesia/ #directory 전체를 삭제
$ sudo /sbin/server rabbitmq-server stop #정상적으로 동작함.

위 처럼 아예 디렉토리 자체를 삭제했다. 그리고 사실 rabbitmq server를 복구하기 위해서 여러 명령어를 쳤었다.

사실 되살리고 보니 설정들이 전부 날아갔었다.

왜일까? 생각해보니 reset명령어를 쳤었는데, 그게 적용이 되었었나 보다.

그래서 rabbitmq 설정을 다시 하고, definitions file을 다시 import 시켜서 기존 설정을 복구 할 수 있었다.

그리고 다시 clustering을 셋팅 해주었다.

다시 복구하고 보니, file discriptor 갯수는 1024개로 롤백되었다…

다음에 다시 해보자.

Weekly News #22

Sat, 17 Mar 2018 13:17:00 GMT

그냥 저냥 #위클리뉴스 #22

How to choose the right NoSQL database : NoSQL database를 선택하는데에 어떤 기준으로 선택할지에 대한 글인데, 읽어두면 좋을 것 같다. (시간이 남거나 영어를 잘 했다면, 번역을 했을 수 있지만..) 실력 부족으로 번역을 하진 못했다.
인도의 시골 소년, 이빨 빠진 마이크로소프트라는 공룡을 부활시키다! : MS사의 새사령탑이 유례없는 엔지니어 등용도 등용이지만, 그의 혜안이 나는 MS를 여기까지 끌고올 수 있는 발판을 마련한 사람이라고 판단한다. 단일 플랫폼에서 크로스 플랫폼 지향으로 나아가며, 모바일 퍼스트 클라우드 퍼스트를 슬로건으로 내세웠다는 점에서 그는 MS의 항해사로 옳음 결정을 했었다고 생각한다.
책을 좋아하면 심심한 사람인가요? : 책을 좋아하는 것과 심심한 사람간의 관계가 있을까 싶기도 했다. 그렇지만, 전부가 아니라는 생각도 했다. 사람의 취향의 문제를 간혹 옮고 그름의 문제로 이어가는 경우가 있다. 여행을 가야 청춘일까? 그저 소비에 중독된 것은 아닌지 의심해야 할 수 있다. 결국 모든 것은 자신의 좋고 싫음인 취향 차이다. 이상하게 생각하지 말자.
인사 안하고 퇴근해도 됩니다: 워라벨 함정에서 벗어 나기 : 인사 하고 안하고의 차이는 무엇일까? 인사를 꼭 하고 퇴근해야 하는 것에 대한 의문이 많아지는 시대가 요즘처럼 또 없을 것 같다. 인사 하고 안하고의 문제 이면 속에 있는 문제가 더 큰 원인이 아닐까? 상사가 퇴근을 하지 않으면, 줄줄이 사탕처럼 눈치만 보고 있던 관습 같은 것이 더 문제가 아닌가 싶기도 하다. 오히려 그 문제를 해결하면, 이 문제가 해결 될것이라 생각한다.
리액트 Advanced guides 후반부 노트 : 리액트의 가이드 페이지를 따라하면서 남긴 노트인데, 잘 정리를 해주셔서 리액트를 공부하는 이에게 도움이 될 수 밖에 없는 글이다.
사고를 쳐도 혼나지 않는 회사 : 포스트모멘텀이라는 것을 잘 하기 위한 회사가 늘어나고 있다. 그래서 나는 이러한 일에 관심이 많고, Infra관련 일에도 관심이 많아 요즘은 SRE에 관심을 가지고 있는데, 이러한 문화가 중요한 것 같다. (약간 사고 발생에 책임 보다는 앞으로의 How?에 관심을 갖는 회사가, 문화가 중요하리라 생각한다.)
기술 뉴스 #98 : React보다 Vue.js를 선호하는 이유에 대해 정리한 글이 있는데, 나는 그 글에 찬성하는 입장이기도 하다. 사실 React가 너무 만능키에 가깝다고 생각하는 사람들이 많아지는데, 나는 반대한다. React, Node.js를 통한 Universal Rendering이 과연 만능에 가깝다고 생각하진 않는데, 그런 글들이 많아 좀 아쉽기도 하다. 기술은 기술로 봐야 하는 것 같다.
Webpack 4.0: release today : 웹팩이 요즘 gulp, grunt를 밀어내고 핫하게 build tool로 자리 잡고 있는데, 벌써 4.0이 나오게 되었고, 이번에 업데이트 된 내용이 무엇인가 확인하는 것도 좋을 것 같다.
Naver Tech talk: FE devtalk 9회,10회 : Naver에서 FE에 관한 테크톡을 열었다고 하는데, 사내 개발자 대상이었지만, 영상으로 제작하여 영상을 공유 하게 됐네요. 특히나, 이번에는 SSR이 관심을 갖게 할만한 요소라고 생각하게 되었습니다. 생산성 측면에서 좋다고는 하는데, 저는 경험해본적은 없습니다.
B급 프로그래머 3월 2주 소식(빅데이터/인공지능, 암호화폐/블록체인, 읽을거리 부문) : 항상 다채로운 정보를 모아서 정리해주시는데, 정말 읽을거리가 넘쳐나고, 이 분 블로그의 소식지만 봐도 트렌드가 무엇인지를 알 수 있게 된다. 특히나, 블록체인, 인공지능 부분은 필수로 읽을 것! 특히나, 블록체인은 너무 미지의 세계라 이용할 만한 기술은 넘쳐나고 있으나, 실제 개발할 사람이 부족하다는 것이 현재의 상황이라는 글이 딱 알맞다는 생각도 했다. (나도 블록체인을 공부 해봐야 할 것 같다.)
1년 반정도의 원격근무 경험 : outsider님이 블로그에 본인의 경험기를 공유해주셨는데, 너무나 공감이 많이 가는 부분이 많다. 출근을 함으로써 손해가 되는 날에는 어떻게 해결 할 것인가?에 대한 스트레스만 줄어도 업무에 대한 효율은 높아지는 것 같다는 생각을 했다.
LINE 개발자 커뮤니티 탄생 : LINE 개발자들의 열정은 대단하기도 하고 놀랍기도 한데, 오픈소스 공헌도 많이 하는 편이라 생각하는데, 이제는 커뮤니티를 만들게 되었다니, 나와 같은 주니어 개발자들은 더 좋은 공간이 생긴 것 같아서 좋다. 특히 해외 개발자들도 LINE API를 많이 쓰기에 해외 개발자들과도 소통 할 수 있다는 점이 좋다.
내 맘대로 위클리 뉴스 - 2018년 11주(3월 12일) : 파이썬으로 메타 프로그래밍을 하는 포스팅이 참 좋은 것 같은데, 요즘 파이썬과 Node.js를 관심가지고 있고, 그 외로는 clojure라는 언어에 관심 갖는데, 특히 요즘은 메타 프로그래밍, 매크로 프로그래밍등과 같은 패러다임이 조금씩 인기를 얻는 것 같다. 그런점에서 파이썬으로 메타프로그래밍을?이라는 생각을 가지고 읽어볼만 하다.
HTTPS와 SSL 인증서, SSL 동작방법 : 초보몽키님의 블로그인데, 본인이 공부한 네트워크 지식을 잘 정리해주셨기에, 보면서 나도 알고 있었다고 생각한 부분에 대해서도 다시 한 번 확인하고, 또 몰랐던 부분들도 공부하게 되는 글이어서 공유하고 싶었다. 특히, 웹 개발자들은 네트워크 지식을 조금은 잘 알고 있어야 한다는게 내가 나의 멘토님께 배운 첫번째다. 고로, 중요하므로 정독해보자.

Weekly News #21

Mon, 12 Mar 2018 22:24:00 GMT

그냥 저냥 #위클리뉴스 #21

뒤늦은 2017년 돌아보기 : 2017년의 일들에 대한 기록들이 정말 잘 정리 되어 있고, 달별로 어떤 일이 발생했고, 기술적으로 어떻게 해결했는지에 대한 이야기들이 써져있다.
내 맘대로 월간뉴스 - 2018년 02월 : 처음 도커를 시작하는 사람들을 위한 글, 자바스크립트 비동기 처리와 콜백 함수에 대한 글, github를 이용해 댓글을 사용하고 싶을때등, 수많은 유용한 글들의 모임이 월간 단위로 정리 되어 있다.
리액트 quick start 노트 : 요즘 리액트가 프론트엔드 개발의 많은 부분을 차지하고 있긴 하다. 그렇기때문에 리액트에 대해 공부할 필요가 있긴 하다. 업무상 프론트를 담당하고있으므로…
NullableJ: Handling Null in Java : 간단하게 본 글이지만, Java에서 Null만 잘 처리해도 에러의 절반은 확 줄어드는 것은 맞다고 생각한다. 그런 점에도 볼만하다.
PWA 시작하기 : PWA를 적용했을때, 좋을 서비스 구조라면 적용해볼법 하지 않은가?라는 생각을 하기도 합니다. 그럴려면, PWA가 무엇인지에 대해 공부할 필요가 있겠죠? 이 글로 한 번 시작해보는 것이 어떨까요?
Spring boot 2.0 on ACID! + Spring Boot : Spring boot가 2.0이 릴리즈 되었는데요. 해당 버전과 관련하여 직접 코드와 함께, 설명하는 글이라 저는 좋다고 판단했습니다.
MongoDB hasNext() and next() Example : MongoDB를 요즘 많이 쓰시는데, 해당 글에 도움이 될만한 글입니다. 커서에 대한 설명도 나오니까요! (정독 가즈아!!!)
Cheatsheet: Java Functional Interfaces : Java8로 넘어오면서 생긴 functional interface에 대한 치트시트입니다. 치트시트로 정리해둔 글을 정독하는 것만으로도 생산성을 빠르게 올릴 수 있겠죠?
MongoDB count() and itcount() Example : MongoDB의 카운트 관련 예제입니다. 요즘 몽고디비를 관심있게 보려고 합니다. 그렇기에 예제의 글을 많이 보게 되네요.
Spring @Lazy annotation use cases : @Lazy라는 어노테이션에 대해서는 처음 본 건데, 생각보다 유용해보입니다.
ElasticSearch Tutorial for Beginners : ElasticSearch는 요즘 대부분 많이 사용하지만, 실질적인 사용이 생각보다 어려울 수 있는데, 이렇게 예제를 올려주는 친절한 분들이 계시네요!
IntelliJ IDEA 2018.1: Kubernetes support : 2018년 버전의 인텔리J는 쿠버네이츠 플러그인도 지원해주게 됐네요!
광광 울며 정리하는 JavaScript의 this : javascript의 this의 개념을 잘 정리해두는 것이 자바스크립트와 친해지는데 가장 좋은 일 같습니다…헤맬때가 한 두번이 아니라는게…
TypeScript: 타입 추론과 타입 단언 : TypeScript의 인기도 요즘은 당연시 되고, React + TypeScript 조합을 쓰는 걸 한 두번 본게 아니기에 중요하다고 생각합니다. 그 중에서 타입에 대한 설명을 자세하게 해주고 있습니다.

Weekly News #20

Mon, 26 Feb 2018 23:28:00 GMT

그냥 저냥 #위클리뉴스 #20

intelliJ에서 Json작업 쉽게 하기 : 언제나 좋은 양질의 글을 올려주시는 창천향로님이시다. 특히, IntelliJ 팁을 잘 알려주시는데 이는 굉장히 중요하다. 생산성을 올리는데에 개발툴이 얼마나 익숙한지에 따라 확연하게 달라진다.
기술 뉴스 #96 - outsider : 신입 프론트엔드 개발자가 무엇을 공부해야 하는지에 대한 포스팅은 흥미롭다. 나는 풀스택을 하고 있으나, 둘다 못하는 잔재주를 부리고 있으므로, 내가 열심히 봐야하는 글이다.
Go 언어 설치 : Go 언어는 신기한게, 잘쓰시는 분들은 엄청 좋다고 하면서, C같은 Python이다라고도 하시지만, 정작 잘쓰기까지가 어렵다고 너무 많이 들어서 무섭다.
내 맘대로 위클리 뉴스 - 2018년 08주(2월 19일) : Node.js로 만들어 볼 수 있는 블록체인의 포스팅이 마음에 든다. 사실 블록체인 블록체인하는데, 정확하게 나도 뭔지 감이 안온다. 대충 저장하는 공간 같다.
B급 프로그래머 - 2월 3주소식: 언제나 좋은 블로그라는 사실에 놀랍고, 인공지능 또는 머신러닝등에 있어서도 좋은 포스팅 링크를 정리 잘 해주시는데, 이번에는 개발/관리도구, 고성능 서버/데이터베이스 부문의 글입니다.
28세 요우의 개발자 이직 대탐험 : 요우님인데, 관심 있게 보고 있는 블로그이기도 합니다. 도움도 많이 받았구요..+ㅁ+ 이직기가 왜이리 재밌어보이는지 모르지만, 정리를 잘 해주셔서 좋습니다.
이상한 모임 - 2017년에 구매한 책을 모아보자. : 이모의 운영진이자, 코파운더라고 부를 수 있는 @minieetea님이 쓰신 글입니다. 그리고 이분의 블로그 또한 양질의 글이 많죠. 물론 서비스 기획자이시지만, 개발력도 어느 정도 있으신…갓기획자..랄까요. 구매한 책 리스트를 회고하는 것도 좋은 포스팅이 되겠네요. 한수 배웠습니다.

삭제한 local branch 복구하기

Wed, 13 Dec 2017 00:24:00 GMT

Git branch를 지워버렸을때, 침착하게 복구하자!

reflog를 기억하라!

$ git branch # check
$ git reflog
$ git checkout -b [deleted-branchName] HEAD@{number}

위의 명령어만 기억하면 된다. 사실, 깃은 모든 Action을 파일로 떨군다고 생각해도 될 것 같다.

오오..갓토발즈형님!!

즉, 삭제한 브랜치도 reflog를 통하여 복구 할 수 있다.

HEAD가 가리키는 커밋이 바뀔 때마다 Git은 자동으로 그 커밋이 무엇인지 기록한다. 새로 커밋하거나 브랜치를 바꾸면 Reflog도 늘어난다. “Git 레퍼런스” 절에서 배운 git update-ref 명령으로도 Reflog를 남길 수 있다. 이 것이 git update-ref를 꼭 사용해야 하는 이유중에 하나다. git reflog 명령만 실행하면 언제나 발자취를 돌아볼 수 있다

위의 인용은 git-scm.com에서 하였습니다.

즉, Git을 잘 쓰는 방법은 자주 망가뜨려 보되, git update-ref를 잘 쓰는 것이 좋다.

그럼 다음에는 어떻게 망가뜨릴지 고민해보겠습니다.

Weekly News #19

Sun, 26 Nov 2017 23:43:00 GMT

그냥 저냥 #위클리뉴스 #19

Article

깃헙 pages에 깃북 배포하기 : Gitbook은 메뉴얼이나, API를 작성하는데 많은 도움이 됩니다. Github는 사실 코드 호스팅이라면, Gitbook은 git을 통해 문서를 버저닝 하는데 도움을 주며, template을 통해 카테고리에 따라 선택해 문서 관리를 하면 된다.
기술 뉴스 #89 : 17-11-01 : 뭐니 뭐니해도 스타웍스 개발기가 제일 재밌다. 더군다나, GraphQL을 위한 프레임워크가 탄생하게 되었는데, 이제는 REST보다 GraphQL의 시대가 점점 올까 싶기도 하다.
기술 뉴스 #90 : 17-11-15 : GraphQL에 대한 부분이 가장 인상적이기도 하다. 아마 현존하는 API 구조를 GraphQL로 전부를 옮기긴 어려워도 일부는 적용 할 수 있을 것 같고, 그로인해 이점을 많이 얻을 수 있을 것 같다. (물론, 러닝커브가 좀 있다는 것이…어느정도의 노오력이 필요해보인다.)
내 맘대로 위클리 뉴스 - 2017년 47주(11월 24일) : vue.js로 블로그를 만드는 링크가 인상적이고, Gitlab에서 Vue.js의 사용기를 쓴 글이 관심이 간다. (개인적으로 내년에는 Vue.js를 공부하고 싶다.)
본격 macOS에 개발 환경 구축하기 : MacOS를 쓴다면, 이 정도는 기본으로 셋팅하고 있어야 한다고 생각하는 편인데, 정말 말끔하게 정리를 잘 해주셨다. 그런데, 여기서 빠진 것이 autojump이다. 이것까지 설치 후 셋팅하면, 저와 비슷한 셋팅이라고…(소근소근)
JetBrains Night 2017 - IntelliJ IDEA의 Tip & Tricks : 창천향로님이 또…젯브레인 나이트 후기를 남겨주셨습니다. 그리고 그 후기 속에 직접 정리 하신 캡쳐와 글들이 아주 인상적입니다. 툴을 잘 다루는 것 또한 개발 생산성을 높이는 지름길입니다.
스타웍스 페이지 : 스타벅스에서 개발을 자주 하게 된다면, 아마 이 앱을 요기나게 쓰게 될 수 있을 것 같다. (그래서 설치를 사알짝..)

JavaScript

Currying is not idiomatic in JavaScript
A Comparison of JavaScript Web frameworks
Comparing Browser Page Load Time: An Introduction to Methodology
React로 레거시(?) 코드 랩핑하기 : 정말 요즘의 대세이긴 한 것 같은데, React가 과연 이렇게 인기를 받을만큼의 메리트를 가져다 주는지에 대해서는 애매하다. 이 글 마지막에도 나오지만, Angular가 오히려 조금이라도 무거운 서비스는 적합할 것 같기도 한데, 리액트를 가곤 한다. 과연 뭐가 맞는지는 모르지만, 정수는 아니더라도 꽁수라도 쓸모가 있을 때가 있다는 것을 배우자.
play.node 2017에서 발표한 “Node.js API 서버 성능 개선기”
메모리 특강
만화로 소개하는 ArrayBuffer 와 SharedArrayBuffer
Atomics 를 이용해서 SharedArrayBuffer 레이스 컨디션 피하기
[ECMAScript6 / ES6] 아름다운 JavaScript를 위한 ES6

Java

[B급 프로그래머] 11월 4주 소식(개발/관리도구, 고성능 서버/데이터베이스 부문) : 사실, 봐야 할 링크들이 워낙 많아서 이 분의 블로그만 봐도 특히 나의 블로그는 안봐도 무방할 정도라고 생각하는데, 역시나 이번 쐉쓰이(광군제)를 개발자의 시각으로 바라본 글이 좋고, 생각보다 기술 스택은 요즘의 회사들이 사용하는 것과 비슷하다.

Scala

진짜 함수형 초보자들을 위한 트레이닝(1) in Scala : 함수형을 공부 할 수록 Java8을 제대로 쓸줄 알게 된다는 말!?을 듣고는 함수형 사고를 하기 위한 공부를 해야 할 것 같은데, 아무래도 스칼라 랭귀지를 배우는 게 가장 빠른 것 같습니다.

딥러닝

딥러닝을 제대로 이해하기 위해서 필요한 배경지식맵 : 딥러닝, 머신러닝하는데, 과연 나는 제대로 이해할 수 있을지 모르겠지만, 앞으로의 개발은 머신 러닝을 통한 서비스가 무조건 나올 수 밖에 없습니다. 이미 빅데이터는 기본이듯이 뭐랄까…어쭙잖게 가져다 붙이는 식의 머신러닝은 지양해야 하되, 서비스에서 어떤 인사이트를 얻을 수 있다면야 제대로 가져다 써야 한다고 생각한다.
[B급 프로그래머] 11월 3주 소식(빅데이터/인공지능, 가상화폐, 읽을거리 부문) : 말로 다 할 수 없다. 짬날때마다 보자. 알짜배기가 가득하다.

Weekly News #18

Sat, 18 Nov 2017 00:02:00 GMT

그냥 저냥 #위클리뉴스 #18

읽어볼만한 아티클

신규 서비스에서 고려해야 할 사항 : 신규 서비스 개발에 대한 개념적인 글이지만, 계속 읽어보면 좋은 글이라 생각합니다. 아직, 많은 경험과 실력이 없는 관계로 단편적으로나마 이해가 갈뿐. 전부를 이해하기는 어렵네요.
OKKY 미니세미나 <비전공 학원출신 SI개발자, 유명스타트업 들어간.ssul>참석 후기 : okky에서 코딩 테스트로 레전더리로 유명하신 분의 세미나인데요. 바빠서 가지는 못했지만, 창천향로님이 직접 들으시고 요약해주셨는데, 배울 점이 많은 것 같습니다. 특히 책을 볼 때, 코드 타이핑 부분은 제가 공감도 하고, 요즘 많이 못하는 부분이라 확실히 코드 타이핑을 할 때와 하지 않을때의 차이를 느끼곤 합니다.
What Is Project Valhalla? : 발할라 프로젝트에 관한 설명인데 Java 개발자라면, 관심있게 보아도 될만한 글이라 생각합니다.
Refactoring vs. Redesign : 무엇이 정답인지는 알 수 없지만, 과연 어떤 상황일때, 무엇이 더 알맞은지를 선택하는 것도 중요하죠.
Introduction to Apache Kafka : 카프카를 많이 쓰시죠? 예전에는 아니, 요즘도 RabbitMq를 많이 쓰시긴 하지만, 카카오나 다른 곳에서는 요즘 카프카를 많이 쓰고 있는 추세입니다. 알아봐두시면 좋겠죠 ??
로그를 잘 남기기 : 로그를 잘 남기는 전략, 설계는 상당히 중요합니다. 로그는 사실, 돈이 되는 데이터는 아니지만, 될 수 있는 충분한 잠재력을 지녔습니다. 페이스북, 구글 우리가 페이스북 좋아요, 구글 지도 사용 흔적등 모든 것들이 로그로 남아 로그는 가치 있는 데이터가 되고, 정보가 됩니다. 그 기반을 잘 다지는 것이 로그 잘 남기기입니다.
비공개 메서드를 테스트 해야 하는가? : C#을 잘하시는 분으로도 유명하시지만, MS MVP라고 들었습니다. 이규원님의 글인데요. 이 분의 블로그나 글들은 워낙 유명하신게 많아서 개발자라면, 한 번씩 읽어봄직하다고 생각하는 편입니다. 이번의 포스트도 확실히 추천할 만한 글이라 생각합니다. 테스트 관련인데, 많은 생각을 하게 됩니다.
Vim에서 저장하는 방법 - 자동 저장 : 개발자가 아니신데도 불구하고, 자바스크립트를 잘 하시는 분으로 유명하시고 번역활동을 활발하게 하시는 김놀부님의 블로그인데, 이번에는 vim에 대해 설명해주셨네요. 저도 vim을 잘 쓰고 싶어하는 유저인데, 이번 기회에 열심히 배워 두어야겠습니다.

Python

HowToMakeWebCrawler-ImplicitWait-vs-ExplicitWait : 크롤러를 만드는 예제인데, Selenuim을 사용합니다. 본래의 기능은 UI테스트 툴이었는데 어느새 크롤러를 만드는 도구로 변화했네요.
국제 상품 가격 데이터 가져오기 : 파이썬은 요즘 배우지 않으면 안되는 언어가 점점 되어가는 것 같습니다. 하둡의 MR또한 파이썬으로 돌리는 시대가 되었으니까요. 12월 연말에는 파이썬 공부를 시작해야겠습니다.

JavaScript

JavaScript Weekly : javascript weekly를 보면, 생태계의 변화라던지 빠른 흐름을 알 수 있게 됩니다. 물론, 유용한 자료가 많다는 점이 최고…
자바스크립트 this 바인딩 우선순위 : 자바스크립트의 this는 잘 알아야 하는 녀석중에 한 명입니다. 더글라스 크락포드의 자바스크립트 핵심 가이드에서도 4가지로 설명을 하고 있을정도죠…중요하므로 까먹지 않는 것이 중요하겠죠??
Vuetiful Korea 2회 모임 발표 자료 : 사실, 요즘 제가 관심 가지는 프론트 기술중에 하나이면서 한 번 도입해보는 것도 나쁘지 않겠다고 생각하는 녀석이 바로 이녀석입니다. 생각보다 배우는데에 어렵지도 않고, Reac, Angular의 장점을 쏙쏙 뽑아놓은 녀석 같아서 관심 갖고 있습니다.

JVM

Practice tmux

Mon, 13 Nov 2017 22:41:00 GMT

tmux 사용 정리

맥에서 일단 설치를 해야 합니다.

homebrew가 설치 되어 있으리라 생각하며, homebrew 설치를 건너 띄겠습니다.

homebrew install

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

tmux install

$ brew install tmux

위 처럼 입력하면 알아서 샥샥 설치가 됩니다.

tmux conf .. Aka. tmux이쁘게 쓰기..?😁

구글 검색하면, 상위에 랭크된 깃허브 레포지토리를 가봅시다.

위와 같은 레포가 많습니다. 원하는 이쁜 녀석으로 골라 셋팅을 해줍니다.

참고로, tmux plugin도 있습니다.

저는 7번 tmux-config를 셋팅 한걸로 기억하고 있습니다.

tmux의 장점은 화면을 분할 할 수 있다는 것이 장점입니다.

tmux를 이용해 화면 분할을 하나의 세션 내에서 자유롭게 할 수 있죠. 특히나, session으로 관리함으로써 2명이 1개의 세션에 attach 하여 같은 화면을 볼 수도 있구요. 장점은 많습니다.

용어

Prefix
- 실제 단축키를 눌르기 전에 눌러야 하는 키를 말하며, 보통 ctrl + b를 말한다.
Session
- tmux가 관리하는 최상위 단위로 세션 단위로 attach/detach가 된다.
Window
- 세션안에 탭 같은 기능으로 하나의 세션 내에 여러개의 윈도우를 가질 수 있다.
Pane
- 윈도우 안에 존재하는 화면 단위로, 세로 분할, 가로 분할 할 수 있다. 각 분할된 화면이 Pane이다.

사용법

세션 실행

$ tmux

$ tmux new -s sessionName
$ tmux new-session -s sessionName

세션 종료

$ exit #in tmux

# or
$ tmux kill-session -t sessionName # in terminal, out tmux

세션 attach

$ tmux attach -t sessionName #이름 지정 안했다면, 숫자

세션 detach

$ tmux detach # iterm2에서 tmux det만 쳐도 가능

세션 목록

$ tmux ls

Window

윈도우 생성
- <prefix> + c
윈도우 이름 변경
- <prefix> + ,
이전, 다음 윈도우 이동
- 이전
- <prefix> + n
- 다음
- <prefix> + p
모든 윈도우 리스트 보기
- <prefix> + w

Pane

세로 분할
- <prefix> + %
가로 분할
- <prefix> + "
팬 이동
- <prefix> + q + Number
- <prefix> + q + 방향키
줌
- <prefix> + z

참고

weekly-news-17

Sat, 28 Oct 2017 16:54:00 GMT

그냥 저냥 #위클리뉴스 #17

스프링 빈이 진짜 뭘까? : 지앤선 블로그에 올라온 “한글화 프로젝트”의 포스팅입니다. 실리콘밸리를 꿈꾸는 개발자인 백재영님이 번역을 해주신 글입니다. 사실, 스프링을 사용하면서도 스프링 빈이 도대체 무엇인가 싶을때가 많습니다. 그만큼 중요하기도 합니다. (그래서 필독….꾹)
webpack과 babel로 최신 javascript 개발환경 만들기 : 사실 요즘의 거의 트렌드인 툴 webpack 그리고, 트랜스파일러의 대표주자 babel이 가장 핫한 조합이 아닐까 한다. 고로, es6 아니지..이제는 es7을 써야하는 시대가 오는 건가 싶기도 하다. 물론, 나는 es5도 제대로 모르는 javascript 알못이라… 잘하고 싶은 마음이 있다. 그래서인지 자바스크립트 진영에 기웃기웃대곤 하는데, 이러한 글들은 중요하고, 입문하는데 큰 도움을 준다.
문장(시계열수치)입력 다중클래스분류 모델 레시피
시계열수치입력 수치예측 모델 레시피
Spring framework5의 변화
junit5 ParameterResolver : junit5에서 나타난 ParameterResolver에 대해 설명하는 글인데, 굉장히 알차다. 파라미터가 포함된 테스트를 할 때, 괜찮을 것 같은 느낌이 들었다. 여전히 한 번 봐서 잘….
spring5 와 junit5 : 분명 버전이 올라가면서 달라지는 점은 분명하다. spring과 junit의 결합의 완성도는 점점 더 높아지는 것 같다. 뭐랄까..블로그에도 나오는 말이지만, 비슷해지는 느낌은 있다.
RxJS 써야겠어요? 안써야겠어요? : RxJS가 이제는 트렌드가 아닌 필수적인 요소로 봐도 될법하다는 느낌이 들었다. 특히, 프레젠테이션에서 RxJS의 역할에 대해 간결하게 정의를 해주고 있다는 점에서 이해가 쉬웠다.
[스프링 웹플럭스] 1.1 소개
[스프링 웹플럭스] 1.1.1 왜 새로운 웹 프레임워크인가?
[스프링 웹플럭스] 1.1.2. 리액티브란 무엇이며 왜?
[스프링 웹플럭스] 1.1.3. 리액티브 API
[스프링 웹플럭스] 1.1.4. 프로그래밍 모델
[스프링 웹플럭스] 1.1.5. 웹 프레임워크 선택하기
[스프링 웹플럭스] 1.1.6. 서버 선택하기
[스프링 웹플럭스] 1.2. 리액티브 스프링 웹
[스프링 웹플럭스] 1.2.1. HttpHandler
[스프링 웹플럭스] 1.1.7. 성능 VS 확장성
자바9 자바 플랫폼 모듈 시스템

백기선님의 블로그에 많은 주요한 글들이 올라와 많은 링크를 포함하게 되었습니다. 저도 정독을 해야 할 것 같아 이렇다할 코멘트를 달기가 어렵더군요. 사실, 스프링5에서는 많은 패러다임의 변화가 예고 되고 있기에, 주요 변화는 ‘webflux’ 다라고만 하기는 어렵긴 하지만, 가장 큰 부분을 차지하는 것은 사실입니다.

아티클

퇴사자는 진실을 말하지 않는다.

weekly-news-16

Tue, 03 Oct 2017 14:54:00 GMT

그냥 저냥 #위클리뉴스 #16

알쓸개식(알면, 쓸모 있는 개발 지식)

Typescript 써야할까? : 타입스크립트 도입에 대한 개인적인 견해를 작성하신 마이구미님의 블로그 포스팅! 사실, 타입스크립트를 꼭 써야하는지에 대해서는 저도 의문이 듭니다.
딥러닝 무식하게 정리해 보기 01 : 딥러닝에 대해 정보를 많이 듣고 있는 중인데요. 잘 정리해주셨습니다.
배민 - 실시간 서비스 경험기(배달운영시스템) : 정말 상세하게 설명하고 있는 실시간 서비스 플랫폼 개발 경험입니다. 현재는 v2.0을 서비스중이지만, v1.0의 이야기를 아는 것도 중요하고, 어떻게 발전했는가?에 대해서도 고민해보면 좋을듯 합니다.
번역 - 10가지 소프트웨어 아키텍쳐 요약 : 파이썬을 주로 즐겨 쓰시는 분으로 유명하신데요. 번역도 자주 해주시는 분입니다. 상당한 실력자이신 mingrammer님의 블로그 포스팅입니다.
라운드 로빈 스케줄러와 시분할 ContextSwitching : 라운드로빈은 OS에서도 쓰이는 기법이지만, 네트워크에서도 흔히 사용하는 기법입니다. 사실, OS, Network는 개발자가 필수적으로 꾸준히 공부해야 하는 기본 베이스 재료입니다.
자바스크립트 객체 JSON화 하기 : javascript에 관해서는 끊임 없는 공부가 필요로 합니다. 사실, 요즘 굉장히 핫한 분야이기도 하고, 다양하게 파생 되는 부분이 많습니다. 좋은자료라 자바스크립트를 쓰시는 분들은 필독하시길 바랍니다.
파이썬을 이용한 데이타 시각화 #1 - Matplotlib 기본 그래프 그리기 : 파이썬을 이용해 데이터 분석을 하고, MR까지 돌리고, 그 결과를 시각화까지 할 수 있는데요. 파이썬에서 흔히 사용하는 시각화 도구를 이용해 그래프 그리는 방법을 설명합니다.

Spring 관련

(Spring Boot) Gradle의 Profile(dev/production)을 구분지어보자. : 사실, Maven에서는 Profile 기법을 이용해 현업에서도 많이 사용하는데, Gradle을 즐겨 써보지 않았는데, Profile을 두개로 사용하는 방법을 직접 경험기로 공유해주고 있습니다.
(Spring Boot) properties 값을 불러와보자 : 스프링 프레임워크를 즐겨 사용하신다면, 스프링 부트에 대해서도 알아두시면 좋습니다. 물론, 두 프레임워크가 완전 별개인 것이 아니라는 사실에 초점을 맞추시면 좋습니다.
Dependency Injection(의존성 주입)을 알아보자 - 막코딩 하기 : 의존성 주입에 관해 상세하게 설명하고 있어서 필독 할 것을 권합니다.
Dependency Injection(의존성 주입)을 알아보자 - 생성자 함수 : 생성자 함수를 통한 의존성 주입이지만, 단점을 지니고 있습니다.
Dependency Injection(의존성 주입)을 알아보자 - setter : 스프링 프레임워크 또한, xml에서 의존성을 주입할때, setter 방식을 사용한다죠?..
(Spring) 자바 빈즈 객체를 XML 파일로 관리하면서 DI하기 - 기본 : 스프링의 의존성 주입에 대해 기본적인 방식으로 설명하고 있는 글입니다.
(Spring) 자바 빈즈 객체를 XML 파일로 관리하면서 DI하기 - property 태그 : 기본에 이어서 property태그를 통해 관리 하는 방법을 설명합니다.
(Spring) 자바 빈즈 객체를 XML 파일로 관리하면서 DI하기 - @Autowired : 어노테이션을 통해 의존성을 주입하는 방법을 설명하고 있습니다.

객체 지향 및 Java

JVM 메모리 구조 (JVM Memory structure) : Java 개발자라면, JVM을 크러쉬를 내는 코드를 작성 할 수 있어야 하고, 당연히 JVM에서 크러쉬가 나지 않도록 하는 코드도 짤 줄 알려면, JVM에 대한 깊은 이해가 필요할 것이라 생각합니다.
OOP(객체 지향 프로그래밍) 5원칙 및 특성 : SOLID라고 불리는 원칙 및 특성이지만, 모두가 동의 하는 것은 아닙니다. 해외에서도 핫한 이슈이기도 하죠. 그래도 5가지의 특성에 대해서 알아두는 것이 좋습니다.

기본 베이스 지식

TCP 3 Way-Handshake & 4 Way-Handshake : 대학교 시절, 컴퓨터 네트워크를 들어 이에 대해 알고는 있었지만, 자칫 까먹기 쉽습니다.
OSI 7 계층 (OSI 7 Layer) : 네트워크에서의 국제 표준인데요. 사실, 이렇게 구성이 된다면야, 해킹의 위험도 줄어들고 하지만, 이미 TCP/IP 모델로 알려진 DoD 모델을 쓰고 있는데요. 이 모델은 5 layer방식이었던가…어찌하든 이미 준표준이 넘어간 상태라 개념적인 7 layer를 공부하는데 도움이 되는 표준안입니다.

weekly-news-15

Tue, 03 Oct 2017 00:32:00 GMT

그냥 저냥 #위클리뉴스 #15

악취나는 코드 개선하기 시리즈 - 심하게 중첩된 코드 : 창천향로님이 요즘 번역과 정리 하시는 시리즈가 악취나는 코드 개선하기입니다. 사실, 코드를 개선하기란 쉽지 않습니다. 일정에서 자유롭기란 어렵습니다. 그럼에도 틈틈히 기술 부채가 쌓이는 코드들을 정리 해주는 것이 좋다고 생각합니다. 이번 편은 난도가 좀 있는 편입니다. Java8의 문법을 좀 알고 있어야 이해하기 좋습니다.
SpringBoot @MockBean, @SpyBean 소개 : 테스트 코드를 작성하는데에는 중요한 요소가 간결성이라고 생각합니다. 테스트 코드가 길어지면, 길어질 수록 테스트 코드 자체에 기술 부채가 쌓이기 쉬운데, spring boot 1.4에서 새로 나온 테스트 어노테이션을 소개해주는 글입니다.
카카오 신입 공채 1차 코딩 테스트 문제해설 : 코드 페스트때의 문제를 보고 카카오에 실망을 좀 하긴 했습니다만, (개인적인 코딩 대회에 대한 회의감?!) 이번 카카오 공채 블라인드 테스트는 문제를 보니 꽤나, 신선한 문제들이 많아 좋다고 판단 했으며, 난도는 적당했다고 판단 됩니다. (물론, 실제로 풀진 않는…^^) 그래도 약간의 논리력을 요했다는 점과 실제로 필요로 해봄직한 프로그래밍적인 요소를 추가 했다는 점이 좋았습니다.
B급 프로그래머 9월 4주 소식 : 개발/관리 도구 관련 링크가 이번에는 많습니다. 훑어보니 vuejs에 관한 이야기도 있고, GraphQL에 관련 링크, C++도 있습니다. 특히나, Java9 and intelliJ 소식에 호기심이 많아지네요!
Spock 소개 및 튜토리얼 : 사실, spock는 groovy라는 언어로 테스트 코드를 작성하면서, 좀 더 편리하다는 소리는 익히 들었으며, TDD에서 중요하게 생각하는 template인 gien-when-then에 대한 부분은 spock framework에서 이미 지원을 하고 있습니다. 사실, 이것만 해도 엄청난 가독성의 증대가 아닐까 합니다. 이에 대한 spock 사용법을 친절하게 알려줍니다.
SpringBoot 환경에서 Spock 사용하기 : 창천향로님이 spock 소개 튜토리얼뿐만 아니라, spring boot에서도 사용하는 방법에 대해 소개해주고 있습니다. (역시, 창천향로님은 갓…👍)
도커 컨테이너 간 아무제약 없이 ssh접속 하도록 설정하기 : 도커에 대해서 공부를 하다보면, 생각보다 설정 하는 부분이 많아 지게 되는데, ssh접속이 사실 굉장히 귀찮긴 합니다. 이에 대해 해결 할 수 있는 포스팅입니다.
기술 뉴스#87 : 17-10-01 : 아웃사이더님이 정리 하신 10월 첫주 기술 뉴스입니다. 특히 더 나은 웹프론트엔드 과정을 고민하며. 라는 포스팅은 정말 볼만한 링크입니다.
내 맘대로 위클리 뉴스 - 2017년 39주(09월 29일) : Django의 포스팅이 좋았는데, 사실, 장고 프레임워크 자체도 이미 중급 프레임워크가 되었으므로 공부하기가 쉽지 않다고 생각한다. 그런점에서 이 분의 블로그를 참조하는 것이 좋아 보입니다.
Ajax Delete Parameter 문제 : 쉽다면, 쉽고 가끔 헤매는 부분이므로 알아두면 좋다.
나만의 웹 크롤러 만들기(7): 창없는 크롬으로 크롤링하기 : 크롤링 하는 부분에 있어서는 이 시리즈를 안 볼래야 안볼수가 없다. 생각보다 정말 짜임새 있게 포스팅을 해주셔서 … 크롤링이 엄청 늘어나지 않을까 싶기도 하다.
kakao의 오픈소스 Ep8 - hbase-packet-inspector : 카카오의 현재 계신 분으로 vim의 신으로 불리기도 하시는 분이시다. Ruby , Go등 수 많은 언어로 vi 플러그인을 제작하신 분으로도 유명하시다. 그런데 이번에는 hbase 패킷의 정보를 분석하는 툴을 개발 하셨네요. 이미 1년전에 만드신 경험이 있으시군요 ^^ kakao의 오픈소스 Ep3 - HBase Region Inspector , 이분의 전문 분야?!인 vim에 대한 글도 좋습니다. 그래, 가끔 “Vim에서” GitHub을 보자!

Infra: Semaphore Install

Tue, 26 Sep 2017 00:57:00 GMT

Ansible GUI Tool #1 - Semaphore 설치 경험기

사실 원래, Ansible Tower라는 막강한 툴이 있으나, 생각보다 정말 많이…비싸다.

그래서 대안으로 Open Source Project인 Semaphore를 설치하기로 했다. 그런데, 가이드는 정말 간단했다.

그래서 더 불안했다.

Semaphore Install

Semaphore Project

위 위키 페이지를 가면, 아래와 같은 Install 가이드를 준다.

Copy download link for your OS from Releases page
(linux) curl -L > /usr/bin/semaphore
Run semaphore -setup
Continue setup (see below for more detail)

참고로, Server OS, CPU 버전이 무엇인지 확인 해두자.

참, Mysql or MariaDB를 먼저 설치 해야 한다.

$ sudo yum install mariadb mariadb-server

명령어로 치면, 알아서 설치를 해준다.

$ curl -L <https://github.com/ansible-semaphore/semaphore/releases/download/v2.4.1/semaphore_linux_386> > /home/seungdols/applications/semaphore
$ chmod +x semaphore
$ ./semaphore -setup

설치시, db password를 지정하면, 에러가 난다.

Guide문서에도 troubleshooting 항목에 보면, default로 db의 문을 개방해두라고 한다.

이때 그만 두었어야 했다.

아무튼, 시작을 하자면, setup은 정말 간편하다.

하라는 대로 default로 enter만 쳐주면 된다.

그리고, Playbook path를 물어보는데, 아래의 경로로 셋팅을 해주었다.

$ pwd
/home/seungdols/applications/ansible

그러면, 하위에 semaphore_config.json file 하나가 뚝 떨어진다.

그리고 명령어를 실행시키면 된다.

$ nohup ./semaphore -config /home/seungdols/applications/ansible/semaphore_config.json &

이렇게 하면, 사실 가이드 상으로는 끝이다.

그러나, 내가 무언가 config 파일을 변경해서 재시작 하려고하면, 이게 말썽이다.

죽어도 실행이 안된다.

그래서 찾은건 config를 건드리면, service가 안뜬다는 정보 정도를 알아냈다.

원인은 모르겠지만, 관리의 부재인 탓인지도 모르겠다.

왜냐하면, 가이드 문서상은 8010 포트가 default port인데, 이 녀석이 실제로 동작하는 port는 3000이었다. 실제로 setup시에도 example <http://localhost:8010> port라고 나온다.

이렇게 해봤는데, 생각보다 Semaphore의 기능이 단순하며, 뭘 어떻게 써먹어야 하는지도 애매했다.

그래서 느낌상, foreman을 설치하고, 그 위에 foreman-ansible 모듈을 설치 할 것 같다.

참고

weekly-news-14

Sun, 10 Sep 2017 00:41:00 GMT

그냥 저냥 #위클리뉴스 #14

혼자서 연습해본 Gradle 4.1 튜토리얼 – 그야 말로 대충 번역! : gradle이 4.0으로 넘어서면서 maven보다 100배 빠르다는 기사를 본적 있는데, 그만큼 gradle이 폭풍 성장!을 하는 것 같습니다. 이제 maven에서 탈피하는 것도 좋은 방법이라고 생각합니다.
자바는 더 함수형으로 업그레이드 돼야 한다. : 이일민님 (토비)이 인터뷰하는 자바9에 대한 이야기 그리고 자바의 위기들에 대해 설명을 해주시는데, 사실 위기는 계속 있었고, 자바9의 핵심 모듈 시스템에 대한 부분도 두번이나 투표를 할 만큼 영향력이 큰 부분이었고, Reactive를 자체 내장함으로써 함수형 프로그래밍의 패러다임을 점차적으로 수용하고 있다.
PyCon2017 후기 : 솔직히 말해서 파이콘을 가지 못한건 좀 아쉬움이 많았는데, 이렇게 후기를 남겨주셔서 감사할따름!
내 맘대로 위클리 뉴스(8월 18일) : 파이콘 특집이다! 읽어보면 좋습니다. 사실, 파이썬이라는 언어가 이제는 강력한 웹 개발, 데이터 분석 및 처리, 머신러닝에도 쓰이기에 그냥 넘어가기에는 활용도가 높은 언어라 배우면 좋은거 같다는게 저의 생각이고, 앞으로도 아마 저는 파이썬을 공부 할 것 같습니다.
로컬 개발 서버를 HTTPS로 세상에 띄우기(like ngork) : 파이썬등 기타 웹 개발을 하다 보면 막히는 부분이 개발 서버에 접근 해야 할 때가 있는데 이를 위해서 ssh 터널링을 이용하는 방법에 대한 소개입니다.
[B급 프로그래머] 9월 1주 소식(빅데이터/인공지능/가상화폐, 읽을거리) : 유용한 내용이 정말로 많습니다. 이것을 주마다 읽는다고 해도 좋은 개발자, 트렌디할 것 같습니다 🙌
Fast Properties in V8 : v8이 properties를 어떻게 빠르게 다루는지에 대한 내용으로 node.js 잘 하기 위해서는 v8을 잘 이해하는 것도 중요합니다.
왜 영어로 감정을 말하기 어려울까?: 감정 영어를 익히는 5가지 팁 : 영어는 중요한 부분인데 늘상 공부하기가 쉽지 않습니다. 저도 꾸준히 하려고는 하는데 어렵더군요. 차라리 하루 15분을 아침 저녁으로 쪼개서 30분이라도 꾸준히 해야 할 것 같습니다.
Spring Security 4 Tutorial : 스프링 시큐리티는 중요합니다. 다만, 커스텀하거나 실질적으로 잘 사용하기가 어렵습니다. 자주 봐두시고, 테스트 해보면 좋습니다.

GDG Front-End 세미나-React, Vue, Angular

Sun, 27 Aug 2017 16:10:00 GMT

프론트엔드 세미나

#1 이건희 - 다우기술 (목적에 Angular, Vue, React 맞게)

프론트 배경과 선택

요즘 프론트는?

브라우저 성능이 높아짐
프론트엔드에서 비즈니스 로직이 복잡해짐

통합 개발

서버
프론트

두 가지를 하나의 서버상에서 구현하고 운용함.

분리개발

서버 사이드 서버
클라이언트 사이드 서버

모놀리틱 vs 마이크로 웹 서비스

프론트선택 요소

클라이언트 / 서버 사이드 렌더링
프레임워크/ 라이브러리
언어
유지보수

클라이언트 사이드

검색엔진이 검색하는데에 제약이 있음

고로, SEO에 대한 최적화가 좀 까다롭긴 함.
SEO에 대한 고려가 필요
네트워크 비용이 적다.
빠른 인터랙션
초기 로딩이 느림.

서버사이드 렌더링

빠른 초기 로딩
SEO 적용이 쉽다.
프론트, 백엔드 코드 통일 하기가 쉽다.
느린 인터랙션
네트워크 비용이 높다.

언어

JSX

react에서 주력으로 사용함.

TypeScript

앵귤러2에서 굉장히 미는 언어. 정적 타이핑 자바스크립트 언어라고 생각하면 된다.

ES6

vue.js에서 사용하는데, 사실 vue.js는 순수 자바스크립트를 주로 사용한다.

React

ES5, Es6 문법을 혼용하여 사용할 수 있음.

스타일, 함수, 렌더링 하는 부분이 같이 있음. (팀내의 코드 컨벤션이 필요로 하다.)

Redux, Flux
이벤트가 많은 작업이라면 리액트가 유리하다. ( Event-driven ?)

VUE

사실 순수한 모듈의 특징을 가지는 듯…

템플릿, 스크립트, 스타일등 영역이 나누어져 있다.

앵귤러처럼 컴포넌트 호출로 묶을 수 있는데, 뷰에서는 하나의 파일안에 스타일, 로직등 모두 한군데에 있는 것이 응집력을 높여준다.

타입 체크 가능 -> 앵귤러
양방향 바인딩 -> 앵귤러
디렉티브 -> 앵귤러
코드 구조 -> 앵귤러, 리액트
코어와 컴페니언의 분리 -> 리액트
VIrtual DOM구조 -> 리액트

AngularJS

템플릿, 스타일이 외부 파일로 정의해서 사용함.

비즈니스로직만 나타낼수 있음.

백오피스 개발 경험

앵귤러가 더 나을 것 같다는 생각
타입 체크가 중요하므로, TypeScript 사용

안드로이드, IOS 개발을 동시에 해야함.
이벤트 동작이 주요 기능
React Native , React가 서비스 성격에 맞았음.

#2 엔터프라이즈 프로젝트와 리액트 (김훈민, 네이버 스마트에디터)

참여하신분들이 리액트를 깊이 아시는 분도 아니고, 싫어하시는 분도 있으실것 같아서 편하게 이야기 할 예정.\

React + Flux -> React + Redux -> React + Mobx

스마트 에디터 3.0이 오픈 되었고, 현재는 기본형 모드를 완전히 뜯어 고치고 있는 중이다.

에디터 개발 초기

초기에는 JQeury + Underscore로 개발했다.

요구사항은 복잡하고, 변경도 잦은……..서비스

수동 의존성 관리
수동 데이터 동기화
설계 일관성 부족
테스트 커버리지 부족

에디터 - 카드형 개발

결론적으로 뭔가 대안이 없었고, 그 당시에는 리액트 밖에 없었다. (카드형 개발)

React + Flux 를 이용해 개발 하게 되었다.

뭔가 좋긴 좋음?

비교적 낮은 학습 비용
UI 상태 동기화
애플리케이션 구조화 문제 해결

다른 문제가 생김

난잡해진 컴포넌트
Jquery와 불편한 동거
예측하기 힘든 데이터 흐름
뚱뚱한 스토어

마크업 개발자와 개발자간의 프로퍼티명의 통일화가 안됨. 용어가 다름.

점점 컴포넌트 계층이 복잡해지고 깊어지기 시작함.

모바일 에디터 개발

개발 프로세스를 다지자.

스터디
설계 논의
코드 리뷰
단위 테스트 작성도 빡세게

스토어가 너무 비대해지니 Redux로 개발하는게 더 좋을것 같다!

Redux를 바라보는 2가지의 시선이 존재함.

단순한 동작도 4가지의 코드를 작성해주어야 하는 문제가 생김.

비동기 처리 하기가 좀 어렵드라.

그래서 Redux-thunk를 쉽고 단순하더라.

그런데 막쓰기가 쉽다. 이것은 문제가 된다. 그리고 테스트가 어려워진다.

리팩토링 시작

플랫폼화를 해보자!

그렇다면, 플러그인 형태로 레이어를 다 찢어서 개발하고 하나의 코어에서 플러그인을 조합하는 에디터로 만들자!

문제는 플러그인끼리 상태가 엮이는 케이스가 있을때 어떻게 해결을 할까?

플러그인을 리액티브하게 바인딩 할 수 있을까?

-> MobX를 채택하게 됨.

또 공부하는 시기가 필요로하고, 노하우를 쌓아야 하는 문제가 있다.

상태가 변경하면, 렌더링이 다시 한다. 바인딩하는 단위가 Redux보다 작은 사이즈다. (이 것을 몰랐음)

결론으로는 마냥 쓰기에는 어렵다.

React에 대한 몇 가지 생각 정리

한 가지를 잘한다는 그것밖에 못한다의 다른말.
1. 리액트만 가지고 뭘 만들 수 있는가?
2. 실무에서는 뷰만 가지고는 할 수 있는 영향이 적다.
3. 비용이 발생함. (스터디, 프로토타이핑 등)
4. 도구들이 흥함
5. create-react-app - 공식 CLI 도구
6. next.js - 서버 사이드 렌더링 프레임워크
7. 추상화의 함정
가져다 쓴다? 참여한다!
1. 홍익인간들의 참 세상 (우왕굳)
2. why-did-you-update
장점과 단점은 동전의 앞과 뒤
1. 완전 귀찮은 부모-자식 관계에 대한 프로그래밍이 필요.
2. redux는 4단계의 코딩이 필요
3. 단방향 데이터 플로우의 제약
4. 끊임없는 코드 정리 (Redux의 철학)
기술과 개발자 사이의 경계
1. 문제에 대한 팀내에 공유 되어야함.
2. 기술에 대한 이해도는 비슷하게 유지해야 하는 작업이 필요.
3. 어떤 기술을 선택하는 문제는 실은 개발 전체에서 보면 아주 작은 일부에 불과함.
React Way를 이해하되, 기술에 기대지 말것.

#3 Angular 기본 개념 잡기 (한장현)

Angular는 angularJS와 다르다.

Angular 2.0 -> Angular
Angular 1.0 -> AngularJS

명칭부터 이름이 다르다.

TypeScript를 도입하면서 프레임워크 이름을 변경 했다.
철학도 비슷, 개발 방법도 비슷
버전 정책은 Semver
숫자는 무관함. (이미 5.0)

종합 프레임워크

전체를 아우르는 구조
뷰, 데이터, 풀, 폼, HTTP, 애니메이션, 서버 사이드 렌더링, CLI, 테스트

SPA를 만든다.

페이지 내부에서 라우터로 뷰를 전환

전통적인 HTML 페이지 전환 방식과는 다름.

해당 주소 일 때 동작하는 컴포넌트를 등록

딥링크도 사용가능.

TypeScript

Javascript의 상위 집합
정적 타입, 제네릭, 인터페이스, TSLint
@Annotaion === function

개발 생산성에는 정적 타입이 생겨나므로 좋은 것은 아니다.

유지보수 측면에서는 좋다.

컴포넌트 기반

추상화된 DOM 엘리먼트
- 템플릿 + 클래스 코드
- DOM에 직접 접근 하는 것은 지양함
어노테이션을 Angular 컴포넌트 등록
- 객체 생성, 주입은 Angular에서 관리
- LifeCycle 관리

데이터 바인딩 지원

성능 향상을 위해 단방향이 기본
양방향 바인딩도 지원
프로퍼티 바인딩
- 어트리뷰트 바인딩
이벤트 바인딩
양방향 바인딩

옵저버블

Callback chain - Promise chain - Async chain - Observable chain

RxJS 내장

기본 패키지에 포함

데이터 스트림에 사용

키보드 입력 이벤트, 서비스 상태 전달에 적합
HTTP는 좀 아님.
WebSocket에 적합함

서비스를 의존성으로 주입한다.

DI의 개념

생각보다 어렵진 않다.
쉽게 생각하면 내가 주입 하는게 아니라 어떤놈이 대신 해준다.
(나는 What을 정의해주면 How는 알아서 해줌)

컴포넌트를 연결

전역 데이터 풀로 활용

의존성 주입기가 인스턴스를 생성하고 주입

생성 방법을 등록하고 사용하면 됨
인스턴스 생성 방법은 알 필요 없음.
컴포넌트처럼 의존성 구성 가능
더미 객체를 사용하는 테스트 코드에서 유리함. (왜냐면 Mocking 하기가 유리해짐)

모듈화 지원

ES6 모듈의 연장, 대체는 아님

export, import 사용
import로 불러오고 @NgModule에 등록

CLI지원

프로젝트 기본 생성
구성 요소 추가
서버 실행
TSLint
Test
Build
Deploy

지금 공부해야 할 것

TypeScript
Angualr framework
Architect besed on Component
Reactive Programming

앞으로 공부 해야 할 것

Webpack Optimization
Server side Rendering & SEO
Meterial & Animation

원모먼트 vue.js 적용하기 (원모먼트 - 김우현)

원모먼트 - 온라인 당일 꽃배달 서비스

vue.js

장점

단일 컴포넌트
template + script + style
한국어 문서 지원
친절한 커뮤니티

사용하기

직접 script에 추가
npm
CLI
- scaffolding 지원 (멋진데?👍)

레거시

메인 페이지
- SQL 문제
결제 오류
- order sheets > PG > Status change : 정상 결제
- PG > Order sheets > Status Change : 비정상 결제

결제가 되었는데, 관리지 페이지에 정보가 안됨 -> 크리티컬 이슈

해결

백엔드는 Restful API
vue.js를 도입

오픈 소스 만들기 - 경험 공유

GITHUB - vue-lunar-calender

음력 달력이 필요해
- 중국 개발자가 만든 것 밖에 없더라.
webpack을 이용함
- yarn을 사용함
awsome-vue관련 프로젝트에 소개 merge.
이탈리아어에 대한 PR이 날라옴

weekly-news-13

Sun, 13 Aug 2017 17:52:00 GMT

그냥 저냥 #위클리뉴스 #13

개발새발

폴더별 환경 관리를 위한 direnv : 폴더별로 특정 설정을 반영하고 싶을 때 쓸만한 툴인 것 같다. python 개발을 한다면, autoenv 같은 느낌이라는 걸 받을 수 있을 것이다.
부동산 - 네이버 부동산 크롤링 : 네이버 부동산의 데이터를 크롤링 하는 방법을 상세하게 알려주며, 실제 코드도 있어 참고하기 좋다.
부동산 - 조인스랜드 데이터 크롤링 : 네이버 부동산 데이터 크롤링 이후 그 다음으로 조인스랜드 데이터를 크롤링 하는 아티클인데, 굉장히 상세하고, 크롤링에 대해 좀 더 많이 알 수 있다.
matplotlib + 한글
autoenv로 편리한 개발하기
virtual DOM이란 무엇인가?
파이썬 로깅의 모든것
java8 Optional.of 쓸 때 주의할점
내 맘대로 위클리뉴스 - 08월 11일

아티클

책을 자주 읽는 사람이라면, 반드시 부딪히는 고민들 : 요즘 내가 겪는 문제이기도 한다. 책을 읽는 시간이 나지는 않는데, 읽어야 할 책을 쌓여가고 그러다보니 주문은 하게 되고, 쌓여만 간다. 그런데, 한 2달 - 3달은 주문 자체를 하지 말아야겠다.
코딩의 함정 : 비전공자가 개발을 하고 싶어 하는 마음은 알겠으나, 요즘처럼 개발에 핫한 때가 있을까 싶기도 하는데, 진입 장벽이 높을 수도 낮을수도 있는 개발 세계에 쉽게 발을 들여놓고, 나중에 후회하면 안된다. 모든 일은 갈수록 어려워져 간다.
한 번쯤 ‘혼자’ 여행해야 하는 이유 : 국내여행은 혼자서도 잘 다니지만, 아마 조만간은 해외도 도전 해봐야 하지 않나 싶긴하다. 중요한 내용이므로 강추강추!

weekly-news-12

Sat, 05 Aug 2017 00:21:00 GMT

그냥 저냥 #위클리뉴스 #12

[elasticsearch5] 집계 (aggregation) 성능 향상 : 내용에 shard request cache에 대한 것들이 나오는데, 아무래도 엘라스틱서치는 입문하는데 좀 진입장벽이 있는 것 같다. 왜 이렇게 동작하고, 어떻게 운영해야 잘 관리 할 수 있는지에 대해서도 사실 딱히 엄청난 가이드가 있는건 아니라서 많은 책을 독파하고, 실제로 운영해보고 알아가야 하는게 많은 녀석임에 확실하다. 특히나, 엘라스틱 쿼리를 잘 짜는 것 또한 중요한 이슈이기에…(공부할게 많다는 생각이 들었다.)
패스트캠퍼스 SQL튜닝캠프 2일차 - 인덱스 향상 : 항상 열심히 사시는 개발자로 유명하신 창천향로님이시다. 요즘은 또 DB쪽에서 중요한 SQL쪽을 공부하시는 것같다. (이분의 시간은 48시간인지도 모를 만큼 열심히 사시는 분이다.) 그리고 정리를 잘 해주시니 꼭 놓치지 말고, 보도록 하자. 인덱스는 3개 이하가 좋다는 것은 결국 인덱스를 많이 생성하면, 할수록 저장 비용이 올라가기 때문일지도 모른다는 생각을 했다. 더군다나 옵티마이저가 갈 수 있는 경로가 많아지므로 거지 같은 실행 계획을 짤 확률이 높아지는 이유가 아닐까…? (어쭙잖은 추정일뿐)
Apache MXNet에 대한 모든 것! : 요즘 하도 딥러닝, 머신러닝하는데 드디어 가장 괜찮은 녀석이 나온거라고 생각하면 되려나..? 딥러닝 프레임워크인데, 생각보다 잘 만들어진 녀석인것 같다. 물론 텐서플로우가 있긴 하지만, 이녀석도 잘 봐두도록 하자.
기술 뉴스 #83 : 17-08-01 : 역시 내용중 관심가는 부분은 ES8과 Spring framework의 아버지 로드 존슨형의 atomist editor가 제일 흥미롭다. 우선은 프레임워크로 접근하라라는 명언도 있는데, 로드 존슨 형은 이제 탈프레임워크를 지향하는 느낌이다. 결국, atomist를 설립하고 개발 리드를 하고 있는데, 개발 자동화 툴이라고해야 하나..http://docs.atomist.com/ 이 쪽 내용을 확인 해봐야 할 것 같다.
MXNet 기반 추천 오픈 소스 딥러닝 프로젝트 모음 : 오픈 소스 딥러닝 프로젝트가 정말 다양하다는 것은 그만큼 현재 IT업계에서 가장 큰 이슈이자, 핫한 기술이라는 증거일 것이다.
증분검색을 통한 텍스트 필터링 도구 페코(Peco) - 명령어 히스토리를 비롯한 셸(shell) 어디서나 증분검색하기 : 터미널에서 fzf라는 도구를 접한지도 얼마 안되었으나, peco라는 증분검색기는 더 재미난 녀석이었다. 사실 속도면에서는 peco가 더 빠른거 같기도하다. fzf는 카카오 개발자이신 최준건님이 만든 오픈소스이며, vie의 GOD라 불리는 분이시다. ~~ruby로 개발한걸로 알고 있는데, 루비도 정말 잘쓰는 분 중 하나인 것 같다.~~ Ruby로 작성 된 것을 Go lang으로 포팅했다고 한다. 어찌되었든, fzf, peco 둘 다 잘만 쓰면, 개발력을 향상시켜준다.
[Review] gitflow, 쉬운 git branch 관리 : git-flow가 단순히 브랜치 전략인줄로만 알았으나, 알고보니 브랜치 전략을 강제화 하도록 만들어둔 git package toolkit 같은 느낌이다. Git-flow를 설치하고, git-flow 명령어로 하다보면, git명령어를 묶음화한 kit라고 생각할 수 있다. 그리고, 쉽게 다중 브랜치를 관리하도록 해준다는 장점이 있고, 협업시에는 무조건 필수적인 요소다. git-flow를 쓰지 않더라도 브랜치 전략은 세워두고 개발을 하는 것이 좋다.

weekly_news_11

Thu, 27 Jul 2017 20:17:00 GMT

개발

Tech HR 컨퍼런스 참석 후기 : 이런건 꼭 봐야 하는 컨퍼런스 후기이고, 이분의 후기 정리는 개발자 중 갑인듯하다.
Spring bean LifeCycle : 기본적은 생명주기는 중요한법이다. 기본을 알아야 응용을 할 수 있을테니..
내 맘대로 위클리 뉴스 - 2017년 28주(07월 14일)
Using IntelliJ IDEA to Develop Apps With Grails 3
21 rules for faster SQL queries
어려운 것을 쉽게 배우는 방법 : 슈퍼 파워를 장착하기 위한 3단계 학습법 : 아주 군더더기 없는 글이다. 결국 실천하는 사람이 빨리 배운다. (한국어 번역)
내 맘대로 위클리뉴스 07월 21일 : graphQL이 또 떠오르는 강자가 되는건가..이미 강자가 되고 있는지도 모른다.

기사

크레용웍스, 네이버 검색광고 자동 운영 솔루션 : 인공지능은 아니라서 다행이다. 차라리 인공지능 아닌 솔루션이 나을듯.
테슬라 전기차에도 구매보조금 지급한다…이르면 9월 중순부터
택시사업 막힌 우버, 음식 배달로 한국 ‘노크’
가상화폐 거래소 ‘코인원’ : 코인원 거래소가 생각보다 잘 짜여진 싸이트라 신기했는데, 대표가 후덜덜한 보안 능력을 지닌 고수였다.
그는 당신의 비즈니스에 별로 관심이 없다.
아마존, 메시징 앱 ‘애니타임’ 만든다 : 상품주문이나 예약까지 가능하다는 것이 장점…이를테면, 쇼핑/예약 + 슬랙 기능을 한데 묶은 느낌.

weekly-news-#10

Mon, 17 Jul 2017 13:30:00 GMT

그냥 저냥 #위클리뉴스 #10

개발

기술 뉴스 #82 : 17-07-15 : 먹으면 득이 되는 음식과도 같다.
kakao의 오픈소스 Ep7 - CMUX: CLI에 날개를 달자!
데이터 워크 플로우 관리를 위한 Apache Airflow : 점점 병렬처리 관련 플랫폼은 늘어나는 것만 같다.
How to get started with Kubernetes
java의 몇가지 이야기
[es2015+] class문은 특별할까? : Hika님 회사 블로그인데, 중급 난도의 js 내용이 오랜만에 올라왔다.
리스코프 치환 원칙 : 객체 지향 설계에 관한 원칙 5가지 솔리드의 한 가지인데, 가장 애매한 느낌을 준다.
개방 폐쇄 원칙 : 머루님의 블로그는 자바 관련해서 난도가 꽤 높은편이다.
알고리즘 논란은 알고리즘으로 치유를.. : 그 유명한 알고리즘 관련 논쟁이 okky에서 일어났었다.

기사

weekly-news-9

Tue, 11 Jul 2017 20:16:00 GMT

그냥 저냥 #위클리뉴스 #9

Super Type Token : 슈퍼 타입 토큰이 뭔지는 토비 방송 시즌2에서 엄청나게 설명을 해주시지만, 사실 이게 뭔지 잘 이해가 안갔다. 보다 보니 이해가 가기 시작했는데, 그럼에도 머루님의 블로그에서 정말 쉽게 설명을 해주고 계신다.
자바스크립트 정규표현식 코딩팁 : 워드프레스로 유명한 회사의 프론트엔드 개발자로 일하시는 태곤님의 자바스크립트 정규표현식의 꿀팁으로, 생각해보니 나는 저렇게 열심히 고민을 하면서 프로그래밍 하는건지 뜨끔했다. 꿀팁으로 꼭 꼭 익혀두면 좋은 스킬이다.
내 맘대로 위클리 뉴스 - 07월 07일 : python과 javascript에 관한 다방면의 아티클을 정리해주시는데, 이번에는 파이썬으로 구현한 링크드 리스트가 인상적이다. 더불어서 vue.js 로 실시간 차트를 작성하는 기사도 충분히 보면 도움 될 것 같다.
권남 - elastic search : 구루라 생각 되시는 분인데, 다방면의 히스토리가 있는 위키를 운영중이시다. 이번에는 엘라스틱 서치 관련한 글인데, 업데이트 되서 읽게 되었다.
권남 - spock : 사실 테스트 유닛 프레임워크는 junit이 강세이긴 한데, 요즘은 spock을 많이 쓰는 것 같다. 그나저나 중요한건 나는 junit도 제대로 잘..못쓴다..이거부터 연습하자.
지앤선(한글화 프로젝트) DataLake : 빅데이터 관련한 용어인데, 이 용어에 대한 히스토리를 알 수 있으며, 관련한 좋은 인사이트를 얻을 수 있다.
내 맘대로 위클리 뉴스 - 06월 30일 : npm5 관련 기존 npm과의 비교 기사, javascript의 set 구조 사용등이 유익했다.
Git Questions – How and When do I Merge or Rebase? : 나도 항상 헷갈리는 것이 언제 merge하고 언제 rebase 하는지 헷갈린다…이건 팀 마다 표준 가이드를 정하는 게 나을 것 같기도 하다.
5 Step Recipe: Everything You Need to Know for Staying Up-to-Date in Java : 이거는 딱히 훑어보기만해서 정확히 좋은 내용이 뭔지는 잘 모르겠…
Programming Without a Framework : 이런 말은 질문으로 해도 좋은 말이다..스프링 없이 웹개발 해봐라라고 한다면, 멘붕오지 않고, 개발 하는 주니어 개발자가 많을까…??? 아마 나부터 멘붕 올듯…JSP/Servlet은 심하잖아요…
What’s new in Kubernetes 1.7 : 쿠버네이트 업데이트에 대한 내용을 담는데, 나는 아무래도 도커나 쿠버네이트는 2.0은 되야 만지게 되지 않을까…ㅜ 공부할게 참 많군요..
MS, 윈도 스토어 통해 우분투 배포판 제공 : 윈도우가 드디어 우분투 배포판을 아예 스토어에서 제공을 하게 되었다..+ㅁ+ 점점 더 윈도우의 플랫폼이 다양해지겠구나.

redis info

Thu, 22 Jun 2017 15:16:00 GMT

Redis

in-memory data structure store, used as a database, cache and message broker. It supports data structures such as strings, hashes, lists, sets, sorted sets with range queries, bitmaps, hyperloglogs and geospatial indexes with radius queries. Redis has built-in replication, Lua scripting, LRU eviction, transactions and different levels of on-disk persistence, and provides high availability via Redis Sentinel and automatic partitioning with Redis Cluster.

개념

Key/Value Store

레디스는 기본적으로 key/value 저장소로, 특정 키 값에 값을 저장하는 구조로 되어 있다.

다만, 이 모든 데이터들이 메모리에 저장 되어 있으므로, 매우 빠른 read/write 속도를 낼 수 있다. 고로, 전체적인 저장 가능한 데이터의 용량은 물리적인 용량을 넘어설 수 없다.

다양한 데이터 타입

memcached와 다른 점이라면, 레디스의 경우 키 값에 매핑하는 값에 다양한 데이터 타입을 매핑 시킬 수 있다. 고로, memcached보다는 다양한 데이터 타입을 지원하므로 더 복잡한 구조를 저장 할 수 있다는 장점이 있다.

String

일반적인 문자열이라 생각하면 되나, 바이너리까지 저장 할 수 있어서, JPEG 이미지나, 직렬화된 루비 객체도 저장 가능하다. 최대 512 MB까지 저장 가능하다.

Sets

레디스에서 문자열들의 무순서 집합 자료형이라고 생각하면 된다. 이 데이터형은 교집합, 차집합등의 연산이 가능한데, 굉장이 빠른 속도를 보장한다.

Sorted Set

set에 score가 추가 된 sets으로 생각하면 된다. sets과 유사하다.

sorted set은 요소에 대한 추가/삭제/업데이트가 굉장히 빠르다.

더군다나, sorted set에서 데이터는 오름차순으로 내부적으로 정렬 되며, range query, top query등 query가 가능하다.

Hashes

value내에 field/string value의 쌍을 저장 할 수 있는 데이터 타입이다.

예시이며, 성별, 이름, 나이등 여러 필드를 가지는 사용자를 저장하는데 적합하다.

@cli
HMSET user:1000 username antirez password P1pp0 age 34
HGETALL user:1000
HSET user:1000 password 12345
HGETALL user:1000

List

문자열의 단순한 나열로, 생각하면 된다. 입력한 순서에 의해 정렬이 된다. 다만, 레디스에서 리스트는 좀 특별한데, Head/Tail에 데이터를 추가/삭제가 가능하다. 고로, Deque라는 자료구조를 생각하면 쉽다.

설치

우선 공식 Redis Home의 다운로드를 받는다. 생각보다 가볍다.

sudo wget https://github.com/antirez/redis/archive/4.0-rc3.tar.gz

make 방식

cd /home/seungdols

tar xzvf 4.0-rc3.tar.gz #압축 해제
cd redis-4.0-rc/
sudo make

다만, 이렇게 할 경우 conf 파일들이 기본 설정으로 셋팅 되어, 수작업으로 변경을 해주거나 해야 한다. 기본 포트 설정은 6379로 설정 된다.

우선, 포트를 7000번으로 수정하려고 하면, 디렉토리를 만들어주고, conf파일을 옮겨주어야 한다.

mkdir 7000
cp redis.conf 7000/redis.conf

그리고, 7000/redis.conf의 파일에 있는 port를 변경해주어야 한다. 그리고, pidfile의 경로에 있는 redis_6379.pid를 7000으로 변경 해주어야 한다.

dbfilename의 dump.rdb는 기존에는 포트가 같이 있었는지 모르지만, 4.0에서는 port 번호는 없어져 변경할 필요는 없다.

이렇게 설정을 했다면, 서버를 띄워보자.

cd /home/seungdols/redis-4.0-rc3/
src/redis-server 7000/redis.conf & #7000/redis.conf 파일을 기반으로 redis를 띄운다.

다만, 여기서 redis를 안전하게 shutdown하는 방법을 못찾았는데, 아무래도 kill을 이용하면 위험하긴 할 것 같다. 그래서 초보자들은 install.sh를 이용하여 설치하는 방법이 제일 깔끔하다. 필요로하는 service 파일들도 /etc/init.d/ 하위에 옮겨 준다.

install.sh 방식

cd redis-4.0-rc3/
cd utils/
sudo ./install_server.sh

다만 이 때에 executable path는 사용자가 직업 지정을 해주어야 한다. 그 외는 상당히 편리하게 변경 가능하다.

Replication 구성하기

Master/Slave를 구성하기 위해서는 master node의 conf 파일에서 bind ip를 변경해준다.

#bind 127.0.0.1
bind 0.0.0.0

requirepass <password> #password 설정
masterauth <master-password> #slave node일때 암호 설정

그리고, slave node의 conf에서 slaveof 라는 옵션을 지정해주어야 한다.

slaveof master_node_ip master_node_port

masterauth <master-password> #slave node일때 암호 설정
repl-ping-slave-period 10
repl-timeout 60

Master/Slave Test 확인

먼저 master node에서 redis-cli을 접속하여 데이터를 생성 해보겠습니다.

127.0.0.1:7000> set seungdols 'redis-replication success'
OK
127.0.0.1:7000> get seungdols
"redis-replication success"

slave node는 read only로 데이터의 접근만 가능합니다.

$ src/redis-cli -p 7000 -a 비밀^^
127.0.0.1:7000> get seungdols
"redis-replication success"
127.0.0.1:7000>

slave node에도 정확하게 데이터가 들어 간 것을 볼 수 있습니다.

Redis 구성

이미지 출처 : http://crystalcube.co.kr/176

그런데 위 처럼 할 경우에 master node가 죽을 경우 문제가 생긴다. 이 때에는 어떻게 처리를 할 것인가?

그래서 Redis에서는 master/slave node 간의 역할 문제를 해결해주는 녀석이 있습니다.

그게 바로 sentinel이라고 합니다.

위 처럼 작업하게 되는데, 이 때 sentinel은 독립 서버에 설치해도 되지만, 동일한 서버에 설치해도 무관하다고 합니다. 정말 만일의 사태에 대비한다면, 따로 분리해두는 것도 좋을듯 합니다.

sentinel의 역할

master node/slave node를 감시한다.

master node가 죽을 경우 slave node중에서 하나를 master node로 변경 한다.

이전 master node가 되살아날 경우 slave node로 변경해준다.

실질적인 역할은 위의 기능이 다입니다. 그럼에도 불구하고, 수동으로 복구 해야하는 기능을 담당 해주므로 failover에 필수적으로 설정을 해야 합니다.

다만, 문제는 client에서 master node가 바뀌었을 경우 port를 자동으로 감지 할 방법은 없습니다. 이 때, HAproxy를 이용하는 방법이 있습니다.

위와 같이 운용을 하려면, HAproxy를 두어야 하는데, 이를 둠으로써 client에서는 master node가 변경 되어도 정상적인 서비스가 가능하게 됩니다. 다만, HAproxy가 1대인 경우에 죽는 경우 Redis 전체를 사용 불가한 상황이 발생합니다. 그래서 2대로 이원화하여 사용하고, L4 switch로 묶는 방법이 있습니다.

출처 : http://crystalcube.co.kr/178

참고

server infra automation

Tue, 20 Jun 2017 21:46:00 GMT

Server Infra Automation 작업

후보군

Chef
Ansible
~~puppet~~
Docker

Ansible

시스템 환경 설정 및 배포 자동화 플랫폼으로 요즘 핫하게 각광 받고 있는 툴이다.

특징

simple format (YAML)
agentless
Python

Ansible 시작하기를 좀 따라해보고 개발기에서 한 번 시도 해볼만 하다. Ansible에는 playbook이라는게 있는데, 이는 Ansible의 환경설정, 배포를 가능케하는 언어라고 한다. 그리고 YAML 문법으로 정책이 기술 되어 있어, 로드밸런서를 모니터링 하는 복잡한 환경에서도 사용 가능하다. ansible-pull도 있어서 node들이 conf등을 pull하고 싶을 경우 이용 가능하다.

참고

Chef

환경의 메타 데이터를 관리하고, 노드의 역할을 조정하는 OPS의 프레임워크라고 한다..출처

생각으로는 서버 환경 설정 툴인줄 알았으나, 그게 아닌가..음..자세히 보니 위 설명이 맞는 듯하다. 사실 툴의 개념보다는 프레임워크로 생각해야 한다.

환경의 구성 관리를 통해 서버 구성을 자동으로 조정 하는 녀석이라는 말이다. 즉, 서버 환경 설정 자동화 툴은 아니고, 많은 기능 중의 일부 기능인 것이다.

특징

agent
Ruby
DSL

우선, Chef의 경우 서버 인프라 환경 자동화 툴이 아닌 일부 기능으로 존재하는 것이 맞고, 이 기능을 주로 쓰면 서버 환경을 자동화 하고, 노드 간 설정을 Refresh 해준다는 장점이 존재한다. 더 불어 아예 개발 환경 까지도 VM을 올리게 되면, vagrant + chef 조합을 많이 사용하는 것 같다.

Chef는 server, client, node, chef indexer등의 구조를 가지고 있으나, 이에 대한 것보다는 Cookbook에 더 관심을 가져야 한다. (실제로 사용자가 건드릴 건 Cookbook이 다라고 한다.)

Cookbook 개념

쿡북은 한 개이상의 레시피, 정의, 자원, 속성, 파일, 라이브러리, 템플릿, 메타 데이터를 묶어 놓은 것이다. chef에서 쿡북은 배포의 기본 단위이다. 예로, MySQL을 위한 쿡북은 defualt, client, server 3개의 레시피와 설정 파일은 위한 3개의 템플릿, 2개의 속성, 1개의 메타데이터로 구성 된다.

Resource

세프 내에서 작업의 기본 단위다. 패키지나, 파일, 디렉토리, 서비스, 심지어 cron, mount도 자원으로 다룰 수 있다. resource에 지정된 동작은 적용 시점에 각 노드에서 실행 된다. 이를 통해 사용자나, 그룹을 생성, 삭제 하거나 노드 내 서비스를 재시작 할 수 있고, 로컬 파티션, 원격 디렉토리를 마운트 한 후 사용할 수도 있다.

Definition

기존 자원을 이용해 사용자 고유의 자원을 만들어 사용할 수 있다.

Recipe

레시피에는 한 개 이상의 자원이 어떤 순서로 관리되는지를 정의한다. 레시피는 다른 레시피를 포함할 수 있고, 쿡북에 정의 된 속성 뿐만 아니라 레시피를 적용하는 대상 노드에 정의 된 모든 속성 역시 이용 할 수 있다.

Provider

자원에 지정된 동작을 실제로 수행하는 주체이다.

Library

반복적이거나 레시피에 기술하기에는 너무 길고, 한 눈에 알아보기 힘든 내용을 레시피 외부에 정의하고, 레시피에서 사용할 수 있도록 해준다. Ruby, Chef의 DSL을 확장하는 형태로 작성 가능하다. libraries 디렉터리에 위치하며, 존재하는 라이브러리 파일은 실행 시 자동으로 로딩 되고, 레시피나 속성, 정의에서 사용 가능하다.

Attribute

레시피 적용 시 노드에서 사용 될 값을 지정할 수 있다. 속성이 중요한 이유는 대상 OS마다 다르게 지정해야 할 값을 레시피에 기술 일일이 기술하거나 각각을 별도의 파일로 만들 필요가 없게 해주기 때문이다. 아파치 서버를 예로 들면, 데비안, 우분투 계열과 레드햇 계열 리눅스는 기본적으로 설치 시에 정해지는 아파치 설정 파일 경로나 이름 등이 좀 다르다. 이를 레시피에 일일이 기술하거나, 여러 종류의 레시피를 만든다면, 내용도 쓸데 없이 길어지고 복잡도만 늘어난다. 속성을 이용해 이 문제를 쉽게 해결 할 수 있다.

File

모든 것이 작성하는 코드만을 이용해 해결된다면 세상은 정말 행복할 것이다. 하지만 실제로는 종종 필요한 파일을 직접 업로드해야 할 경우가 발생한다. 예를 들어 각 리눅스/유닉스 시스템의 패키지 관리자가 지원하지 않는 파일을 설치해야 한다거나, 직접 제작한 파일을 각 시스템에 배포해야 하는 경우가 그러하다.

Template

파일과 매우 비슷하지만 한 가지 결정적인 다른 점은 노드에 템플릿이 전송될 때 렌더링 작업을 거친 후 전송된다는 것이다. 각 노드의 시스템 속성 및 정의된 속성이 템플릿 렌더링 시 사용된다. 이것이 의미하는 바는 앞서 속성에서 언급한 바와 같이 각 노드 별로 달라야 하는 값 때문에 설정 파일을 여러 개 만들 필요가 없다는 것이다.

Role

노드에 적용될 여러 레시피와 속성의 집합이다. 노드 하나에 하나 이상의 역할을 할당할 수 있다. 역할은 레시피나 속성을 역할의 특성에 맞게 쉽게 조합 가능하며, 역할 이름이 무엇을 하는지 명확히 나타내주기 때문에 차후 유지보수에도 도움이 된다.

Metadata

셰프 서버가 각 노드에 제공하는 몇 가지 기본적인 정보를 담고 있다. 각 쿡북의 최상위 디렉터리에 metadata.rb 파일을 만들고 필요한 내용을 기술하면 해당 파일은 JSON파일로 컴파일된 후 셰프 환경에서 사용된다.

참고

Docker + Kubernates

특징

도커를 이용해 개발 서버들을 모두 컨테이너 형식으로 생성/삭제 할수 있다. 한 번 설정 된 이미지를 가지고 같은 컨테이너를 생성하는 것은 쉽다. 다만, 관리하는 툴이 필요로 한데, Kubernates를 이용하면 된다.

내 생각

도커와 함께 쿠버네이트를 이용해 가상화 하는 방법은 참으로 좋은 방법이긴 하지만, 서버 환경 셋팅을 자동화 하는 방식에서는 맞지 않는다.

왜냐하면, 도커의 경우 이미지를 만들어 필요한만큼 가상화로 생성한다. 그런데, 이 때, 톰캣 설정이나, 아파치 설정을 바꿔서 변경해야 한다는 것은 이미지를 삭제하고, 다시 새로운 이미지를 올리는 것과 같은 행태로 봐야 한다.

이 말은, 도커와 쿠버네이트 조합으로 서버 환경 전체를 스냅샷으로 생성/삭제하는 방식인것이지, 서버 환경만 자동화 한다는 관점에서는 다소 어긋난 접근일 수 있지 않나 생각해본다.

참고

weekly_news_8

Fri, 16 Jun 2017 11:32:00 GMT

[정리] 그냥 저냥 #위클리 뉴스 #8

테스트 주도 개발 : Test-Driven Development by Example : TDD에 대한 책을 읽고 쓴 후기 같은 글이지만, 잘 정리 되어 있고, TDD의 실질적인 의미에 대해서 생각해볼 수 있는 글이다.
outsider 기술뉴스 #80 : 언제나 읽어도 도움 되는 기술 뉴스/다양한 기술에 대한 스펙트럼을 가지고 정리해주시기에 읽어야만 한다. 이번에는 Docker나, 탭 하이재킹 공격 같은게 신선해보였다.
내가 도커를 시작했던 방법 : Docker에 대한 시작했던 경험에 대한 후기를 친절하게 쓰고 있으며, 전반적인 내용을 담고 있다.
Refactoring Java in IntelliJ : 리팩토링에 관한 꿀팁을 얻을 수 있다. 그런데, 영어이니 잘 이해하는 것이 중요한 것 같다.
Zero downtime Deployments with Kubernates : 쿠버네이트를 활용한 Zero downtime 배포 시스템 구축인데, 참고 해도 좋을 것 같다. 앞으로의 인프라는 Docker에 의해서 동작하게 될 가능성이 높아져 간다.
Java Microservices : Java 기반의 마이크로 웹서비스에 대한 설명과 약간의 코드가 포함 되어 있는 아티클이다. 마이크로 웹 서비스의 이점이 뭔지가 가장 중요하며, 서비스의 니즈/적합도가 중요한 판단 요소라는 것을 인지 하고 있어야 한다고 생각한다.
Jersey Web Service Hello World Example in Java : 위에서 소개한 마이크로 웹 서비스에서 Jersey를 썼는데, 이 아티클은 Jersey로의 입문을 소개 한 아티클이다. Jersey가 뭔지를 공부해두면 좋을 듯 하다.
랜섬웨어 사태의 나야나 관련 기사 : 해커에게 돈을 주는 것은 위험한 예시를 남기는 것이지만, 이미 호스팅 업체에 위탁한 많은 서비스들의 정보가 백업도 되지 못하고, 사용 불능이라면, 호스팅 업체의 사장으로서의 결단력이 놀라웠다. 회사를 매각하면서까지 거액을 준비 했는데도 해커가 복화화 키를 안준다면..이라는 생각을 하자니 마음이 무겁다.
비트코인을 통한 범죄, 추적이 가능할까? : 가상 화폐라고 추적이 불가능하다고 생각하지 말자. 비트코인 자체 기반 기술은 블록체인이라는 전세계 컴퓨팅 자원을 사용하면서 기록하는 전 세계 회계 장부에 기록이 된다. 정확하게 누가 누구와 거래 했는지를 추적하는 것은 굉장히 어려운 일이지만, 환전하는 거래소에 입장하는 순간 추적이 가능하다.
outsider - Python3에 뛰어 들기 : 아웃사이더님이 Python의 문법을 공부하시면서 참고하신 책에 대한 정리가 되어 있으며, Python을 쓰게 된다면, 이 정리 본을 보는 것도 좋고, 직접 책을 읽는 것도 좋을 것 같다.
머루 - Java Generic : 생각처럼 쉽게 쓸 수 있는 스킬은 아닌게 제네릭이다. 대부분의 언어에 포함 되어 있는 개념이지만, 생각처럼 자유자재로 쓰기는 어렵다는게 나의 지론이다. 이를테면, C의 void 포인터, C++의 템플릿등과 같은류라 생각한다. 잘 쓰기 위해서는 노력을 해야 한다. Java Generic을 위해 보면 좋은 아티클이다. 해
머루 - 미리 만나는 Java9 : 자바9의 릴리즈 일정이 7월에서 9월로 밀렸고, 아마 더 밀릴 가능성도 있다. 일단, Jigsaw는 포함이 안 될 가능성도 높아졌다. 일단은 Java9를 지나 10이 되면 얼마나 또 재밌는 기능이 만들어지려나..우선 Java8부터 공부를 해야겠죠…?
30년간 개발자로 살면서 배운 것 - 번역 : 무조건 읽어야 할 아티클이다. 좋은 번역이라 감사하다는…
sk A/B Test 플랫폼 개발 경험 : 앞으로의 웹 서비스나 모바일 시장에서 A/B 테스트 플랫폼은 중요한 평가 기준이 될 전망이므로, 거의 대부분의 서비스에서 사용 될 가능성이 높다. 관심을 가져야 할 분야이기도 하다.
내 맘대로 위클리 뉴스 - 2017년 23주 : 파이썬의 함수가 어떻게 동작하는지에 대한 아티클은 파이썬으로 개발하는 사람이라면, 읽어볼만 하다고 생각한다. 그리고 YAML 포맷이 생각보다 점점 인기를 끌고 있다는 것에 놀라워 하는 중..
개발자의 효율성 : 개발자가 보면 좋은 글인 줄 알았으나, 기획자가 보아도 좋은 글이라고 생각한다.
내맘대로 월간뉴스 5월 : 알짜 정보가 한 눈에 다 보이도록 들어있다. 이런건 감사하게 읽고, 중요한건 저장해두자.

weekly_news_7

Wed, 07 Jun 2017 19:53:00 GMT

그냥 저냥 #위클리뉴스 #7

intellij에서 패턴으로 replace : 많은 부분에 있는 텍스트를 패턴 치환으로 변경하는 방법을 알려주는데, intelliJ의 강력함을 엿볼 수 있는 부분으로 알아두면, 쓸 일이 많을 것 같다. 툴 하나를 완벽히 잘 다루는 것도 생산성 향상에 도움이 될 것 같다.
java 9 delayed due to modularity controversy : java9 Standard Edition의 릴리즈 일정이 7월 21일로 예정되어 있었으나, 그 일정에 릴리즈 되지 못할 거라는 소식이다.
git command tutorial: 깃을 커맨드로 기초를 알 수 있는 페이지이다. 커맨드에 익숙치 않다면, 따라 해보는 것도 좋다.
20 dev leaders thoughts on great java devs: 20명의 리드 개발자들이 생각하는 자바 개발에 대한 생각이다.
내 맘대로 위클리 뉴스 - 2017년 22주(06월 02일: 사실 요즘은 파이썬을 주로 쓰지를 않아 기본적인 것도 많이 까먹어서 그런데..이 분의 블로그를 보며 파이썬의 발자취를 대강 눈으로, 어중이 떠중이 감으로 따라가고 있다..

weekly news #6

Thu, 01 Jun 2017 18:20:00 GMT

그냥 저냥 위클리 뉴스 #6

outsider - 기술뉴스 #79 : 무조건 봐야하는 정보들이다. 심지어 국내외 불문하고 요약 된 정보들을 올려주시니 필수로 봐야 한다.
OKKY 취준생 Q&A Meet-up 참석 후기! : 우아한 형제들에 계신 창천향로님이 정리해주신 세미나 후기이다. 주니어 개발자이시면서 취업을 위한 개발자, 갓취업을 한 개발자들에게 유익한 정보와 개발 테크 블로깅을 자주 해주신다.
지금까지 정규 표현식을 오해하고 있었던 이야기 : 정규식에 대한 포스트로 읽어볼만 하다. ;;;사실 나도 잘 몰랐다.
git branching model : git을 더 잘 쓰기 위한 브랜치 전략이다. 꼭 시도 해볼만 한 내용이다.
how to use javascript to detect browser: 제목에 나와있듯이 브라우저를 탐지하는 방법에 대한 글이다. 이걸 쓸일이 생각보다 많다.
jdk9 execute java code like unix shell script: jdk9에는 repl도 포함 되고 여러모로 java가 functional한 감성을 많이 담으려고 노력하는 것 같다. 예상해볼때는 jdk10정도에서 현재의 C#수준의 functional을 따라 갈 것 같기도 하다. 혹은 더 이후 버전이라던지…
권남 java9 : java9가 곧 릴리즈 될 예정이다. 고수들이 보는 문건들은 보통 중요한 법이니 꼭 읽자!
청첩장 페이지 개발기 - 경험공유: 호주 개발자로 일하시는 분이신데, 청첩장 개발기 경험 공유를 해주셨다. 나도 이런 행복하게 개발하는 일이 생겨야 할텐데…(연애부터 하자)
spring5 webFlux and jdbc to block or not to block: spring5의 가장 큰 핵심 기능으로 급부상하고 있는 webFlux와 jdbc 내용이다. spring5 이후부터는 jdk8 + 비동기 처리 지향으로 웹 서비스가 개발 될 것 같다. 그리고 앞으로는 굳이 WAS스택 중 하나인 Tomcat으로 서비스를 안하게 될 날이 곧 올 것 같다.
혀로그래머 - 레디스 관련 Q&A: 레디스의 전문가이시기도 하신 분의 캐시 관련 꿀팁이랄까요..레디스의 메모리 파편화는 심각한 문제긴 하네요..주기적으로 장비 이전을 해야 한다니…참..ㅠㅠ

when commit vi on git

Wed, 31 May 2017 18:06:00 GMT

어느 순간 Commit을 하려 했으나, 안되는 증상이 발생!

error: There was a problem with the editor 'vi'.
Please supply the message using either -m or -F option.

찾아 보니 이렇다. 무슨 문제로 인한 vi editor 버그라는데 갑자기 생긴 이유는 모르겠다.

그런데, 해결방법은 참 쉽다.

git config --global core.editor `vim`

위 명령어처럼 git 전역 설정에 vim editor 설정을 등록하는 방법이 있다.

맥에서는 아래의 방법을 써도 된다.

git config --global core.editor /usr/bin/vim

이상 seungdols 올림.

merge two git repositories

Sun, 28 May 2017 22:50:00 GMT

Merge Two Repositories

github를 하다보니 쓸데 없이 저장소를 나누어 놓고 쓰고 있더라..

그러다보니 이게 여기다 올려야 하는지 아닌지도 모르겠고…

일명 대환장파티 레포지토리라고 해야 할까..

그래서 시도를 해보았다. (스프링 공부나 할 것이지)

저장소 병합 (서브 트리 이용) — 별로다..
요우님 블로그 (cherry-pick 이용) —이게 맞는건가 싶었다.
스택오버플로우 형님들 (걍 머지 때려라)

처음에는 그냥 머지를 해보았다.

참고 : merging two git repositories

실패했다.

$ g merge practice_js/master
fatal: refusing to merge unrelated histories

다른 히스토리를 가졌으니 안된다고 한다.

그 다음으로 요우님 방법으로 시도를 했다. (그냥 머지는 안된다고 알려주셨다..😊😊)

요우님 블로그 발췌

git checkout merge/PP
git log #에서 가장 최근의 Commit SHA값을 복사해둔다.
git checkout master
git cherry-pick 9ede61845d75411e8cef35303b6eeaa5d7c26bdb

그런데 생각보다 블로그에 나와 있는 글에는 마지막 해시 값만 넣으면 된다는 뉘앙스로 써져 있었으나, 그게 아니라 커밋 자체를 모두 체리픽으로 가져오는 것인 것 같았다. (이해를 잘 못 했을 수도 있다.)

나의 경우 마지막 해시 값을 가져오니 딱 그 해시 값만 가져오더라.. (방법을 잘못 따라한 것 같다.) 😂😂😂

그래서 검색했다… 무언가 방법이 있을 것만 같다.

찾았다..👍👍👍 스택오버 플로우 누님/형님들은 대단하다.

참고 : how do you merge two git repogitories

방법은 이렇다..그냥 머지 하면 된다.

단, 다른 히스토리인 것도 허용한다는 옵션을 준다.

cd path/to/project-b
git remote add project-a path/to/project-a
git fetch project-a
git merge --allow-unrelated-histories project-a/master  #or whichever branch you want to merge
git remote remove project-a

위처럼 옵션을 준 결과

git merge --allow-unrelated-histories practice_js/master
Auto-merging README.md
CONFLICT (add/add): Merge conflict in README.md

바로 이렇게 README.md에서만 conflict가 난다. 이것만 해결해주면 된다. ^^ (찡긋😉)👍👍

don't work run java on Mac OS

Sun, 28 May 2017 22:44:00 GMT

Mac에서 Java run 안 될 때!

Class JavaLaunchHelper is implemented in both ~ 라는 에러를 발견 한다면, 운이 나쁜 겁니다…ㅠㅠ 😭😭😭

이럴때는 어떻게 해야하는지 알려 드리겠습니다. 스택 오버 플로우를 찾아 보니 아래와 같습니다. 이 문제에 대해서 java9 or java8.152 업데이트에서 fixed 될 예정이라네요.

You can find all the details here:

IDEA-170117 “objc: Class JavaLaunchHelper is implemented in both …” warning in Run consoles It’s the old bug in Java on Mac that got triggered by the Java Agent being used by the IDE when starting the app. This message is harmless and is safe to ignore. Oracle developer’s comment:

The message is benign, there is no negative impact from this problem since both copies of that class are identical (compiled from the exact same source). It is purely a cosmetic issue. The problem is fixed in Java 9 and in Java 8 update 152.

If it annoys you or affects your apps in any way (it shouldn’t), the workaround for IntelliJ IDEA is to disable idea_rt launcher agent by adding idea.no.launcher=true into idea.properties (Help | Edit Custom Properties…). The workaround will take effect on the next restart of the IDE.

고로, 지금은 idea.properties 옵션 파일 안에 idea.no.launcher=true을 추가 해주면 됩니다.

참고

objc3648-class-javalaunchhelper-is-implemented-in-both

weekly-new

Sun, 28 May 2017 00:00:00 GMT

그냥 저냥 위클리 뉴스 5월의 마지막주

샤딩하세요. 샤딩 쉬워요에 대한 글 : 생각보다 샤딩은 쉽지 않다. 서비스 초기 시작인 경우도 그렇고, 서비스 중인 경우에도 샤딩은 쉽지만은 않다.
내 맘대로 위클리뉴스 : 항상 좋은 글과 뉴스가 잘 정리 되어있으며, 파이썬, 자바스크립트의 주류가 올라온다.
things3 app에 대한 이야기: 이 글을 읽고 나도 뽐뿌가 와서 맥과 아이폰 둘 다 결제를 해버렸다. 나도 할일을 좀 관리하면서 살아보자..2017년을 기분 좋게 회고 하고 싶어졌다.
아웃사이더님의 기술뉴스 : 주니어 개발자라면 필독 해야하는 아웃사이더님의 블로그 명물인 기술 뉴스이다. 항상 좋은 글과 좋은 내용이 많이 포함 되어 있고, 프로그램이나 오픈소스 버전업 정보도 올라온다.
d2 blog - 빅데이터 다차원 분석 플랫폼: 빅데이터란 말은 앞으로 의미가 없어질 것임에 틀림 없다. 내가 아는 바로는 결국에는 데이터의 처리, 효율적인 저장, 유의미한 정보를 뽑아내는 기술을 돕는 플랫폼이 성공한다고 생각한다. 이 플랫폼도 유심있게 지켜볼만 하다.
github와 travis-ci의 연동: 누가 일일히 손으로 한땀한땀 빌드하는가? 아마 그렇게 물으면, 나는 뜨끔 하겠지만, 이제는 젠킨스 빌드, 테스트, 배포 환경이 당연해지긴 했다. 그럼에도 travis-ci 또한 괜찮은 선택이므로 시도 해보자
shell-script를 작성하는 이를 위한 shellcheck 강추에 대한 글: 정적 분석 도구는 기술부채를 줄이는데 아주 큰 도움을 준다. 그러므로 적극적으로 도입하자.👍 우리 부서에도 sonarqube를 도입하자고 권해볼까 생각중이다.
java9에 대한 마이그레이션에 대한 글: 사실 아직 Java8 문법으로 깊이 있는 코드를 짜본적이 없는 관계로 그냥 저냥 Java9에 대한 주요 특징만 공부하는 중인데, 굉장히 신선하기도 할 것 같고 생각보다 Java8+이면서 하위 오래된 버전을 지우려는 버전업이 아닐까란 생각도 했다.
week in spring: 스프링 프로젝트의 주간 내용인데, 스프링을 잘 알려면 이런 내용도 빠짐 없이 확인 하는 습관을 들이자.
How to use jquerys mouse methods: jquery는 어찌하든 javascript 진영에서 빼놓을 수 없는 강력한 라이브러리이므로 잘 쓰는 방법을 연구하는 것은 중요하다고 생각한다. 😊 가끔 필요한 마우스 이벤트에 관한 메소드에 대해 알 수 있으니 공부해두자!
drag-and-drop html table rows using jquery: 이 기능을 잘 가꾸어 두면 요긴하게 쓸때가 있을 것 같다.

try-with-resources

Thu, 18 May 2017 22:56:00 GMT

Try-with-resources 사용하기

JDK7에서 생겨난 자원 자동 종료?라고 생각하면 된다. 물론, 다되는 것은 아니고 Autocleable을 구현한 클래스만 사용가능하다.

String readDataFromFile(String filePath) {
    BufferedReader br = null;
    String data = "";
    try {
        br = new BufferedReader(new FileReader(filePath));

        data = br.readLine();

    } catch (FileNotFoundException e) {
        e.printStackTrace();
    } catch (IOException e) {
        e.printStackTrace();
    } finally
    {
        try {
            br.close();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
    return data;
}

보통 파일이나 어떤 자원을 생성하고 읽어야 한다면, 수 많은 try-catch-finally 구문을 사용해야 했습니다.

그런데, 아래처럼 바뀐 것이죠.

static String readFirstLineFromFile(String path) throws IOException {
     try (BufferedReader br =
                  new BufferedReader(new FileReader(path))) {
         return br.readLine();
     }
 }

사용 방법은 간단하며, try () 구문 안에서 자원을 생성하면, 알아서 close()를 호출해줍니다.

더군다나, JDK7에서부터 Multi-catch를 쓸 수 있죠.

public class ExampleExceptionHandlingNew
{
   public static void main( String[] args )
   {
   	try {
   		URL url = new URL("http://www.yoursimpledate.server/");
   		BufferedReader reader = new BufferedReader(
   			new InputStreamReader(url.openStream()));
   		String line = reader.readLine();
   		SimpleDateFormat format = new SimpleDateFormat("MM/DD/YY");
   		Date date = format.parse(line);
   	}
   	catch(ParseException | IOException exception) {
   		// handle our problems here.
   	}
   }
}

참고

spring in action

Mon, 08 May 2017 17:48:00 GMT

스프링 인 액션

1장. 스프링속으로

1.2 컨테이너

스프링 기반 어플리케이션에서는 스프링 컨테이너 안에서 객체가 태어나고, 자라고, 소멸한다. 스프링 컨테이너는 스프링 프레임워크의 핵심부에 위치한다. 스프링 컨테이너는 종속객체 주입을 이용해 어플리케이션을 구성하는 컴포넌트를 관리하며, 협력 컴포넌트 간 연관관계의 형성도 여기서 이루어진다.

스프링 컨테이너에는 여러가지가 있으나 통상적으로 2가지로 분류 된다.

BeanFactory : DI에 대한 기본적인 지원을 제공하는 단순한 컨테이너이다.
ApplicationContext : BeanFactory를 확장함으로써 기능을 추가하여 어플리케이션 프레임워크 서비스를 제공하는 컨테이너이다.

1.2.1 어플리케이션 컨텍스트

AnnotationConfigApplicationContext - 하나 이상의 자바 기반 설정 클래스에서 스프링 어플리케이션 컨텍스트를 로드한다.
AnnotationConfigWebApplicationContext - 하나 이상의 자바 기반 설정 클래스에서 스프링 웹 어플리케이션 컨텍스트를 로드한다.
ClassPathXmlApplicationContext - classpath에 위차한 XML파일에서 context 정의 내용을 로드한다.
FilSystemXmlApplicationContext - 파일 경로로 지정 된 XML을 읽어서 컨텍스트 정의 내용을 로드한다.
XmlWebApplicationContext - 웹 어플리케이션에 포함된 XML 파일에서 컨텍스트 정의 내용을 로드한다.

1.2.2 빈의 일생

보통의 자바 어플리케이션에서 빈의 생명 주기는 매우 단순하다. 왜냐, new 연산자로 인스턴스화 하고, 바로 사용이 가능하다. 사용되지 않는 경우에는 결국 가비지 컬렉션에 의해 메모리가 제거 된다.

스프링은 이보다 더욱 정교한 메커니즘을 가지고 있다고 한다.

BeanFactory 컨테이너 내 빈이 갖는 구동 생명주기

인스턴스화 : 스프링이 빈을 인스턴스화한다.
프로퍼티 할당 : 스프링이 값과 빈의 레퍼런스를 빈의 프로퍼티에 주입한다.
빈이 BeanNameAware를 구현하면, BeanNameAware의 setBeanName()을 호출한다.
BeanFactoryAware의 setBeanFactory()를 호출하여, BeanFactory 자체를 넘긴다.
ApplicationContextAware의 setApplicationContext()를 호출하고, 둘러싼 application context에 대한 참조를 넘긴다.
BeanPostProcessors의 사전 초기화 : BeanPostProcessor를 구현하면, postProcessBeforeInitalization() 메소드를 호출한다.
InitializingBean의 afterPropertiesSet() 메소드를 호출한다.
커스텀 호출 메서드 초기화
BeanPostProcessors의 후속 초기화 : BeanPostProcessor를 구현하면, postProcessAfterInitalization() 메소드를 호출한다.
빈 사용 준비가 완료 된다.

이후 컨테이너가 종료 될 경우

DisposableBean의 destroy()
커스텀 소멸 메서드 호출

2장 와이어링

2.1 스프링 설정 옵션 알아보기

세가지 기본적인 와이어링 메커니즘을 스프링에서는 제공하고 있다.

XML의 명시적 설정
Java에서 명시적 설정
빈을 찾아 자동으로 와이어링

대부분의 선택은 개인 취향의 문제이며 마음에 드는 것으로 선택한다.

2.2 자동으로 빈 와이어링하기

컴포넌트 스캐닝
오토 와이어링

두 가지 방식으로 빈에 와이어링을 한다. 모두 사용할 경우 강력하고, 명시적인 설정을 최소로 유지 가능.

스프링 어플리케이션 컨텍스트에서 모든 빈에게 ID를 할당한다. 모든 자동으로 ID를 주게 되면, 클래스 명의 첫 글자를 소문자화한 ID를 빈의 이름으로 갖는다.

명시적으로 빈에 이름을 부여하는 방법에는 @Component가 있고, 이와 같은 기능을 하는 JSR-330 표준에 해당하는 @Named 어노테이션이 있다.

@Component
public class CDPlayer implements MediaPlayer {
  private CompactDisc cd;

  @Autowired
  public CDPlayer(CompactDisc cd) {
    this.cd = cd;
  }

  public void play() {
    cd.play();
  }

}

그러나, 스프링에서는 주로 @Component 어노테이션을 주로 사용한다.

컴포넌트 스캐닝을 위해서는 베이스 패키지를 세팅 해야 하는데, 여러가지 방법이 있다.

XML을 이용한 방법

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:context="http://www.springframework.org/schema/context"
  xmlns:c="http://www.springframework.org/schema/c"
  xmlns:p="http://www.springframework.org/schema/p"
  xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
		http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd">

  <context:component-scan base-package="soundsystem" />

</beans>

Annotation 방법

@ComponentScan(basePackages="soundsystem") //array라, 복수개도 가능
public class CDPlayerConfig {
}

오토와이어링은 스프링이 빈의 요구 사항과 매칭되는 어플리케이션 컨텍스트상에서 다른 빈을 찾아 빈 간의 의존성을 자동으로 만족시키는 것을 말하는데, 스프링에서는 @Autowired 어노테이션을 사용한다. 표준으로는 @Inject를 사용하면 된다.

단, 매칭 되는 빈이 없다면 예외가 발생하는데, 이 예외를 피하려면, 어노테이션에 속성을 추가하면 되는데, @Autowired(required = false) 이렇게 하면 단점으로는 빈이 null일 가능성이 있어 방어 코딩이 안되면, NPE가 발생한다.

@bean 어노테이션이 하는 역할은 무엇일까 ? 모호하긴 한데, 좀 더 찾아 보고 해야 하는데, 일단 예제 코드 기준에서 이해한 바는 이렇다.

@Configuration
public class CDPlayerConfig {

  @Bean
  public CompactDisc compactDisc() {
    return new SgtPeppers();
  }

  @Bean
  public CDPlayer cdPlayer(CompactDisc compactDisc) {
    return new CDPlayer(compactDisc);
  }

}

stereo-javaconfig 하위 프로젝트인데, 여기서 @Bean 어노테이션을 지우고 실행 시켜보면, 실행 할 수 없다.

왜냐, 의존성을 주입 해야하는데, 둘 중 하나라도 없다면, 의존성을 주입할 객체를 찾을 수가 없다. 물론, 생성도 되지 않는다.

compactDisc 메소드의 경우 이 친구가 결국 의존성을 주입 할 대상 객체인데, 이 대상 객체가 없으면, cdPlayer에서 객체를 생성할 수 조차 없다.

@Bean 대신에 xml로도 설정을 할 수 있다.

생성자 주입을 사용, 빈 초기화하기

<constructor-arg>
c-namespace

2가지 방법으로 설정을 할 수 있는데, 사실 그냥 1번으로 하는게 더 깔끔하지 않나 싶기도 하다.

3장 고급 와이어링

3.3 오토와이어링의 모호성

기본 빈 지정
- @Primary로 지정
- @Qualifier를 통한 지정

git-command-collections

Wed, 12 Apr 2017 18:01:00 GMT

Git-tip

git 유용한 명령어 모음

환경 설정

출처 - 아웃사이더님 블로그

$ git config --global --list
현재 설정정보 조회할 수 있습니다. --global옵션은 전역설정에 대한 옵션이며 현재 프로젝트에만 적용할때는 주지 않습니다.
$ git config --global user.name "사용자명"
사용자명을 등록합니다 (필수)
$ git config --global user.email "이메일주소"
이메일 주소를 등록합니다. (필수)
$ git config --global color.ui “auto”
터미널에 표시되는 메시지에 칼라를 표시해줌

기본 명령어

git --version

현재 git의 버전을 확인합니다.

git init

현재 디렉토리에 git 저장소를 생성합니다.

git add 파일명

해당 파일을 추척함.

git add -u

Tracked file 중 수정 된 파일 전체를 staged file 상태로 만든다.

git commit -m "커밋메시지"

스테이징 영역에 올라가 있는 파일들을 커밋합니다.
-m 은 커밋메시지를 주는 옵션으로 여러 줄의 커밋메시지를 쓸 경우 -m 을 여러개 사용할 수 있습니다.

git commit -C HEAD -a --amend

지정한 커밋의 로그메시지를 다시 사용하여 기존커밋을 수정합니다.
-c를 사용하면 기존메시지를 수정할 수 있는 편집기를 실행해 줍니다.

git status

커밋되지 않은 변경사항을 조회합니다.

git diff

스테이징영역과 현재 작업트리의 차이점을 보여줍니다.
--cached 옵션을 추가하면 스테이징영역과 저장소의 차이점을 볼 수 있다.
git diff HEAD를 입력하면 저장소, 스테이징영역, 작업트리의 차이점을 모두 볼 수 있다.
파라미터로 log와 동일하게 범위를 지정할 수 있으며 --stat를 추가하면 변경사항에 대한 통계를 볼 수 있습니다.

git mv 파일명 새파일명

기존에 존재하는 파일을 새파일로 이동합니다.
변경이력은 그대로 유지합니다.

git checkout -- 파일명

아직 스테이징이나 커밋을 하지 않은 파일의 변경내용을 취소하고 이전 커밋상태로 돌립니다.
svn에서 revert와 동일합니다.

Branch와 Tag

git branch

현재 존재하는 브랜치를 조회합니다.
-r 옵션을 사용하면 원격저장소의 브랜치를 확인할 수 있습니다.

git branch 브랜치명B 브랜치명A

브랜치명A에서 새로운 브랜치 브랜치명B를 만듭니다. (git에서 기본 브랜치는 master라는 이름을 사용합니다.)

git branch 브랜치명

브랜치명의 새로운 브랜치를 만듭니다.(체크아웃은 하지 않습니다.)

git branch -d 브랜치명

브랜치를 삭제합니다.

git push <repository> :<branch_name>

원격 브랜치를 삭제합니다.
ex) git push origin :102-feature-seungdols

git branch -m 존재하는브랜치명 새로운브랜치명

존재하는 브랜치를 새로운브랜치로 변경합니다.
이미 존재하는 브랜치명이 있을 경우에는 에러가 나는데 -M 옵션을 사용하면 이미 있는 브랜치의 경우에도 덮어씁니다.

git tag 태그명 브랜치명

브랜치명의 현재시점에 태그명으로 된 태그를 붙힙니다.
git tag만 입력하면 현재 존재하는 태그 목록을 볼 수 있습니다.

git checkout 브랜치명/태그명

해당 브랜치나 태그로 작업트리를 변경합니다.

git checkout -b 브랜치명B 브랜치명A

브랜치명A에서 브랜치명B라는 새로운 브랜치를 만들면서 체크아웃을 합니다.

git rebase 브랜치명

브랜치명의 변경사항을 현재 브랜치에 적용합니다.

git rebase -i HEAD~~~

현재 HEAD에서 commit 3개 전까지를 rebase 대상으로 설정한다.

git merge 브랜치명

브랜치명의 브랜치를 현재 브랜치로 합칩니다.
--squash 옵션을 주면 브랜치명의 모든 커밋을 하나의 커밋으로 만듭니다.

git cherry-pick 커밋명

커밋명의 특정 커밋만을 선택해서 현재 브랜치에 커밋으로 만듭니다.
-n 옵션을 주면 작업트리에 합치지만 커밋은 하지 않기 때문에 여러개의 커밋을 합쳐서 커밋할 수 있습니다.

로그 관리

git log

커밋로그들을 볼 수 있으면 -1나 -2같은 옵션을 주어 출력할 커밋로그의 갯수를 지정할 수 있습니다.
--pretty=oneline 옵션을 주면 한줄로 간단히 보여주고 h 처럼 형식을 정해줄 수 있습니다.
-p 옵션을 사용하면 변경된 내용을 같이 보여줍니다.
--since="5 hours" 이나 --before="5 hours"같은 옵션도 사용가능합니다.
--graph 옵션을 주면 브랜치 트리를 볼 수 있습니다.

git log 커밋명

해당 커밋명의 로그를 볼 수 있습니다.
커밋명A..커밋명B (마침표2개)와 같이 입력하면 커밋명 A이후부터 커밋명 B까지의 로그를 볼 수 있습니다.
^은 -1과 동일해서 HEAD^라고 하면 최신바로 이전 커밋이고 HEAD^^^와 같이 쓸 수 있으며 HEAD~3을 하면 HEAD의 3개 이전의 커밋을 뜻합니다.

git blame 파일명

갈 줄 앞에 커밋명과 커밋한 사람등의 정보를 볼 수 있습니다.

git blame -L 10,15 파일명

-L 옵션을 사용하면 10줄부터 15줄로 범위를 지정해서 볼수 있고 15대신 +5와 같이 사용할 수 있습니다.
숫자의 범위 대신 정규식도 사용이 가능합니다.

git blame -M 파일명

-M 옵션을 사용하면 반복되는 패턴을 찾아서 복사하거나 이동된 내용을 찾아줍니다.
-C 옵션을 사용하면 파일간의 복사한 경우를 찾아줍니다.
-C는 git log에서도 사용가능하며 내용의 복사를 찾을때는 git log에서 -p옵션을 사용합니다.

git revert 커밋명

기존의 커밋에서 변경한 내용을 취소해서 새로운 커밋을 만듭니다.
-n옵션을 사용하면 바로 커밋하지 않기 때문에 revert를 여러번한 다음에 커밋할 수 있습니다.(항상 최신의 커밋부터 revert해야 합니다.)

git reset 커밋명

이전 커밋을 수정하기 위해서 사용합니다.
--soft 옵션을 사용하면 이전 커밋을 스테이징하고 커밋은 하지 않으며 --hard옵션은 저장소와 작업트리에서 커밋을 제거합니다.
git reset HEAD^와 같이 입력하면 최근 1개의 커밋을 취소할 수 있습니다.

git rebase -i 커밋범위

-i 옵션으로 대화형모드로 커밋 순서를 변경하거나 합치는 등의 작업을 할 수 있습니다.

원격저장소

git clone 저장소주소 폴더명

원격저장소를 복제하여 저장소를 생성합니다.
폴더명을 생략가능합니다.

git fetch

원격저장소의 변경사항 가져와서 원격브랜치를 갱신합니다.

git pull

git fetch에서 하는 원격저장소의 변경사항을 가져와서 지역브랜치에 합치는 작업을 한꺼번에 합니다.
파라미터로 풀링할 원격저장소와 반영할 지역브랜치를 줄 수 있습니다.

git push

파라미터를 주지 않으면 origin 저장소에 푸싱하며 현재 지역브랜치와 같은 이름의 브랜치에 푸싱합니다.
--dry-run 옵션을 사용하면 푸시된 변경사항을 확인할 수 있습니다.
로컬에서 tag를 달았을 경우에 기본적으로 푸시 하지 않기 때문에 git push origin 태그명이나 모든 태그를 올리기 위해서 git push origin --tags를 사용해야 합니다.

git remote add 이름 저장소주소

새로운 원격 저장소를 추가합니다.

git remote

추가한 원격저장소의 목록을 확인할 수 있습니다.

git remote show 이름

해당 원격저장소의 정보를 볼 수 있습니다.

git remote rm 이름

원격저장소를 제거합니다.

서브 모듈

git submodule

연관된 하위모듈을 확인할 수 있습니다.

git submodule add 저장소주소 서브모듈경로

새로운 하위모듈을 해당경로에 추가합니다.
추가만하고 초기화 하지는 않으며 commit hash 앞에 마이너스(-) 표시가 나타납니다.

git submodule init 서브모듈경로

서브모듈을 초기화 합니다.

git submodule update 서브모듈경로

서브모듈의 변경사항을 적용합니다.(저장소의 최신커밋을 추적하지 않습니다.)

기타 명령어

git archive --format=tar --prefix=폴더명/ 브랜치혹은태그 | gzip > 파일명.tar.gz

git archive --format=zip --prefix=폴더명/ 브랜치혹은태그 > 파일명.zip

해당 브랜치나 태그를 압축파일로 만듭니다.
--prefix를 주면 압축하일이 해당폴더 안에 생성되도록 할 수 있습니다.

git mergetool

설정에 merge.tool의 값에 있는 머지툴을 찾아서 실행합니다.

git gc

저장소의 로그를 최적화 합니다.
로그가 변경되지는 않고 저장하는 방식만 최적화 합니다.
--aggressive 옵션을 주면 더 자세하게 최적화합니다.

git rev-parse --show-toplevel

git 저장소내에서 입력하면 루트디렉토리를 알려줍니다.

출처 - 꿀벌 개발 일지

$ git branch -va

리모트를 포함한 브랜치 정보 보기

$ git remote update

리모트 정보가 업데이트 필요할 때

$ git log

로그 보기

$ git log --graph

그래프 형태로 보기

$ git log --pretty=oneline

한 줄로 보기

$ git log -p -1

마지막 1개 커밋과 변경된 diff 를 함께 보기

$ git shortlog

짧은 로그 보기

$ git shortlog --no-merges

머지 로그를 제외하고 보기

$ git show 커밋번호

특정 커밋의 로그 보기

$ git show topic1

브랜치는 커밋의 포인터이기 때문에 브랜치 이름을 사용해도 된다.

$ git show HEAD^

커밋 뒤에 ^를 붙이면 해당 부모를 찾는다.
위 코드는 바로 전 커밋을 보여준다.

$ git log master..topic1

아래 커밋은 master 에는 없지만, topic1 에는 있는 커밋을 보여준다.

$ git log origin/master..topic1

리모트 저장소를 대상으로도 비교할 수 있다.

$ git commit --amend

이전 커밋에 덮어쓰기
--amend 옵션으로 커밋하면, 이전 커밋과 다른 커밋 번호가 생성된다.

버그 찾기

git blame 명령을 사용하면, 해당 코드가 언제 수정되었는지 확인할 수 있다.

$ git blame -L 11,12 README.md

위 코드는 README.md 파일의 11,12 번째 라인이 언제 수정되었는지 추적한다.
결과 목록에서 ^가 붙은 것은 해당 줄이 처음 커밋되었다는 얘기다.

git commit - 취소 관련 명령어 정리

출처 - 에코지오 블로그

개별파일 원복

git checkout <파일>

워킹트리의 수정된 파일을 index에 있는 것으로 원복

git checkout HEAD <파일명>

워킹트리의 수정된 파일을 HEAD에 있는 것으로 원복(이 경우 —는 생략가능)

git checkout FETCH_HEAD <파일명>

워킹트리의 수정된 파일의 내용을 FETCH_HEAD에 있는 것으로 원복? merge?(이 경우 —는 생략가능)

index 추가 취소

git reset -- <파일명>

해당 파일을 index에 추가한 것을 취소(unstage). 워킹트리의 변경내용은 보존됨. (—mixed 가 default)

git reset HEAD <파일명>

위와 동일

commit 취소

git commit --amend

commit 후 수정 안하고, 바로 명령어를 입력하면 커밋 메시지만 변경 된다.

git reset HEAD^

최종 커밋을 취소. 워킹트리는 보존됨. (커밋은 했으나 push하지 않은 경우 유용)

git reset HEAD~2

마지막 2개의 커밋을 취소. 워킹트리는 보존됨.

git reset --hard HEAD~2

마지막 2개의 커밋을 취소. index 및 워킹트리 모두 원복됨.

git reset --hard ORIG_HEAD

머지한 것을 이미 커밋했을 때, 그 커밋을 취소. (잘못된 머지를 이미 커밋한 경우 유용)

git revert HEAD

HEAD에서 변경한 내역을 취소하는 새로운 커밋 발행(undo commit). (커밋을 이미 push 해버린 경우 유용)

워킹트리 전체 원복

git reset --hard HEAD

워킹트리 전체를 마지막 커밋 상태로 되돌림. 마지막 커밋이후의 워킹트리와 index의 수정사항 모두 사라짐. (변경을 커밋하지 않았다면 유용)

git checkout HEAD .

워킹트리의 모든 수정된 파일의 내용을 HEAD로 원복.

git checkout -f

변경된 파일들을 HEAD로 모두 원복(아직 커밋하지 않은 워킹트리와 index 의 수정사항 모두 사라짐. 신규추가 파일 제외)

참조 : reset 옵션

--soft : index 보존, 워킹트리 보존. 즉 모두 보존.
--mixed : index 취소, 워킹트리만 보존 (기본 옵션)
--hard : index 취소, 워킹트리 취소. 즉 모두 취소.

untracked 파일 제거

git clean -f
git clean -f -d : 디렉토리까지 제거

유용한 Alias 지정하기

git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit
git config --global alias.st status
git config --global alias.last 'log -1 HEAD'

기타 다른 별칭도 지정이 가능하니, 자주 사용하는 명령어는 alias 지정을 해두는 것이 좋다.

Git remote branch 가져오기

git branch
git branch -r : 원격 브랜치 목록
git branch -a : 모든 브랜치 목록
git checkout remote이름/branch이름
git checkout -b 생성할브랜치이름 원격브랜치이름
git checkout -t remote이름/branch이름

Reset 한 것을 취소하기

git reflog

#몇 번째 HEAD로 이동할지 확인한다.

git reset --hard HEAD@{num}

하던 일을 stashing 하기

작업을 막 하다가 갑자기 다른 일을 먼저 처리 해야 할 때가 있다. 그럴때, 현재 작업 트리를 temp로 저장시킬 수 있다.

$ git stash

위 명령을 하게 되면, 하던 일을 저장한다.

$ git stash list

위 명령어를 입력하면, stash의 목록을 확인 할 수 있다.

$ git stash apply

해당 명령어 입력시 가장 최근의 stash를 적용한다.
다른 것을 적용 하고자 한다면, stash 이름을 입력하면 된다.
--index 옵션을 주어야 staged 상태까지 복원이 된다.

Stash list 깔끔하게 정리하기

stash list는 자동으로 삭제가 되지 않는다.
단, 한 경우를 제외하면 말이다.
바로 stash로 branch를 만들고, 그것이 성공 했을 때를 제외하면, list를 수동으로 삭제 해주어야 한다.

$ git stash drop stash@{0}

Stash 되돌리기

stash를 적용하고 나니, 아차…이건 아니다 싶을 때 다시 복원하는 방법이다.
중요한 점은 아무래도 stash unapply를 지원하지 않아 우회적으로 사용하는 방법이다.

$ git stash show -p stash@{0} | git apply -R

위 명령을 alias 지정하여 사용하면 편리하다.

git config --global alias.stash-unapply '!git stash show -p | git apply -R'

Stash를 적용한 브랜치 만들기

git stash branch testchanges

remote에서 merge 완료 된 것 local에서 안보도록 하는 방법

alias git-clear='git fetch -p && git branch --merged | grep -v "\*" | grep -v master | grep -v dev | xargs -n 1 git branch -d'

git log 이쁘게 보기

git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit

javascript-Deferred-and-promise

Fri, 07 Apr 2017 12:09:00 GMT

JavaScript Deferred 객체와 promise

요즘 업무를 하다보니 느낀 사실인데, 비동기 처리나, 동기처리에 관한 이슈가 늘 나를 덮치곤 했다. 그런 이유로 JavaScript를 좀 더 잘하고 싶은 마음에 찾아본 자료를 정리해보았다.

Deferred Object

jQuery에서는 promise를 사용할 수 있도록 Deferred 객체를 제공합니다. 물론, jQuery.Promise()를 지원한다. 3.0부터 아마 제대로 지원한다고 생각하면 될 것 같습니다. 그러나, 사용하는 jQuery 버전이 3.0 이하인 경우에는 jQuery.Promise()를 사용할 수는 없습니다. jQuery.Deferred()가 존재하므로 이를 이용하여 promise를 사용할 수 있어 Callback Hell에서 벗어 날 수 있습니다.

var seungdolsProfileUpdateFunction = function() {
  var Deferred = jQuery.Deferred()
  try {
    Deferred.resolve('성공')
  } catch (error) {
    Deferred.reject(error)
  }
  return Deferred.promise()
}

var promise = seungdolsProfileUpdateFunction()

//1
promise
  .done(function(message) {
    console.log('success')
  })
  .fail(function(error) {
    console.log('fail')
  })
  .always(function() {
    console.log('All about success')
  })
//2
promise.done(function(message) {
  console.log('success')
})
promise.fail(function(error) {
  console.log('fail')
})
promise.always(function() {
  console.log('All about success')
})

다만, 여기서 주요하게 봐야 할 점은 Deferred()객체를 생성하여 사용할 경우, promise를 쓰려면, Deferred.promise()를 리턴해 사용해야 합니다.

Promise

이 패턴이 나온 계기는 콜백 헬이라는 코드를 분리시키고 콜백 헬에서 벗어나고자 나온 패턴으로 jQuery에서도 지원합니다. 물론, 기타 수 많은 라이브러리에서도 지원한다. 크롬은 자체 내장 Promise 또한 32버전 이후 부터 지원하고 있습니다.

jQuery
  .ajax
  //
  ()
  .done(function() {
    //work1
    //work2
  })

이러한 구조라면, 상당히 애매해지죠? work1이 먼저 수행 할지, work2가 먼저 수행 할지 모릅니다. 그러한 니즈로 인해 찾다 보니 Deferred객체를 알게 되었습니다. 그에 따르는 Promise 패턴을 또 보게 되었습니다.

일단, jQuery 1.5 이후 버전부터 포함 된 기능이며, Ajax 같은 비동기 함수를 핸들링하기 위한 도구로 나타났습니다. (단, jQuery 3.0 이하 버전에서 상당히 복잡한 promise를 쓸 경우 문제가 발생 할 수 있다고 합니다. 이유는 jQuery 자체에서 구현한 걸 사용한 문제이나, 3.0부터는 commonJS Promise/A를 구현하여 사용했다고 합니다.)

참고

jQuery API

The jqXHR Object

The jQuery XMLHttpRequest (jqXHR) object returned by $.ajax() as of jQuery 1.5 is a superset of the browser’s native XMLHttpRequest object. For example, it contains responseText and responseXML properties, as well as a getResponseHeader() method. When the transport mechanism is something other than XMLHttpRequest (for example, a script tag for a JSONP request) the jqXHR object simulates native XHR functionality where possible. As of jQuery 1.5.1, the jqXHR object also contains the overrideMimeType() method (it was available in jQuery 1.4.x, as well, but was temporarily removed in jQuery 1.5). The .overrideMimeType() method may be used in the beforeSend() callback function, for example, to modify the response content-type header:

The jqXHR objects returned by $.ajax() as of jQuery 1.5 implement the Promise interface, giving them all the properties, methods, and behavior of a Promise (see Deferred object for more information). These methods take one or more function arguments that are called when the$ .ajax() request terminates. This allows you to assign multiple callbacks on a single request, and even to assign callbacks after the request may have completed. (If the request is already complete, the callback is fired immediately.) Available Promise methods of the jqXHR object include

jqXHR.done(function( data, textStatus, jqXHR ) {}); An alternative construct to the success callback option, refer to deferred.done() for implementation details.
jqXHR.fail(function( jqXHR, textStatus, errorThrown ) {}); An alternative construct to the error callback option, the .fail() method replaces the deprecated .error() method. Refer to deferred.fail() for implementation details.
jqXHR.always(function( data|jqXHR, textStatus, jqXHR|errorThrown ) { }); (added in jQuery 1.6) An alternative construct to the complete callback option, the .always() method replaces the deprecated .complete() method. In response to a successful request, the function’s arguments are the same as those of .done(): data, textStatus, and the jqXHR object. For failed requests the arguments are the same as those of .fail(): the jqXHR object, textStatus, and errorThrown. Refer to deferred.always() for implementation details.
jqXHR.then(function( data, textStatus, jqXHR ) {}, function( jqXHR, textStatus, errorThrown ) {}); Incorporates the functionality of the .done() and .fail() methods, allowing (as of jQuery 1.8) the underlying Promise to be manipulated. Refer to deferred.then() for implementation details.

jQuery의 ajax() 함수는 jqXHR 객체를 반환하는데, 1.5부터 이 객체는 promise 인터페이스를 구현하여, promise 메소드의 주요 기능을 구현했다고 합니다. jqXHR객체에 대해 더 알고 싶다면, Deferred 객체에 대해 더 찾아 보면 될 것 같습니다.

Deprecation Notice: The jqXHR.success(), jqXHR.error(), and jqXHR.complete() callbacks are removed as of jQuery 3.0. You can use jqXHR.done(), jqXHR.fail(), and jqXHR.always() instead.

jQuery.ajax({
  url: '/seungdols/update',
  success: sucFunc,
  error: failFunc,
})

위처럼 작성했다면 이제는 아래 코드처럼 변화했습니다.

var promise = jQuery.ajax({
  url: '/seungdols/update',
  data: params,
})

promise.done(sucFunc)
promise.fail(failFunc)

then()를 이용하여 성공시 콜백과 실패시 콜백을 둘 다 하나로 합칠 수 있습니다.

var promise = jQuery.ajax({
  url: '/seungdols/update',
  data: params,
})

promise.then(sucFunc, failFunc)

그렇다면, promise의 장점을 무엇일까?

다수의 done, fail함수를 호출 할 수 있습니다.
ajax 수행 이후에도 done(), fail()을 콜 할 수 있으며, 콜백이 즉시 실행 됩니다.
promise를 서로 합칠 수 있습니다.

var promise1 = jQuery.ajax({
  url: '/seungdols/profile/update',
  data: params,
})
var promise2 = jQuery.ajax({
  url: '/seungdols/profile/info',
  data: params,
})

jQuery.when(promise1, promise2).done(function(xhrObject1, xhrObject2) {
  //work
})

jQuery 1.8부터 then() chaining이 가능해졌습니다.

var promise = jQuery.ajax({
  url: '/seungdols/profile/update',
  data: params,
})

function getThumnailImg() {
  return jQuery.ajax({
    url: '/seungdols/profile/thumnail',
    data: userId,
  })
}

promise
  .then(getThumnailImg)
  .then(function(data) {
    //work1
  })
  .then(successFunc, failFunc)

단, then() chaining이 가능해지면서 편리해진 것도 사실이지만, 중요한 점으로는 우선, 위 콜백 형태의 경우 anonymous function에서 Error가 발생하거나, getThumnailImg Function error가 발생할 경우, failFunc가 동작해야 하나, jQuery에서는 그렇게 동작하지 않는 문제로 인해 무분별한 promise pattern 사용을 금하는 게 좋다고 한다.

Promise pattern은 ECMA Script 6에 정식 포함 되었으며, Chrome 브라우저에서도 32이후 부터 native promise가 지원되기 시작했다. 당연히 node.js에도 포함 되어 있을 터…추가적으로 promise를 쓰는 방식이 2가지가 존재한다고 합니다. 이것에 대해서는 좀 더 연구가 필요로 해보입니다.

new Promise vs Promise.resolve()

Async 로직을 감싸거나 할 때는 new Promise()를 쓰자!
sync 로직인 경우 Promise.resolve()를 쓰자!

참고

javascript-pattern

Thu, 06 Apr 2017 17:39:00 GMT

[책] JavaScript Patterns

2장 기초

전역변수 최소화

전역변수의 문제점은 자바스크립트 어플리케이션이나 웹페이지 내 모든 코드 사이에서 공유가 된다. 모든 전역변수는 동일한 전역 네임스페이스 공간 안에 존재하게된다.

그래서 무조건 var 키워드를 변수 선언시 사용하는 것이 좋다.

자바스크립트에서는 var 키워드를 쓰지 않고도 변수 생성이 가능하다.
암묵적 전역이라는 개념이 존재하여, 선언 하지 않고 사용할 경우 명시적으로 선언한 전역변수와 다를바 없다.

function foo() {
  var a = (b = 0)
}

위처럼 코드를 작성하면, b는 전역변수가 된다. 평가 방식이 우측에서 좌측으로 이동한다.

var선언을 빼먹음으로써 부족용이 2가지 있다.

var를 사용하여 명시적으로 선언된 전역 변수는 삭제 할 수 없다.
var를 사용하지 않고, 생성한 암묵적 전역변수는 삭제 할 수 있다.

단일 var 패턴

함수에서 필요한 변수를 한군데서 찾을 수 있다.
변수를 선언하기 전에 사용할 때 발생하는 로직상의 오류를 막아준다.
변수를 먼저 선언한 후에 사용해야 한다는 사실을 상기시킨다.
코드량이 줄어든다.

function funcexmaple() {
  var a = 1,
    b = 2,
    sum = a + b,
    myObject = {},
    i,
    j
}

초기 값없이 선언된 변수들을 모두 undefined라는 값으로 초기화 된다.

암묵적 타입캐스팅 피하기

자바스크립트는 변수를 비교할 떄 암묵적으로 타입캐스팅을 실행한다. 그런 이유로 false == 0 이나 """== 0과 같은 비교가 true를 반환한다. 암묵적 타입 캐스팅을 피하기 위해서는 항상 표현식의 값과 타입을 모두 확인하는 ===, !== 연산자를 사용해야 한다.

var seungdols = 0
if (seungdols === false) {
}

//anti-patterns
if (seungdols == false) {
}

eval() 피하기

보안상에도 좋지 않고, 주로 사용하지 않으므로 아예 쓰지 말자. 쓰는 코드를 발견할 경우 즉시, 변경하도록 하자.

특히, setInterval(), setTimeout(), Function() 생성자에 문자열을 넘기는 것도 eval()과 유사한 기능을 하므로, 지양하자.

//안티패턴
setTimeout("seungdolsFunc()", 1000);
setTimeout("seungdolsFunc(1,2,3)", 1000);


//권장사항
setTimeout(seungdolsFunc, 1000);
setTimeout(funtion() {
    seungdolsFunc(1,2,3);
}, 1000);

parseInt()를 통한 숫자 변환

parseInt()를 사용하면 문자열로부터 숫자 값을 얻을 수 있다. 이 함수의 두번째 매개변수로 기수를 받는데, 생략하는 경우에 많지만 그럼 안된다. 파싱할 문자열이 0으로 시작할 경우 문제가 생길 수 있다. 일관성 없고, 예측을 벗어나는 결과를 피하려면 항상 기수 매개변수를 지정해주어야 한다.

var strMonth = '06'
var month = parseInt(strMonth, 10)

3장 - 리터럴과 생성자

var dog = {}

위는 빈 객체를 생성하는 객체 리터럴 표기법이다. 그러나, 참고해야 할 것은 자바스크립트에는 빈 객체라는 것은 없으며, 쉽게 말하는 의미이다. 간단한 객체 자체도, Object.prototype에서 상속받은 프로퍼티와 메서드를 가지고 있다.

var dog = { gender: 'M' } //권장 패턴

var cat = new Object() //안티패턴
cat.gender = 'W'

리터럴 표기법을 사용시, 유효범위 판별 작업도 하지 않는다. 생성자 함수 사용시에는 지역 유효범위에 동일한 이름의 생성자가 있을 수 있어, Object()를 호출한 위치에서부터 전역 Object 생성자까지 인터프리터가 쭉 거슬러 올라가면서 유효범위를 검색해야 한다.

사용자 정의 생성자 함수

var Person = function(name) {
  this.name = name
  this.say = function() {
    return 'I am ' + this.name
  }
}

var adam = new Person('Adam')
adam.say()

new 와 함께 생성자 함수를 호출하면, 함수 안에서 아래와 같은 일이 벌어진다.

빈객체가 생성되며, 이 객체는 this라는 변수로 참조할 수 있고, 해당 함수의 프로토타입을 상속받는다.
this로 참조 되는 객 체에 프로퍼티와 메서드가 추가 된다.
마지막에 다른 객체가 명시적으로 반환되지 않을 경우, this로 참조된 이 객체가 반환된다.

코드의 내부적인 상황을 표현하면 이렇게 된다.

var Person = function(name) {
  var this = {}

  this.name = name
  this.say = function() {
    return 'I am ' + this.name
  }

  return this
}

생성자의 반환 값

생성자의 반환값으로는 생성자 함수를 new와 함께 호출하면 항상, 객체가 반환 된다. 기본 값으로는 this호 참조되는 객체다.

함수내에 return문을 쓰지 않더라도 생성자는 암묵적으로 this를 반환한다.

생성자는 new와 함께 호출 될뿐이지, 다른 함수와 다를바가 없다. 그러나 new를 생략하면, 생성자 내부의 this 참조가 전역 객체인 window를 가리키므로 오류를 발생할 가능성을 높인다.

배열 리터럴

var arr = new Array('seungdols', 'seungho', 'speed') //안티 패턴

var arr = ['seungdols', 'seungho', 'speed']

참고로 자바스크립트에서 배열은 object 타입이다. 더군다나, new Array로 생성할 경우 오류가 발생할 요지가 있는데, 이는 인자로 숫자를 줄 경우이다.

var arr = new Array(3)

console.log(arr.length)

인자로 숫자를 주면 배열의 길이가 인자로 준 숫자 값으로 배열을 만드는데, 각 원소는 undefined로 생성 된다. 특히나, 부동 소수점으로 인자를 줄 경우 더욱 문제가 심해진다. 부동 소수점을 인자로 줄 경우에는 RangeError가 발생한다.

정규 표현식 리터럴

var re = '/\\/gm'

var reg = new RegExp('\\\\', 'gm') //안티 패턴

g: 전역매칭
m: 여러줄 매칭
i: 대소문자 구분 없이 매칭

에러 객체

자바스크립트에는 Error(), SyntaxError(), TypeError()등 여러 가지 에러 생성자가 내장 되어 있으며, throw문과 함께 사용된다. 이 생성자들을 통해 생성된 에러 겍체들은 다음과 같은 프로퍼티를 가진다.

name
- 객체를 생성한 생성자 함수의 name 프로퍼티, 범용적인 ‘Error’일 수 도 있고, ‘RangeError’와 같이 좀 더 특화된 생성자 일 수 있다.
message
- 객체를 생성할 떄 생성자에 전달된 문자열

try {
  throw {
    name: 'MyErrorType',
    message: 'oops',
    extra: 'This was rather embarrassing',
    remedy: genericErrorHandler,
  }
} catch (e) {
  alert(e.message)

  e.remedy()
}

에러 생성자를 new 없이 일반 함수로 호출해도 new를 써서 생성자로 호출한 것과 동일하게 동작하여 에러 객체가 반환된다.

4장 - 함수

함수는 일급객체이다.
함수는 유효범위를 가진다.
런타임 시점에 생성 가능하다.
변수에 할당 가능하며, 다른 변수에 참조를 복사 할 수 있고, 확장 가능하고, 몇몇 특별한 경우를 제외하면, 삭제 할 수 있다.
다른 함수의 인자로 전달할 수 있고, 다른 함수의 반환 값이 될 수 있다.
자기 자신의 프로퍼티와 메서드를 가질 수 있다.

//기명 함수 표현식 (named function expression)
var add = function add(a, b) {
  return a + b
}

//(무명)함수 표현식 or 익명 함수 (anonymous function)
var add = function(a, b) {
  return a + b
}

위 둘의 차이점은 별다른 것은 없고, 함수 객체의 name property가 빈문자열이 된다는 차이 밖에 없다.

//함수 선언문(function declaration)
function add(a, b) {
  //
}

함수 선언문은 전역 유효범위나 다른 함수의 본문 내부, 즉 ‘프로그램 코드’에서만 쓸 수 있다.

callMe(function() {
  //unnamed function expression
})

callMe(function me() {
  //named function expression
})

var seungdolsObject = {
  say: function() {
    //function expression
  },
}

위의 예 같은 경우에는 함수 선언문을 쓸 수 없다.

함수 호이스팅

function foo() {
  alert('global foo')
}
function bar() {
  alert('global bar')
}

function hoistMe() {
  console.log(typeof foo) //function
  console.log(typeof bar) //undefined

  foo() //local foo
  bar() //TypeError

  function foo() {
    alert('local foo')
  }

  var bar = function() {
    alert('local bar')
  }
}
hoistMe()

결국 선언된 위치와 상관 없이 끌어 올려지며 전역의 foo, bar를 덮어쓴다.

그런데, 지역변수 foo()는 나중에 정의되더라도 상단으로 호이스팅 되어 정상 작동하나, bar()의 정의는 호이스팅 되지 않고, 선언문만 호이스팅 된다.

때문에 bar()의 정의가 나오기 전까지는 undefined 상태이고, 따라서 함수로 사용할 수 없다. 또한 선언문 자체는 호이스팅 되어 유효범위 체인 내에서 전역 bar()도 보이지 않는 이유이다.

함수는 객체다.
함수는 지역 유효범위를 제공한다.

콜백 패턴

콜백 패턴은 이를테면, 함수의 특징 중 하나인 다른 함수의 인자로 전달 할 수 있다.를 활용한 방법이다.

function requestSpec(callback) {
  //working
  callback()
}

위와 같은 코드를 콜백 패턴이라 말하는데, 요즘은 사실 콜백 헬 패턴이 될 가능성이 높아서 꺼리는 패턴이긴 하다.

콜백과 유효범위

콜백이 일회성의 익명함수나 전역 함수가 아니고, 객체의 메서드인 경우도 많은데, 이 때, 콜백 메서드가 자신이 속한 객체를 참조하기 위해 this를 사용하면, 예상치 않게 동작할 수 있다.

var seungdolsApp = {}
seungdolsApp.color = 'green'
seungdolsApp.paint = function(node) {
  node.style.color = this.color
}

var findNodes = function(callback) {
  if (typeof callback === 'function') {
    callback(found)
  }
}

this.color가 정의 되지 않아 예상대로 동작 할 수 없다. 그리하여 동작 할 수 있도록 변경한다.

var findNodes = function (callback, callback_obj) {
    if(typeof callback === "function") {
        callback.call(callback_obj,found);
    }
}

findNodes(seungdolsApp.paint, seungdolsApp); -> findNodes('paint', seungdolsApp);//이렇게 바꿀 수 있다.
var findNodes = function (callback, callback_obj) {
    if (typeof callback === 'string') {
        callback = callback_obj[callback];
    }
    if (typeof callback === "function") {
        callback.call(callback_obj,found);
    }
};

함수 반환하기

함수는 객체이기 때문에 반환 값으로 사용될 수 있다. 즉, 함수의 실행 결과로 꼭 어떤 데이터 값이나, 배열을 반환할 필요는 없다는 뜻이다.

var setup = function() {
  alert(1)
  return function() {
    alert(2)
  }
}

var my = setup()
my()

자기 자신을 정의하는 함수

함수는 동적으로 정의 할 수 있고, 변수에 할당 할 수 있다. 새로운 함수를 만들어 이미 다른 함수를 가지고 있는 변수에 할당하면, 새로운 함수가 이전 함수를 덮어 쓰게 된다.

var scareMe = function() {
  alert('Boo')
  scareMe = function() {
    alert('Double Boo')
  }
}

scareMe()
scareMe()

이 패턴은 lazy function definition이라고도 불리는데, 최초 사용 시점 전까지 함수를 완전 정의 하지 않고 있다가 호출된 이후에는 더 게으르게 동작하기 때문이다.

장점으로는 함수가 어떤 초기화 준비 작업을 단 한 번만 수행하는 경우 유용하다. 단점으로는 자기 자신을 재정의한 이후에는 이전에 사용한 함수에 추가 되었던 프로퍼티를 모두 찾을 수 없다.

var seungdols = function() {
  console.log('Boo')
  seungdols = function() {
    console.log('Double Boo')
  }
}
seungdols.property = 'property'

var seungdols_company = seungdols

var seungho = {
  nick: seungdols,
}

seungdols_company()
seungdols_company()
console.log(seungdols_company.property)

seungho.nick()
seungho.nick()
console.log(seungho.nick.property)

seungdols()
seungdols() //undefined

즉시 실행 함수

즉시 실행 함수 패턴은 함수가 선언되자마자 실행되도록 하는 문법이다.

;(function() {
  console.log('watch out')
})()

JSLint는 위 패턴을 선호하는데, 보통 아래와 같이 사용해도 무방하다.

;(function() {
  console.log('watch out')
})()

즉시 실행 함수의 매개변수

;(function(name) {
  console.log('My ' + name)
})('seungdols')

매개변수도 전달을 할 수 있으나, 되도록 즉시 실행 함수에 많은 매개변수를 전달 하는 것은 좋지 않다.

장점으로는 전역 변수를 남기지 않고, 많은 양의 작업을 가능하도록 해준다. 선언 된 모든 변수는 스스로를 호출 하는 (self-invoking) 함수의 지역 변수가 되어 임시 변수가 전역 공간에 할당 되지 않는다.

즉시 객체 초기화

즉시 객체 초기화 패턴이라 불리며, 즉시 실행 함수와 유사하다.

;({
  maxHeight: 1330,
  maxWidth: 780,
  getWidth: function() {
    return this.maxWidth
  },
  getHeight: function() {
    return this.maxHeight
  },
  init: function() {
    console.log(this.getWidth())
    console.log(this.getHeight())
  },
}.init())

일회성 작업에 적합하고, init()이 완료되고 나면, 객체에 접근 할 수 없다. 만약 객체의 참조를 유지하고 싶다면, init() 마지막에 return this;를 추가 하면 된다.

장점으로는 단 한 번의 초기화 작업을 실행 하는 동안 전역 네임스페이스 영역을 보호 할 수 있다.

단점으로는 자바스크립트 압축 도구가 즉시 실행 함수 패턴에 비해 덜 효율적인 압축을 한다는 것이다.

메모이제이션 패턴

함수는 객체여서 프로퍼티를 가질 수 있는데, 이를 이용하여 함수에 프로퍼티를 추가하여 결과를 캐시하면, 다음 호출 시점에 복잡한 연산을 반복하지 않아도 되는 이점을 얻을 수 있다. 이를 Memoization이라 부른다.

var myFunc = function(param) {
  if (!myFunc.cache[param]) {
    var result = {}
    //working
    myFunc.cache[param] = result
  }
  return myFunc.cache[param]
}

myFunc.cache = {}

물론, 더 많은 매개변수나 복잡한 타입을 갖는다면, JSON 문자열로 직렬화하고, 이 문자열을 cache 객체에 키로 사용 할 수 있다.

단, 직렬화 하면 객체를 식별 할 수 없게 되는 단점이 존재한다.

설정 객체 패턴

설정 객체 패턴은 좀 더 깨끗하게 API를 제공하는 방법이다.

초기에는 어떤 함수가 단순 했다고 가정하자.

function addPerson(first, last) {}

function addPerson(first, median, date, last) {}

이렇게 유지보수 하다보면, 매개변수가 늘어 날 수 있다. 이 때 사용하는 방법이 설정 객체 패턴이다.

var conf = {
  first: 'seungdols',
  median: 'seungseung',
  last: 'jojoldu',
}

addPerson(conf)

매개변수와 순서를 기억하여 매칭 할 필요 없다.
선택적인 매개변수 사용이 가능하다.
가독성이 좋다.
매개변수 추가/삭제가 용이하다.
매개변수 명을 외워야 하는 단점 존재한다.
프로퍼티의 이름은 압축이 되지 않는다.

커리

함수적용

순수한 함수형 프로그래밍 언어에서 함수는 불려지거나 호출된다고 표현하는 것보다 적용 된다고 표현한다. 자바스크립트에서도 Function.prototype.apply()를 사용하면 함수를 적용할 수 있다.

var sayHi = function(who) {
  return 'Hello' + (who ? ',' + who : '') + '!'
}
sayHi()
sayHi('world')

sayHi.apply(null, ['hello'])

예제에서 확인이 가능하듯이 함수의 호출이나, 함수의 적용의 결과는 같다. apply()는 2개의 매개변수를 받는데, 첫번째는 함수내 this와 바인딩할 객체이고, 두번째는 배열 또는 인자로 함수 내부에서 배열과 비슷한 형태의 arguments 객체로 사용한다.

var seungdols = {
  sayHi: function(who) {
    return 'Hello' + (who ? ',' + who : '') + '!'
  },
}

seungdols.sayHi('world')
sayHi.apply(seungdols, ['company'])

위 처럼 함수가 객체의 메서드일 때의 예시이다. seungdols를 전달하게 되면, 해당 함수내의 this는 seungdols에 바인딩이 된다.

원래는 apply로 함수를 적용하는 방법이 더 직관적일 수도 있다는 생각이 든다…물론, 인자를 하나만 가지고도 해결 할 수 있다면, call() 메서드도 있다는 것을 기억하자!!

sayHi.apply(seungdols, ['company'])
sayHi.call(seungdols, 'company')

위 처럼 call()을 이용하는 것이 더 편리할 수도 있다.

부분 함수 적용

함수의 일부만 적용하는 것이 가능할까? 수학에서도 볼 법한 내용이지만, 실제로 가능하다.

var add = function(x, y) {
  return x + y
}

add.apply(null, [5, 4])

var newadd = add.partialApply(null, [5])
newadd.apply(null, [4])

위 처럼 partialApply() 메소드가 있다는 걸로 가정하고, 5 + 4를 부분적으로 적용 할 수 있는 함수를 머릿속으로 생각만 해보자. 이러한 방법을 써먹을 수 있을까? 자바스크립트에서는 자유도가 높기에 이러한 기능을 하는 함수를 구현 할 수 있다. 함수가 부분적인 적용을 이해하고 처리 할 수 있도록 만드는 과정을 커링이라고 한다.

커링

다른 함수형 언어에서는 커링이 언어 자체에 내장 되어 모든 함수가 커링 된다. 자바스크립트는 약간의 기교를 추가하면 커링이 가능하게끔 할 수 있다.

function add(x, y) {
  var oldx = x,
    oldy = y
  if (typeof oldy === 'undefinded') {
    return function(newy) {
      return oldx + newy
    }
  }
  return x + y
}

typeof add(5)
add(3)(4)

var add2000 = add(2000)
add2000(10)

위 코드를 조금만 살펴보면, add 함수에서 리턴하는 내부 함수에 클로저가 생성 된다. 부분 적용이 없이 값이 둘 다 전달 되면, 단순히 두 값을 더한다. 실제로 위 코드를 조금 더 간략하게 만들 수는 있다.

function add(x, y) {
  if (typeof y === 'undefined') {
    //부분 적용
    return function(y) {
      return x + y
    }
  }
  return x + y //전체 인자 적용
}

이러한 방식으로 커링을 만들어 볼 수 있다.

심화로 범용적으로 사용 할 수 있는 커링 함수를 만들어 본다면, 아래와 같다.

function schonfinkelize(fn) {
  var slice = Array.prototype.slice,
    stored_args = slice.call(arguments, 1)
  return function() {
    var new_args = slice.call(arguments),
      args = stored_args.concat(new_args)
    return fn.apply(null, args)
  }
}
function add(x, y) {
  return x + y
}
var newadd = schonfinkelize(add, 5)
newadd(4)

schonfinkelize(add, 1)(3)
//2단계 커링
var addOneCurry = schonfinkelize(add, 3)
addOne(10, 20, 30, 40)
var addTwoCurry = schonfinkelize(addOneCurry, 2, 3, 4, 5)
addTwoCurry(45, 4)

4장 요약

API패턴 : 함수에 더 좋고 깔끔한 인터페이스를 제공할 수 있게 돕는다.
- 콜백패턴 : 함수를 인자로 전달한다.
- 설정 객체 : 함수에 많은 수의 매개변수를 전달할 떄 통제를 벗어나지 않도록 해준다.
- 함수 반환 : 함수의 반환 값이 또 다시 함수 일 수 있다.
- 커링 : 함수와 매개변수 일부를 물려받는 새로운 함수를 생성한다.
초기화 패턴
- 즉시 실행 함수 : 정의되자 마자 실행
- 즉시 객체 초기화 : 익명 객체 내부에서 초기화 작업을 구조화하고, 다음 즉시 호출 할 수 있는 메서드를 제공한다.
- 초기화 시점의 분기 : 최초 코드 실행 시점에 코드를 분기하여, 어플리케이션 생명 주기 동안 계속해서 분기가 발생하지 않도록 막는다.
성능 패턴
- 메모이제이션 패턴 : 함수 프로퍼티를 사용해 계산 된 값을 저장하고, 그 값을 사용한다.
- 자기선언 함수 : 자기 자신을 덮으씀으로 두번 째 호출 이후부터 작업량을 줄이는 용도

5장 Patterns

네임스페이스 패턴

네임스페이스 패턴을 사용함으로써 전역 변수를 줄 일 수 있는 패턴으로 흔히 사용한다.

var SH = {}

SH.Parent = function() {}
SH.Child = function() {}

SH.seungdols = 1
SH.hello_module = {}
SH.hello_module.korean_hello = {}
SH.hello_module.korean_hello.data = { HI: '안녕하세요 ?', Hello: '안녕?' }
SH.hello_module.english_hello = {}

전역 네임스페이스 객체의 이름은 보통 어플리케이션 이름이나 라이브러리의 이름, 도메인명, 회사 이름 중에서 선택하여 사용하곤 한다. 보통 전역 객체 이름은 모두 대문자로 쓰는 명명 규칙을 사용한다.

장점

코드 내의 이름 충돌을 방지해준다.
전역변수를 줄일 수 있다.

단점

모든 변수, 함수에 접두어를 붙여야 한다.
전역 인스턴스는 하나이므로, 일부분이 수정되면, 전역 인스턴스를 수정 하게 된다.
이름이 중첩되고, 길어져 가독성은 나빠질 수 있다.

범용 네임스페이스 함수

var SH = {} //이렇게 쓰면, 기존에 있는 이름과 충돌 가능성이 높다.

if (typeof SH === 'undefined') {
  //개선안
  var SH = {}
}

var SH = SH || {}

기존 코드를 망가뜨리지 않고, 네임스페이스를 만드는 네임스페이스 함수를 구현 할 수 있다.

var SH = SH || {}
SH.namespace = function(ns_string) {
  var parts = ns_string.split('.'),
    parent = SH,
    i

  if (parts[0] === 'SH') {
    parts = parts.slice(1)
  }
  for (i = 0; i < parts.length; i += 1) {
    if (typeof parent[parts[i]] === 'undefined') {
      parent[parts[i]] = {}
    }

    parent = parent[parts[i]]
  }
  return parent
}

위 함수를 가지고 네임스페이스를 안전하게 만들 수 있다.

SH.namespace('SH.modules.hello')

비공개 프로퍼티와 메서드

자바스크립트에는 private, protected, public 프로퍼티와 메서드를 나타내는 별도 문법적인 방법이 없으나, 클로저를 이용해 비공개 멤버를 구현 할 수 있다.

function private_member() {
  var sh = 'seungdols'
  this.getSH = function() {
    //특권 메서드(privileged method)
    return sh
  }
}

var seungdols = new private_member()

console.log(seungdols.sh) //접근 안됨.
console.log(seungdols.getSH) //접근 됨.

객체 리터럴로 만드는 방법

var myobj = (function() {
  var name = 'seungdols'

  return {
    getName: function() {
      return name
    },
  }
})()

자바스크립트에서 클로저를 활용한 비공개 멤버를 쉽게 구현 할 수 있다.

비공개 멤버의 허점

파폭 초기 버전 일부는 eval() 함수에 두 번째 매개변수를 전달 할 수 있게 되어 있어 비공개 유효범위에도 접근 할 수 있다.
특권 메서드에서 비공개 변수의 값을 바로 반환할 경우 참조가 반환되어 외부 코드에서 비공개 변수 값을 수정할 수 있게 된다.

생성자를 사용해 비공개 멤버를 만들 경우 생성자를 호출하여 새로운 객체를 만들기 때문에 비공개 멤버가 매번 재생성 된다는 단점이 있다. 이를 해결하려면, 공통 프로퍼티와 메서드를 생성자의 prorotype 프로퍼티에 추가해야 한다. 이렇게 하면, 감춰진 비공개 멤버들도 모든 인스턴스가 함께 쓸 수 있다. 이를 위해서는 , 생성자 함수 내부에 비공개 멤버를 만드는 패턴과 객체 리터럴로 비공개 멤버를 만드는 패턴을 함께 써야 한다.

function Seungdols() {
  var name = 'seungdols'
  this.getName = function() {
    return name
  }
}

Seungdols.prototype = (function() {
  var browser = 'Chrome'
  return {
    getBrowser: function() {
      return browser
    },
  }
})()

var sh = new Seungdols()
console.log(sh.getName())
console.log(sh.getBrowser())

비공개 함수를 공개 메서드로 노출시키는 방법

노출 패턴은 비공개 메서드를 구현하면서 동시에 공개 메서드로도 노출하는 것을 말한다.

var SH

;(function() {
  var isEmpty = false

  function isEmpty() {
    //
  }

  function isNotEmpty() {
    //
  }

  SH = {
    isEmpty: isEmpty,
    isNotEmpty: isNotEmpty,
  }
})()

마지막 부분에서 접근을 허용해도 괜찮은 부분에 대해 SH 객체에 추가해준다. 즉, SH를 통해서는 공개 메서드가 되나, 다른 부분에서는 비공개 멤버가 된다.

모듈 패턴

늘어나는 코드를 구조화하고, 정리하는데 도움되는 패턴이다. 이 패턴을 이용하면, 개별적인 코드를 느슨하게 결합시킬 수 있다. 모듈패턴은 여러개의 패턴을 조합한 것을 말한다.

네임스페이스 패턴
즉시 실행 함수
비공개 멤버와 특권 멤버
의존 관계 선언

SEUNGDOLS.namespace('SEUNGDOLS.utilites.ArrayUtils')

SEUNGDOLS.utilities.ArrayUtils = (function() {
  //의존 관계
  var obj = SEUNGDOLS.utilities.object,
    lang = SEUNGDOLS.utilities.lang,
    array_string = '[object Array]',
    tos = Object.prototype.toString

  //비공개 메서드
  //...

  //var 선언 끝

  //일회성 초기화 실행
  //...

  //공개 API
  return {
    //1
    //2
  }
})()

모듈 패턴은 점점 늘어가는 코드를 정리 할 때 널리 사용하며, 추천 되는 방법이다.

참고

영문서이나 괜찮은 문서

모듈에 전역변수 가져오기

모듈을 감싼 즉시 실행 함수에 인자를 전달하는 형태가 있는데, 보통 전역 변수에 대한 참조 또는 전역 변수 자체를 전달한다. 이렇게 전달을 하게 되면, 탐색작업이 좀 더 빨라진다.

SEUNGDOLS.utilities.module = (function(app, global) {
  //
  //
})(SEUNGDOLS, this)

샌드박스 패턴

네임스페이스 패턴의 단점을 해결해주는 패턴이다. 더군다나 전역 네임스페이스를 보호해주는 역할을 한다. (아직 이해가 잘…)

function Sandbox() {
  var args = Array.prototype.slice.call(arguments),
    callback = args.pop(),
    modules = args[0] && typeof args[0] === 'string' ? args : args[0],
    i

  //함수가 생성자로 생성되도록 보장
  if (!(this instanceof Sandbox)) {
    return new Sandbox(modules, callback)
  }

  //this에 필요한 프로퍼티들을 추가
  this.a = 1
  this.b = 2

  // core this 객체에 모듈 추가
  if (!modules || modules === '*' || modules[0] === '*') {
    modules = []
    for (i in Sandbox.modules) {
      if (Sandbox.modules.hasOwnProperty(i)) {
        modules.push(i)
      }
    }
  }

  //필요한 모듈들 초기화
  for (i = 0; i < modules.length; i += 1) {
    Sandbox.modules[modules[i]](this)
  }

  callback(this)
}

Sandbox.prototype = {
  name: 'seungdols Application',
  version: '1.0',
  getName: function() {
    return this.name
  },
}

Sandbox('dom', 'hello', function() {
  console.log('hello')
})

스태틱 멤버

스태틱 프로퍼티와 메서드란 인스턴스에 따라 달라지지 않는 프로퍼티와 메서드를 말한다. 자바스크립트 언어에서는 스태틱 멤버를 지칭하는 문법이 지원 되지 않는다. 하지만, 생성자에 프로퍼티를 추가하여 구현할 수 있다.

공개 스태틱 멤버

var Gadget = function() {}

Gadget.isShiny = function() {
  return 'you bet'
}

Gadjet.prototype.setPrice = function(price) {
  this.price = price
}

위처럼 코드를 작성하면, 위험한 점이 존재하게 된다. Gadget.isShiny()를 호출 하면, 내부의 this는 Gadget 생성자를 가리키지만, 아래 코드에서는 위험하다.

var iphone = new Gadget()
iphone.setPrice(1000)

typeof Gadget.setPrice
typeof iphone.isShiny

스태틱 메서드가 인스턴스를 통해 호출 했을 때도 동작한다면, 편리한 경우가 있을 수 있는데, 이 때는 프로토타입에 메서드를 추가 하는 것만으로도 가능하다. 그러나, 문제가 포함되어 있다.

스태틱 메서드 안에서 this를 사용할 떄 주의해야 한다. Gadget.isShiny()를 호출했을 떄는 isShiny()는 가젯 생성자를 가리키지만, iphone, isShiny()를 호출 했을 때는 this가 iphone을 가리키게 된다.

비공개 스태틱 멤버

동일한 생성자 함수로 생성된 객체들이 공유하는 멤버다.
생성자 외부에서는 접근할 수 없다.

먼저 클로저 함수를 만들고, 비공개 멤버를 이 함수로 감싼 후, 이 함수를 즉시 실행한 결과로 새로운 함수를 반환하게 한다.

var Gadget = (function() {
  var counter = 0
  return function() {
    console.log((counter += 1))
  }
})()

실제로 카운터 값을 인스턴스끼리 공유하는 것을 확인 할 수 있다.

체이닝 패턴

객체에 연쇄적으로 메서드를 호출 할 수 있도록 하는 패턴이다.

코드량이 줄어 들고, 간결해진다.
디버깅이 어렵다.

양날의 검인듯 하지만, 알아 두면 좋을 듯한 패턴이다. 메서드에서 return 할 때에 this를 리턴하면 체이닝이 가능해진다.

method() 패턴

더글라스 크락포드가 고안한 클래스 기반의 언어에 적응한 사람들이 메서드를 구현하는 방식을 고안했다. 허나 이 방법을 추천하지는 않는다.

생성자 본문 내에 인스턴스 프로퍼티를 추가 할 수 있다. 그러나 this에 인스턴스 메서드를 추가하게 되면, 인스턴스 마다 메서드가 재생성 되어 메모리를 잡아 먹어 비효율적이다.

if (typoef Function.prototpye.method !== "function") {
    Function.prototype.method = function(name, implementation) {
        this.prototype[name] = implementation;
        return this;
    };
}