Hi, I'm who's behind Fedify, Hollo, BotKit, and this website, Hackers' Pub!

Fedify, Hollo, BotKit, 그리고 보고 계신 이 사이트 Hackers' Pub을 만들고 있습니다.

FedifyHolloBotKit、そしてこのサイト、Hackers' Pubを作っています。

嗨,我是 FedifyHolloBotKit 以及這個網站 Hackers' Pub 的開發者!

Website
hongminhee.org
GitHub
@dahlia
Hollo
@hongminhee@hollo.social
DEV
@hongminhee
velog
@hongminhee
Qiita
@hongminhee
Zenn
@hongminhee
Matrix
@hongminhee:matrix.org
X
@hongminhee

I'm looking for a Markdown formatter, and I'm quite particular about my Markdown style. I don't want it to be formatted in a generic Markdown style. For instance, I prefer a style that adheres to rules such as:

  • 80 characters at most per line, except for code blocks and URLs.
  • Prefer reference links over inline links.
  • Prefer setext headings over ATX headings.
  • Two new lines before opening an H1/H2 heading.
  • One space before and two spaces after a bullet.
  • Wrap file paths in asterisks.
  • Wrap inline code in backticks.
  • Wrap code blocks in quadruple tildes (~~~~), and specify the language with a single space after the opening tildes (e.g., ~~~~ bash).

Are there any Markdown formatters that allow for such detailed customization of these elements? Or would I have to build one myself?

2

Nix 언어를 새로 만들지말고 그냥 Python DSL 같은걸 썼으면 어땠을까 종종 생각한다. 그 세계선에선 또 그 Python DSL 욕을 주구장창 하고 있겠지만, 적어도 생태계는 더 커지지않았을까. 남바완 Linux 배포판이 됐을 수도 있다.

3
1
10
0

같은 이유로 Neovim을 못 쓰고 있다.

요즘은 에디터를 쓰고 있는데, .helix/languages.toml 파일로 프로젝트 별 구성을 쉽게 할 수 있어서 맘에 든다:

[language-server]
deno = { command = "deno", args = ["lsp"], config.deno.enable = true }

[[language]]
name = "javascript"
language-servers = ["deno"]
formatter = { command = "biome", args = [ "format", "--stdin-file-path", "buffer.js" ]

https://hackers.pub/@hongminhee/0196c20f-71e3-7a7c-920c-2f4cf8790b13

1
4

Cursor 탭 자동완성의 짧은 역사
------------------------------
- Cursor의 *최고 수준 탭 자동완성 기능* 은 Supermaven의 Babble 모델 인수로 가능해졌으며, 이 모델은 *최대 100만 토큰 컨텍스트 창* 과 *250ms의 낮은 지연 시간* 을 자랑함
- 기존 LLM 기반 자동완성은 caret 위치 이후 코드만 예측하는 한계가 있었으나, Babble은 *git diff 기반 편집 시퀀스 학습* 을 통해…
------------------------------
https://news.hada.io/topic?id=20845&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

0

Looking for implementations with support! 🔍

As mentioned in the Fedify announcement below, I've implemented RFC 9421 (HTTP Message Signatures) and need to verify its interoperability with other ActivityPub implementations.

The challenge is that most major ActivityPub projects don't seem to have full RFC 9421 implementations in production yet. If you're working on an ActivityPub project that:

  • has implemented RFC 9421 (even in a development branch)
  • is currently implementing it
  • has plans to implement it soon

Please reach out! I'd love to collaborate on interoperability testing to ensure our implementations work properly with each other before merging this into 's main branch.

Any leads or connections would be greatly appreciated! 🙏

Okay, I've just deployed a bleeding edge , which implements both RFC 9421 and double-knocking, to Hackers' Pub. If you'd like to test your implementations against a real server, please give it a try! (If you want to create an account, let me know—I can invite you.)

2
0
0
0

How does libpq from postgresql load SSL root certificates and how can you mirror that behavior in node.js?

Well, here's waaaaay too much information: github.com/mastodon/mastodon/p

Yes, I had to checkout the postgresql source code and reference the openssl API docs and Node.js source code to work this out.

1

그나저나, useEffect 에서 Server Actions 호출 할 수 있는 거 나만 몰랐지 또.

https://nextjs.org/docs/app/building-your-application/data-fetching/server-actions-and-mutations#useeffect

컴포넌트가 마운트되거나 종속성이 변경될 때 서버 액션을 호출하기 위해 React useEffect 훅을 사용할 수 있습니다. 이는 글로벌 이벤트에 의존하거나 자동으로 트리거되어야 하는 변이에 유용합니다. 예를 들어 앱 바로 가기를 위한 onKeyDown, 무한 스크롤을 위한 교차점 관찰자 후크, 컴포넌트가 마운트되어 뷰 수를 업데이트할 때 등이 있습니다:

라고 합니다.

1

안녕하세요, 업으로 프로그래밍을 하고 있는 컴퓨터 학부생 김무훈입니다.
현재 3년차 웹 프론트엔드 개발자로서, 다가오는 7월부터 함께할 정규직 포지션을 적극적으로 찾고 있습니다.

최근 학과 사무실에서 졸업 요건을 확인한 결과, 전공 필수 한 과목전공 선택 2학점(총 5학점)이 남아있음을 확인했습니다.
본래는 다음 2학기까지 수료 후 내년 2월에 졸업할 예정이었으나, 교수진과 상의한 결과 취업 및 재직이 확정된다면 수업 이수 방식을 보다 유연하게 결정할 수 있다는 긍정적인 답변을 받아 적극적으로 조기 취업을 추진하게 되었습니다.

이는 전공 필수 과목의 경우에만 해당이 되는 문제이고, 전공 선택 2학점의 경우 앞으로의 여름 학기 현장 실습 또는 다음 학기에 개설되는 하나의 원격 강의로 대체하여 문제가 없는 상태입니다.

지금까지의 업무 경험과 프로젝트는 아래의 포트폴리오에서 확인하실 수 있습니다.
📌 경력기술서 겸 포트폴리오 페이지: https://www.frontend.moe/portfolio/

좋은 인연을 찾을 수 있도록, 많은 관심과 연락 부탁드립니다!

8
3
3
1

WASM 2.0 공식 릴리즈
------------------------------
- *Wasm 2.0 스펙* 이 공식적으로 발표됨
- Wasm Community와 Working Groups가 2022년부터 스펙을 완성했고, 주요 구현체는 이미 2.0을 지원하고 있었음
- 2.0부터는 *에버그린 모델* 이 도입되어, Candidate Recommendation 문서가 지속적으로 최신 상태로 갱신됨
- 새 버전이 발표될 때마다 최종 권고안으로…
------------------------------
https://news.hada.io/topic?id=20812&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

0

AWS 를 바닥 (vpc 세팅) 부터 새롭게 하고 있다. private, public subnet 나누고 NAT 인스턴스 올리고, 베스천으로 프록시점프해서 private 구간 인스턴스 ssh 접속 확인하고 nginx 올리고 next 프로젝트 가져와서 proxy pass 걸고 alb 넣고.. 콘솔에서 바닥부터 한땀한땀 설정하는 게 오랜만이라 그런가 재밌다.

(요즘 엔지니어들이라면 IaC로 단숨에 끝냈겠지만)

아무도 알아주지 않지만 견고하게(?) 세팅 끝냈다며 혼자 뿌듯해 하는 1인, 그렇게 하루종일 개발 안하고 인프라 만지작 거리다 하루가 끝났다.

5
1

We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in , complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.

This implementation includes both signature generation and verification, meaning is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other implementations. Once these tests confirm compatibility, we'll proceed with the merge.

As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the . Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.

Currently, we support RSA-PKCS-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.

We look forward to contributing to a more standardized and secure fediverse!

HTTP Message Signatures

This API is available since Fedify 1.6.0.

RFC 9421, also known as HTTP Message Signatures, is the final revision of the HTTP Signatures specification. Although it is the official standard, it is not widely used in the fediverse yet. As of May 2025, major ActivityPub implementations, such as Mastodon, et al., still rely on the draft cavage version of HTTP Signatures for signing portable activities.

Fedify automatically signs activities with the sender's private key if the actor keys dispatcher is set and the actor has any RSA-PKCS#1-v1.5 key pair. If there are multiple key pairs, Fedify selects the first RSA-PKCS#1-v1.5 key pair among them.

NOTE

Although HTTP Message Signatures support other than RSA-PKCS#1-v1.5, Fedify currently supports only RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures. This limitation will be lifted in the future releases.Double-knocking HTTP Signatures

This API is available since Fedify 1.6.0.

As you read above, there are two revisions of HTTP Signatures: the draft cavage version and the RFC 9421 version. The draft cavage version is declared as obsolete, but it is still widely used in the fediverse, and many ActivityPub implementations still rely on it. On the other hand, the RFC 9421 version is the official standard, but it is not widely used yet.

To support both versions of HTTP Signatures, Fedify uses the double-knocking mechanism: trying one version, then falling back to another if rejected. If it's the first encounter with the recipient server, Fedify tries the RFC 9421 version first, and if it fails, it falls back to the draft cavage version. If the recipient server accepts the RFC 9421 version, Fedify remembers it and uses the RFC 9421 version for the next time. If the recipient server rejects the RFC 9421 version, Fedify falls back to the draft cavage version and remembers it for the next time.
1
0
1

학과 책장에 11년 전에 출간한 웹 접근성 책을 찾았습니다.

책 목차를 살펴보니 WCAG 표준에서 제정한 아래 4가지 원칙을 개별마다 많은 사례를 바탕으로 다루고 있네요.

  • 인지할 수 있는(Perceivable)
  • 조작 가능한(Operable)
  • 이해할 수 있는(Understandable)
  • 견고함(Robust)

자료가 오래되었지만 흥미 있는 사례집이라 읽어 보려고 합니다.

책장 중간에 
"장애인차별금지법 대응을 위한 웹 접근성과 품질인증
류영일 • 하성필 • 김혜일 • 성영한 지음

에이콘"라고 적힌 책이 놓여 있다.| 지은이

류영일
2007년부터 2012년까지 한국정보화진흥원에서 웹 표준과 웹 접근성 관련 업무 를 맡아왔으며, 웹 접근성 품질인증마크 담당과 법 제도 T/F를 운영하여 지금의 국가정보화기본법 개정 내용을 만들었다. 부족한 인증심사 기준을 제시하기 위 해 좀 더 구체적인 웹 접근성 품질인증심사가이드를 제작하는 등 다양한 웹 접근 성 업무를 추진해왔다. 현재 웹 접근성 컨설턴트로 일하고 있으며, 다수의 강의 및 컨설팅, 자문을 수행 중이다. 특히 접근성이 웹에 머물지 않고 모바일 분야와 소프트웨어, 제품, 서비스까지 확장되어야 한다는 생각으로 접근성 연구회를 설 립하여 기반 기술을 사회에 제시하고 웹 접근성을 알 수 있는 기회를 제공하는 등 사회 곳곳에 접근성을 향상시키는 연결 구조를 만들기 위해 노력하고 있다.

하성필
1999년 웹 제작을 시작한 이후 웹 디자이너, 기획자 등을 거처 현재 웹 퍼블리셔 및 웹 접근성 컨설턴트로 일하고 있다. 다양한 웹 기술 분야의 경험을 바탕으로 다수의 웹 접근성과 웹 퍼블리싱 강의를 하며, 웹 접근성의 모호한 영역까지 모두 실무적으로 구현할 수 있는 실력의 소유자다.

김혜일
국내에서 점유율이 가장 높은 화면 낭독기 개발 기업의 기술자문 경험을 바탕으로 한 사용자 평가와 저시력 사용자에 대한 웹 접근성 전문가다. 실제 시각장애인이 면서 다수의 웹 접근성 관련 사용자 평가 경험을 바탕으로 현재는 전문가 평가로 영역을 확대했으며 다양한 웹사이트, 모바일 앱 등 접근성 평가와 자문을 진행하 고 있다. 스스로 시각장애로 인해 느끼는 불편을 누구보다 잘 알기에 실제 사용성 을 높일 수 있도록 지침 이외의 영역에 대한 접근성 개선을 소명으로 생각하는 접 근성 지킴이다.
성영한
자바와 관련해서 10년 이상 개발을 하다가 우연한 기회로 접근성을 접한 후, 퍼 블리셔 위주의 접근성을 개발자들도 모두 기본적으로 숙지해야 한다는 생각을 하 게 됐다. 사회 비용이 증가하더라도 웹을 사용하는 모든 사용자에게 평등한 기회 를 부여해야 한다는 철학하에 현재는 웹 접근성을 자동화할 수 있는 자바스크립 트를 연구하고 있고, 웹뿐만 아니라 모바일까지 연구 범위를 확대하고 있다.2부 웹 접근성 기본 4원칙
3장 인식의 용이성: 모든 콘텐츠는 사용자가 인식할 수 있어야 한다
3.1
[검사항목 1] 적절한 대체 텍스트 제공 ... 111
3.1.1 [오류유형 1-1] 텍스트 이미지의 대체 텍스트 미 제공 ..• 113
3.1.2 [오류유형 1-1] 불충분한 대체 텍스트를 제공한 경우 ... 115
3.1.3 [오류유형 1-1] 대체 텍스트가 오타로 표기된 경우 ... 117
3.1.4 [오류유형 1-1] 이미지 버튼에 대체 텍스트를 제공하지 않은 경우 ... 118
3.1.5
[오류유형 1-1] 게시물의 이미지에 대체 텍스트가 제공되지 않은 경우 ... 119
3.1.6
[오류유형 1-2] 불릿 이미지에 대한 대체 텍스트를 제공하지 않은 경우 ... 121
3.1.7
[오류유형 1-2] 의미 없는 이미지에 대체 텍스트를 제공한 경우 ... 123
3.1.8 [오류유형 1-2] 분리된 이미지 조각의 대체 텍스트 제공 ... 124
3.1.9 [오류유형 1-3] 〈Iongdesc〉의 파일이 없거나 연결되지 않은 경우... 125
3.1.10 [오류유형 1-3] 〈longdesc〉 내용이 의미나 기능을 파악하기 어려운 경우 ... 126
3.1.11 [오류유형 1-4] 이미지맵의 〈img〉 요소에 alt 속성을 제공하지 않은 경우 ... 129
3.1.12 [오류유형 1-5] 조직도 이미지맵의 〈area〉로만 대체 텍스트를 제공한 경우 ... 131
3.1.13 [오류유형 1-6] 대체 텍스트를 tite만으로 제공하는 경우 ... 133
3.1.14 [오류유형 1-7 QR 코드의 이동 주소 정보를 대체 텍스트 등으로 제공하지 않은 경우
... 133
3.1.15 [오류유형 1-8] 의미 있는 배경 이미지의 대체 콘텐츠를 제공하지 않은 경우 ... 135
3.1.16 [오류유형 1-8] 의미 있는 색상 배경 이미지에 대체 콘텐츠를 제공하지 않은 경우 ... 137
3.1.17 [오류유형 1-9] 플래시 콘텐츠에 대체 텍스트를 제공하지 않은 경우 ... 138
3.1.18 [오류유형 1-9] 웹 애플리케이션의 대체 콘텐츠가 접근성이 없는 경우 ... 1414장 운용의 용이성: 사용자 인터페이스 구성요소는 조작 가능하고 내비게이션할 수 있어야 한다
4.1
[검사항목 기 키보드 사용 보장 ... 191
4.1.1 [오류유형 1-1] 이미지에 onclick 이벤트를 적용하여 키보드로 제어할 수 없는 경우 ... 198
4.1.2 [오류유형 7-1] 키보드 이벤트를 적용하지 않아 키보드 접근이 안 되는 경우 ... 195
4.1.3 [오류유형 7-11 readonly 속성을 사용하여 대체 수단이 비활성화되는 경우 ... 197
4.1.4 [오류유형 1-1 마우스용 자바스크립트 사용으로 키보드 이용이 불가능한 경우 ... 198
4.1.5 [오류유형 7-2] 플래시 wmode 값 설정으로 키보드 이용이 불가능한 경우 ... 200
4.1.6 [주의사항 7-1] 웹 접근성 품질인증심사에서는 IE8 브라우저에서 키보드 테스트함 ... 203
4.1.7 [주의사항 7-21 onclick 이벤트 핸들러에 키보드로 제어가 불가한 경우 감점 ... 203
4.1.8 [주의사항 7-3] 예외 콘텐츠라도 주변 인터페이스는 키보드로 사용할 수 있어야 함 ... 203
4.1.9 [주의사항 7-4] 키보드로 탭메뉴에서 탭 내용을 확인할 수 없는 경우 감점 ... 204
4.1.10 [주의사항 7-5 oniocus="this.blur0;" 사용 시, 검사항목 7, 8, 16에서 감점 ... 204
4.1.11 [주의사항 7-61 wmode를 transparent, opaque로 지정 시 화면 낭독기 인식 불가능
... 205
4.2
[검사항목 8] 초점 이동 ... 206
4.2.1 [오류유형 8-1] 초점의 이동 순서가 논리적이지 않으며 일관성이 없는 경우 ... 207
4.2.2 [오류유형 8-21 초점의 위치가 시각적으로 표시되지 않은 경우 .•. 209
4.2.3 [오류유형 8-3] 〈area〉 요소의 순서가 키보드 순서와 다른 경우 ... 213
4.2.4 [주의사항 8-11 onfocus="this.blur0;" 사용 시, 검사항목 7, 8, 16에서 감점 ... 214
4.3
[검사항목 9] 응답시간 조절 ... 215
4.3.1 [오류유형 9-1] 페이지 재이동 시 회피할 수 있는 수단을 제공하지 않은 경우 ... 2165장 이해의 용이성: 콘텐츠는 이해할 수 있어야 한다
5.1
[검사항목 15] 기본 언어 표시 ... 257
5.1.1
[오류유형 15-11 〈html〉에 lang 속성을 명시하지 않은 경우 ... 258
5.1.2
[오류유형 15-1] 〈html〉에 lang 속성을 잘못 명시한 경우 ... 259
5.1.3 [주의사항 15-1] lang 속성값에 국가별 지정언어 코드를 사용해야 함 ..• 260
5.1.4 [주의사항 15-21 페이지 중간에 언어가 바뀔 때 lang 속성으로 명시해주는 것을 권장 ... 262
5.2
[검사항목 16] 사용자 요구에 따른 실행 ... 263
5.2.1
[오류유형 16-1] 사용자가 예측하지 않은 새 창이 열리는 경우 ... 264
5.2.2
: [오류유형 16-1] 사전에 알리지 않은 새 창이 발생되는 경우 ... 267
5.2.3 [오류유형 16-2] 웹사이트 초기화면에 팝업창을 제공하는 경우 ... 268
5.2.4 [오류유형 16-3] 사용자가 의도하지 않은 초점 변화가 발생하는 경우 ... 271
5.2.5 [오류유형 16-4] 입력 서식의 값 변경만으로 제출되어 문맥이 바뀌는 경우 ... 273
5.2.6 [오류유형 16-4] 체크상자의 선택만으로 값이 제출되어 문맥이 바뀌는 경우 ... 274
5.2.7 [주의사항 16-1] onkeypress에 의해 포커스를 옮기는 동작만으로 새 창이 발생하면 감점
... 275
5.2.8 [주의사항 16-21 〈a targel="_blank">로만 새 창을 알린 경우는 감점하지 않음 ... 276
5.2.9
[주의사항 16-3] onfocus="this.blur)" 사용 시, 검사항목 7, 8, 16에서 감점 ... 2766장 견고성: 웹 콘텐츠는 미래의 기술로도 접근할 수 있도록 최대한 호환되어야 한다
6.1
[검사항목 21] 마크업 오류 방지 ... 317
6.1.1 [오류유형 21-1] 태그의 열고 닫음 오류 ... 318
6.1.2 [오류유형 21-2] 태그의 중첩 오류 ... 319
6.1.3 [오류유형 21-3] 중복 선언된 속성 오류 ... 320
6.1.4 [주의사항 21-1] ID 값 중복 선언은 오류유형 21-3에서 심사 ... 320
6.1.5 [주의사항 21-2] 위에 언급된 항목 이외의 표준문법 오류는 포함하지 않음 ... 321
6.1.6 마크업 오류 세부 사례 ... 321
6.1.6.1 [열고 닫음 오류 사례 1 (a) 요소 여는 태그 미 제공 ... 321
6.1.6.2 [열고 닫음 오류 사례 2 〈ul〉 요소 여는 태그 미 제공 ... 322
6.1.6.3 [열고 닫음 오류 사례 31 div》요소 여는 태그 미 제공 ... 323
6.1.6.4 [열고 닫음 오류 사례 41 〈a〉 요소 닫는 태그 미 제공 ... 323
6.1.6.5 [열고 닫음 오류 사례 5] 《strong〉 요소 닫는 태그 미 제공 ... 324
6.1.6.6 [열고 닫음 오류 사례 61 〈h 요소 닫는 태그 미 제공 ... 325
6.1.6.7 [태그의 중첩 오류 사례] 《p》와 《strong》의 중첩 제공 ... 326
6.1.6.8 [속성 중복 오류 사례 11 〈p〉 요소에 대한 style》 속성 중복 제공 ... 326
6.1.6.9 [속성 중복 오류 사례 2] ID 속성 중복 제공 ... 327
6.2
[검사항목 22] 웹 애플리케이션 접근성 준수 ... 330
6.2.1 [오류유형 22-1] 접근성이 없는 웹 애플리케이션의 대체 콘텐츠가 없는 경우 ... 331
6.2.2 [오류유형 22-1] 대체 콘텐츠가 핵심 기능을 동등하게 제공하지 못한 경우 ... 332
1

세계 접근성 인식의 날은 매년 5월 셋째주 목요일로 지정되어있고, 올해는 오는 5월 15일(목)입니다.

a11ykr 커뮤니티 멤버들과 함께 한국어 소개글을 준비해서 제출했는데, 사이트에 게시되면 좋겠습니다.

https://accessibility.day

1

C++를 통해 Rust의 매력을 보여준 Matt Godbolt의 설득
------------------------------
- 20년 이상 C++을 사용한 저자가 *Rust의 장점을 재발견* 하게 된 계기를 Matt Godbolt의 강연을 통해 소개함
- C++에서는 *타입 혼동에 의한 실수* 가 컴파일러에서 제대로 잡히지 않지만, Rust는 이를 *컴파일 타임에 강하게 차단* 함
- Rust는 *단순한 메모리 안전성 외에도 API 오용 방지* 에 유리한 설계를…
------------------------------
https://news.hada.io/topic?id=20760&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

0
2
0
0

개발자의 저주: 고치는 능력을 가진 자의 무한한 책임감
------------------------------
- 사소한 자동화를 반복하다 보면 어느 순간 모든 도구와 시스템이 *고쳐야 할 대상* 으로 보이게 되는 *인지의 임계점* 에 도달하게 됨
- 기술력이 쌓일수록 문제를 단순히 인식하는 것을 넘어 *책임처럼 느끼게 되는 감정의 무게* 를 가지게 됨
- *고치고자 하는 욕구* 는 단순한 생산성 향상을 넘어서
감정…
------------------------------
https://news.hada.io/topic?id=20735&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

1

나는 버전 올리기 강박증같은게 있는데, RN 초기에 불안정한 라이브러리들 많이 쓰다가 생긴거 같다. 일단 버전 올린다음에 빌드 터지는지 기존 기능 잘돌아가는지 확인하는데, 이거하느라 쓰는 시간도 꽤 된다. 실제로 시간을 아끼고 있는지(모르던 버그를 모르고 해결해서) 아닌지 모르겠다.

3

GitHub 저장소 코드를 분석해 AI로 문서화하는 도구. 다이어그램을 적극적으로 활용해 아키텍처를 쉽게 이해할 수 있고, 문서의 깊이와 정확도도 높다. 여러모로 <오픈 소스 소프트웨어 아키텍처>를 읽으며 아쉬웠던 부분들을 커버해주는 프로젝트. deepwiki.com/

4

AI에 대한 SW 엔지니어들의 자신감은 "어쨌거나 업계 내에서 만드는거라서-" 인거 같다. 손바닥 위에 있다는 감각(얼추 맞긴 하다).

타 직업군은 AI나 LLM 솔루션 자체를 다루는데도 한계가 있거니와(아무래도 fork떠서 고친다거나 할순 없으니까) 결과물도 자기 의사와 관계 없이 학습당하고 있기 때문에…

아예 거스를 수 없는 것이기 때문에, 타 분야에서는 오히려 공격적으로 자기 분야에 특화된 모델을 만들고, 기존 저작물들을 학습으로 부터 보호해서 우선권을 선점 하는게 그나마 좀 더 낫지 않을까?

근데 후자는… 테크기업이 양아치라서 잘 안될거같다.

2

Next.js 서버 액션은 서버 데이터를 가져오는 용도로 사용하기에 적합하지 않다. React 공식문서에서는 다음과 같이 말하고 있다.

Server Functions are designed for mutations that update server-side state; they are not recommended for data fetching. Accordingly, frameworks implementing Server Functions typically process one action at a time and do not have a way to cache the return value.

서버 액션이 여러 호출되면 바로 실행되는 대신 큐에 쌓이고 순차적으로 처리된다. 이미 실행된 서버 액션은 이후 취소할 수 없다.

이에 서버 액션을 데이터 가져오기로 활용하면 끔찍해지는 UX가 생길 수 있는데, 예를 들어 페이지의 목록 검색 화면에서 검색 후 데이터를 가져오는 상황에 않았다고 다른 화면으로 네비게이션이 불가능한 것은 일반적인 경험이 아니다.

이러면 RSC를 통해 무한 스크롤을 구현하지 못하는가? 에 대해서 의문이 생길 수 있는데 여기에 대해서 대안을 발견했다.

function ServerComponent({ searchParams }) {
  const page = parseInt((await searchParams).page ?? "1", 10)
  const items = await getItems(page)
  return (
    <Collection id={page}>
      {items.map(item => <InfiniteListItem key={item.id} {...items} />)}
    </Collection>
  )
}
"use client"

function Collection({ id, children }) {
  const [collection, setCollection] = useState(new Map([[id, children]]))
  const [lastId, setLastId] = useState(id)
  if (id !== lastId) {
    setCollection(oldCollection => {
      const newCollection = new Map(oldCollection)
      newCollection.set(id, children)
      return newCollection
    })
    setLastId(id)
  }
  return Array
    .from(collection.entries())
    .map(
      ([id, children]) => <Fragment key={id}>{children}</Fragment>
    )
}

대충 이런 꼴이다. 이러고 page를 증가시키거나 감소시키는건 intesection observer나 특정 엘리먼트의 onClick 이벤트 따위를 의존하면 된다. 이러면 데이터 가져오기 패턴을 RSC 형태로 의존할 수 있다. InfiniteListItem는 서버컴포넌트, 클라이언트컴포넌트 무엇으로 구현하더라도 상관없다. 가령 아래와 같은 식:

function ServerComponent({ searchParams }) {
  const page = parseInt((await searchParams).page ?? "1", 10)
  const { items, hasNext } = await getItems(page)
  return (
    <div>
      <Collection id={page}>
        {items.map(item => <InfiniteListItem key={item.id} {...items} />)}
      </Collection>
      {hasNext && (
        <IntersectionObserver nextUrl={`/?page=${page + 1}`} />
      )}
    </div>
  )
}

검색 조건이나 검색어에 따라 상태를 초기화시키려면 다음과 같이 표현하면 된다.

function ServerComponent({ searchParams }) {
  const page = parseInt((await searchParams).page ?? "1", 10)
  const query = parseInt((await searchParams).query ?? "")
  const { items, hasNext } = await getItems(page, query)
  return (
    <div>
      <Form action="/">
        <input name="query" />
        <button />
      </Form>
      <Collection id={page} key={query}>
        {items.map(item => <InfiniteListItem key={item.id} {...items} />)}
      </Collection>
      {hasNext && (
        <IntersectionObserver nextUrl={`/?page=${page + 1}&query=${query}`} />
      )}
    </div>
  )
}

매우 PHP스럽고, 암묵적이기도 하다. 다만 RSC의 데이터 가져오기 패턴을 활용하면서 기존 컴포넌트를 최대한 재사용할 수 있게 된다는 점이 좋다.

2

실제로 방금 어떤 사례를 발견했냐면, 계산이 살짝 까다로운 값에 대한 테스트를 만들라고 시켰더니 코드를 한 백줄 뱉어내는데

expect(x).toBe(42)

이렇게 값에 대한 테스트를 안하고

expect(typeof x).toBe("number")

이러고 넘어가려고 했다. 손바닥 이리내.

5

@TakTak! @hongminhee洪 民憙 (Hong Minhee) it's the other way around, FEP-5624 pre-dates GTS' interaction policies but was never implemented anywhere and did not get much traction; the bulk of the discussion at the time was about who should control the reply policy (original post author or person you immediately reply to)

GTS decided to pick the second solution even if it's not necessarily the ideal one, because it's much simpler to implement

GTS' interaction policies were then refined with a lot of back-and-forth with Mastodon devs when we were working on quote posts (resulting in FEP-044F which re-use GTS' interaction policies)

maybe we should retire FEP-5624

0
2
0
0
0

あー。drizzleって、PostgreSQLlのmoney(通貨型)はまだサポートしてないのか。なるほど、試さないと分からないもんだ。他の型で代用するか。

書籍「テスト駆動開発」か「リファクタリング第二版」でいうプログラムだけでなく、データベースもリファクタリングの対象にするというか、将来に向かって現在動くものを作る感じなんだな。これも。

1
2
1
0
0

아까 Post에 달린 이모지 리엑션 쪽 API 깎느라고 n시간 동안 삽질하다가 결국 때려치고 질문을 올렸었는데 아직 구현이 안 된 부분이었다고 해서 PR을 올렸다 (???

https://github.com/hayes/pothos/pull/1440

2

@bglbgl gwyng 커스텀 렌더러 (Solid에선 Universal Rendering이라고 부름) 지원 자체는 잘 되어 있는데 그냥 커뮤니티 망치가 부족해서 유지보수가 안 되는 것에 가깝고 😅 이런 물건은 왜인진 도저히 모르겠지만 나름 관리가 잘 되고 있습니다

3
0
0