Juntai Park

@arkjun@hackers.pub · 47 following · 44 followers

中年(중년)中小企業(중소기업) 開發者(개발자), 90年代(년대) Console Gamer(콘솔 게이머). 좋은 하루를 繼續(계속)해 나아간다. 좋은 하루가 모이면 좋은 人生(인생)이 된다.

韓国人のプログラマー、40代、小学生の息子とゲームするのが幸せ😃💕龍が如く 、ゼルダの伝説、マリオ、ピクミン好き

「いい1日を続ける」
いい1日を続けていけば、いい人生になる!

threads
@rkjun
x
@rkJun
uri.life
@arkjun@uri.life
GitHub
@arkjun

技術者向けSNS「Hackers' Pub」の招待枠を持っています。ActivityPubに対応し多言語サポートもある、エンジニアや技術に興味がある方のためのコミュニティです。参加希望の方はDMやコメントでメールアドレスをお知らせください。招待状をお送りします。

#HackersPub #テック #プログラミング



RE: https://hackers.pub/@hongminhee/0195faee-783f-7d33-ad90-88c497655ab9

3
0
0

GeekNews의 〈소프트웨어 엔지니어로 산다는 건 미친 짓이야〉 주제에 @youknowone 님께서 쓰신 좋은 댓글:

소프트웨어 개발이 어려운 일이라는 사람들은 본인이 그 일을 하는 이유가 뭘까요? 고되고 힘든 일이지만 보람있는 일이라서 하시나요? 이 업계에서 그런 분들은 그리 많지는 않았던 것 같습니다. 남들이 못하는 것 같으니까 어렵다고 주장하는거지, 실상은 그게 본인한테 가장 쉬운 일이니까 하시는 것 아닌가요? 남들이 좀 띄워준다고 자화자찬하면서 나만 특별한 양 여기면서 눈을 가리지 말고 주위를 봐야합니다. 이공계에서 어떤 분야가 방구석에서 인터넷 좀 보고 독학한다고 (잘 하면) 몇달만에 현업에 투입할 수 있는 전문가가 됩니까?

(…중략…)

물론 남들이 가지지 못한 훌륭한 손재주를 가진 사람은 존중받아 마땅하지만, 약간의 손재주를 연마했다고 해서 소싯적 배워둔 손재주로 평생 먹고 살면 좋을텐데 왜 그럴수 없을까, 나는 이런 훌륭한 손재주를 가졌는데 다른 사람들처럼 힘들게 일하지 않아야 하는 것 아닐까, 나는 남들은 쉽게 하지 못하는 대단한 재능을 가진 것이 아닐까 등등의 특별한 나에 심취하는건 교만에 가까운 일이 아닐까 합니다.

8
0
0

PostgreSQL 풀 텍스트 검색: 제대로 하면 빠르다(느리다는 오해 해소)
------------------------------
- PostgreSQL의 기본 Full-Text Search(FTS)는 느리다는 인식이 있지만, *적절한 최적화만 하면 매우 빠르게 동작함*
- Neon의 블로그에서는 Rust 기반
pg_search 확장과 기본 FTS를 비교하여 후자가 느리다고 주장함
- 하지만 이 비교는 PostgreSQL FTS에 필수적인 *기본 최적화 작업들이 누락* 된 상태에서 이…
------------------------------
https://news.hada.io/topic?id=20247&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

0
6
13
0
0

Kube가 모든 회사에서 사용중인데... 왜쓰는거지...? 매번 일거리가 생기고 어떻게 업그레이드 할지에 대한 고민을 해야하는데... 좋은 도구인건 알겠으나... 그렇게까지 사용하지 않는 회사에서 왜 사용하고자 하는걸까...? MSA랑 Kube는 동의어인가...?

1
0
0
0

줄리 모로누키(Julie Moronuki) 님이 원래 언어학을 전공하셔서 그런지 글을 참 잘 쓰시는 것 같고 그 필력으로 하스켈 책을 세 권이나 써주셔서 너무 감사하다. 새로운 콘텐츠를 만들어 주시기를 고대하고 있는데 최근 어떻게 지내시는지 너무 궁금하다.

ChatGPT는 Moronuki가 일본식 성씨일 가능성을 제기했다.

그렇지 않아도 그의 블로그를 보니, 그가 일본에 방문해서 영어를 가르쳤던 경험이, 프로그래밍을 전혀 몰랐던 그로 하여금 하스켈을 대중에게 가르치는 사명을 일깨워준 계기가 된 것 같다.

만약 일본식 성씨가 맞다면 아마도 もろぬき라고 쓰는 것 같다.

0

주말에 했던 〈국한문혼용체에서 Hollo까지〉의 발표에서 대강:

  1. 연합우주에서도 국한문혼용체로 글을 쓰는데 사람들이 읽기 쉽게 한글 독음을 <ruby> 태그로 달고 싶다!
  2. Mastodon에 패치를 할 수는 있지만 업스트림에 받아들여질 리가 없으니 패치된 Mastodon 서버를 직접 운영할 수 밖에 없다.
  3. 혼자 쓰자고 Mastodon 서버를 운영하려니 비용이 크다. 가벼운 ActivityPub 서버 구현을 만들어야겠다.
  4. ActivityPub 서버 구현을 바닥부터 하자니 할 일이 너무 많다. ActivityPub 프레임워크를 만들어야겠다. → Fedify
  5. Fedify를 만들었으니 일인 사용자용 ActivityPub 서버를 구현하자. → Hollo
  6. Hollo를 만들었으니 Seonbi를 연동하자.
  7. Seonbi를 연동하여 한자어에 한글 독음이 <ruby>로 달게 했으나 Mastodon과 Misskey에서 <ruby> 태그를 지원 안 한다.
  8. Mastodon 쪽에 이슈를 만들고 연합우주에서 홍보하여 결국 패치됨. Mastodon에서도 <ruby> 지원!
  9. Misskey 쪽에 패치를 보내서 결국 Misskey에서도 <ruby> 지원!
  10. 행복한 국한문혼용 생활.

이상과 같은 이야기를 했더니, “야크 셰이빙이 엄청나다”라는 의견을 들었다.



RE: https://hackers.pub/@hongminhee/019603e0-33ef-700f-90f4-153c8c995135

0
0
0

Juntai Park shared the below article:

CLI 도구를 조합하여 나만의 요술봉 만들기 (feat. Ruby)

Jaeyeol Lee @kodingwarrior@hackers.pub

본론으로 들어가기에 앞서, 이 글에서는 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"]}"'

동작하는 방식은 간단하다.

  1. curl로 요청을 날려서 JSON 응답을 반환받는다.
  2. JSON 데이터를 파싱하고, 그 중에서 title 필드를 추출한다
  3. 출력한다.

외부 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"]}"'

이것도 역시 동작방식은 간단하다.

  1. cat 명령어로 config.yaml 파일의 내용을 읽어오고,
  2. Ruby의 YAML.load를 사용해 파싱한 후,
  3. 서버 설정에서 포트 번호를 출력한다.

이와 같이 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("=====")
  gets
end

checklist = []
git_logs.each_line do |line|
  checklist << "- [ ] #{line}"
end

puts checklist.join

이번엔 조금 복잡할 수 있다. 그래도 인내심을 가지고 보면 그렇게 어렵진 않다.

  1. Git 로그 추출:

    • git log --oneline #{file} 명령을 실행하여 한 줄에 하나의 커밋 정보를 출력한다.
    • gum choose --limit 100을 사용해, 출력된 로그 중 조회하고 싶은 라인을 인터랙티브하게 선택할 수 있다.
    • 선택된 결과는 git_logs 변수에 저장된다.
  2. 각 커밋별 상세 조회:

    • git_logs.each_line을 통해 선택된 로그를 한 줄씩 순회한다.
    • 각 줄은 <commit hash> <commit message> 형식을 갖고 있으므로, split 메서드를 사용해 첫 번째 토큰(커밋 해시)만 추출한다.
    • 추출한 커밋 해시를 이용해 git show #{commit_hash} 명령을 실행, 해당 커밋의 변경 내용을 출력한다.
    • 각 커밋 조회 후, 사용자에게 "계속 진행하려면 ENTER 키를 누르라"는 메시지를 띄워 한 단계씩 진행할 수 있도록 한다.
  3. 체크리스트 생성:

    • 다시 한 번 git_logs의 각 라인을 순회하며, 각 커밋 로그 앞에 체크리스트 형식(- [ ])을 붙여 리스트 항목을 만든다.
    • 모든 항목을 조합해 최종 체크리스트를 출력한다.

마치며

우리는 CLI 도구들과 Ruby 스크립트를 비롯한 다양한 스크립팅 언어를 활용해, 간단한 커맨드 조합만으로도 나만의 비밀무기를 만들 수 있는 방법들을 살펴보았다. 이러한 접근법을 통해 각 도구가 가진 단일 기능의 강점을 그대로 유지하면서, 이를 결합해 더욱 강력하고 유연한 자동화 워크플로우를 구성할 수 있음을 확인했다.

작은 한 줄의 스크립트가 복잡한 데이터 처리, 로그 분석, 버전 관리 작업을 손쉽게 해결해줄 뿐만 아니라, 실제 업무 현장에서 생산성을 극대화할 수 있는 발판이 된다. 여러분도 이번 기회를 계기로 다양한 CLI 도구와 스크립트를 조합하여, 나만의 맞춤형 자동화 도구를 만들어 보는 것은 어떨까?

이 글을 작성하기까지 적지 않은 영향을 주셨던 @ssiumha님께 감사를 표한다.


그 외에도, Perl도 익혀두면 도움이 될 수 있다. Perl은 Git(libgit)이 설치되어 있다면 원플러스원으로 같이 설치되기 때문이다. 요즘은 Perl One-Liners Guide 같은 훌륭한 교재도 있고, LLM도 perl로 one liner 스크립트를 짜달라고 물어보면 뚝딱뚝딱하고 잘 짜주는 편이다.

Read more →
1

회사에서 쓴 코드를 공개 저장소에 올릴 수는 없어서 hackage-server를 직접 돌려보기로 했다. 빌드할 때 의존성 맞추기가 어려울 것 같아서 속는 셈 치고 Nix를 써봤는데⋯ 한 번에 서버가 에러 없이 실행됐다. 이제 사내에서 하스켈 패키지 관리를 할 수 있다!(그런데 아무도 안 씀⋯)

0

간혹 "이모지"가 아니라 "에모지"라고 쓰는 이유에 대한 질문을 받습니다. 여기다 써 두면 앞으로 링크만 던지면 되겠지?

요약: 에모지라서 에모지라고 씁니다.

"이모지"라는 표기는 아마도 "emoji"가 "emotion"이나 "emoticon"과 관련이 있다고 생각해서 나오는 것으로 보이는데요. "emoji"와 "emoticon"은 가짜동족어(false cognate)입니다. "emoji"는 일본어 絵文字(에모지)를 영어에서 그대로 받아들여 쓰고 있는 것입니다. 심지어 구성원리도 에모+지가 아니고 에+모지(絵+文字)입니다. "emotion"과 유사해 보이는 것은 순전히 우연일 뿐, 계통적으로 전혀 아무 상관이 없습니다. "이모티콘"과 "이미지"의 합성어가 아닙니다. (그랬으면 "-ji"가 아니라 "-ge"였겠죠.)

그리고 그렇기 때문에 에모지를 에모지로 표기할 실익이 생깁니다. :), ¯\_(ツ)_/¯, ^_^ 등은 이모티콘입니다. 반면 😂는 명확히 에모지입니다.

프로그래머에게 이건 정말 중요한 구분입니다. "이모티콘을 잘 표현하는 시스템"과 "에모지를 잘 표현하는 시스템"은 전혀 다른 과제이기 때문입니다. 에모지는 "그림 문자"라는 원래 뜻 그대로, 어떤 문자 집합(예를 들어 유니코드)에서 그림 문자가 "따로 있는" 것입니다. 내부 표현이야 어떻든, 적어도 최종 렌더링에서는 별도의 글리프가 할당되는 것이 에모지입니다. "무엇이 에모지이고 무엇이 에모지가 아닌가"는 상대적으로 명확합니다(문자 집합에 규정되어 있으니까).

반면 이모티콘은 "무엇이 이모티콘인가?"부터 불명확합니다. 우선 대부분의 이모티콘은 이모티콘이 아닌 문자를 조합하여 이모티콘이 만들어지는 형식입니다. 예를 들어 쌍점(:)이나 닫는 괄호())는 그 자체로는 이모티콘이 아니지만 합쳐 놓으면 :) 이모티콘이 됩니다. 하지만 조합에 새로운 의미를 부여했다고 해서 다 이모티콘이라고 부르지도 않습니다. -_- 같은 것은 대다수가 이모티콘으로 인정하지만, -> 같은 것은 이모티콘이라고 부르지 않는 경향이 있습니다.

- 문자와 > 문자에는 화살표라는 의미가 없기 때문에, -> 조합과 화살표의 시각적 유사성에 기대어 화살표라는 새로운 의미로 "오용"한 것은 이모티콘의 구성 원리에 해당합니다. 하지만 화살표는 인간의 특정한 정서(emotion)에 대응하지 않으므로 이모티콘이라고는 잘 부르지 않습니다. 그렇다고 얼굴 표정을 나타내야만 이모티콘인가 하면 그렇지도 않습니다. orz 같은 것은 이모티콘으로 간주하는 경향이 있어 보입니다. 오징어를 나타내는 <:=는 이모티콘인가? 이모티콘이 맞다면, 왜 ->는 이모티콘이 아니고 <:=는 이모티콘인가? 알 수 없습니다. ㅋㅋㅠㅠ는 둘 다 정서를 나타내는데, ㅠㅠ만이 아이콘적 성질을 가지므로 이모티콘이고 는 이모티콘이 아닌가? 알 수 없습니다. 만약 만 이모티콘이 아니라고 한다면, ㅋ큐ㅠ 에서 는 이모티콘인가 아닌가?? 알 수 없습니다. 이 알 수 없음은 이모티콘의 생래적 성질입니다. 어쩔 수 없죠.

0
0
0
0

Why the Latest JavaScript Frameworks Are a Waste of Time

https://dev.to/holasoymalva/why-the-latest-javascript-frameworks-are-a-waste-of-time-52pc

The next time a new JS framework drops, I won’t be rushing to rewrite my projects. Instead, I’ll be focused on shipping products, writing solid code, and improving my problem-solving skills.
0

패키지 저장소에 내가 만든 패키지를 업로드해보니까 다음과 같이 코딩말고도 할 게 꽤 많다.

  • 저장소 계정 만들고 권한 승인 받기[1]
  • 라이브러리 코드에 주석 적기
  • 라이선스 정하기
  • 소스 코드 저장소 정하기
  • 커밋 메시지 적기
  • 체인지로그 적기
  • 테스트 코드 적기
  • 버전 관리하기[^4]

LLM 덕분에 영어로 적어야 하는 문서 대부분은 어렵지 않게 할 수 있었다. LLM 때문에 바보 된다는 말도 많지만 영어 때문에 주저 했던 작업을 쉽게 시작할 수 있었다는 점에서 확실히 진입 장벽은 낮아졌다.

앞으로 더 해볼 일은 특정 배포판에 패키지를 배포하는 일이다. 해키지에서 지원하는 배포판은 다음과 같다.

  • Arch
  • Debian
  • Fedora
  • FreeBSD
  • LTS
  • LTSHaskell
  • NixOS
  • Stackage
  • openSUSE

도전 과제로 위에 적은 모든 배포판에 내가 만든 패키지 배포해보는 것도 재밌겠다. LTS, LTSHaskell은 뭔가 했는데, 스태키지(Stackage)에 패키지 업로드하는 방법을 안내한 문서를 보니까 스태키지의 저장소 종류인 것 같다.

한편 해커즈 퍼브의 홍민희 님도 헤비(?) 하스켈 패키지 업로더이신데 예를 들어 seonbi도 사실 하스켈 패키지이다.

해키지 업로더 계정이 필요하신 분은 나와 홍민희 님을 멘션하면 이미 두 명의 승인은 따 놓은 당상이다.


  1. 해키지에서는 가입 후 기존 해키지 업로더 2명의 승인이 필요하다. ↩︎

0
0
0

연합우주 계정의 이전에 관한 규격인 FEP-7628를 구현하고 있습니다. 아직 Hackers' Pub 계정을 다른 계정으로 이전하거나, 다른 계정을 Hackers' Pub 계정으로 이전하는 기능은 구현되지 않았지만, 그 밑작업으로서 FEP-7628을 이미 구현한 Mastodon, Misskey, Pleroma 등의 계정끼리 서로 이전한 것을 반영하는 기능은 구현되었습니다. 예를 들어, 제 옛날 계정 중 하나인 @hongminhee洪 民憙 (Hong Minhee) 계정을 보면 첨부한 캡처 화면처럼 계정의 이전 안내가 표시되게 됩니다.

Hackers' Pub에서 더이상 사용되지 않는 계정의 프로필 화면. 새로운 계정으로 이전되었다는 메시지가 상단에 표시되고, 옛 계정의 프로필 사진은 흑백으로 보인다.
0
0
0

@hongminhee洪 民憙 (Hong Minhee) 아⋯ 이 커밋 보고 언어 설정과 관련이 있을 것 같아서 설정을 보다가 그 옵션을 보긴 했는데 ‘이게 원래 없었나?’라고 생각했습니다. 다른 서비스에서는 못본 기능 같은데 꽤 유용할 것 같습니다! 한편 요즘 타임라인에 일본어가 자주 올라오긴 했는데 안 보고 싶다는 생각보다는 번역해서 보고 싶다고 생각했어요. 팬피의 일본어 번역 품질은 별로더라고요.

0

https://newsletter.posthog.com/p/50-things-weve-learned-about-building

PostHog가 성공적인 제품을 만들면서 깨달은 50가지 교훈 (뉴스레터에서 지금까지 발행해놓은 것들 오마카세처럼 모아놓음)

그 중에서 마음에 드는 것들을 몇개 뽑아보자면...

  1. 신뢰는 투명성에서 온다. Build in Public 같은 것이 도움이 될 수 있음
  2. 시장에 내놓지 않으면 검증 조차 할 수 없음. 일단 시장에 내놓고 반응을 살펴볼 것
  3. 개밥먹기를 통해서 고객에게 전달되기 전에 문제점을 빠르게 인식하고 개선할 수 있는 흐름을 만들 것
0

보통은 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 등의 포맷으로 출력되는 데이터를 어렵지 않게 처리할 수 있습니다. one-liner 스크립트를 작성하는 방법에 대해 자세히 알아가고 싶다면, https://learnbyexample.github.io/learn_ruby_oneliners/one-liner-introduction.html 여기를 참고해주시면 좋을 것 같습니다.

이에 관해서, 25분-30분 정도 분량의 글을 정리해서 올릴 것 같은데 커밍쑨.....

0

CLI 도구를 조합해서 커맨드 작성할때, (일회성이라면 모르겠지만) 자주 사용하는 스크립트라면 짧은 옵션보다 긴 옵션을 사용하는 것이 좋습니다. 풀 네임으로 커맨드라인 명령어를 작성하는 것이 어떻게 보면 문서화의 역할도 하기 때문입니다. 다른 프로그램에서 시스템 콜을 호출해서 사용하는 유즈케이스라면 더더욱 가독성을 높이는 효과가 있습니다.

어떤 CLI 도구는 man 커맨드로 문서를 봤을때 양이 어마어마하고 어렵게 느껴질 수 있습니다. 하지만, 위에서 언급한 것처럼 full name으로 작성한 스니펫들을 모아놓으면 그렇게 어렵지도 않고 각 도구의 역할을 명확하게 이해할 수 있고, 결과적으로는 장기적인 기억으로 남을 수 있습니다. git, curl, aws-cli, jq, gh 어떤 CLI 도구이던간에 모든 옵션을 하나하나 기억하려고 할 필요도 없습니다. 필요하면 그때그때 full name으로 명시된 옵션으로 스크립트를 짜놓고 모아두면 됩니다.

https://matklad.github.io/2025/03/21/use-long-options-in-scripts.html

0
0

프론트엔드 개발자분들 위주로 페디버스로 영입을 많이 해보고 싶다. 포트폴리오로 개발할만한 것이 지천에 널려있는데...!!

  • 인스타그램 클론코딩 : PixelFed 클라이언트 개발에 적용하기
  • 트위터 클론코딩 : 마스토돈 클라이언트 개발할때 적용하기
  • 나만의 블로그 만들기 : 이건.... 해커스펍이 그 역할을 하겠지...?
0

@hongminhee洪 民憙 (Hong Minhee) 발표자료를 이제서야 봤네요. 지나온 오픈소스 여정을 잘 보았습니다. 모든 것이 결국 Hackers' Pub 으로까지 이어진 느낌이네요. 앞으로 또 어떤 길을 걸으실지도 기대되고, 응원도 하고 싶습니다.
자, 이제 Hackers' Pub 에 국한문혼용기능을 넣을 차례입니다(?) 😂

0

닉스(Nix)를 써보려고 Nix Pills라는 글을 읽기 시작했다. 화면에 Hello, world!를 출력하는 패키지 hello를 닉스로 설치하는 방법이 나오더라.

nix-env -i hello

저런 하찮은 프로그램이 패키지로 존재하는지 처음 알았다.

혹시 해키지에도 저런 게 있는지 검색을 해봤는데 있더라.[1] 2010년에 Simon Marlow가 업로드했다. 그런데 특이한 점이 이 패키지의 소스 코드 저장소 주소가 darcs.haskell.org라는 것이다. darcs를 호스팅하는 곳은 hub.darcs.net만 있는 줄 알았는데 haskell.org에도 있었구나⋯ 그런데 이 사이트 UI도 아예 없고 그냥 디렉터리 리스팅이 나오는데 hub.darcs.net으로 이전하시면 안 되려나.


  1. https://hackage.haskell.org/package/hello-1.0.0.2 ↩︎

0
0

正體中文翻譯現已可用!

我們很高興地宣布,Hackers' Pub 現在支援正體中文(zh-TW)!這意味著我們的介面將更加親近使用正體中文的軟體工程師和技術愛好者。

關於 Hackers' Pub

Hackers' Pub 是一個專為軟體工程師共同分享知識和經驗的平台。我們不僅是一個社區,還是一個啟用了 ActivityPub 的社交網路,讓您可以在聯邦宇宙(fediverse)中關注您喜愛的開發者,並在您的訂閱流中獲取他們的最新貼文。

我們的特色:

  • 開放的技術交流:自由分享您的知識、經驗和見解
  • 多語言支援:現在包括正體中文在內的多種語言
  • 聯邦互連:通過 ActivityPub 協議與其他平台(如 Mastodon)互通
  • 程式碼分享:支援 Markdown 和程式碼語法高亮
  • 包容性社區:遵循我們的行為準則,確保所有人都受到尊重

如何切換到正體中文

要將介面切換到正體中文,請按照以下步驟操作:

  1. 登入您的 Hackers' Pub 帳戶
  2. 前往「Settings」頁面
  3. 選擇「Language settings」標籤
  4. 在左側「Languages to select:」列表中找到並點擊「Chinese (Taiwan) 中文(台灣)」
  5. 該選項會移至右側的「Selected languages:」列表
  6. 如果您希望將正體中文設為主要介面語言,可以使用箭頭按鈕將其移至已選擇語言列表的最上方
  7. 點擊頁面底部的「Save」按鈕保存設定

我們也提供了正體中文版的 Markdown 指南,幫助您以最佳方式格式化您的貼文和文章。

加入 Hackers' Pub

Hackers' Pub 目前採用邀請制。如果您希望加入我們的社區,可以通過直接發送私人訊息(DM)給我來請求邀請碼。我們非常歡迎正體中文使用者的加入!

幫助我們改進

這是我們首次推出正體中文介面,可能仍有需要改進的地方。如果您發現任何翻譯錯誤或有改進建議,請透過以下方式聯繫我們:

感謝您成為 Hackers' Pub 社區的一員,讓我們一起建立一個更加包容、多元的技術交流平台!


附言:如果您對其他語言的翻譯感興趣,請查看我們的翻譯貢獻指南(英文)。

0
0
0
1

주로 hackers.pub에 서식하고 있고, 개발 얘기는 주로 여기(@kodingwarrior@hackers.pubJaeyeol Lee)에서 하게 될 것 같습니다. 연친소를 쓰고 있는 이 계정은 사담용!

한국 연합우주 개발자 모임(fedidev.kr)
한국어권 Vim 사용자 모임(vim.kr)

각각의 커뮤니티에서 취미로 모더레이터를 하고 있습니다.

(굳이 언급하자면) 개발하는 분야는 백엔드 프론트엔드 가리지 않아왔지만, 현재는 프론트엔드에 집중하고 있음!

---

개발자가 아닌 나라는 사람에 대해서 소개하자면,

애니메이션 좋아하고!
넷플릭스에서 영화/드라마 보는거 좋아하고!
어쩌다보니 마작도 하게 되어서 맛들렸고!
듀오링고도 쫌좀따리도 돌리는!

평범한 사람입니다. 혼자 코인노래방가서 노래부르는 것도 좋아하는데, 저랑 노래방 같이 가는 분이 계신다면 저의 퍼포먼스를 가장한 재롱잔치를 보는 진귀한 광경을 체험하실 수 있읍니다

0
0
0

내가 AI 코드 편집기 사용을 중단한 이유
------------------------------
- 처음 AI 코드 도구를 사용할 때는 놀라움과 효율성에 감탄했음
- 특히 C++ 컴파일 에러 분석에 도움을 줘 마치 마법처럼 느껴졌음
- GitHub Copilot과 다양한 LLM 기반 에디터 통합 도구를 사용하면서 개발 워크플로우의 일환이 되었음
- 그러나 2024년 말에는 모든 LLM 통합 기능을 코드 에디터에서 제거했음 …
------------------------------
https://news.hada.io/topic?id=20145&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

0

@hongminhee洪 民憙 (Hong Minhee) Twitterはイーロンされててもうだめだ、ActivityPub対応のアカウントが欲しい → この「ハッカーズ・パブ」がよさそうだな → 会員登録がない → 管理者に申し込み → 管理者にメッセージを送るには、ActivityPub対応のアカウントが必要

😂

0
0
0
0
0
0

この「ハッカーズ・パブ」(Hackers' Pub)は、ハッカーたちが集まるネット上の場所であって、各自ブログも出来て、レスも出来て、掲示板みたいにも使えて、ユーザーの望みであればFediverseなる世界中の 変人 みんなのネットワークとも繋がりうる、言わばハッカーたちのための新しいツイッターみたいなサイトらしい。

ツイッターより優れた部分は何かというと、技術的に何時間も喋れそうだが、私が注目するのは、まずここの創立者および主任開発者である洪 民憙 (Hong Minhee)先生はイーロンなどよりかはずっとましな方で、頼れる方だということ。ユーザーの自由に関する彼の哲学、このサイトの設計思想などは信用できる。多分。なにしろ彼は今やFLOSS(Free/Libre/Open-Source Software)の開発を専業としておられるのだ。

なお、例えひょんな事で洪さんがイーロン並みに暴走する、由々しき事態でも、ここはツイッターみたいにはならないということ。この「ハッカーズ・パブ」はソースコードに限らず、プロトコルや作動原理も全部FLOSSなので。まあ洪さんの暴走なんてないでしょうけどね。

エンジニアとして生きてきた分、こういうサービスを運営する側の負担を大体把握しているので、自分ではやらないと思うし、ここが盛り上がったところで (盛り上げたところで) 自分の人生に役立つかというと、そうも言えない。が、「みんながTwitterとかFacebookとかInstagramなどを使っている」今の状態と比べれば、ハッカーズ・パブがもっと使われる未来の方が好ましいことに違いはない。そう考えると、洪さんの努力に感謝せざるをえない。

で、パブに日本語圏のユーザーをもっと招くのが創立者の方針というかご希望らしく、衝動的に参加してみる。これから機会あれば、日本語でも面白い話をここに残すのを目指してみる。自分日本語全然下手ですが。よろしく。

0
0
0

Hackers' Pubは現在、韓国語中心のコミュニティが形成されていますが、日本語のコミュニティも拡大することを希望しています。Hackers' Pubは、まるでQiitaやZennの様なソフトウェア開発者の為のブログプラットフォームであると同時に、MisskeyやMastodonの様なマイクロブログプラットフォームでもあり、何よりもActivityPubをサポートしているので、Mastodonや Misskey等とも交流が出来ます。(このアカウントもHackers' Pubのアカウントです!)

Hackers' Pubに興味の有る方は、私にDMでメールアドレスをお知らせいただければ、招待状を送らせていただきます。 是非、ご参加をお待ちしております。宜しくお願いします。

0