Profile img

bgl gwyng

@bgl@hackers.pub · 99 following · 124 followers

GitHub
@bglgwyng
0
0
0
0
0
0
1
0
1
0
1
0
0
0
0
0
1
0
박준규 @curry@hackers.pub
Public

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

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

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

Tamgu (탐구), a FIL programming language: Functional, Imperative, Logical all in one for annotation and data augmentation - naver/tamgu

GitHub - naver/tamgu: Tamgu (탐구), a FIL programming language: Functional, Imperative, Logical all in one for annotation and data augmentation

Tamgu (탐구), a FIL programming language: Functional, Imperative, Logical all in one for annotation and data augmentation - naver/tamgu

github.com · GitHub

0
0
0
Fedify: ActivityPub server framework @fedify@hollo.social
Public
Shared by bgl gwyng

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!

Released on March 28, 2025. Improved activity delivery performance with large audiences through a two-stage queuing system. Sending activities to many recipients (e.g., accounts with many follow...

Release Fedify 1.5.0 · fedify-dev/fedify

Released on March 28, 2025. Improved activity delivery performance with large audiences through a two-stage queuing system. Sending activities to many recipients (e.g., accounts with many follow...

github.com · GitHub

0
0
0
bgl gwyng @bgl@hackers.pub
Public

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

0
0
0
0
0
0
Christine Lemmer-Webber @cwebber@social.coop
Public
Shared by bgl gwyng

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

AI: The New Aesthetics of Fascism

It's embarrassing, destructive, and looks like shit: AI-generated art is the perfect aesthetic form for the far right.

newsocialist.org.uk · New Socialist

0
26
0
0
1
0
0
3
0
Hyunjin Cho @resistan@hackers.pub
Public
Shared by bgl gwyng

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

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

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

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

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

영어 틀린 표기 올바른 표기
app 어플 앱
application 어플리케이션 애플리케이션
directory 디렉토리 디렉터리
front-end 프론트엔드 프런트엔드
message 메세지 메시지
method 메소드 메서드
release 릴리즈 릴리스
repository 레포지토리 리포지터리

또 있을까요?

0
0
0
Simon Park @parksb@silicon.moe
Public
Shared by bgl gwyng

<Tracing the thoughts of a large language model>

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

anthropic.com/research/tracing

A hand-drawn image where a black square overlaps with a white circle, revealing nodes and connections inside the circle, some of which are highlighted

Tracing the thoughts of a large language model

Anthropic's latest interpretability research: a new microscope to understand Claude's internal mechanisms

www.anthropic.com

1
0
0
bgl gwyng @bgl@hackers.pub
Public

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

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

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

bgl gwyng @bgl@hackers.pub
Public

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

<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과 #d2의 width가 어떻게 될까요?

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

0
0
0
bgl gwyng @bgl@hackers.pub
Public

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

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

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

0
2
0
0
0
0
0
0
2
Cojette @cojette@hackers.pub
Public
Shared by bgl gwyng

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

인과 관계의 다양한 구조와 분석 방안

현실에서 나타나는 현상은 시간에 따라 변화한 무언가를 말한다. 그리고 그런 시간에 따른 변화는 독립적으로 이루어지는 건 많지 않아, 그 변화 속에서 다양한 인과 관계가 형성된다. 그리고 사람들은 그 관계를 특정하고 싶어하고, 이를 수치적으로 풀고자 한다. 하지만 이를 풀어내는 것은 쉽지 않고 오용되는 경우가 너무나도 많아, ‘상관관계는 인과관계를 의미하지 않는다’는 말을 다들 입에 달고 살게 되었다. 하지만 여전히 이 말만 유명하고, 이 이상으로 나아가지 않는다. 심지어 이를 이상하게 해석한 후 마치 진실인 양 호도하는 이야기마저도 눈에 띈다. 물론 데이터에서 인과 관계를 아예 찾을 수 없냐면, 그렇지는 않다. 그 과정이 생각보다 조금 더 단계가 많을 뿐이다.

cojette.github.io · Cojette의 Data Wonderland

0
0
0
0
1
0
0
0
0
박준규 @curry@hackers.pub
Public
Shared by bgl gwyng

해키지(Hackage)[1]에 업로드한 패키지에 하독(Haddock)[2] 문서가 보이지 않을 때 다음과 같이 하면 된다.

먼저 다음 명령어로 하독 문서를 빌드한다.

cabal haddock --haddock-for-hackage

빌드된 압축 파일을 다음 명령어에 인자로 넣어 해키지에 업로드한다.

cabal upload --documentation --publish

이렇게 하면 이미 업로드된 패키지를 버전 변경(bump up)할 필요 없이 패키지에 누락된 하독 문서만 따로 업로드할 수 있다.

  1. 하스켈 패키지 저장소 ↩︎

  2. 하스켈 코드에 적은 주석 기반으로 HTML 문서를 만들어 주는 도구 ↩︎

0
0
0
0
0
0
0
0
0
0
1
0
박준규 @curry@hackers.pub
Public
Shared by bgl gwyng

@hongminhee洪 民憙 (Hong Minhee) 서울하스켈숲 1회 워크샵 참가 신청서 링크가 공개되었습니다. 다만 대상이 ‘하스켈을 잘 모르는 사람’이네요⋯

서울하스켈숲 1회 워크샵 참가 신청서

안녕하세요. 🌲서울하스켈숲🌲 김은민(https://github.com/eunmin)입니다. 서울하스켈숲은 서울숲 근처를 기반으로 하스켈 프로그래밍 언어를 함께 알리고 즐기기 위한 모임이 되려고 합니다. 하지만 아직 혼자입니다. 사람을 모으기 위해 먼저 4월은 하스켈을 배울 수 있는 워크샵을 열어보려고 합니다. 워크샵 후에 하스켈과 모인 사람들이 재밌는 모임이 될 것 같다고 생각이 되면 본격적인 모임을 만들 수도 있을 것 같아요. 워크샵은 다음과 같이 진행합니다. 서울하스켈숲은 liftIO와 함께합니다. :) 0. 내용 하스켈을 모르시는 분들에게 하스켈 기초 함께 따라하며 배우는 워크샵 1. 회차 및 시간 1회 4/3 (목) 저녁 7시~9시 2회 4/7 (월) 저녁 7시~9시 3회 4/10 (목) 저녁 7시~9시 4회 4/14 (월) 저녁 7시~9시 5회 4/17 (목) 저녁 7시~9시 6회 4/21 (월) 저녁 7시~9시 7회 4/24 (목) 저녁 7시~9시 8회 4/28 (월) 저녁 7시~9시 간식은 있지만 식사는 하고 오셔야 함 2. 장소 뚝섬역 도보 3분 이내 (구체적인 장소는 참석 확정 때 알려드림) 3. 비용 2만 원 (모아서 간단한 간식비로 쓸 예정) 참석 확정되면 계좌를 알려드림 4. 대상 다른 프로그래밍을 한 개 이상 할 수 있는 사람, 하스켈을 잘 모르는 사람 5. 인원 및 선발 전체 12명 먼저 신청했다고 참석이 확정되는 것이 아닙니다. 성별, 연령대등이 치우치지 않게 구성(자연스럽게 여성 개발자 우대)하려고 합니다. 따라서 신청서를 보고 참가 인원을 구성해서 확정 여부를 알려드리겠습니다. 참석 확정 여부는 늦어도 4월 1일에는 문자로 알려드리겠습니다. 6. 준비물 실습이 필요하니 개인 노트북을 가져오세요. 7. 개인정보 처리방침 아래 수집한 개인정보(이름, 성별, 연령대, 휴대폰번호, 소속, 하고 싶은 말, 소셜링크)는 워크샵 기간 동안 워크샵을 위해서 저(김은민)만 사용하고 워크샵이 끝나는 2025년 4월 28일 이후에 폐기(구글에서 삭제)합니다. 안전을 위해 개인정보를 구글에서만 보고 파일로 다운로드하거나 다른 곳에 복사해서 관리하지 않을 것입니다. 문제가 생기면 김은민(telepopsound@gmail.com)이 책임지겠습니다.

docs.google.com · Google Docs

0
2
0
0
0
0
박준규 @curry@hackers.pub
Public

@hongminhee洪 民憙 (Hong Minhee) 서울하스켈숲 1회 워크샵 참가 신청서 링크가 공개되었습니다. 다만 대상이 ‘하스켈을 잘 모르는 사람’이네요⋯

서울하스켈숲 1회 워크샵 참가 신청서

안녕하세요. 🌲서울하스켈숲🌲 김은민(https://github.com/eunmin)입니다. 서울하스켈숲은 서울숲 근처를 기반으로 하스켈 프로그래밍 언어를 함께 알리고 즐기기 위한 모임이 되려고 합니다. 하지만 아직 혼자입니다. 사람을 모으기 위해 먼저 4월은 하스켈을 배울 수 있는 워크샵을 열어보려고 합니다. 워크샵 후에 하스켈과 모인 사람들이 재밌는 모임이 될 것 같다고 생각이 되면 본격적인 모임을 만들 수도 있을 것 같아요. 워크샵은 다음과 같이 진행합니다. 서울하스켈숲은 liftIO와 함께합니다. :) 0. 내용 하스켈을 모르시는 분들에게 하스켈 기초 함께 따라하며 배우는 워크샵 1. 회차 및 시간 1회 4/3 (목) 저녁 7시~9시 2회 4/7 (월) 저녁 7시~9시 3회 4/10 (목) 저녁 7시~9시 4회 4/14 (월) 저녁 7시~9시 5회 4/17 (목) 저녁 7시~9시 6회 4/21 (월) 저녁 7시~9시 7회 4/24 (목) 저녁 7시~9시 8회 4/28 (월) 저녁 7시~9시 간식은 있지만 식사는 하고 오셔야 함 2. 장소 뚝섬역 도보 3분 이내 (구체적인 장소는 참석 확정 때 알려드림) 3. 비용 2만 원 (모아서 간단한 간식비로 쓸 예정) 참석 확정되면 계좌를 알려드림 4. 대상 다른 프로그래밍을 한 개 이상 할 수 있는 사람, 하스켈을 잘 모르는 사람 5. 인원 및 선발 전체 12명 먼저 신청했다고 참석이 확정되는 것이 아닙니다. 성별, 연령대등이 치우치지 않게 구성(자연스럽게 여성 개발자 우대)하려고 합니다. 따라서 신청서를 보고 참가 인원을 구성해서 확정 여부를 알려드리겠습니다. 참석 확정 여부는 늦어도 4월 1일에는 문자로 알려드리겠습니다. 6. 준비물 실습이 필요하니 개인 노트북을 가져오세요. 7. 개인정보 처리방침 아래 수집한 개인정보(이름, 성별, 연령대, 휴대폰번호, 소속, 하고 싶은 말, 소셜링크)는 워크샵 기간 동안 워크샵을 위해서 저(김은민)만 사용하고 워크샵이 끝나는 2025년 4월 28일 이후에 폐기(구글에서 삭제)합니다. 안전을 위해 개인정보를 구글에서만 보고 파일로 다운로드하거나 다른 곳에 복사해서 관리하지 않을 것입니다. 문제가 생기면 김은민(telepopsound@gmail.com)이 책임지겠습니다.

docs.google.com · Google Docs

0
0
0
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
Public
Shared by bgl gwyng

아마도 2006년이었던 것 같다. 처음 가본 대안언어축제에서 정말 충격적인 체험을 했었다. 당시는 Python이 대안 언어였던 시절… Io도 배우고 J도 배우고 Haskell도 배우고. 고등학생 때였는데, 동아리 사람들을 모두 데려가서 어른들에게 예쁨 받았던 기억도 있다. 행사가 어디서 후원을 받았었는지 기억은 안 나지만, 후원을 아주 크게 받았던 것만 기억이 난다.



RE: https://hackers.pub/@kodingwarrior/0195d560-1a2e-73db-847f-cd71b4d18653

0
0
0

bgl gwyng shared the below article:

복잡한 코드를 단순하게 줄여나갈 수록 발생하는 버그의 빈도나 심각도가 점진적으로 올라가는 경향이 있다고 느낀다

ㄹ @disjukr@hackers.pub

이 기술 블로그 포스팅에서는 코드 복잡도와 버그 심각도 사이의 미묘한 관계를 탐구합니다. 저자는 복잡도를 높이는 방향으로 문제를 해결할 때, 버그 빈도와 심각도를 점진적으로 줄일 수 있지만 최적의 해결책에 도달하지 못할 수 있다는 점을 지적합니다. 반대로, 복잡도를 낮추는 방향으로 접근하면 문제 해결에 드는 비용을 예측하기 어렵다는 어려움이 있습니다. 특히, 회사에서 코드 복잡도를 줄이는 대신 높이는 방향으로 문제 해결을 요구받는 상황에서 엔지니어로서의 자아와 현실 사이의 괴리를 느끼는 저자의 고충이 드러납니다. 개인 시간을 투자하여 더 나은 해결책을 찾아도, 이를 회사에 도입하는 데 많은 설득 비용이 소요된다는 점을 강조하며, 회사 내에서 자아실현을 포기해야 하는지에 대한 고민을 토로합니다. 이 글은 기술적 효율성과 조직적 요구 사이의 균형을 찾는 데 어려움을 겪는 개발자들에게 깊은 공감을 불러일으킬 수 있습니다.

Read more →
0
0
0
0
0
0
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
Public
Shared by bgl gwyng

개인적으로 Hackers' Pub 행동 강령에서 내세우고 싶은 곳이 있다면 이 부분이예요:

구조적 차별과 불평등에 대한 우리의 입장

우리는 현실 세계의 구조적 불평등이 온라인 공간에도 그대로 반영되고 있다는 현실을 직시합니다. Hackers' Pub은:

  • 성차별, 인종차별, 장애인 차별 등 우리 사회에 만연한 구조적 차별이 존재한다는 현실을 인식하고, 이러한 차별에 반대합니다.
  • “모든 사람을 동등하게 대우한다”는 명목 하에 이러한 구조적 불평등을 무시하거나 부정하지 않습니다.
  • 사회적 약자와 소수자에 대한 적극적인 포용 정책이 진정한 평등을 향한 필수적인 과정임을 확신합니다.
  • 차별과 혐오에 대항하는 발언과, 차별과 혐오 자체를 동일선 상에 두지 않습니다.
  • 우리는 이러한 구조적 차별이 결코 정당화될 수 없으며 반드시 극복되어야 할 과제임을 분명히 합니다.

Hackers' Pub Code of Conduct

hackers.pub

0
0
0

bgl gwyng shared the below article:

Browser-Native Translation and Language Detection APIs Coming Soon

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

Just reviewed the W3C draft for the Translator and Language Detector APIs. This is genuinely exciting development for web developers.

The proposal would add native browser support for:

  • Text translation between languages
  • Language detection of arbitrary text
  • Both with streaming capabilities

No more relying on third-party translation services or embedding external APIs for basic language operations. All processing happens locally in the browser.

The API design is clean and straightforward:

// Translation example
const translator = await Translator.create({
  sourceLanguage: "en",
  targetLanguage: "fr"
});

const translatedText = await translator.translate("Hello world");

// Language detection example
const detector = await LanguageDetector.create();
const results = await detector.detect("Hello world");
// Returns array of detected languages with confidence scores

This will be a game-changer for multilingual sites and applications. The browser handles downloading appropriate language models and manages usage quotas.

The spec is still in draft form but shows promising progress toward standardizing these capabilities across browsers. Looking forward to seeing this implemented.

Read more →
0
1
0
0
0
0
0
1
0
0
1
0
bgl gwyng @bgl@hackers.pub
Public

옛날에 만들어놓고 저 혼자는 잘쓰고 있는 React 폼 라이브러리 react-form-mozard를 소개합니다.

폼 중에서 Stepper 또는 Wizard라고 하는, 여러 개의 폼을 순차적으로 합친 형태를 다룰때 씁니다. 그래서 하나의 폼에 대해서는 react-hook-form 등 을 쓰고, 그걸 여러개 조합할땐 react-form-mozard를 활용하면 됩니다.

순차적으로 합친 에서 느낌이 오지요? 모나드가... 그대를 부릅니다...

폼 말고 CLI를 만들때를 잠깐 생각해보죠.

const name = prompt("이름이?")
const age = prompt(`{name} 님, 나이가?`)
if (Number(age) < 20) {
  console.info("미성년자는 이용할 수 없습니다")
  return
}
const gender = prompt(`{name} 님, 성별이?`)

뭐 이런 흐름을 생각해볼 수 있는데요. 보시면 먼저 받은 입력값에 따라 이후의 메시지나, 제어 흐름이 달라질 수 있습니다. 즉, 모나딕하죠. 근데 이런 평범한 로직을 Stepper/Wizard 에서 짜게되면 코드게 쉽게 더러워 지는걸 알수 있습니다.

react-form-mozard의 step은 위 예제의 prompt와 같은 역할을 합니다. 그리고 그걸 Generator 위에 얹으면 모나딕한 폼 합성이 가능해집니다.

단점이라면... 지금은 React랑 강결합 되어 있어, XState 등 다른 상태관리 라이브러리를 같이 쓴다면 연동이 깔끔하지 않을수 있습니다. 근데 평소에 쉽게 겪을 문제는 아니라고 보고, 또 추후에 설계를 수정해서 개선이 가능한 부분입니다.

Compose multiple forms into a single form wizard using a monadic approach. - gwyng-dev/react-form-mozard

GitHub - gwyng-dev/react-form-mozard: Compose multiple forms into a single form wizard using a monadic approach.

Compose multiple forms into a single form wizard using a monadic approach. - gwyng-dev/react-form-mozard

github.com · GitHub

0
0
0
Simon Park @parksb@silicon.moe
Public

코틀린+스프링 백엔드 개발하다가 지금은 프론트엔드 개발하고 있다는게 다른 사람들에게 꽤 재밌는 이야기로 다가오는 것 같다. 당연히 선택의 이유에 대한 질문을 가장 많이 받는데, 가장 특이한 질문은 OOP가 그립지 않은지(?)라는 질문. (OOP도, AOP도 전혀 그립지 않다.)

Simon Park @parksb@silicon.moe
Public
Shared by bgl gwyng

그리고 이런 입장에서 BE vs FE 같은 대결 구도가 조금... 그렇다. 사실 업무상 관점이 좀 다를 수는 있어도, 다른 직군으로 분류할 정도로 기술적 관심사나 고민의 주제가 그렇게 까지 다른가 싶기도. 나중에 이 생각의 해상도를 좀 더 높여봐야겠다.

0
0
0
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
Public
Shared by bgl gwyng

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

영어 틀린 표기 올바른 표기
app 어플 앱
application 어플리케이션 애플리케이션
directory 디렉토리 디렉터리
front-end 프론트엔드 프런트엔드
message 메세지 메시지
method 메소드 메서드
release 릴리즈 릴리스
repository 레포지토리 리포지터리

또 있을까요?

1
9
0
Simon Park @parksb@silicon.moe
Public
Shared by bgl gwyng

'탈중앙'같은 키워드가 대다수 사용자에게는 그다지 매력적이지 않은게 사실이지만, 적어도 나는 오래 전부터 RSS에서 얻고자 했던 것과 얻지 못 했던 것을 ActivityPub으로 얻을 수 있어서 너무 좋다. 특히 콘텐츠 생산자 입장에서는 정말 참여하지 않을 이유가 없을 것 같은데...

0
0
0
Jaeyeol Lee (a.k.a. kodingwarrior) :vim: @kodingwarrior@silicon.moe
Quiet public
Shared by bgl gwyng

액티비티펍을 사용하는지는 중요하지 않지만 제품이 훌륭하면 그 기반이 되는 액티비티펍이 장점을 더욱 발휘하는게 있는 것 같음. 액티비티펍이 장점으로 먼저 내세워져서는 안되는 것 같음. 액티비티펍을 쓰는지는 개발자한테나 어필이 되는 것이 아닌가..

0
0
0
0
0
0
0
0
0
bgl gwyng @bgl@hackers.pub
Public

다들 개발할때 '하느님 제게 왜 이딴 시련을 : 하느님 이런 흥미로운 문제를 풀 기회를 주셔서 감사합니다'의 비율이 어떻게 되시나요? 저는 근 몇달간은 거의 99:1에 육박하는거 같습니다

0
0
0
Simon Park @parksb@silicon.moe
Public
Shared by bgl gwyng

"es-git은 Node.js를 위한 현대적인 git 라이브러리예요. 간편하고 직관적인 인터페이스 덕분에 복잡한 git 작업도 쉽게 통합할 수 있으며, TypeScript 타입을 내장해 빠르고 안정적인 개발을 지원해요." github.com/toss/es-git

A modern Git library built for Node.js with blazing-fast installation and rock-solid stability, powered by N-API. - toss/es-git

GitHub - toss/es-git: A modern Git library built for Node.js with blazing-fast installation and rock-solid stability, powered by N-API.

A modern Git library built for Node.js with blazing-fast installation and rock-solid stability, powered by N-API. - toss/es-git

github.com · GitHub

0
0
0