bgl gwyng

@bgl@hackers.pub · 63 following · 64 followers

슈티를 함께 만들 팀을 만들고 있습니다. 관심 있으신 분, 또는 잘 모르겠지만 이야기를 나눠보고 싶은 분도 bgl@gwyng.com으로 편하게 연락주세요.

GitHub
@bglgwyng
shootee
www.shootee.io

Hello @MastodonEngineering,

I wanted to share some feedback on the documentation provided in the Highlighting Journalism on Mastodon blog post.

Specifically, in The technical section, the example code for the fediverse:creator meta tag is given as:

<meta name="fediverse:creator" content="@Gargron@mastodon.social" />

Based on my testing (and that of others), Mastodon doesn't seem to recognize the creator link correctly when the leading @ is present in the content attribute. It only works when the @ is removed, like this:

<meta name="fediverse:creator" content="Gargron@mastodon.social" />

Following the blog's example directly led to some wasted time figuring out why it wasn't working. It would be great if either the example in the blog post could be corrected to reflect the current requirement, or if Mastodon's parser could be made more flexible to accept the handle with or without the leading @.

Appreciate all you do for !

0
0

Polymarket 등의 예측 시장에는 오라클 문제가 있다. 블록체인으로 만들어봤자, 어차피 베팅의 승패를 결정하려면 외부에서 딸깍 해줘야한다. 가령 4월 내에 탄핵이 이뤄질거냐 마냐 같은 게임을 상상하면 된다. 그 딸각하는 사람을 어떻게 믿을수 있냐는 문제가 오라클 문제다.

오라클 문제가 없는 예측 시장이 하나 생각났는데, 바로 수학 문제가 언제 풀릴 것이냐에 대한 것이다. 가령 리만 가설이 앞으로 1,000,000 블록 내에 풀릴지, 또는 P=NP랑 둘 중에 뭐가 먼저 풀릴지 등에 대한 것이다. 여기서 풀리는건 Lean 등으로 작성된 Formal Proof을 통해서 온체인으로 판단한다.

수학자들은 자신이 베팅을 걸어놓고 연구를 열심히해서 돈을 벌 수도 있다. 또 직접 연구를 하지 않더라도 GPU를 사서 자신의 베팅에 유리하도록 연구에 도움을 줄 수 있다. 앞서 그냥 유명하단 이유로 너무 거창한 문제를 예시로 들었는데, 그보다는 더 작고 쉬운 많은 문제들에 대해 이런 식의 경제가 돌아가는걸 상상해보자. 연구에 들어가는 자원 배분이 최적화되지 않을까?

@bglbgl gwyng 개인적으로는 오라클이 필수적인 애플리케이션은 처음부터 블록체인으로 만들면 안 된다고 생각합니다. 😂 관련된 주제로 〈탈중앙 게임, 그리고 블록체인과 NFT〉라는 글을 예전에 쓴 바 있습니다.

0

@bglbgl gwyng 개인적으로는 오라클이 필수적인 애플리케이션은 처음부터 블록체인으로 만들면 안 된다고 생각합니다. 😂 관련된 주제로 〈탈중앙 게임, 그리고 블록체인과 NFT〉라는 글을 예전에 쓴 바 있습니다.

0
0
0

Polymarket 등의 예측 시장에는 오라클 문제가 있다. 블록체인으로 만들어봤자, 어차피 베팅의 승패를 결정하려면 외부에서 딸깍 해줘야한다. 가령 4월 내에 탄핵이 이뤄질거냐 마냐 같은 게임을 상상하면 된다. 그 딸각하는 사람을 어떻게 믿을수 있냐는 문제가 오라클 문제다.

오라클 문제가 없는 예측 시장이 하나 생각났는데, 바로 수학 문제가 언제 풀릴 것이냐에 대한 것이다. 가령 리만 가설이 앞으로 1,000,000 블록 내에 풀릴지, 또는 P=NP랑 둘 중에 뭐가 먼저 풀릴지 등에 대한 것이다. 여기서 풀리는건 Lean 등으로 작성된 Formal Proof을 통해서 온체인으로 판단한다.

수학자들은 자신이 베팅을 걸어놓고 연구를 열심히해서 돈을 벌 수도 있다. 또 직접 연구를 하지 않더라도 GPU를 사서 자신의 베팅에 유리하도록 연구에 도움을 줄 수 있다. 앞서 그냥 유명하단 이유로 너무 거창한 문제를 예시로 들었는데, 그보다는 더 작고 쉬운 많은 문제들에 대해 이런 식의 경제가 돌아가는걸 상상해보자. 연구에 들어가는 자원 배분이 최적화되지 않을까?

0
0
0

별 것 아니지만, Markdown 문법 가이드를 추가했습니다. Markdown을 모르는 분들은 거의 없겠지만, Hackers' Pub은 Markdown 확장 문법을 꽤 많이 지원하기 때문에, 이를 문서화할 필요가 있었습니다.

단문 작성 화면에서 “이미지 업로드” 버튼 왼쪽의 “Markdown 사용 가능” 링크를 누르시면 언제든지 Markdown 문법 가이드를 보실 수 있습니다.

0
0

React Native에선 설계를 보고 라이브러리를 고를 수가 없다. 뭔가 돌아가긴하는게 있다면 그걸 써야한다. react-navigation의 디자인을 도저히 이해못하겠는데 다른 선택지가 없는게 예시다.

0

엘리먼트의 클래스 목록에서 순서는 의미가 없고 집합처럼만 작동하기 때문에 (선언 순서가 영향을 주는건 css rule만 해당) d1과 똑같이 적용될 것 같아요.

0
0
0

드디어 단문 입력란에 “이미지 업로드” 버튼이 생겼습니다. 기존에도 이미지 업로드는 가능했지만 드래그 앤 드롭을 하거나 클립보드에서 붙여넣기를 해야 했기 때문에, 특히 모바일 같은 환경에서는 불편함이 있었습니다. 이제는 버튼을 누르면 이미지 파일을 선택하는 창이 뜨게 됩니다.

참고로 이 기능은 100% Claude Code로 구현되었습니다. 커밋까지도요. 제가 한 일은 다음 프롬프트를 적은 것 뿐입니다:

현재는 Composer 컴포넌트에 이미지 업로드 기능이 있긴 하지만 1) 드래그 앤 드롭을 하거나 2) 클립보드에서 붙여넣기를 해야 합니다. 그래서 이미지 업로드 기능이 있다는 걸 인지조차 못하는 경우도 있습니다. 이를 개선하기 위해, 명시적인 이미지 업로드 버튼을 추가하려고 합니다. 기존의 이미지 업로드 기능을 망가뜨리지 않으면서 동작하는 이미지 업로드 버튼을 구현해 주실 수 있을까요? 참고로 UI 프레임워크는 Preact를 쓰고 있습니다. 코드 내 주석은 영어로 작성해 주세요.

구체적인 변경 사항이 궁금하신 분은 dfa9091ed32536fe8e8c22d57b56b3dd191290ec 커밋을 확인해 보세요.

Hackers' Pub의 새로운 단문 작성란. “미리보기” 버튼 왼쪽에 “이미지 업로드” 버튼이 보인다.
0
0
0
2

bgl gwyng shared the below article:

연합우주(fediverse)와 ActivityPub 프로토콜 이해하기: 개발자를 위한 가이드

洪 民憙 (Hong Minhee) @hongminhee@hackers.pub

연합우주란 무엇일까?

X(구 Twitter)나 Instagram 같은 중앙화된 소셜 미디어에 지치셨나요? 데이터 프라이버시, 알고리즘 추천, 그리고 끊임없는 광고가 걱정되시나요? 여기 대안이 있습니다. 바로 연합우주(fediverse)입니다.

페디버스(fediverse)는 “federated”(연합된)와 “universe”(우주)를 합친 말로, 한국어권에서는 주로 “연합우주”라고 불립니다. 연합우주는 하나의 거대한 플랫폼이 아닌, 서로 대화할 수 있는 독립적인 서버(인스턴스)들의 네트워크입니다.

이게 어떻게 가능할까요? 바로 ActivityPub이라는 프로토콜 덕분입니다. 이 프로토콜은 서로 다른 소셜 미디어 플랫폼이 정보를 교환할 수 있게 해주는 공통 언어 같은 것입니다.

연합우주는 어떻게 작동하나요?

연합우주를 이해하는 가장 쉬운 방법은 이메일 시스템과 비교하는 것입니다.

Gmail 사용자가 네이버 메일 사용자에게 이메일을 보낼 수 있는 것처럼, Mastodon 사용자는 Misskey나 PeerTube 사용자와 소통할 수 있습니다. (Mastodon, Misskey, PeerTube가 무엇인지는 아래에서 설명하겠습니다. Gmail과 네이버처럼 서로 다른 서비스라고 보시면 됩니다.) 이것이 가능한 이유는 이 서비스들이 모두 같은 언어인 ActivityPub 프로토콜로 대화하기 때문입니다.

연합우주에서 사용자 ID는 @사용자명@인스턴스.도메인 형식으로 되어 있습니다. 이메일 주소와 매우 비슷하죠? 예를 들면:

  • @honggildong@mastodon.social: mastodon.social 인스턴스 사용자
  • @kimcheolsu@pixelfed.social: pixelfed.social 인스턴스 사용자
  • @leeyeonghui@misskey.io: misskey.io 인스턴스 사용자

연합우주의 다양한 플랫폼 둘러보기

연합우주는 마치 여러 행성으로 이루어진 태양계 같습니다. 각 행성(플랫폼)은 고유한 특성을 가지고 있지만, 모두 같은 우주(연합우주)에 속해 있죠. 아래 표에서 주요 플랫폼들을 살펴봅시다:

플랫폼 설명 주요 인스턴스 특징
Mastodon X(구 Twitter)와 유사한 마이크로블로깅 플랫폼 • mastodon.social (공식 인스턴스)
• 우리.인생 (한국 중심)
500자 제한의 짧은 게시물, 해시태그, 컨텐츠 경고 기능
Misskey 일본에서 개발된 고도로 커스터마이징 가능한 마이크로블로깅 플랫폼 • misskey.io (가장 인기 있는 일본 인스턴스)
• 스텔라 (한국 중심)
리액션, 게임, 채팅 등 다양한 기능, 높은 커스터마이징 가능성
Pixelfed Instagram과 유사한 이미지 공유 플랫폼 • pixelfed.social (공식 인스턴스)
• 추억:사진 (한국 중심)
스토리, 필터, 발견 기능
PeerTube YouTube와 유사한 비디오 호스팅 플랫폼 • PeerTube.TV P2P 기술로 비디오 스트리밍, 채널, 재생목록
WriteFreely 미니멀한 블로그 플랫폼 • write.as Markdown 지원, 심플한 디자인
Lemmy Reddit과 유사한 링크 애그리게이터 및 토론 플랫폼 • lemmy.ml
• YuruLemmy (한국 중심)
커뮤니티(서브레딧과 유사), 투표, 토론

플랫폼 vs 인스턴스: 무슨 차이가 있을까?

연합우주를 이해할 때 흔히 혼동되는 개념이 있습니다. 바로 플랫폼(소프트웨어)과 인스턴스(서버)의 차이인데요.

플랫폼은 Mastodon, Misskey, Pixelfed와 같은 소프트웨어 자체를 의미합니다. 이들은 오픈 소스 소프트웨어로, 누구나 다운로드받아 설치할 수 있습니다.

인스턴스는 그 소프트웨어를 실행하는 개별 서버를 말합니다. mastodon.social과 우리.인생은 모두 Mastodon 플랫폼을 실행하는 별도의 인스턴스입니다.

Meta의 Threads 같은 일부 서비스는 플랫폼과 인스턴스가 동일합니다. 하지만 대부분의 연합우주 서비스는 여러 인스턴스로 구성되어 있습니다.

연합우주의 매력 포인트

연합우주가 갖는 몇 가지 매력적인 특징이 있습니다:

  1. 탈중앙화: 특정 기업이 모든 데이터와 규칙을 통제하지 않습니다. 각 인스턴스는 자체 규칙을 가질 수 있습니다.
  2. 데이터 주권: 자신의 데이터에 대한 더 많은 통제권을 가질 수 있습니다.
  3. 검열 저항성: 한 인스턴스가 차단되더라도 다른 인스턴스로 쉽게 이동할 수 있습니다.
  4. 커뮤니티 중심: 각 인스턴스는 특정 관심사나 지역 커뮤니티를 중심으로 형성됩니다.
  5. 다양성: 다양한 플랫폼과 인스턴스가 존재하여 선택의 폭이 넓습니다.

연합우주 시작하기

연합우주에 참여하는 것은 생각보다 쉽습니다:

  1. 자신의 관심사나 지역과 관련된 인스턴스를 선택합니다.
  2. 해당 인스턴스에 계정을 만듭니다.
  3. 다른 인스턴스의 사용자들을 팔로우하고 소통을 시작합니다!

한국 사용자라면 Mastodon 인스턴스인 우리.인생, Misskey 인스턴스인 스텔라 같은 한국어 중심 인스턴스를 추천합니다. 한국어 환경을 지원하고 한국 사용자들이 활발하게 활동하고 있어 시작하기 좋습니다.

아니면 이 글이 올라온 Hackers' Pub도 괜찮습니다. 소프트웨어 엔지니어들을 위한 소셜 미디어랍니다. 아직 개발중이라 공개적으로 가입을 받고 있지는 않습니다만, 홍민희에게 연락 주시면 계정을 생성해 드릴 수 있습니다.

ActivityPub: 연합우주의 심장

이제 개발자 관점에서 ActivityPub이 어떻게 작동하는지 자세히 살펴보겠습니다.

ActivityPub은 W3C에서 권장하는 표준 프로토콜로, 분산 소셜 네트워킹의 기반이 됩니다. ActivityStreams 2.0 데이터 형식을 기반으로 하며, 서로 다른 서버 간에 정보를 교환하는 방법을 정의합니다.

ActivityPub의 핵심 개념

ActivityPub은 몇 가지 핵심 개념으로 구성됩니다:

  1. 액터(actor): 사용자, 그룹 등 행동을 수행할 수 있는 주체입니다. 각 액터는 고유한 URL을 가지며, 수신함(inbox)과 발신함(outbox)을 가집니다.
  2. 액티비티(activity): 액터가 수행하는 행동으로, 게시물 작성, 댓글 좋아요, 다른 사용자 팔로우 등이 있습니다.
  3. 객체(object): 텍스트 게시물, 이미지, 비디오와 같이 생성되고 공유되는 콘텐츠입니다.

실제 작동 방식

홍길동(@honggildong@mastodon.social)이 게시물을 작성하고, 이영희(@leeyeonghui@misskey.io)가 이에 반응하는 과정을 살펴봅시다:

  1. 게시물 작성: 홍길동이 Mastodon에서 게시물을 작성합니다. Mastodon 서버는 이 게시물을 ActivityStreams 2.0 형식의 Create(Note) 액티비티로 변환합니다. 이 액티비티는 홍길동의 팔로워(이영희 포함)에게 전달됩니다.

  2. 게시물 수신: 이영희의 Misskey 서버는 이 액티비티를 받고 처리하여 이영희의 타임라인에 홍길동의 게시물을 표시합니다.

  3. 상호작용: 이영희가 게시물에 좋아요를 누르면, Misskey 서버는 Like(Note) 액티비티를 생성하여 홍길동의 Mastodon 서버로 보냅니다. 홍길동은 이영희가 자신의 게시물을 좋아했다는 알림을 받게 됩니다.

마치 다른 언어를 사용하는 사람들이 통역사를 통해 대화하는 것과 비슷하죠? ActivityPub이 바로 그 통역사 역할을 합니다.

ActivityPub의 실제 메시지 들여다보기

개발자로서 실제 ActivityPub 메시지가 어떻게 생겼는지 궁금하실 텐데요. 몇 가지 예시를 살펴봅시다:

1. 사용자 프로필(액터) 정보

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    "https://w3id.org/security/v1"
  ],
  "id": "https://mastodon.social/users/honggildong",
  "type": "Person",
  "preferredUsername": "honggildong",
  "name": "홍길동",
  "summary": "연합우주의 개척자",
  "inbox": "https://mastodon.social/users/honggildong/inbox",
  "outbox": "https://mastodon.social/users/honggildong/outbox",
  "followers": "https://mastodon.social/users/honggildong/followers",
  "following": "https://mastodon.social/users/honggildong/following",
  "publicKey": {
    "id": "https://mastodon.social/users/honggildong#main-key",
    "owner": "https://mastodon.social/users/honggildong",
    "publicKeyPem": "-----BEGIN PUBLIC KEY-----\n...\n-----END PUBLIC KEY-----"
  },
  "icon": {
    "type": "Image",
    "mediaType": "image/jpeg",
    "url": "https://mastodon.social/system/accounts/avatars/000/000/001/original/avatar.jpg"
  }
}

이 JSON 데이터는 홍길동의 프로필 정보를 담고 있습니다. 사용자 이름, 소개, 프로필 사진 URL, 그리고 중요한 inboxoutbox URL이 포함되어 있죠.

2. 게시물 작성 액티비티

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "id": "https://mastodon.social/users/honggildong/statuses/123456/activity",
  "type": "Create",
  "actor": "https://mastodon.social/users/honggildong",
  "published": "2025-02-21T14:30:00Z",
  "to": [
    "https://www.w3.org/ns/activitystreams#Public"
  ],
  "cc": [
    "https://mastodon.social/users/honggildong/followers"
  ],
  "object": {
    "id": "https://mastodon.social/users/honggildong/statuses/123456",
    "type": "Note",
    "content": "<p>연합우주에 오신 것을 환영합니다! #fediverse #연합우주</p>",
    "published": "2025-02-21T14:30:00Z",
    "attributedTo": "https://mastodon.social/users/honggildong",
    "to": [
      "https://www.w3.org/ns/activitystreams#Public"
    ],
    "cc": [
      "https://mastodon.social/users/honggildong/followers"
    ],
    "tag": [
      {
        "type": "Hashtag",
        "href": "https://mastodon.social/tags/fediverse",
        "name": "#fediverse"
      },
      {
        "type": "Hashtag",
        "href": "https://mastodon.social/tags/연합우주",
        "name": "#연합우주"
      }
    ]
  }
}

이것은 홍길동이 게시물을 작성했을 때 생성되는 Create(Note) 액티비티입니다. 게시물 내용, 해시태그, 공개 범위 등이 포함되어 있습니다.

3. 팔로우 액티비티

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "id": "https://misskey.io/users/leeyeonghui/follow/1234",
  "type": "Follow",
  "actor": "https://misskey.io/users/leeyeonghui",
  "object": "https://mastodon.social/users/honggildong"
}

이영희가 홍길동을 팔로우할 때 생성되는 Follow 액티비티입니다. 단순하죠?

ActivityPub 서버 구현하기: 개발자를 위한 팁

직접 ActivityPub 서버를 구현하고 싶다면 다음 단계를 따라야 합니다:

  1. 액터 구현: 사용자 프로필 정보를 ActivityStreams 형식으로 제공합니다.
  2. 수신함과 발신함 설정: HTTP 엔드포인트를 만들어 액티비티를 받고 전송합니다.
  3. 서명 및 인증: HTTP Signatures를 사용하여 요청을 서명하고 검증합니다.
  4. 액티비티 처리: 다양한 액티비티 유형(Create, Follow, Like 등)을 처리하는 로직을 구현합니다.
  5. 데이터 저장: 사용자, 게시물, 액티비티 등의 정보를 데이터베이스에 저장합니다.
  6. 연합 정책 구현: 어떤 인스턴스와 연합할지, 어떤 컨텐츠를 허용할지 등을 설정합니다.

개발을 시작하기 전에 Mastodon, Misskey 같은 기존 구현체의 코드를 살펴보는 것이 도움이 됩니다. 처음부터 모든 것을 구현하는 것보다 Fedify 같은 프레임워크를 활용하는 것도 좋은 방법입니다.

WebFinger: 사용자를 찾는 방법

연합우주에서 @leeyeonghui@misskey.io 같은 사용자 ID를 어떻게 실제 ActivityPub 액터 URL로 변환할까요? 그 비밀은 WebFinger 프로토콜에 있습니다:

GET https://misskey.io/.well-known/webfinger?resource=acct:leeyeonghui@misskey.io

이 요청을 보내면 서버는 다음과 같은 응답을 반환합니다:

{
  "subject": "acct:leeyeonghui@misskey.io",
  "links": [
    {
      "rel": "self",
      "type": "application/activity+json",
      "href": "https://misskey.io/users/leeyeonghui"
    }
  ]
}

이제 https://misskey.io/users/leeyeonghui URL을 통해 사용자의 전체 프로필 정보를 얻을 수 있습니다. 마치 전화번호부에서 이름으로 전화번호를 찾는 것과 비슷하죠!

연합우주의 도전 과제와 미래

연합우주는 계속 성장하고 있지만, 몇 가지 도전 과제도 있습니다:

  1. 확장성: 수많은 서버 간의 통신을 효율적으로 처리하는 것은 쉽지 않습니다.
  2. 모더레이션: 각 인스턴스가 자체 규칙을 가지므로 콘텐츠 조정에 일관성이 부족할 수 있습니다.
  3. 발견성: 중앙화된 플랫폼에 비해 새로운 사용자나 콘텐츠를 찾기 어려울 수 있습니다.
  4. 사용자 경험: 일부 플랫폼은 아직 UI/UX 측면에서 개선이 필요합니다.

그러나 Threads와 같은 주요 서비스들이 ActivityPub을 채택하기 시작하면서, 연합우주의 미래는 밝아 보입니다. 개발자로서, 이런 성장하는 생태계에 참여할 수 있는 기회가 많이 있습니다.

마무리

연합우주와 ActivityPub은 중앙화된 소셜 미디어의 대안으로서 점점 더 주목받고 있습니다. 사용자에게 더 많은 통제권을 부여하고, 다양하고 풍부한 온라인 경험을 제공하는 연합우주의 세계는 계속해서 확장되고 있습니다.

개발자로서, 여러분은 이 새로운 탈중앙화된 웹의 생태계에 기여할 수 있습니다. 기존 애플리케이션에 ActivityPub 지원을 추가하거나, 완전히 새로운 서비스를 만들거나, 현재의 도전 과제를 해결하는 솔루션을 개발할 수 있습니다.

한국 개발자들의 참여가 늘어나면 한국 사용자들을 위한 더 다양하고 풍부한 서비스가 생길 것이고, 이는 더 건강하고 다양한 인터넷 문화를 만드는 데 기여할 것입니다.

그럼, 연합우주로의 여행을 시작해 보시는 건 어떨까요?

Read more →
1

@hongminhee洪 民憙 (Hong Minhee) 꼭 외래어만 그런 건 아니지만 ㅐ와 ㅔ의 혼선이 제법 있는데, 이를테면 lag 랙("렉"으로 틀림) 같은 사례가 있습니다. 그 밖에는 daemon 다이먼(동계어인 demon에 이끌려 "데몬"이 널리 쓰이지만, 애초에 demon의 올바른 표기는 "디먼"임) 같은 게 생각나네요. 뭐 알아도 그렇게 안 쓰는 사람이 너무 많아서 대부분 틀린 표기로 쓰게 되지만...

0

bgl gwyng shared the below article:

페디버스에서 어떤 사람들을 팔로하면 좋을까?

Jaeyeol Lee @kodingwarrior@hackers.pub

Hackers' Pub을 포함하여 페디버스에 입문한 여러분 중 누군가는 막막한 생각이 들 수도 있습니다. 특히 지인의 Pool이 없는 상황이거나 혹은 Fediverse라는 개념 자체가 낯설 수록이요.

먼저 인스턴스라는 개념도 낯설게 느껴지거니와, 어떤 사람을 팔로할 지도 아예 생태계에 쌩으로 입문하는 입장에서는 시작을 하는 것 자체가 난해합니다.

Hackers' Pub을 포함한 ActivityPub 프로토콜을 사용하는 서비스들의 장점은 Bluesky, Mastodon, Misskey 어디에든 걸쳐있는 사람들과 하나로 연결되는 경험을 누릴 수 있다고 언급한 적은 있었습니다만, 이러한 장점을 어떻게 누릴 수 있는지도 알기는 어려울 겁니다.

보통은 트위터나 혹은 다른 알고리즘 기반의 추천을 해주는 여러 서비스들은 좋아하는지 취향에 맞는지와는 상관없이 일단 추천하긴 하지만, 페디버스는 국내 생태계 한정으로는 추천을 하기가 쉽지 않은 것 또한 사실이긴 합니다. 하지만, 해외개발자 Pool은 굉장히 넓은 것이 자명합니다. 물론, 이것도 역시 추천을 하기가 쉽지 않습니다. 여러분이 혹시 단골로 찾아보는 개발자 블로그가 있다면 Mastodon 계정이 보이는 경우를 최소 두 자릿수는 준하게 보실 수 있을 것이긴 합니다.

아무튼, 페디버스 생태계에도 소프트웨어 종사자인 여러분이 읽을만한 피드는 준비되어 있습니다. 팔로해볼 수 있는 여러 계정들을 예시로 들어서 소개해볼까 합니다.

개발자들이 모여있는 인스턴스

어떤 마스토돈 인스턴스를 이용할 수 있는지는 **여기**에도 잘 설명되어 있습니다. 개인적으로 추천하는 마스토돈 인스턴스는 아래와 같습니다.

국내

  • silicon.moe -- 이공계열에 종사하는 사람들을 위한 한국어권 마스토돈 인스턴스입니다.
  • Hackers' Pub -- 개발자를 위한 블로깅 서비스입니다. ActivityPub 프로토콜을 지원하여서 ActivityPub 프로토콜을 지원하는 페디버스에서 구독이 가능합니다.

해외

  • hachyderm.io -- IT 업계 종사자를 위한 마스토돈 인스턴스입니다. 대부분의 유명한 개발자들이 여기에 몰려있다고 봐도 됩니다.
  • emacs.ch -- Emacs 에디터를 사용하는 사람들을 위한 마스토돈 인스턴스입니다.
  • functional.cafe -- 함수형 개발자를 위한 마스토돈 인스턴스입니다.
  • genserver.social -- Erlang/Elixir 개발자를 위한 Akkoma 인스턴스입니다.
  • ruby.social -- Ruby 개발자를 위한 마스토돈 인스턴스입니다.
  • mtd.pythonasia.org -- 아시아권의 Python 개발자를 위한 마스토돈 인스턴스입니다.
  • fosstodon.org -- 오픈소스 개발자를 위한 마스토돈 인스턴스입니다. Python Software Foundation, Libre Office 등 오픈소스 프로젝트의 공식계정들이 많이 있습니다.
  • hci.social -- HCI 연구자들을 위한 마스토돈 인스턴스입니다. Princeton HCI에서 운영하고 있습니다.
  • vt.social -- 개발 분야 버츄얼 유튜버를 위한 마스토돈 인스턴스입니다. Asahi Lina, Luna가 공동 운영하고 있습니다.

Who to follow

Twitter/Threads에서는 자체적인 추천 알고리즘을 통해 어떤 계정을 팔로하면 괜찮을지 제안을 하기도 합니다. 하지만, 마스토돈은 그런 기능 쪽으로는 미비하다시피합니다.

개발 관련 정보를 구독하고 싶은 분들의 입장에서는 굉장히 치명적일 수도 있습니다. 아래에서는 어떤 개발자에게든 팔로할 것을 권장하는 계정들을 소개합니다.

개발 관련 뉴스

  • Geeknews Bot -- GeekNews의 피드를 실시간으로 받아볼 수 있습니다.
  • Hackernews
    • Hacker News 500 -- Hacker News 에서 500 포인트 받은 글들을 볼 수 있습니다.
    • Hacker News 100 -- Hacker News 에서 100 포인트 받은 글들을 볼 수 있습니다.
    • Hacker News 50 -- Hacker News 에서 50 포인트 받은 글들을 볼 수 있습니다.
  • Lobsters -- Lobsters는 Hacker News 보다는 좀 더 소프트웨어 개발/컴퓨터 사이언스에 초점이 맞춰진 글들이 올라옵니다.
    • Twitter 공식 계정도 있었지만, 트위터의 Bot 관련 정책 변경으로 인해 2023년 5월 3일부로 운영이 중단되었습니다.
  • discu.eu Weekly newsletter - 각종 분야별로 newsletter를 받아볼 수 있습니다.
    • Python weekly, Haskell weekly 등등의 마스토돈 공식 계정이 있습니다.

오픈소스 컨트리뷰터

  • Hong minhee -- Hackers' Pub, Hollo, Fedify 등 v페디버스 생태계에서 다양하고 재밌는 것들을 개발하고 계시는 분입니다.
  • Eugen Rochko -- Mastodon 코어 컨트리뷰터입니다.
  • Rob Pike -- Golang을 개발하신 그 분 맞습니다.
  • Asahi Lina -- Asahi Linux에 기여하는 모습을 생중계하는 버츄얼 유튜버입니다.
  • b0rks -- 개발자를 위한 N컷 만화를 연재하는 분입니다. Make Hard Things Easy라는 강연도 유명하니 한번씩은 보시는걸 권장합니다.

그 외에는...?

그 외에도, 관심이 가는 분야가 있으시다면 해당 분야 쪽 사람들이 모여있는 인스턴스를 눈여겨보시는 것을 권장합니다. 팔로우할 계정을 추천해주는 서비스를 찾으신다면 이것도 고려해보세요! (추천해주신 @rghw님 감사합니다.)

그 외에도 팔로할만한 계정이나 눈여겨볼만한 인스턴스가 있다면 댓글로 알려주세요! 여러분들의 댓글이 처음 입문하는 분들에게 도움이 될 수 있습니다!

Read more →
1
0
1

Hackers' Pub 타임라인에 내부적인 개선이 있었습니다. 이제까지는 타임라인을 렌더링하기 위해 실시간으로 복잡한 조건의 SQL을 실행하는 방식이었지만, 이제는 글이 작성될 때 구독자의 수신함(inbox)에 글이 들어가는 방식으로 바뀌었습니다. 타임라인을 렌더링할 때는 각자의 수신함만 확인하면 되기 때문에 훨씬 조건이 간단해진 것입니다.

더불어, 같은 글을 여러 사람이 공유했을 때 타임라인이 같은 글로 도배되던 문제를 해결했습니다. 이제는 마지막에 공유한 사람의 글만 딱 하나 보이게 됩니다.

이번 변경에 관해 궁금하신 분은 f692909cdd5149c68ca5a91fb4e964042115ab83 커밋을 확인하시면 되겠습니다.

이 변경을 배포하다가 데이터베이스 스키마 마이그레이션이 PostgreSQL을 멈추게 하여 Hackers' Pub이 몇 분 동안 내려가는 일이 있었습니다. 마이그레이션 SQL이 너무 비효율적이라 그랬던 것인데요, Claude Code의 도움을 받아 하나의 비효율적인 SQL을 몇 개의 SQL로 나눠서 실행하게끔 고쳐서 해결했습니다. 이 역시 궁금하신 분은 33f2209f206bee84ddf5d1a7124527dade948610 커밋을 확인하시면 됩니다.

앞으로는 더 안정적인 서비스 운영을 위해 노력하겠습니다. 죄송하고 감사합니다.

0

bgl gwyng shared the below article:

Vim이랑 Neovim은 어떻게 다를까?

Jaeyeol Lee @kodingwarrior@hackers.pub

주변에서 하도 계속 물어봐서 Vim과 Neovim의 결정적인 차이점을 문서로 남긴다. 당장은 생각나는대로 나열했기 때문에, 추후에 내용이 더 추가될 순 있다.

사용하는 언어부터 다르다 (VimScript / Lua)

Vim을 커스터마이징할때는 VimScript를 쓰지만, Neovim을 커스터마이징할때는 lua를 사용한다.

개인적으론 VimScript를 선호하진 않는데, vimscript 기반으로 짜여져 있는 플러그인의 소스코드를 읽는 것 자체가 고통스러웠던 경험이기도 했고, vimscript라는 언어 자체가 그닥 가독성이 좋은 편은 아니라고 생각한다. 기능적으로는 모자람이 없을 순 있으나, 읽을때도 고통스러운데 이걸로 스크립트를 짜라면 어지간하면 피할 것 같다.

반면. lua는 vimscript에 비하면 가독성이 적당히 나쁜 편은 아니다. 언어 자체의 기능으로 보자면 Python/Ruby/Javascript 등의 언어와 비교했을때 굉장히 좀 난해하게 느껴질 수는 있다.[1] 다만, lua는 macOS에서 사용하는 자동화 툴인 hammerspoon이라던가, 터미널 에뮬레이터인 wezterm이라던가 Unix 계열의 CLI 프로그램의 configuration을 작성하는데 있어서 사실상 De facto의 역할을 하고 있다. 언어 자체가 마음에 들지 않는 부분은 어느 정도 있긴 하지만, 가독성이나 개발편의성이 엄청 나쁜 것은 아니기 때문에 거부할 이유는 딱히 없다고 생각하고 쓰고 있다.

luarocks 패키지와 호환이 된다

Neovim을 커스터마이징할때 활용하는 lua는 luarocks라는 패키지매니저가 있기 때문에, 필요하다면 얼마든지 가져다 쓸 수 있다.

luarocks를 이용하는 Neovim 플러그인은 그렇게 많지는 않지만, (실질적인 쓸모의 유무를 떠나서) luarocks를 활용한 플러그인도 종종 보이긴 한다. 확실한건, lua 기반으로 개발되어 온 ecosystem을 등에 업고 언제든지 활용할 수 있다.

플러그인 생태계도 제법 괜찮은 편이다.

telescope / nvim-cmp / treesitter 같은 키워드 위주로만 찾아봐도 이걸 응용한 괜찮은 기능의 플러그인들을 많이 살펴볼 수 있다.

telescope

Neovim에서 사용할 수 있는 검색엔진이라고 생각해봐도 될 것 같다. 자세한 내용은 :help telescope 만 봐도 알 수 있겠지만, 파일 검색/패턴 검색 뿐만이 아니라 query를 넣을 수 있는 것이라면 어떤 것이든 다 해낼 수 있는 요술봉이라 생각한다.

예를 들면, git log를 검색한다던가, 현재 열어놓은 파일의 git history를 열람한다던가, 각각의 브랜치에 대한 git history를 표시하는 등의 git과 관련된 유용한 기능은 이미 네이티브로 들어가 있다.

여기서 좀 더 응용한다면, 아래의 예시와 같이 이용할 수 있다.

  • 프로젝트를 구성하는 소스코드의 클래스/모듈/함수/상수 검색
  • formatter/linter 오류 검색 (diagnostics)
  • GitHub 리포지토리의 issue/PR 검색 -- pwntester/octo.nvim 참고
  • throttling만 잘한다면 웹 요청이랑도 연결할 수 있다. 개인적으론 알라딘 검색 API와 연동하는 실험을 하고 있다.

nvim-cmp

이름에서 알 수 있듯이, 말 그대로 자동완성 기능을 위해 만들어진 플러그인 ecosystem이다. Neovim에서 자동완성 기능을 커스터마이징 해야 한다면, 바로 이 친구를 이용한다면 아주 간단한 문제가 된다.

pwd 기준의 경로 자동 완성 / emoji / 버퍼 내에서 반복적으로 사용되는 단어 위주의 자동완성 같은 사소한 것부터 Code Snippet / git commit sha1 해쉬 / GitHub author 자동 완성 / Language Server와 연동된 auto import 까지 입맛대로 자동완성 기능을 커스터마이징할 수 있다. 위에서 설명했던 telescope와 마찬가지로 쿼리할 수 있는 것이라면 어떻게든 활용할 수 있기 때문에 가능성은 무궁무진하다.

treesitter

사실 이게 왜 좋냐고 하냐면 많은 사람들에게 설득하는게 약간 어려운 난제이기도 하다. "굳이?" 라는 생각이 들 수도 있기 때문이다.

treesitter 자체는 파서를 만들어주는 제네레이터일 뿐이지만, 트리시터 기반으로 만들어진 파서가 활용도가 높기 때문에 유용함을 알고 있는 사람들은 잘 쓰고 있는 것 같다.

예를 들면, 커스텀 룰을 지정해주면 내가 탐험하고자 하는 소스코드의 범위를 탐색하는 것이 간단해진다. 왜냐면, scheme으로 커스텀 룰을 추가하는 것 자체가 일종의 트리 자료구조를 탐색하는 쿼리이기 때문이다.

알고리즘에 대한 배경지식이 있는 사람들한테는 좀 더 단순하게 설명하기도 하는데, "treesitter는 2차원 배열로 바라봐야 하는 소스코드를 트리로 바꿔서 생각할 수 있게 해준다." 이런 표현을 즐겨쓰는 편이다.

이에 대해 좀 더 직관적으로 와닿을 수 있는 예시는 ziontee113/syntax-tree-surfer인데, 함수가 정의되어 있는 위치를 바꾸는 demo 영상을 살펴보자. Syntax tree로 나타내면 두 함수의 위치는 Tree의 관점에서 보면 sibling으로 볼 수 있다. 두 함수가 정의되어 있는 위치를 바꾸는것은 사실상 트리 노드의 위치를 바꾸는 아주 간단한 문제로 환원이 된다.

그 외에도 두드러지는 점들

language server 지원도 나름 나쁘지는 않은 편인데, 제대로 세팅하려면 각각 language server마다 걸맞는 configuration을 해줘야 하는 수고로움이 생길 순 있지만, coc-nvim 세팅해놔도 개인적으론 크게 문제가 없었다.

Helix라는 신흥강자도 생기고 있는 모양이지만, 2023년 11월 기준, 2025년 3월으로는 크게 확 와닿을 정도로 삶에 혁신을 가져다 줄 만한 변화가 없기 때문에 당문간 관심을 가지는 건 보류


  1. lua라는 언어의 불편함에 대해서는 따로 글로 작성하게 될 것 같다. 그렇다고 아예 못 쓰겠다라고 느낄 수준은 아니지만, 여러가지 면에서 인지 부조화를 느끼게 하는 부분이 있다는 것은 부정할 여지가 없다. ↩︎

Read more →
0
0
1

I received a heartwarming about today!

@bglbgl gwyng shared in the FediDev KR Discord server:

I had trouble finding good resources explaining ActivityPub, but after reading through the Fedify docs from start to finish, I feel like I've actually digested it.

They also posted on their Hackers' Pub:

If you want to learn ActivityPub efficiently, just read the Fedify docs from beginning to end.

This makes all the documentation work worthwhile. Glad our docs are helping people understand not just Fedify, but itself.

0
0
0
0
0
0
0
0
0
0
1
0
0
0

네이버에서 이런 걸 왜 만들었을까?

Tamgu는 Prolog에서 영감을 받은 술어 엔진과 Haskell 언어에서 영감을 받은 기능적 기능을 갖춘 명령형 언어입니다. 이 세 가지 프로그래밍 스타일을 자유롭게 혼합할 수 있습니다.

https://github.com/naver/tamgu/tree/master

0

We're excited to announce the release of Fedify 1.5.0! This version brings several significant improvements to performance, configurability, and developer experience. Let's dive into what's new:

Two-Stage Fan-out Architecture for Efficient Activity Delivery

now implements a smart fan-out mechanism for delivering activities to large audiences. This change is particularly valuable for accounts with many followers. When sending activities to many recipients, Fedify now creates a single consolidated message containing the activity payload and recipient list, which a background worker then processes to re-enqueue individual delivery tasks.

This architectural improvement delivers several benefits: Context.sendActivity() returns almost instantly even with thousands of recipients, memory consumption is dramatically reduced by avoiding payload duplication, UI responsiveness improves since web requests complete quickly, and the system maintains reliability with independent retry logic for each delivery.

For specific requirements, we've added a new fanout option with three settings:

// Configuring fan-out behavior
await ctx.sendActivity(
  { identifier: "alice" },
  recipients,
  activity,
  { fanout: "auto" }  // Default: automatic based on recipient count
  // Other options: "skip" (never use fan-out) or "force" (always use fan-out)
);

Canonical Origin Support for Multi-Domain Setups

You can now explicitly configure a canonical origin for your server, which is especially useful for multi-domain setups. This feature allows you to set different domains for WebFinger handles and URIs, configured through the new origin option in createFederation(). This enhancement prevents unexpected URL construction when requests bypass proxies and improves security by ensuring consistent domain usage.

const federation = createFederation({
  // Use example.com for handles but ap.example.com for ActivityPub URIs
  origin: {
    handleHost: "example.com",
    webOrigin: "https://ap.example.com",
  },
  // Other options...
});

Optional Followers Collection Synchronization

Followers collection synchronization (FEP-8fcf) is now opt-in rather than automatic. This feature must now be explicitly enabled through the syncCollection option, giving developers more control over when to include followers collection digests. This change improves network efficiency by reducing unnecessary synchronization traffic.

await ctx.sendActivity(
  { identifier: sender },
  "followers",
  activity,
  { 
    preferSharedInbox: true,
    syncCollection: true,  // Explicitly enable collection synchronization
  }
);

Enhanced Key Format Compatibility

Key format support has been expanded for better interoperability. Fedify now accepts PEM-PKCS format in addition to PEM-SPKI for RSA public keys. We've added importPkcs1() and importPem() functions for additional flexibility, which improves compatibility with a wider range of ActivityPub implementations.

Improved Key Selection Logic

The key selection process is now more intelligent. The fetchKey() function can now select the public key of an actor if keyId has no fragment and the actor has only one public key. This enhancement simplifies key handling in common scenarios and provides better compatibility with implementations that don't specify fragment identifiers.

New Authorization Options

Authorization handling has been enhanced with new options for the RequestContext.getSignedKey() and getSignedKeyOwner() methods. This provides more flexible control over authentication and authorization flows. We've deprecated older parameter-based approaches in favor of the more flexible method-based approach.

Efficient Bulk Message Queueing

Message queue performance is improved with bulk operations. We've added an optional enqueueMany() method to the MessageQueue interface, enabling efficient queueing of multiple messages in a single operation. This reduces overhead when processing batches of activities. All our message queue implementations have been updated to support this new operation:

If you're using any of these packages, make sure to update them alongside Fedify to take advantage of the more efficient bulk message queueing.

CLI Improvements

The Fedify command-line tools have been enhanced with an improved web interface for the fedify inbox command. We've added the Fedify logo with the cute dinosaur at the top of the page and made it easier to copy the fediverse handle of the ephemeral actor. We've also fixed issues with the web interface when installed via deno install from JSR.

Additional Improvements and Bug Fixes

  • Updated dependencies, including @js-temporal/polyfill to 0.5.0 for Node.js and Bun
  • Fixed bundler errors with uri-template-router on Rollup
  • Improved error handling and logging for document loader when KV store operations fail
  • Added more log messages using the LogTape library
  • Internalized the multibase package for better maintenance and compatibility

For the complete list of changes, please refer to the changelog.

To update to Fedify 1.5.0, run:

# For Deno
deno add jsr:@fedify/fedify@1.5.0

# For npm
npm  add     @fedify/fedify@1.5.0

# For Bun
bun  add     @fedify/fedify@1.5.0

Thank you to all contributors who helped make this release possible!

0
0
0

드디어 Bartosz Milewski의 Category Theory 강의를 챕터 2까지 끝냈다. 몇년 걸렸지... 중간에 정체된 기간이 꽤 길었는데, 야식 먹을때 죄책감을 달래는 용도로 틀어놓았더니 진도를 빨리 뺄수 있었다.

0
0

It's no coincidence that alt-right people have taken up AI generated artwork so intensely. It allows bypassing all the ethics and care of typically left-leaning artists. To show the ability to wield aesthetics without the social values tied to those aesthetics is a power move.

This is well covered in "AI: The New Aesthetics of Fascism" newsocialist.org.uk/transmissi

0
28
0
0
0

개인적으로 bootstrap이나 tailwind를 좋아하지 않는다. 이런 CSS 프레임웍이 굉장히 작은 단위(일반적으로 컴포넌트)의 스타일을 클래스 집합으로만 컨트롤 하려고 하기 때문이다.

CSS(Cascading Style Sheets)는 그 이름에서 알 수 있듯이 계층 구조를 기준으로 동작한다. 부모 요소에서 자식 요소로 스타일을 상속하는 게 중요한 개념 중 하나이고 이걸 이용하면 여러 페이지 단위의 스타일을 일관성 있게 잡을 수 있다. 물론, 개발에서 특정 클래스를 반복 출력하는 것도 결과는 같을 수 있겠지만, 개발 편의를 위해 CSS 규칙을 깡그리 무시하는 방식이 tailwind 같은 거라고 보는 입장이다.

어차피 공통 스타일은 필요하지 않나. 그래서 컴포넌트를 쓰더라도 글로벌 스타일을 따로 선언해두고 예외를 CSS-in-JS로 처리하는 것이 맞다고 본다.

0

소프트웨어 개발자들이 자주 틀리는 외래어 표기법.

영어 틀린 표기 올바른 표기
app 어플
application 플리케이션 플리케이션
directory 디렉 디렉
front-end 트엔드 트엔드
message
method
release 릴리 릴리
repository 포지 포지

또 있을까요?

0

<Tracing the thoughts of a large language model>

LLM이 어떻게 생각하는지 추적하는 연구인데 아주 흥미롭다. LLM이 단순히 바로 다음에 올 높은 확률의 단어를 선택할 것이라고 생각했지만, 실제로는 미리 단어를 계획한 다음에 문장을 완성했다고. 다국어 구사와 암산 부분도 재미있다. 인간이 생각하는 방식과 크게 다르지 않은 것 같은데 기계가 정말 생각을 못한다고 할 수 있을까...

anthropic.com/research/tracing

1

better CSS에 대한 접근들(CSS-in-JS, Atomic CSS, Preprocessor)의 공통된 한계는 constraint solving 방식이 아니란 것이다.

다들 어떤 기존의 스타일을 '덮어쓰는' 방법, 근데 개중에 좀 잘 덮어쓰는 방법을 찾고 있다. 그런데 많은 경우, 뭔가를 덮어쓰려고 하고 있다면, 그건 사실 값을 덮어쓰는게 아니고 만족해야할 조건을 추가하고 싶은거다. 값을 덮어쓰는 것은 조건을 추가하는 방법 중 가장 강제적인 하나의 방법일 뿐이고. 즉, 디자인 시스템은 어떤 조건들의 합들로부터 실제 스타일을 구하는 방법이어야 하고, 개발자는 조건만 명시할 수 있어야 한다.

constraint solving을 잘 설계하고 구현하는게 어렵다 왜 이렇게 안 하냐고 하긴 좀 거시기하다. 그래서 나도 요즘 propagator를 공부중이다.

부연 설명을 위한 퀴즈. 정답은 저도 방금 실험해보고 알았습니다.

<style>
  .box1 {
    min-width: 200px;
  }

  .box2 {
    min-width: 300px;
  }
</style>

<div style="width: 0px;">
  <!-- 케이스 2: 두 클래스 모두 (box2의 200px가 적용) -->
  <div id="d1" class="box1 box2">200 px or 300px</div>
  <!-- 케이스 3: box1 box2 순서가 다름 -->
  <div id="d2" class="box2 box1">200 px or 300px</div>
</div>

여기서 #d1#d2width가 어떻게 될까요?

혹시 맞춘분이 많을까봐 그러는데, 이 동작이 원래 잘 알려져 있나요?

0

better CSS에 대한 접근들(CSS-in-JS, Atomic CSS, Preprocessor)의 공통된 한계는 constraint solving 방식이 아니란 것이다.

다들 어떤 기존의 스타일을 '덮어쓰는' 방법, 근데 개중에 좀 잘 덮어쓰는 방법을 찾고 있다. 그런데 많은 경우, 뭔가를 덮어쓰려고 하고 있다면, 그건 사실 값을 덮어쓰는게 아니고 만족해야할 조건을 추가하고 싶은거다. 값을 덮어쓰는 것은 조건을 추가하는 방법 중 가장 강제적인 하나의 방법일 뿐이고. 즉, 디자인 시스템은 어떤 조건들의 합들로부터 실제 스타일을 구하는 방법이어야 하고, 개발자는 조건만 명시할 수 있어야 한다.

constraint solving을 잘 설계하고 구현하는게 어렵다 왜 이렇게 안 하냐고 하긴 좀 거시기하다. 그래서 나도 요즘 propagator를 공부중이다.

0
0
0

데이터에서 인과 관계를 아예 찾을 수 없냐면, 그렇지는 않습니다. 그 과정이 생각보다 조금 더 단계가 많을 뿐입니다. 인과 분석에 있어서, 인과 구조가 단순히 ‘뭐가 바뀌면 뭐가 바뀐다‘ 이상으로 다양하고, 어떤 식으로 다양할 수 있는지를 이해해야 인과 관계를 가정하고 조건적 사고를 진행할 수 있을 것입니다. 이를 고려하지 않고 너무 인과관계를 단순하게 보다보니 잘못된 내용을 호도하거나 아예 배제하는 경우가 종종 눈에 띄어 아쉽습니다. 관련하여 인과 관계 구조를 구분하고 각각의 분석법을 훑어볼 수 있게 정리해 보았습니다. https://cojette.github.io/posts/structureofcausation/

0
0
0
0