이맥스 org mode로 작성한 글을 블로그로 배포해보았다.
css를 좀 더 만져볼까 했지만, 역시 치장보단 글 자체가 중요하다고 생각해서 글이나 써야겠다고 생각한다.
새로 만든 사이트에는 좀 제대로 써보려고한다. 기존에 회사에서 썼던 기술블로그들도 좀 다시 정리해서 올려볼까 한다.
나의 사견이 들어간 글이 필요하다. 왜냐하면, 정보는 어짜피 책을 보는 것이 더 정확하기 때문이다.
나는 개발자로서 기술을 말로 유창하게 말하는 것을 좋아하지 않는다. 이것이 옳고 저것이 그르다. 라는 것을 말로만 유창한 사람들을 피한다.
개발자라면 기어코 코드로 먼저 말하는 사람들이 좋다.
개발은 이상하게 하면서 말은 유창하고 잘하는 것처럼 말하는 사람들이 많다. 하지만 그것을 말만 듣는 사람들은 잘 모른다.
복싱분석은 선수보다 비평가들이 더 잘하는 법이니까. 이론만으로는 그가 복싱을 잘하는지 알기 어려울 것이다.
그래서 새로운 기술블로그에는 코드를 보여주고 짧게 설명하는 식으로 가볼까한다.
그 첫번째 clojure에서 유명한 라이브러리 중에 하나인 ring 프로젝트의 소스를 까보고 직접 간단하게 만들어서 돌려보는 것을 주제로 삼았다.
https://ssisksl77.gitlab.io/code-that-talks/220122-ring.html
2022년 1월 2일 일요일
2021년 12월 20일 월요일
[리뷰] 자바스크립트 디자인 패턴
http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9788960778856
객체지향 프로그래밍
GoF패턴을 자바스크립트로 설명한다. 그렇기에 '이게 뭐야? 뭐 이런거에 이름을 붙여서까지 해서 사용해야해?' 라는 생각이 들게 만든다. 자바를 사용한 사람에게는 꽤나 중요한 패턴들이지만, 자바스크립트로 그 패턴을 어거지로 표현하려다보니 색다르면서 몇몇 패턴들은 자바스크립트에서는 쓰지 않겠다 라는 생각을 했다.
함수형 프로그래밍
GoF 패턴을 설명한 후, 함수형 프로그래밍을 간단하게 소개한다. 확실히 자바스크립트의 특성상 함수형 프로그래밍이 좀 더 깔끔하다는 느낌이 든다.
이후 패턴들
이후 설명하는 모델 뷰 패턴, 웹 패턴은 별로였다. 사실 GoF 설명 이후부터는 대충 페이지 크기를 부풀리기용처럼 보일정도다.
하지만 가장 마지막에 고급패턴이라고 써있는 내용은 꽤나 재밌었다.
괜찮은 책이지만 다른 명저에 비해서는 우선순위가 적은 책이라고 할 수 있다. 이 책을 보기 전에 GoF의 디자인패턴을 보지 않았다면 그 책부터 보는 것이 좋겠다.
2021년 12월 5일 일요일
기술 덜어내기
항상 덜어내야 한다고 생각했다.
가볍게 살아야 한다고 생각했다.
무언가 잘 안될 때, 항상 무엇을 더 버려야 하지? 라고 생각했다. 잠자는 시간을 버려야 하는걸까. 좋아하는 음식을 먹기를 버려야 하는 걸까? 나의 어떤 생각이 잘못되고 버려야 할까? 혹은 내가 항상 옳다고 생각했던 신념을 버려야 하는 걸까?
계속 버리다보면 거울 속에 보이는 초라한 몸뚱아리 넘어 정직한 나를 보게 된다.
덜어내기 전에
그 동안 많은 기술들을 습득하려했다.
알고리즘, 디자인패턴을 넘어서 유펭린의 집합론, OOP, 여러 고수들의 에세이, 철학, 소설, FP, 리스프, Clojure, 매크로, 유다시티의 로보틱스/블록체인 강의, nodejs와 express, golang ...
언어의 문법을 익히는 것은 너무 쉽다.
중요한 것은 왜 새로 만들어져야 하는가 라고 생각한다. IT만큼 새로운 것이 급격하게 만들어지고 사그러지는 곳은 드물다. (CoffeeScript 잘 지내니?)
go 언어에서 덜어내기
go는 그런면에서 지루한 언어이면서 새롭다. go는 심플함을 위해 신기능들을 넣지 않으려고 노력한다.
오늘 내가 이 글을 적는 가장 결정적인 동기는 바로 golang에 대한 세미나를 듣던 중 go언어 개발자의 인상깊은 Q&A답변을 들어서이다.
So what's been the biggest challenge in Go?
I'd say that, for me at least, the biggest challenge is keeping it simple.
It's always so easy to add another feature. And you can see so clearly how useful it would be to have this new facility in the language. But if we add every new facility in the language, then we get something so complicated that it's very difficult to use, like some existing languages today.
And I'd say the biggest challenge has been to say no.
언어를 만들면서 가장 힘들었던 것은 언어를 심플하게 만들기 위해 no를 말하는 것이 가장 힘든 허들이라는 점이었다는 것이다.
메인스트림의 언어들은 너도나도 할 것 없이 새로운 기능들을 추가한다. 옆 언어에서 쓰는 문법들을 추가하고 '우리도 이거 있어요~' 라고 판매한다. 이해한다. 그들이 어떻게 잘 사용하는지는 모르겠고, 모든 사람이 좋아할만한 모든 기술을 추가하는 것이다. 쓰고 안쓰고는 당신의 마음이다. 좋은 코드를 만드는 것은 오로지 당신의 선택이 좌우하는 것이다 라고 말하는 것 같다.
더글라스 크록포드의 덜어내기
더글라스 크록포드는 그의 서적 [javascript : The Good Parts] 나 최근 서적에도 소개하듯이, 좋은 기능만을 쓰고 좋지 않은 기능은 기본문법에 추가되었더라도 쓰지말라고 말한다. 쓰지 않는 것은 용기가 필요하다. 덜어내는 것은 참으로 힘들다.
추가하는 것은 때때로 힙해보이고, 여러 경험을 얻을 수 있을 것이다.
덜어내는 것은 힙하지도 않고, 경험을 얻지도 못한다. 덜어내는 것은 이미 경험한 자들 그리고 정확한 믿음이 있는 사람들의 것이다.
더 나은 코드란 무엇일까?
나의 덜어내기
나에게 더 나은 코드란, 더욱 담백하고, 덜어내고 덜어내서, 이해가 쉬운 별거 아닌 것처럼 보이는 코드이다. (사실 별거지만...)
이기능 저기능을 넣어서 오히려 복잡해보인다면 큰 문제가 있을 것이다.
최소한 새로운 기술, 범용함수 또는 매크로를 넣었다면 보기에는 쉬워보여야 한다.
별거 아닌 것처럼 보여서 '별거 아니네 이것만 고치면 되겠구만' 라고 고치고 지나갈 수 있는 코드이길 바란다.
2021년 12월 3일 금요일
Clojure를 하다가 Node.js/Express 만져보면서 느낀점.
Javascript는 참으로 특이한 언어이다. 문서를 보지 않아도 대충 보고 쓸 수 있을 정도로 직관적이다. 당연히 공식문서를 우선적으로 읽고 차근차근 문법을 익히고 개발을 진행하겠지만, 이상하게도 자바스크립트를 만질 때는 공식문서를 보지 않고, 기존 코드를 보더니 '음... 이렇게 돌아가는 거군?' 하면서 간단한 코드를 짤 수 있게 되었다. '물론 null이 Object라던가 하는 문제는 그 이후에 하나씩 알아가는 거고'
Node.js/Express를 현업에서 쓰진 않았지만 어떻게 사용하는지 궁금했다.
해서 Udacity강의를 들어보고 아래 유튜브를 보았다.
고백하자면 Clojure의 웹개발과 아주 비슷하다는 느낌을 받았다. 유튜브 강의에서 나오는 몇몇 기능은 개선을 하면 좀 더 멋지게(생산성있게) 개발할 수 있겠다는 생각도 했다.
2021년 11월 27일 토요일
매크로에 대한 글을 적다
https://green-labs.github.io/the-macro
이직한지 6개월이 되는 시점에 드디어 기술블로그를 올리게 되었다. 입문자를 위해 자세한 설명을 적거나 하진 않았지만 최소한 말로 약만 파는 것이 아니라, 나의 코드로 가능하다는 것을 보여주고 싶었다. 개발자는 코드로 말하는 것이 기본이니까.
LISP 매크로는 개발자에게 만지기 어려운 무서운 기술처럼 보이는가보다. 실제로 쉽지는 않다.
주류의 인사들은 '매크로를 쓰는 가장 좋은 방법은 쓰지 않는 것'이라고 한다. 그 만큼 매크로는 과한 기술이라는 평이 지배적이다.
하지만 과한 기술이라고 쓰지말라고 하는 것은 웃기다. 기술에 대한 이해도가 부족할 때 과하게 사용하니까 말이다. 즉, 이 말은 나에게 '넌 잘 모르니까 쓰지마' 라는 말로도 들린다.
매크로를 쓰지 말아야 하는 가장 큰 이유는 제대로 사용할 수 없는 개인의 이해도만이 이유가 되어야 한다고 주장하겠다.
어떤 기술이던 이해하지 못하고 쓰면 화를 면치 못한다. 반복문/조건문을 이해하지 못하고 쓴다면 안전할까? 죽음이 무서운 이유는 우리가 죽음을 모르기 때문이라는 말이 있듯이 매크로가 어둠의 기술처럼 느껴지는 이유는 그 만큼 매크로를 모르기 때문이라고 생각한다. 매크로는 죽음과 다르게 다행스럽게도 관심이 있으면 이해할 수 있다. 즉, 매크로가 두려운 이유는 매크로를 온전히 받아들이려고 하지 않는 나의 마음일 것이다.
난 권위에서 오는 말을 좋아하면서도 싫어한다. 여러 잠언들은 때때로 나를 편안하게 하지만 어떤 문장들은 맞는 말 같으면서도 고개를 갸우뚱하게 만드는 경우가 있다. 이때 '권위자'라는 단어는 그 갸우뚱하던 고개를 끄덕이게 만든다. 알아서 고개를 숙이거나 주위에서 숙이도록 강요하게 하는 힘이 있다.
'매크로를 쓰지말라' 라고 말한다면, 우리는 매크로가 무엇인지 정확히 알 필요가 있다. C, LISP의 매크로는 모두 컴파일러가 미리 만들어놓은 룰을 초월한다.
이 초월하는 힘을 처음 접한 나는 다음과 같은 경험을 하였다.
첫째, 내가 한번 휘두른 이 힘이 어디까지 닿는지 가늠이 되지 않는다.
둘째, 기존의 힘이 무색함을 느낄 수 있다.
셋째, 결국 강력한 이 힘에 집착하게 된다.
아마 구루들은 세번째에 이르는 것에 두려움을 느끼게 하고 싶었다고 생각한다.
그리고 구루들의 "매크로를 잘 쓰는 방법은 쓰지 않는 것이다" 라고 말하는 것에 대한 숨겨진 또다른 의도는 아래와 같다고 생각한다.
"매크로는 어짜피 기어코 위험을 무릎쓰고 자유로운 힘을 얻고자 하는 사람들이 쓰는 기술이다. 쓰지말라고 쓰지 않는 사람들에게는 필요없다. 어짜피 매크로를 쓰고자 하는 사람들은 나의 말이 의미 없다. 이미 쓰고 있을테니"
나는 위처럼 이해를 했다. 나는 그래서 매크로의 강력함과 위험성을 인지하고 자유롭게 쓰려고 한다. 만약에 그분들이 자신들은 그런 의미로 말한 것이 아니라고 말하면 어떤가?
그런 것들은 이미 상관없다.
2021년 11월 22일 월요일
2021년 4월 30일 금요일
컬리에서 작성하는 마지막 기술 블로그
y combinator에 대해서 한번 적어보았다.
마지막에는 종립님께서 글을 다듬어 주시고 javascript 코드를 추가해주셨다.
글이 더 풍부해졌다.
종립님과 함께 기고할 수 있어서 영광이다.
무엇보다
즐거웠다
2021년 3월 14일 일요일
[그런 REST API로 괜찮은가]를 보고
REST API는 무엇일까.
로이 필딩의 논문을 다 읽진 않았지만 그곳에는 client-server 아키텍처 사이에서 완벽하게 독립적으로 개발을 할 수 있도록 하는 API 아키텍처를 상상한 듯 하다.
만약에 할일 목록을 가져왔다면, 그 할일 목록에서 할 수 있는 행위들을 위한 링크를 제공하는 것이다. 그러면 클라이언트에선 특정 uri에 대한 정보를 알 필요도 없을 것이다.
이것이 HATEOS의 중요성인 듯하다. 로이 필딩을 정확히 무엇을 꿈꾼 것일까.
아래 유튜브 비디오를 보면서 고민을 하는 하루가 되었다. 로이 필딩 논문을 한 번 마저 읽어봐야겠다.
2021년 3월 11일 목요일
폴그레이엄은 왜 ycombinator라고 이름을 지었을까
ycombinator는 lambda calculus에서 꽤나 중요하게 여겨지는 아이디어이다.
오랫만에 컬리에 기술블로그로 기고할 겸 공부도하고 정리도 했다.
https://www.notion.so/tombox/Y-combinator-865c9614db0245ce869424a92462406b
취직을 위한 공부만 했다면 달라졌을까
Java/Spring을 많이 사용해왔지만, 솔직하게 Spring을 잘 안다고 할 수는 없겠다.
더 솔직히 말하면, 그동안 너무 쓸데없어 보이는 것들에 신경을 많이 썼던 것 같다.
유펭린의 집합론을 공부하질 않나, 잘 이해도 못하는 Lisp 책이나 보려고 하질 않나...
다 나의 커리어에는 큰 도움을 줄 것같지 않는 것들만 산더미로 공부했다.
그나마 괜찮은건 그래도 공부를 하긴 했다는 점
나만 괜찮다면 그것이 정도가 아니라도 괜찮다고 생각했다.
후회하지 않을 거라고 생각했다.
회사에서 사용하는 기술들을 그때그때 공부하면 되지 라는 알인한 생각을 가져왔다.
왜 그랬을까.
왜 나는 해야하는 공부에는 관심을 갖지 않고, 꼭 필요 없어 보이는 것에만 열중했을까
아쉽고도 아쉽지만, 어쩔 수 없다.
지금에라도 나의 공부 포트폴리오를 바꿔야할 것이다.
평생 이렇게 공부만 할 수는 없을 것이다.
언젠가는 꽃을 피워야 하고, 또 동료들이 내가 동료인 것이 만족할 수 있도록 나는 더 분발해야 한다.
누구를 만나던 그들과의 만남과 헤어짐에서 내가 좋은 동료로 남고 싶으니까...
나는 더 열심히 살아야겠다.
2021년 3월 4일 목요일
[패스트캠퍼스] 강의를 구매했다.
컬리에 있으면서 고민을 하게된 큰 그림을 보는 인사이트를 얻기 위해 구매해보았다.
아래는 관련 강의 링크이다.
https://www.fastcampus.co.kr/dev_red_yjs
윤진석님이 어떤 분인지는 잘 모르겠지만, 나보다 많은 경험을 하신분이니 가격에 맞는 정보를 알려주지 않을까 라는 생각에 구매를 진행했다.
그리고 생각보다 비싸진 않다. (이전에 구매한 clojureScript 강의에 비하면...)
수강을 다 하지 못해서 속단할 수는 없지만, 강의시간이 4시간 정도 된다. 거기에서 intro 관련 내용을 빼면 더 시간이 줄어든다. 가격은 15만원 정도였으니, 약 4시간이라고 치면 한시간에 37500원 정도다.
싼 가격은 아닌 것 같다.
그래도 다 들어보면 생각이 달라질 수 있으니 전부 수강하고 다시 리뷰를 해야겠다.
2021년 3월 1일 월요일
Learn Reagent Pro by Jacek Schae 강의 후기
reagent 란
reagent react를 clojureScript로 개발할 수 있게 해주는 라이브러리다.html을 만들 때는 hiccup라이브러리 처럼 clojure 자료 구조로 표현이 가능하다.
즉 일반적으로 컬렉션을 다루는 함수를 그대로 적용해도 잘 작동한다.
더 특이한 것은 reagent의 atom이다.
clojure에서 atom은 java의 AtomicInteger, AtomicReference와 같은 녀석처럼 병렬 프로그래밍을 할 때 사용한다.
reagent 에서 atom은 react, redux의 조합처럼 값을 변경시키면 저절로 해당 atom을 dereference해서 사용하는 구간이 다시 렌더링 되면서 값이 보여진다.
Learn Reagent Pro
강의는 꽤나 비싼데 reagent를 처음 접하는 사람에게는 유용할 것이다.reagent만 배우는 것이 아니라, shadow-cljs 같이 의존성을 적용하는 방법이나, 일반적으로 reagent를 사용할 때 어떻게 사용하는지 알 수 있다.
현재 5강 정도를 남겨두고 firebase에 올려보기 까지 진행했다.
꽤나 유익했고, 다음 강의 Learn Reframe Pro도 이어서 수강할 예정이다.
2021년 2월 27일 토요일
clojure로 카프카에 이벤트 발행
의존성
[org.apache.kafka/kafka-clients "2.5.0"]
사용코드
(ns kafka-demo2.core
(:import [org.apache.kafka.common.serialization StringSerializer]
[org.apache.kafka.clients.producer KafkaProducer ProducerRecord])
(:gen-class))
(def config
{"bootstrap.servers" "127.0.0.1:9092"
"key.serializer" StringSerializer
"value.serializer" StringSerializer})
(defn publish [topic str]
(let [producer (KafkaProducer. config)
record (ProducerRecord. topic str)]
(try
(.send producer record)
(finally (.close producer)))))
(defn -main
"I don't do a whole lot ... yet."
[& args]
(println "push A")
(publish "yhnam-topic" "A"))
도커
https://github.com/ssisksl77/clojure-breadcrumb 위 깃허브 참고실행
별거 없음 위 깃허브 참고
$ docker-compose up
$ lein uberjar
$ java -jar kafka-demo2-0.1.0-standalone.jar
그외 정리
https://www.notion.so/tombox/db6bc836f25d41948d28f3aff9ec1aff
피드 구독하기:
글 (Atom)