jq manpage와 code

https://stedolan.github.io/jq/

jq이 뭐하는 도구인지 소개는 한국어로 많은데, 그걸 갖고 조금 복잡한 패턴을 처리하는 자료는, 머리 나쁜 내가 이해하기에 적합한 자료는 찾지 못해서, 그냥 manpage을 읽고 시도.

이미 알고 있는 도구, 혹은 이미 대부분의 unix-like, linux 시스템에 깔려있는 도구들이 있는데, 막상 그 도구의 manpage을 차분히 읽어 보면, 내가 너무 게을렀었고 알려고 하지 않았기에 내 삶을 더 도움을 받을 수 있었을텐데, 그렇지 못했었던 도구들이 많은것 같아.

gnu coreutils, m4, awk, perl 만 해도 그랬었고, 조금이라도 알아가고 응용을 할수록 매일매일이 더 재밌고 강력해졌었던거 같아.

jq도 마찬가지일것 같아. 이 글을 쓰는 시점은 사실 몇주가 지났고, 어떻게 사용할지를, 기술적인 내용을, 어떻게 정리할지는 잘 모르겠다.

다만, 그래도 받았었던 인상은, 단순하게 보기에는 충분히 정밀하고 재밌는 도구라는 생각. 그 자체의 쿼리, 실행스크립팅, 함수 정의 등이 가능함을 보면서 흥미롭고 재밌었다.

그래서 저장소의 소스코드를 조금은 읽어보았다. 다른 인터프리터, vm의 코드들과 비슷한 기반을 갖고 나름대로 흥미롭게 구성한거 같았다. (난 잘모르니까ㅋ)

unix pipes, awk, perl, jq정도면 그래도 꽤 재밌는것들을 만들기에 충분하지 않을까 싶기도 해.

혹은, 이걸 이해하고, vm까지 이해한 다음에, 이와 유사한것을 내게 필요할때마다 만들어 쓰는것도 가능할거 같다.

과거 redis을 처음 접했을때, 이걸 이렇게 바라보고, 이렇게 설계해서 사용할수도 있구나 하는 감탄.

…문득 재밌게 읽었던 내용 인용: http://www.paulgraham.com/vwfaq.html

What database did you use?

We didn’t use one. We just stored everything in files. The Unix file system is pretty good at not losing your data, especially if you put the files on a Netapp.

It is a common mistake to think of Web-based apps as interfaces to databases. Desktop apps aren’t just interfaces to databases; why should Web-based apps be any different? The hard part is not where you store the data, but what the software does.

While we were doing Viaweb, we took a good deal of heat from pseudo-technical people like VCs and industry analysts for not using a database– and for using cheap Intel boxes running FreeBSD as servers. But when we were getting bought by Yahoo, we found that they also just stored everything in files– and all their servers were also cheap Intel boxes running FreeBSD.

(During the Bubble, Oracle used to run ads saying that Yahoo ran on Oracle software. I found this hard to believe, so I asked around. It turned out the Yahoo accounting department used Oracle.)

…사실 요즘의 웹앱은 너무 obtrusive하고 over-engineered되어 있는 모습인데, 특정한 부분만 기형적으로 그렇고, 정작 제대로 엔지니어링되어야 할 부분은 전무하거나, 거부하려고 하지.

마치, ‘프로젝트에서 특정한 xyz방법/활동은 시간낭비-or-너무 할일이 늘어나지 않나요?’..같은 질문과 같은거 같아. …다시 생각해보면, 어차피 조금이라도 제대로 의도를 살려서 해내려면, 그걸 걱정하기 이전에 그냥 해야 하는데…싶은 생각이 드는 발언처럼.

마찬가지로, 내가 볼때엔, 정말 재능있는, 그대로 해내는 이를 찾는 방법은 간단하지 않을까. …그냥 단순히 트렌디한 키워드가 이력서에 있거나, 당장 기술키워드가 매칭되는 경우는 오히려 쉬울지도 모른다.¹ …그냥 매칭되기 위해서 그걸 익히고 썼을테니, 그 이상은 ㅎㅎㅎ…그렇잖은가.

그리고 이런 쿼리언어 같아 보이는 것, 혹은 특정목적에 특화된 작은 functional language, logic language이 앞으로 더 가치가 커질 가능성이 높다고 생각. 직접 이걸 사용하지 않더라도 말이다. 위의 ‘너무 많은 웹/앱서비스들이 오버이지 않나’이란 생각은, 실은 대부분은 진지하게 코드를 짜고, 그 엔지니어링의 난이도가 엄청 높다기 보다는 착실함, 검증가능하고, 명세적으로 잘 정리하는지, 꾸준히/명확한 방식으로, 자기 ego을 좀 내려놓고 bs 않고, 그냥 해나가면 좋은 결과가 나온다고 생각한다. …솔직히 말해서. …그런데 그런 ‘대부분’은 역으로 말하자면, 굳이 복잡한 코드를 직접 짜는거 자체가 불필요한 일이고, 지금 과도기적으로 어쩔수없이 해야 하는것뿐이고, 심지어 소모적인데… 그렇다면 요즘 이야기가 대두되는 코드를 만들어주는 도구들이나 그런것들로 대체가 되어갈것이 당연한거 같아. …그렇다면, 그렇게 된 시점이라면, 당연히 데이터를 어떻게 잘 조작하고, 다루는것에 집중하게 될테니까.

음… 조금 더 상상을 더 발전시켜 보면, 흔히 팔아먹는 기획자와 개발자의 스테레오타입과 그 대립 같은거 별로 좋아하지 않는데,² 어쨌든 그런것들이 되면, 과연 지금의 code literacy 조금 있다고 그럴 필요도, 그게 먹히지도 않을거 같고, 반대로 그때에는 그냥 해내는, 그대로 하려는 이들이 더 좋을 시점이 될거 같아서. 단지 code literacy 조금이 장벽으로서 무너지게만 된다고 해도 말이다.

“Programming in Basic causes brain damage.” — Edsger W. Dijkstra

https://quotefancy.com/quote/1164258/Edsger-W-Dijkstra-Programming-in-Basic-causes-brain-damage

…지금의 “code literacy"은 단지, imperative한 사고구조는 그다지 어려울게 없지만, 거기에 익숙해져서 과도기적인 코드를 읽고 따라가는것뿐인데, 실제로 현실의 문제들은 logic language, functional language으로 더 효과적으로 표현될테고, 그건 오히려 역설적이게도 그런 imperative한 mental model에 굳은 이들에게는 더 불편하고, 그렇지 못한 이들이 더 효과적이고 명확하게 표현하기 적합할거 같아.

…어느쪽이 됐든, 어떻게 되든 상관없이. 주변인들에게 감사할줄 알고, 미안해할줄 알고, 겸손하고 염치와 양심을 잃지 않고 살아야 하는거 같다. 그렇다면 그때에도 별 상관이 없을테니까.