
Jaeyeol Lee
@kodingwarrior@hackers.pub · 501 following · 394 followers
Neovim Super villain. 풀스택 엔지니어 내지는 프로덕트 엔지니어라고 스스로를 소개하지만 사실상 잡부를 담당하는 사람. CLI 도구를 만드는 것에 관심이 많습니다.
Hackers' Pub에서는 자발적으로 바이럴을 담당하고 있는 사람. Hackers' Pub의 무궁무진한 발전 가능성을 믿습니다.
그 외에도 개발자 커뮤니티 생태계에 다양한 시도들을 합니다. 지금은 https://vim.kr / https://fedidev.kr 디스코드 운영 중
Blog
- kodingwarrior.github.io
mastodon
- @kodingwarrior@silicon.moe
Github
- @malkoG
Jaeyeol Lee shared the below article:
지적 재산권
정진명의 굳이 써서 남기는 생각 @jm@guji.jjme.me
지적 재산권에 대해서 이야기를 하려면 지적 재산권 제도를 통해서 이룩하려는 것이 무엇인지를 이야기해야 합니다. 저는 지적 재산권을 세 가지로 보는데, 기능을 실현하는 것에 관련된 것과(특허, 실용신안) 표현에 관한 것과(저작권) 공정한 시장을 위한 것(상표)으로 나눌 수 있을 것 같습니다. 상표는 조금 성격이 다르다고 생각해 따로 이야기하겠지만, 어쨌든 지적 재산권이란 어떤 이로운 것을 새롭게 생각해낸 주체의 권리를 보장해주기 위한 제도지요.
그런데 이 '생각해낼 수 있는 어떤 이로운 것'이란, 대다수가 저렴하게 복제가 되거나 복제된다고 해서 그 가치가 줄어들지 않는다는 특징이 있습니다. 기능을 실현하는 지식도, 표현된 이야기도, 가끔은 '이 로고가 붙은 제품은 좋다'는 믿음도 말이지요. 어떤 면에서 말하자면, '생각해낼 수 있는 이로운 것'이 제한없이 복제될 수 있는 상태가 편익의 합을 극대화할 수도 있을 것입니다.
하지만 이렇다면, 어떠한 노력을 들여서 복제될 수 있는 무언가를 만들어내는 행위가 경제적으로 보답받지 못하는 상태가 되리라고 생각할 수 있겠지요. 우리는 그런 행위가- 발명과 창작이 사회의 편익을 증가시킨다고 이해하고 있고, 그걸 위한 인센티브를 주고 싶다고 생각합니다. 지적 재산권은 제 생각에 그것을 보장하기 위한 도구입니다. 그러나 극단적인 경우를 생각해 봅시다. 지적 재산권이 개인에게 기한과 범위 없이 인정되고, 그것을 계속 물려줄 수 있는 거지요. 불을 쓰기 위해서 처음 불을 발견한 사람의 자손에게 사용료를 내고요. 누군가가 벽에 커다란 낙서를 해서 그것을 방송으로 보도하면, 그 낙서를 복제한 것이기 때문에 보도하기 위해서 저작권료를 지불해야 할 수도 있지요. 뭐, 그러면 안 되는 건 아닐 순 있지만, 사회의 편익이 그렇게 높을 것 같지는 않습니다.
제 주장은, 지적 재산권은 다음 두 상황의 균형을 맞추는 제도라는 것입니다.
- 지식과 표현이 아무 제한 없이 복제되어 지식과 표현을 만들어려내는 시도가 저해되거나, 사회가 원하는 만큼 이루어지지 않는 상황
- 지식과 표현의 복제가 너무 제한되어 사회가 복제로 얻을 수 있는 편익이 감소하는 상황
대부분의 경우는 1번 상황이 문제가 됩니다. 2번 상황은 꽤 이론적인 것처럼 보이지만, 충분히 주의해서 관찰한다면 사회의 어떤 문제는 2번 상황에 해당한다는 걸 찾아보실 수도 있을 것입니다. 이미 우리의 지적 재산권은 만료, 공정 이용과 같은 방식으로 동의 없는 복제를 허용하고― 다시 말해 제작자의 권리를 무한정 인정하고 있지는 않습니다.
두 상황의 균형은 사회의 영향을 받기 때문에, 지적 재산권이 어디까지는 제작자의 권리를 보호하고 어디부터는 보호 없는 복제를 허용하게 두어야 하는지는 그 사회의 변화에 맞추어 적절하게 갱신되어야 한다고 생각합니다.
좀 쓰다 급하게 마무리하고 자러 갑니다. Hacker's Pub 가입 이후 처음이라 올리긴 하는데요…
옥텟 규칙으로 본 IETF RFC 9110 “HTTP Semantics” https://eonj.github.io/trouble.log/2025-04-09.an-octet-aspect-to-ietf-rfc-9110/
GeekNews의 〈소프트웨어 엔지니어로 산다는 건 미친 짓이야〉 주제에 @youknowone 님께서 쓰신 좋은 댓글:
소프트웨어 개발이 어려운 일이라는 사람들은 본인이 그 일을 하는 이유가 뭘까요? 고되고 힘든 일이지만 보람있는 일이라서 하시나요? 이 업계에서 그런 분들은 그리 많지는 않았던 것 같습니다. 남들이 못하는 것 같으니까 어렵다고 주장하는거지, 실상은 그게 본인한테 가장 쉬운 일이니까 하시는 것 아닌가요? 남들이 좀 띄워준다고 자화자찬하면서 나만 특별한 양 여기면서 눈을 가리지 말고 주위를 봐야합니다. 이공계에서 어떤 분야가 방구석에서 인터넷 좀 보고 독학한다고 (잘 하면) 몇달만에 현업에 투입할 수 있는 전문가가 됩니까?
(…중략…)
물론 남들이 가지지 못한 훌륭한 손재주를 가진 사람은 존중받아 마땅하지만, 약간의 손재주를 연마했다고 해서 소싯적 배워둔 손재주로 평생 먹고 살면 좋을텐데 왜 그럴수 없을까, 나는 이런 훌륭한 손재주를 가졌는데 다른 사람들처럼 힘들게 일하지 않아야 하는 것 아닐까, 나는 남들은 쉽게 하지 못하는 대단한 재능을 가진 것이 아닐까 등등의 특별한 나에 심취하는건 교만에 가까운 일이 아닐까 합니다.
쿠버세란 옵스 엔지니어 연봉을 뜻한다
Model Context Protocol has prompt injection security problems
https://simonwillison.net/2025/Apr/9/mcp-prompt-injection/
📣 Exciting news! Fedify CLI is now available via Homebrew!
If you're using #Homebrew on macOS or #Linuxbrew on Linux, you can now install our CLI toolchain with a simple command:
brew install fedify
This makes it even easier to get started with building your federated server app. Try it out and let us know what you think!
개인적으로 쿠버네티스를 편하게 쓰기 위한 공부를 어느 정도 마친 상태에서 보면 "아 이거 쿠버 하나만 떠 있으면 편하게 이것저것 띄우고 할 수 있는데 괜히 귀찮게 세팅해야 하네"라는 생각이 들기도 하지만 😅 쿠버네티스 잘 모르는 상태에서는 참 막막하겠다 싶긴 합니다....
RE: https://hackers.pub/@xt/01961970-a29f-78ff-baaf-1db2056a78e1
저, 저도 90% 이상의 경우 도커 컴포즈 정도가 적당한 추상화 수준이라고 생각해요...
실제로 쿠버네티스 쓰는 팀에서 일해 본 경험도 그렇고, 주변 이야기 들어 봐도 그렇고, 도입하면 도입한 것으로 인해 증가하는 엔지니어링 코스트가 분명히 있다는 점은 누구도 부인하지 않는 것 같은데요. 쿠버네티스를 제대로 쓰는 것 자체도 배워야 할 것도 많고, 엔지니어가 유능해야 하고, 망치도 들여야 하고... 웬만하면 전담할 팀이 필요하지 않나 싶어요. (전담할 '사람' 한 명으로 때우기에는, 그 사람 휴가 가면 일이 마비되니까.)
엔지니어만 100명이 넘는 곳이라면 확실히 도입의 이득이 더 크겠지만, 반대로 혼자 하는 프로젝트라면 도무지 수지타산이 안 나올 것이라고 생각합니다. 따라서 쟁점은 그 손익분기점이 어디냐일 텐데... "대부분의" 서비스는 대성공하기 전까지는 도입 안 해도 되지 않나, 조심스럽게 말씀드려 봅니다. 즉 쿠버네티스가 푸는 문제는 마세라티 문제인 것이죠...
특히 클라우드 남의 컴퓨터 를 쓰지 않고 베어메탈 쓰는 경우는 더더욱...
RE: https://hackers.pub/@hongminhee/019618b4-4aa4-7a20-8e02-cd9fed50caae
Hackers' Pub의 에모지 반응 기능은 Mastodon의 좋아요, Misskey 계열, Pleroma 계열, kmyblue 및 Fedibird의 에모지 반응 기능과 호환됩니다. 기술적으로는 기본 에모지인 ❤️는 Like
액티비티로 표현되며 그 외 나머지 에모지는 EmojiReact
액티비티로 표현됩니다. Mastodon, kmyblue, Fedibird의 좋아요는 ❤️ 에모지 반응으로 변환됩니다 (Misskey의 동작과 유사). 또한, Misskey 계열과 달리 한 사람이 한 콘텐츠에 여러 에모지 반응을 남길 수도 있습니다 (Pleroma 계열의 동작과 유사). Hackers' Pub 사용자가 남길 수 있는 에모지 반응은 ❤️, 🎉, 😂, 😲, 🤔, 😢, 👀 이렇게 7종이며, 그 외의 에모지 및 커스텀 에모지는 보낼 수는 없고 받는 것만 됩니다.
에모지 반응 기능이 배포되었습니다. 당분간 버그가 좀 있을 수도 있지만 양해 바랍니다. 전 이제 차단을 구현하러 가겠습니다…
Jaeyeol Lee shared the below article:
같은 것을 알아내는 방법

Ailrun (UTC-5/-4) @ailrun@hackers.pub
이 글은 일상적인 질문에서부터 컴퓨터 과학의 핵심 문제에 이르기까지, '같음'이라는 개념이 어떻게 적용되고 해석되는지를 탐구합니다. 특히, 두 프로그램이 '같은지'를 판정하는 문제에 초점을 맞춰, 문법적 비교와 $\beta$ 동등성이라는 두 가지 접근 방식을 소개합니다. 문법적 비교는 단순하지만 제한적이며, $\beta$ 동등성은 프로그램의 실행을 고려하지만, 계산 복잡성으로 인해 적용이 어렵습니다. 이러한 어려움에도 불구하고, 의존 형 이론에서의 형 검사(변환 검사)는 $\beta$ 동등성이 유용하게 활용될 수 있는 중요한 사례임을 설명합니다. 이 글은 '같음'의 개념이 프로그래밍과 타입 이론에서 어떻게 중요한 역할을 하는지, 그리고 이 개념을 올바르게 이해하고 구현하는 것이 왜 중요한지를 강조하며 마무리됩니다.
Read more →윌 라슨의 엔지니어링 리더십 - 테크 리더를 위한 성공 전략 (윌 라슨 (지은이), 임백준 (옮긴이) / 한빛미디어 / 2025-04-18 / 26,000원) https://feed.kodingwarrior.dev/r/g3kdkp
http://www.aladin.co.kr/shop/wproduct.aspx?ItemId=362060448&partner=openAPI&start=api
North Korean IT workers have infiltrated the Fortune 500
Link: https://www.yahoo.com/news/thousands-north-korean-workers-infiltrated-110000417.html
Discussion: https://news.ycombinator.com/item?id=43617352
이 글에선 없는, bash보다 Ruby가 좋은 이유가 하니 더 떠오른다.
셸 스크립트를 작성하다보면 필연적으로 awk나 sed 같은 걸 쓰게 되는데, 이게 macOS/BSD와 Linux에서 서로 다른 버전(BSD awk / GNU awk)이 들어있고 지원하는 기능도 미묘하게 다르다보니 작성한 스크립트가 다른 OS에서 작동하지 않을 수 있는데, Ruby나 Perl로 짜면 이런 걱정을 하지 않아도 된다.
https://hackers.pub/@kodingwarrior/2025/cli-workflow-hacks-using-bash-and-ruby
CLI 도구를 조합하여 나만의 요술봉 만들기 (feat. Ruby)
<본론으로 들어가기에 앞서, 이 글에서는 Bash 스크립트에다가 Ruby를 섞어서 사용하는 트릭을 서술할 예정인데, 다른 스크립팅 언어로도 해낼 수 있음을 강조해둔다.쉘스크립트로 어떻게 워크플로우를 개선할 수 있을까?어떻게 하면 CLI 도구를 잘 사용할 수 있을까?<이런 고민들, 누군가는 했을 것이다. 이 글을 읽는 여러분은 한번씩은 거치고도 남았을 것이다. 이 글에서는 간단한 커맨드의 조합만으로도 여러분의 삶을 바꿀지도 모르는 비법을 소개하고자 한다. Bash 스크립트를 잘 짜는 방법을 안다면 분명 도움이 되는 구석이 많다. OpenBSD, 리눅스 등을 기반한 어지간한 OS에서는 Bash 스크립트를 지원하기도 하니까 말이다. 하지만, Bash 스크립트 단독으로는 가독성이 떨어지기도 하고, 일회성으로 짠다면 더더욱 직관적으로 와닿는 코드를 짜기도 어렵다. 하지만, Ruby나 Perl 등의 스크립트와 함께라면 그나마 좀 더 가독성이 있는 스크립트를 짤 수 있게 된다.그렇다면 왜 Bash 대신 Ruby인가? Bash를 사용해서 스크립트 짜는 것이 원론적인 접근이고, 많은 곳에서 스크립트를 짤 때 권장하고 있다. 가능하면 외부 소프트웨어와의 의존성을 줄여야 하고, 어디서든 돌아가는 스크립트를 짜야하기 때문이다. 하지만, 내 개발환경에서만 돌리는 일회성의 스크립트라면? Ruby 정도는 섞어서 써도 괜찮다. 사실상 답정너이긴 하지만, 왜 Ruby로 스크립트를 짜는 것이 도움이 되는가? 왜, 꼭 Ruby를 써야하는가? 이유를 나열하자면 아래와 같다.자료형을 다루는 데 있어서 타입 구분이 확실하다내가 다루는 데이터가 어떤 자료형인지 긴가민가한 Bash 스크립트에 비해, Integer/Float/String/Hash/Array 등 명시적으로 구분되는 자료형으로 확실하게 구분되는 점에 감사할 수 있다.여러분이 macOS를 사용하고 있다면, homebrew가 깔려있다면, 사실상 Ruby는 기본으로 딸려오는 옵션이라고 보면 된다.(macOS 유저 한정으로) 빌드 스크립트를 짜는데 요긴하게 도움이 될 수 있다.XCode에서 빌드할때 CocoaPod를 사용하는데, 내부적으로 Ruby 스크립트로 구성이 되어 있다. 또한 Fastlane에서 빌드 스크립트를 작성할때 Ruby를 사용한다. 유사한 작업을 할 때 지식이 전이될 수 있다.JSON/CSV/YAML을 다루는 라이브러리가 표준라이브러리로서 내장이 되어 있다. 이를 어떻게 다룰 수 있는지는 후술하겠다.<Ruby로 One-liner 스크립트 작성하기 보통은 Ruby 코드를 작성할때 irb 같은 대화형 인터페이스를 사용하는 것이 일반적이지만, Bash 스크립트와 섞어서 사용할때는 one-liner 스크립트를 작성하는 것으로 시작한다. 여기서 one-liner 스크립트란 한줄짜리로 실행하는 스크립트라고 이해하면 된다. ruby one-liner 스크립트로 작성할때는 다음과 같이 시작한다.$ ruby -e "<expression>"<여기서 -e 옵션은 one-liner 스크립트의 필수요소인데, 파라미터로 넘겨준 한줄짜리 Ruby 코드를 evaluation해주는 역할을 한다. 여러분이 파이프 혹은 리다이렉션에 대한 개념을 이해하고 있다면, 이런 트릭도 사용할 수 있다.$ echo "5" | ruby -e "gets.to_i.times |t| \{ puts 'hello world' \}"# =># hello world# hello world# hello world# hello world# hello world<여러분이 표준라이브러리를 사용하고 싶을때는 -r 옵션을 사용할 수도 있다. 이 옵션은 ruby에서 require를 의미하는데, 식을 평가하기전에 require문을 미리 선언하고 들어가는 것이라 이해하면 된다. 예를 들면, 이런 것도 가능하다.$ echo "9" | ruby -rmath -e "puts Math.sqrt(gets.to_i)"# => 3.0<위의 스크립트는 아래와 동일하다.$ echo "9" | ruby -e "require 'math'; puts Math.sqrt(gets.to_i)"# => 3.0<이런 원리를 이용하면, JSON/XML/CSV/YAML 등의 포맷으로 출력되는 데이터를 어렵지 않게 처리할 수 있다.다른 CLI 도구와 조합해서 사용해보기 <이 글에서는 여러분이 표준 입출력, 리다이렉션, 그리고 유닉스 기본 명령어(e.g. echo/tail/tead/more/grep 등)는 이미 숙지를 하고 있으리라 생각한다. 이에 대해서 다루자면, 전하고자 하는 의도에 비해 글이 엄청 길어질 수 있어서 의도적으로 생략했다. 혹시나 당장은 모르더라도 상관없다. 그렇게 어렵지 않으니 실습을 한번쯤은 해보는 것을 권장한다.<위에서 예시를 든 것 가지고는 어떻게 하면 나한테 유용한 도구를 만들 수 있는지 파악하기 어려울 수 있다. 그렇다면, 실제로 우리가 사용하고 있는 CLI 도구를 같이 결합해보는건 어떨까? 친숙한 사례를 예시로 들자면 aws-cli, git, gh, jq, curl 등의 커맨드라인 도구가 있을 수 있겠다. 각각은 단일 작업에 특화되어 있어 그 자체로도 훌륭하지만, Ruby 스크립트와 결합했을 때 더욱 강력한 도구로 탈바꿈할 수 있다. 아래에서는 몇 가지 활용 사례와 그로 인해서 어떻게 시너지 효과를 일으킬 수 있는지 살펴보자. 먼저, 간단한 예시를 살펴보자.JSON 데이터 처리하기 JSON 포맷은 어떻게 보면 굉장히 범용적으로 사용되는 포맷이다. API 요청 날릴 때 쓰이는 것은 물론이고, 설정 파일에 쓰이기도 하고, 다른 인터페이스 간 데이터를 교환할 때도 많이 쓰이기도 한다. Ruby에서는 JSON 라이브러리를 표준 라이브러리로 포함하고 있기 때문에, 이것을 굉장히 유용하게 활용할 수 있다.$ curl -s https://jsonplaceholder.typicode.com/posts/1 | ruby -rjson -e 'data = JSON.parse(STDIN.read); puts "Title: #{data["title"]}"'<동작하는 방식은 간단하다.curl로 요청을 날려서 JSON 응답을 반환받는다.JSON 데이터를 파싱하고, 그 중에서 title 필드를 추출한다출력한다.<외부 API에 요청을 날리고 거기서 받은 JSON 응답을 처리하고자 할 때 굉장히 편리하게 처리할 수 있다. 단순히 뽑아내기만 할 때는 jq를 사용하는 것도 방법이긴 하지만, Ruby 스크립트 안에서는 더욱 다양하게 활용할 수 있다. 또한, GitHub CLI/Flutter/AWS CLI 등등이 --format json 같은 옵션을 지원하는데, 한번 섞어서 사용해보는 것을 권장한다.YAML 데이터 처리하기 YAML 포맷은 일반적으로는 설정 파일에 널리 사용된다. Ruby는 기본적으로 yaml 라이브러리를 포함하고 있으므로 YAML 파일을 읽고, 필요한 정보만 출력하는 작업을 쉽게 수행할 수 있다. 예를 들어, config.yaml 파일에서 특정 설정 값을 추출하는 스크립트는 다음과 같다.$ cat config.yaml | ruby -ryaml -e 'config = YAML.load(STDIN.read); puts "Server port: #{config["server"]["port"]}"'<이것도 역시 동작방식은 간단하다.cat 명령어로 config.yaml 파일의 내용을 읽어오고,Ruby의 YAML.load를 사용해 파싱한 후,서버 설정에서 포트 번호를 출력한다.<이와 같이 YAML 파일을 손쉽게 읽어서 원하는 부분만 추출하거나, 구조화된 데이터를 다른 CLI 도구와 연계하여 활용할 수 있다.이도 역시 --format yaml 같은 옵션을 지원하는 kubectl 같은 CLI 도구와 함께 유용하게 사용될 수 있다.정형화되어 있지 않은 복잡한 텍스트 데이터를 처리하기 모든 데이터가 JSON/CSV/YAML 포맷처럼 정형화되어 있으리라는 보장이 없다. 많은 경우 로그 파일, 시스템 메시지, 사용자 입력 등은 형식이 일정하지 않은 경우가 많다. 이런 경우에도 Ruby의 강력한 정규표현식 기능이나 텍스트 처리 능력을 활용하면 데이터를 원하는 형태로 추출하거나 가공할 수 있다. 대부분의 경우에는 높은 확률로 한줄한줄 읽어서 처리하면 되는 경우가 많다. 이번엔, 간단하면서 친숙한 git log를 예시로 살펴보자. 이번에는 글의 주제(one-liner)에서 다소 벗어났지만, 이런 식의 활용도 가능하다는걸 밝히고 싶다. 다음에서 설명하는 스크립트는 내가 굉장히 애용하는 스크립트 중 하나이다. Git 로그 중에서 원하는 커밋을 선택하고, 해당 커밋의 변경사항을 보여준 후, 조회한 내역을 체크리스트 형태로 출력한다.git_logs = `git log --oneline #{file} | gum choose --limit 100`git_logs.each_line do |line| commit_hash, *_ = line.split system("git show #{commit_hash}") puts("=====") puts("Press ENTER key to CONTINUE") puts("=====") getsendchecklist = []git_logs.each_line do |line| checklist << "- [ ] #{line}"endputs checklist.join<이번엔 조금 복잡할 수 있다. 그래도 인내심을 가지고 보면 그렇게 어렵진 않다.<Git 로그 추출:git log --oneline #{file} 명령을 실행하여 한 줄에 하나의 커밋 정보를 출력한다.gum choose --limit 100을 사용해, 출력된 로그 중 조회하고 싶은 라인을 인터랙티브하게 선택할 수 있다.선택된 결과는 git_logs 변수에 저장된다.<각 커밋별 상세 조회:git_logs.each_line을 통해 선택된 로그를 한 줄씩 순회한다.각 줄은 <commit hash> <commit message> 형식을 갖고 있으므로, split 메서드를 사용해 첫 번째 토큰(커밋 해시)만 추출한다.추출한 커밋 해시를 이용해 git show #{commit_hash} 명령을 실행, 해당 커밋의 변경 내용을 출력한다.각 커밋 조회 후, 사용자에게 "계속 진행하려면 ENTER 키를 누르라"는 메시지를 띄워 한 단계씩 진행할 수 있도록 한다.<체크리스트 생성:다시 한 번 git_logs의 각 라인을 순회하며, 각 커밋 로그 앞에 체크리스트 형식(- [ ])을 붙여 리스트 항목을 만든다.모든 항목을 조합해 최종 체크리스트를 출력한다.<마치며 우리는 CLI 도구들과 Ruby 스크립트를 비롯한 다양한 스크립팅 언어를 활용해, 간단한 커맨드 조합만으로도 나만의 비밀무기를 만들 수 있는 방법들을 살펴보았다. 이러한 접근법을 통해 각 도구가 가진 단일 기능의 강점을 그대로 유지하면서, 이를 결합해 더욱 강력하고 유연한 자동화 워크플로우를 구성할 수 있음을 확인했다. 작은 한 줄의 스크립트가 복잡한 데이터 처리, 로그 분석, 버전 관리 작업을 손쉽게 해결해줄 뿐만 아니라, 실제 업무 현장에서 생산성을 극대화할 수 있는 발판이 된다. 여러분도 이번 기회를 계기로 다양한 CLI 도구와 스크립트를 조합하여, 나만의 맞춤형 자동화 도구를 만들어 보는 것은 어떨까? 이 글을 작성하기까지 적지 않은 영향을 주셨던 @ssiumha님께 감사를 표한다.<그 외에도, Perl도 익혀두면 도움이 될 수 있다. Perl은 Git(libgit)이 설치되어 있다면 원플러스원으로 같이 설치되기 때문이다. 요즘은 Perl One-Liners Guide 같은 훌륭한 교재도 있고, LLM도 perl로 one liner 스크립트를 짜달라고 물어보면 뚝딱뚝딱하고 잘 짜주는 편이다.
hackers.pub · Hackers' Pub
Link author: Jaeyeol Lee@kodingwarrior@hackers.pub
주말에 했던 〈국한문혼용체에서 Hollo까지〉의 발표에서 대강:
- 연합우주에서도 국한문혼용체로 글을 쓰는데 사람들이 읽기 쉽게 한글 독음을
<ruby>
태그로 달고 싶다! - Mastodon에 패치를 할 수는 있지만 업스트림에 받아들여질 리가 없으니 패치된 Mastodon 서버를 직접 운영할 수 밖에 없다.
- 혼자 쓰자고 Mastodon 서버를 운영하려니 비용이 크다. 가벼운 ActivityPub 서버 구현을 만들어야겠다.
- ActivityPub 서버 구현을 바닥부터 하자니 할 일이 너무 많다. ActivityPub 프레임워크를 만들어야겠다. → Fedify
- Fedify를 만들었으니 일인 사용자용 ActivityPub 서버를 구현하자. → Hollo
- Hollo를 만들었으니 Seonbi를 연동하자.
- Seonbi를 연동하여 한자어에 한글 독음이
<ruby>
로 달게 했으나 Mastodon과 Misskey에서<ruby>
태그를 지원 안 한다. - Mastodon 쪽에 이슈를 만들고 연합우주에서 홍보하여 결국 패치됨. Mastodon에서도
<ruby>
지원! - Misskey 쪽에 패치를 보내서 결국 Misskey에서도
<ruby>
지원! - 행복한 국한문혼용 생활.
이상과 같은 이야기를 했더니, “야크 셰이빙이 엄청나다”라는 의견을 들었다.
RE: https://hackers.pub/@hongminhee/019603e0-33ef-700f-90f4-153c8c995135
간혹 "이모지"가 아니라 "에모지"라고 쓰는 이유에 대한 질문을 받습니다. 여기다 써 두면 앞으로 링크만 던지면 되겠지?
요약: 에모지라서 에모지라고 씁니다.
"이모지"라는 표기는 아마도 "emoji"가 "emotion"이나 "emoticon"과 관련이 있다고 생각해서 나오는 것으로 보이는데요. "emoji"와 "emoticon"은 가짜동족어(false cognate)입니다. "emoji"는 일본어 絵文字(에모지)를 영어에서 그대로 받아들여 쓰고 있는 것입니다. 심지어 구성원리도 에모+지가 아니고 에+모지(絵+文字)입니다. "emotion"과 유사해 보이는 것은 순전히 우연일 뿐, 계통적으로 전혀 아무 상관이 없습니다. "이모티콘"과 "이미지"의 합성어가 아닙니다. (그랬으면 "-ji"가 아니라 "-ge"였겠죠.)
그리고 그렇기 때문에 에모지를 에모지로 표기할 실익이 생깁니다. :)
, ¯\_(ツ)_/¯
, ^_^
등은 이모티콘입니다. 반면 😂는 명확히 에모지입니다.
프로그래머에게 이건 정말 중요한 구분입니다. "이모티콘을 잘 표현하는 시스템"과 "에모지를 잘 표현하는 시스템"은 전혀 다른 과제이기 때문입니다. 에모지는 "그림 문자"라는 원래 뜻 그대로, 어떤 문자 집합(예를 들어 유니코드)에서 그림 문자가 "따로 있는" 것입니다. 내부 표현이야 어떻든, 적어도 최종 렌더링에서는 별도의 글리프가 할당되는 것이 에모지입니다. "무엇이 에모지이고 무엇이 에모지가 아닌가"는 상대적으로 명확합니다(문자 집합에 규정되어 있으니까).
반면 이모티콘은 "무엇이 이모티콘인가?"부터 불명확합니다. 우선 대부분의 이모티콘은 이모티콘이 아닌 문자를 조합하여 이모티콘이 만들어지는 형식입니다. 예를 들어 쌍점(:
)이나 닫는 괄호()
)는 그 자체로는 이모티콘이 아니지만 합쳐 놓으면 :)
이모티콘이 됩니다. 하지만 조합에 새로운 의미를 부여했다고 해서 다 이모티콘이라고 부르지도 않습니다. -_-
같은 것은 대다수가 이모티콘으로 인정하지만, ->
같은 것은 이모티콘이라고 부르지 않는 경향이 있습니다.
-
문자와 >
문자에는 화살표라는 의미가 없기 때문에, ->
조합과 화살표의 시각적 유사성에 기대어 화살표라는 새로운 의미로 "오용"한 것은 이모티콘의 구성 원리에 해당합니다. 하지만 화살표는 인간의 특정한 정서(emotion)에 대응하지 않으므로 이모티콘이라고는 잘 부르지 않습니다. 그렇다고 얼굴 표정을 나타내야만 이모티콘인가 하면 그렇지도 않습니다. orz
같은 것은 이모티콘으로 간주하는 경향이 있어 보입니다. 오징어를 나타내는 <:=
는 이모티콘인가? 이모티콘이 맞다면, 왜 ->
는 이모티콘이 아니고 <:=
는 이모티콘인가? 알 수 없습니다. ㅋㅋ
과 ㅠㅠ
는 둘 다 정서를 나타내는데, ㅠㅠ
만이 아이콘적 성질을 가지므로 이모티콘이고 ㅋ
는 이모티콘이 아닌가? 알 수 없습니다. 만약 ㅋ
만 이모티콘이 아니라고 한다면, ㅋ큐ㅠ
에서 큐
는 이모티콘인가 아닌가?? 알 수 없습니다. 이 알 수 없음은 이모티콘의 생래적 성질입니다. 어쩔 수 없죠.
패키지 저장소에 내가 만든 패키지를 업로드해보니까 다음과 같이 코딩말고도 할 게 꽤 많다.
- 저장소 계정 만들고 권한 승인 받기[1]
- 라이브러리 코드에 주석 적기
- 라이선스 정하기
- 소스 코드 저장소 정하기
- 커밋 메시지 적기
- 체인지로그 적기
- 테스트 코드 적기
- 버전 관리하기[^4]
LLM 덕분에 영어로 적어야 하는 문서 대부분은 어렵지 않게 할 수 있었다. LLM 때문에 바보 된다는 말도 많지만 영어 때문에 주저 했던 작업을 쉽게 시작할 수 있었다는 점에서 확실히 진입 장벽은 낮아졌다.
앞으로 더 해볼 일은 특정 배포판에 패키지를 배포하는 일이다. 해키지에서 지원하는 배포판은 다음과 같다.
- Arch
- Debian
- Fedora
- FreeBSD
- LTS
- LTSHaskell
- NixOS
- Stackage
- openSUSE
도전 과제로 위에 적은 모든 배포판에 내가 만든 패키지 배포해보는 것도 재밌겠다. LTS, LTSHaskell은 뭔가 했는데, 스태키지(Stackage)에 패키지 업로드하는 방법을 안내한 문서를 보니까 스태키지의 저장소 종류인 것 같다.
한편 해커즈 퍼브의 홍민희 님도 헤비(?) 하스켈 패키지 업로더이신데 예를 들어 seonbi도 사실 하스켈 패키지이다.
해키지 업로더 계정이 필요하신 분은 나와 홍민희 님을 멘션하면 이미 두 명의 승인은 따 놓은 당상이다.
해키지에서는 가입 후 기존 해키지 업로더 2명의 승인이 필요하다. ↩︎
Hackers' Pub에 리액션 기능 만들고 있는데, 선택 가능한 에모지 세트를 이 정도로 대충 정해봤습니다. 더하거나 뺄 게 있을까요? 그리고 5 종류인 게 많다고 보시나요 적다고 보시나요?
일단 이 정도로 가기로 했습니다.
출근길에 보았던 재호님 스레드 글이 너무 좋아서, 더 많은 개발자들이 봤으면 하는 마음에 내용을 일부 인용하며 Hackers' Pub 에도 공유합니다.
일을 하는 것 자체의 행복이 있거든요. 그니깐... 열심히 일을 하고 나가 놀아야 더 재밌다는 것.
글안에 링크된 GeekNews 의 내용도 좋아서 함께 인용합니다.
좋은 사이드 프로젝트가 주는 행복한 선(Zen, 禪) | GeekNews
모든 사람이 창작 본능을 어느 정도 가지고 있다고 믿음
반드시 예술적이거나 창의적인 것이 아니더라도 무언가를 '만드는 일'은 누구에게나 중요함
인생의 의미가 있다면, 그것은 ‘무언가 새로운 것을 존재하게 만드는 것’이라는 신념
창작을 통해 우리는 세상을 조금씩 바꾸고, 자신도 변화시킴
Jaeyeol Lee shared the below article:
mkDerivation 인자로 함수를 넘기는 이유

lionhairdino @lionhairdino@hackers.pub
NixOS.kr 디스코드에 올렸는데, 다른 분들의 의견을 들어보려고 해커스펍에도 올립니다. 닉스 경험이 많지 않은 사람의 글이니, 정확하지 않을 수 있습니다. 틀린 곳이 있으면 바로 알려주세요.
※ 닉스를 처음 접하는 분들이나, 닉스로 실용적인 업무를 하시는데 문제가 없는 분들한테는 적당한 글은 아닙니다. 서두에 읽으면 도움이 될만한 분들을 추려서 알려 드리려고 하니, 의외로 필요한 분들이 없겠습니다. 실무자들은 이렇게까지 파고들며 알 필요 없고, 닉스 개발자들이야 당연히 아는 내용일테고, 입문자 분들도 역시 이런 내용으로 어렵다는 인식을 갖고 시작할 필요는 없으니까요. 그럼 남은 건 하나네요. mkDerivation 동작을 이미 아는 분들의 킬링 타임용이 되겠습니다.
외국어를 익힐 때, 문법없이 실전과 부딪히며 배우는 방법이 더 좋기는 한데, 가끔은 문법을 따로 보기 전엔 넘기 힘든 것들이 있습니다. 닉스란 외국어를 익히는데도 실제 설정 파일을 많이 보는 것이 우선이지만, 가끔 "문법"을 짚고 넘어가면 도움이 되는 것들이 있습니다.
닉스 알약 (제목이 재밌네요. 알약) 글을 보면 mkDerivation
이 속성 집합을 받아, 거기에 stdenv 등 기본적인 것을 추가한 속성 집합을 만들어 derivaition
함수에 넘기는 간단한 래핑 함수임을 직관적으로 잘 설명하고 있습니다.
그런데, 실제 사용 예시들을 만나면, mkDerivation
에 속성 집합을 넘기지 않고, attr: {...} 형태의 함수를 넘기는 경우를 더 자주 만납니다. 그래서, 왜 그러는지 실제 구현 코드를 보고 이유를 찾아 봤습니다.
mkDerivation =
fnOrAttrs:
if builtins.isFunction fnOrAttrs then
makeDerivationExtensible fnOrAttrs
else
makeDerivationExtensibleConst fnOrAttrs;
mkDerivation
의 정의를 보면 인자로 함수를 받았느냐 아니냐에 따른 동작을 분기합니다. 단순히, stdenv에서 가져온 속성들을 추가한다면, 함수를 인자로 받지 않아도 속성 집합을 병합해주는 //
의 동작만 있어도 충분합니다.
{ a = 1; } // { b = stdenv.XXX; }
하지만, 함수로 받는 이유를 찾으면, 코드가 단순하지 않습니다. 아래는 함수를 받을 때 동작하는 실제 구현 일부를 가져 왔습니다.
makeDerivationExtensible =
rattrs:
let
args = rattrs (args // { inherit finalPackage overrideAttrs; });
...
전체를 보기 전에 일단 args
에서부터 머리가 좀 복잡해집니다. args
가 args
를 재귀 참조하고 있습니다. 보통 rattrs
매개 변수로는 아래와 같은 함수들이 들어 옵니다.
stdenv.mkDerivation (finalAttrs: {
pname = "timed";
version = "3.6.23";
...
tag = finalAttrs.version;
}
(와, 해커스펍은 코드 블록에 ANSI가 먹습니다! 지원하는 곳들이 드문데요.)
코드를 바로 분석하기 전에, 닉스의 재귀 동작을 먼저 보면 좋습니다.
재귀 생각 스트레칭
nix-repl> let r = {a = 1; b = a;}; in r error: undefined variable 'a'
위 동작은 오류지만, 아래처럼
rec
를 넣어주면 가능합니다.nix-repl> let r = rec {a = 1; b = a;}; in r { a = 1; b = 1; }
※
rec
동작은 Lazy 언어의fix
로 재귀를 구현하는 동작입니다. ※ 참고 Fix 함수
rec
를 써서 속성 안에 정의 중인 속성에 접근할 수 있습니다. 그런데, 아래 같이 속성을r.a
로 접근하면,rec
없이도 가능해집니다.nix-repl> let r = {a = 1; b = r.a;}; in r { a = 1; b = 1; }
닉스 언어의 Lazy한 특성 때문에 가능합니다.
이제, 원래 문제와 비슷한 모양으로 넘어가 보겠습니다. 아래같은 형태로 바로 자기 자신에 재귀적으로 접근하면 무한 재귀 에러가 나지만,
nix-repl> let x = x + 1; in x
error: infinite recursion encountered
아래처럼 람다 함수에 인자로 넘기면 얘기가 달라집니다.
nix-repl> let args = (attr: {c = 1; b = attr.a + attr.c + 1;}) (args // { a = 1; }); in args
{ b = 3; c = 1; }
여기서 속성b
의 정의 동작이 중요합니다. 위 내용을 nix-instantiate
로 평가하면,
nix-instantiate --eval -E 'let args = (attr: {c = 1; b = attr.a + attr.c + 1;}) (args // { a = 1; }); in args'
{ b = <CODE>; c = 1; }
--eval
옵션은 WHNF까지만 평가합니다. <CODE>
는 하스켈 문서에서 나오는 <thunk>
와 같은, 평가가 아직 이루어지지 않은 상태를 뜻합니다. ※ Nix Evaluation Performance
b
는 아직 평가가 되지 않았으니, 에러가 나지 않고, b
가 필요한 순간에는 attr.a
가 뭔지 알 수 있는 때가 됩니다.
attr:
{ c = 1;
b = attr.a + attr.c + 1;
}
속성 b
는 아직 알 수 없는, 미래의 attr에 있는 a를 받아 써먹고,
원래는 rec
없이 접근하지 못했던, c
에도 attr.c로 접근이 가능합니다. (attr.c
은 현재 정의하고 있는 속성셋의 c
가 아니라, 매개 변수 attr
로 들어온 속성셋의 c
입니다.)
원래 문제로 다시 설명하면, mkDerivation
에 넘기고 있는, 사용자 함수 finalAttrs: { ... }
에서,
닉스 시스템이 넣어주는 stdenv 값 같은 것들과 사용자 함수내의 속성들을 섞어서 속성 정의를 할 수 있다는 얘기입니다. 아래처럼 말입니다.
tag = finalAttrs.version;
뭐하러, 이런 복잡한 개념을 쓰는가 하면, 단순히 속성 추가가 아니라, 기존 속성이 앞으로 추가 될 속성을 기반으로 정의되어야 할 때는 이렇게 해야만 합니다. 함수형 언어에선 자주 보이는, 미래값을 가져다 쓰는 재귀 패턴인데, 저는 아직 그리 익숙하진 않습니다.
[Cloudflare] Meta’s Llama 4 is now available on Workers AI (2025-04-06)
The Llama 4 herd
Link: https://ai.meta.com/blog/llama-4-multimodal-intelligence/
Comments: https://lobste.rs/s/i4h5o3
오늘은 오픈소스 기여 연대기에 특별한 날로 기록될듯.
- 공식 디코에서 메인테이너의 Thanks to 6인에 에 리스트업
- 해당 오픈소스 주도하는 회사 개발자의 선제적 LinkedIn 친추요청
working on this drawing for the “secret rules of the terminal" zine
正體中文翻譯現已可用!
我們很高興地宣布,Hackers' Pub 現在支援正體中文(zh-TW
)!這意味著我們的介面將更加親近使用正體中文的軟體工程師和技術愛好者。
關於 Hackers' Pub
Hackers' Pub 是一個專為軟體工程師共同分享知識和經驗的平台。我們不僅是一個社區,還是一個啟用了 ActivityPub 的社交網路,讓您可以在聯邦宇宙(fediverse)中關注您喜愛的開發者,並在您的訂閱流中獲取他們的最新貼文。
我們的特色:
- 開放的技術交流:自由分享您的知識、經驗和見解
- 多語言支援:現在包括正體中文在內的多種語言
- 聯邦互連:通過 ActivityPub 協議與其他平台(如 Mastodon)互通
- 程式碼分享:支援 Markdown 和程式碼語法高亮
- 包容性社區:遵循我們的行為準則,確保所有人都受到尊重
如何切換到正體中文
要將介面切換到正體中文,請按照以下步驟操作:
- 登入您的 Hackers' Pub 帳戶
- 前往「Settings」頁面
- 選擇「Language settings」標籤
- 在左側「Languages to select:」列表中找到並點擊「Chinese (Taiwan) 中文(台灣)」
- 該選項會移至右側的「Selected languages:」列表
- 如果您希望將正體中文設為主要介面語言,可以使用箭頭按鈕將其移至已選擇語言列表的最上方
- 點擊頁面底部的「Save」按鈕保存設定
我們也提供了正體中文版的 Markdown 指南,幫助您以最佳方式格式化您的貼文和文章。
加入 Hackers' Pub
Hackers' Pub 目前採用邀請制。如果您希望加入我們的社區,可以通過直接發送私人訊息(DM)給我來請求邀請碼。我們非常歡迎正體中文使用者的加入!
幫助我們改進
這是我們首次推出正體中文介面,可能仍有需要改進的地方。如果您發現任何翻譯錯誤或有改進建議,請透過以下方式聯繫我們:
- 在 GitHub 儲存庫中提交問題或拉取請求
- 在我們的討論區分享您的反饋
感謝您成為 Hackers' Pub 社區的一員,讓我們一起建立一個更加包容、多元的技術交流平台!
附言:如果您對其他語言的翻譯感興趣,請查看我們的翻譯貢獻指南(英文)。
普段、日本語を読む時、漢字の意味だけを見て韓国の漢字音で読む事が多く、意味は分かっていても正確な読み方が分からない事が多いのだが、明日の発表を控え、私の拙い日本語力が借りを背負って帰ってきた。発表の原稿で、読み方がよく分からない単語に一々振り仮名を付ける中。😮💨
내가 AI 코드 편집기 사용을 중단한 이유
------------------------------
- 처음 AI 코드 도구를 사용할 때는 놀라움과 효율성에 감탄했음
- 특히 C++ 컴파일 에러 분석에 도움을 줘 마치 마법처럼 느껴졌음
- GitHub Copilot과 다양한 LLM 기반 에디터 통합 도구를 사용하면서 개발 워크플로우의 일환이 되었음
- 그러나 2024년 말에는 모든 LLM 통합 기능을 코드 에디터에서 제거했음 …
------------------------------
https://news.hada.io/topic?id=20145&utm_source=googlechat&utm_medium=bot&utm_campaign=1834
향후 10여년 간 AI가 일으킬 변화는 산업혁명을 능가할 것이다. 샘 올트먼은 OpenAI가 "진정한 의미의 초지능"과 "영광스러운 미래"를 목표로 한다고 말했다. 그 미래는 어떤 모습일까? 이에 답하기 위한 시나리오. https://ai-2027.com/
RAG 마스터 : 랭체인으로 완성하는 LLM 서비스 - 멀티모달·그래프 RAG·에이전트·파인튜닝까지 (브라이스 유, 조경아, 박수진, 김재웅 (지은이) / 프리렉 / 2025-04-28 / 32,000원) https://feed.kodingwarrior.dev/r/HBSao7
http://www.aladin.co.kr/shop/wproduct.aspx?ItemId=361845185&partner=openAPI&start=api
진짜 이건 명 짤이다
조던 엘렌버그라는 수학자가 쓴 '틀리지 않는 법'이란 책이 있는데, 재밌고 읽어볼만하다.
그 책에서 컴퓨터가 수학자가 하던일을 할수 있게되면 어떡하냐에 대해 저자의 해결책을 제시하는데 원래 하던일을 컴퓨터한테 맡기고 수학자들은 더 고차원적인 일을 하면 된다고 한다. 한 10년 전에 읽었을때도 그냥 대책없고 나이브한 생각으로 보였다. 근데 요즘은 (실제로 어떻게 될지랑은 상관없이) 저런 나이브한 마음가짐을 일부러라도 가지고 일해야 뭐라도 해낼듯.
AI MVP를 넘어서: 실제로 필요한 것
------------------------------
- AI 제품을 만드는 대부분의 회사는 실험 단계에 갇혀 있으며 신뢰할 만한 시스템과 도구가 부족함
- 우리의 사례
- 올해 초, LLM 모델을 gpt-4o-2024-08-06
에서 gpt-4o-2024-11-20
로 업데이트함
- 핵심 프롬프트 테스트 통과율이 기존 100%에서 79%로 하락함
- 정작 Anthropic의 Sonnet 3.5가 95%…
------------------------------
https://news.hada.io/topic?id=20119&utm_source=googlechat&utm_medium=bot&utm_campaign=1834
Hackers' Pub의 소스 코드 저장소를 제 개인 계정에서 hackers-pub 조직 계정으로 옮겼습니다.
Two fascinating new papers on LLM interpretability from Anthropic
https://simonwillison.net/2025/Mar/27/tracing-the-thoughts-of-a-large-language-model/
Claude code를 잘 써보려고 이렇게 저렇게 해보는 중.
코드는 잘 찍어내는데… 가끔씩 삑사리를 내서 끝도없는 삽질하느라 크레딧만 쳐묵쳐묵해서 쳐다보고 있다가 끊어줘야한다.
내가 없어도 이 정도 할 수 있으면(시간당 $5정도) 쓸만한데… 계속 쳐다보고 있을거면… 그냥 클로드 웹(월 $20)이나 깃헙 코파일럿(월 $10)보다 나을 게 없다.
사실 휴먼 개발자도 비슷하다. 해보고 안되면 “적절한” 시점에 도움을 청해야하는데… “적절한”게 어렵다. 제대로 해보지도 않고 도움을 청해도 안되고, 안되는 걸 끝까지 붙잡고 있어도 안된다.
이 녀석에게 “적절함”을 어떻게 가르쳐야하나…
この「ハッカーズ・パブ」(Hackers' Pub)は、ハッカーたちが集まるネット上の場所であって、各自ブログも出来て、レスも出来て、掲示板みたいにも使えて、ユーザーの望みであればFediverseなる世界中の 変人 みんなのネットワークとも繋がりうる、言わばハッカーたちのための新しいツイッターみたいなサイトらしい。
ツイッターより優れた部分は何かというと、技術的に何時間も喋れそうだが、私が注目するのは、まずここの創立者および主任開発者である洪 民憙 (Hong Minhee)先生はイーロンなどよりかはずっとましな方で、頼れる方だということ。ユーザーの自由に関する彼の哲学、このサイトの設計思想などは信用できる。多分。なにしろ彼は今やFLOSS(Free/Libre/Open-Source Software)の開発を専業としておられるのだ。
なお、例えひょんな事で洪さんがイーロン並みに暴走する、由々しき事態でも、ここはツイッターみたいにはならないということ。この「ハッカーズ・パブ」はソースコードに限らず、プロトコルや作動原理も全部FLOSSなので。まあ洪さんの暴走なんてないでしょうけどね。
エンジニアとして生きてきた分、こういうサービスを運営する側の負担を大体把握しているので、自分ではやらないと思うし、ここが盛り上がったところで (盛り上げたところで) 自分の人生に役立つかというと、そうも言えない。が、「みんながTwitterとかFacebookとかInstagramなどを使っている」今の状態と比べれば、ハッカーズ・パブがもっと使われる未来の方が好ましいことに違いはない。そう考えると、洪さんの努力に感謝せざるをえない。
で、パブに日本語圏のユーザーをもっと招くのが創立者の方針というかご希望らしく、衝動的に参加してみる。これから機会あれば、日本語でも面白い話をここに残すのを目指してみる。自分日本語全然下手ですが。よろしく。
오늘이 첫 번째 서울하스켈숲 워크샵이었을텐데 어땠을지 너무 궁금하다. 어디 후기 안 올라오려나⋯
RE: https://hackers.pub/@curry/0195d0ee-d8d2-7711-b550-b54cc1b5d599
#neovim Development News
The 0.12 version will have customizable diff mode for changes within a line via `inline:` part of 'diffopt' option.
Also a new `DiffTextAdd` highlight group will be used for added text within a changed line.
PR (Vim patch):
- github.com/neovim/neovi...
vim-patch:9.1.{1243,1246} by z...
@6aoi24aoi🏳🌈 さん、Hackers' Pubへようこそ!
@hongminhee洪 民憙 (Hong Minhee)
@kodingwarriorJaeyeol Lee 해시태그는 ActivityPub의 어떤 개념에 대응되나요? 또는 그냥 별개인건가요?
AI한테 코딩을 왜 시킵니까? 팀원들한테 JIRA 이슈 배분하면 되는데... ㅠㅠ
Show HN: Mermaid Chart VS Code Plugin: Mermaid.js Diagrams in Visual Studio Code
Link: https://docs.mermaidchart.com/blog/posts/mermaid-chart-vs-code-plugin-create-and-edit-mermaid-js-diagrams-in-visual-studio-code
Discussion: https://news.ycombinator.com/item?id=43558517
아이패드로 원격 개발만 하겠다고 결심 했는데 code-server는 웹브라우저의 IME 버그가 너무 빈발해서 고통스럽고, 원격지가 맥인데 vnc클라가 딱히 멀쩡한게 안보인다. 결국 ssh로 하자! 라고 결심하고 다시 이맥스를 집었는데... 예전에 어떻게 설정했는지 전혀 모르겠다. 둠 이맥스를 한번 설정 해봤는데 따로 설치한 패키지가 껐다 켜면 로드가 안되어서 어찌 해야 할 지 모르겠다. 근데 스페이스맥스도 둠 이맥스도 다들 빔을 섞는게 기본이네...
【拡散希望】
Hackers' Pub(ハッカーズ・パブ)は現在開発中の、ソフトウェアエンジニアと技術愛好家の為のActivityPub対応ソーシャルネットワークです。現在は韓国語中心のコミュニティが形成されていますが、日本のエンジニアの方々にも参加していただきたいと考えています。
Hackers' Pubは短文の投稿[1]と長文の記事[2]の両方をサポートしています。日常的な会話や簡単な質問は短文投稿で、詳細な技術解説やチュートリアルなどは長文記事で表現できます。QiitaやZennのような技術ブログ機能と、MastodonやMisskeyのようなタイムライン機能を兼ね備えた一つのプラットフォームで、両方の利点を享受できます。何よりもActivityPubプロトコルに対応している為、Mastodon、Misskey、Akkoma等と連携可能です。(このアカウントもHackers' Pubから投稿しています!)
技術的な特徴として、拡張Markdownによるテーブル、脚注、警告ボックス、ダイアグラム、数式などの多様な記法をサポートし、構文ハイライト、行ハイライト、差分表示などの強力なコードブロック機能も備えています。また、様々な言語での投稿が可能で、将来的には自動翻訳機能も予定しています。
Hackers' PubはAGPL-3.0ライセンスの下で開発されているオープンソースプロジェクトです。コードの貢献や機能提案も歓迎しています。
現在はまだ開発段階のため招待制となっています。Hackers' Pubに興味がある方は、DMや返信でメールアドレスをお知らせいただければ、招待状をお送りします。技術コミュニティの一員として、ぜひご参加をお待ちしております。よろしくお願いいたします。
F# 재밌어 보이네... 😇
F# 재밌어 보이네... 😇
@pkgupdtpkg update 멀리서 보면 희극, 가까이서 보면 비극입니다… (뭐, 저도 엄청 많이 써 본 건 아니지만요.)
Jaeyeol Lee shared the below article:
셸 언어는 때로 추하길 요구 받는다

洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
이 글에서는 명령줄 인터페이스(CLI)를 지배하는 셸 언어의 독특한 설계 철학을 탐구하며, 셸 언어가 왜 때로는 "추함"을 받아들여야 하는지에 대한 이유를 설명합니다. Bash와 PowerShell을 비교하며, PowerShell이 가독성을 높이기 위해 장황해진 반면, Bash는 간결함을 유지하여 빠른 상호작용에 더 적합함을 지적합니다. 현대적인 셸인 Nushell이 이 균형을 맞추기 위해 노력하는 점을 언급하며, 셸 언어의 성공은 "아름다운 코드"와 "효율적인 상호작용" 사이의 균형에 달려 있음을 강조합니다. 마지막으로, 모든 도구는 사용 맥락에 맞게 설계되어야 한다는 더 넓은 소프트웨어 설계 원칙을 제시하며, 셸 언어의 맥락은 키보드와 사용자 사이의 빠른 대화임을 강조합니다. 이 글은 셸 언어 설계에 대한 흥미로운 통찰력을 제공하며, 소프트웨어 설계 시 맥락의 중요성을 일깨워 줍니다.
Read more →