Profile img

洪 民憙 (Hong Minhee)

@hongminhee@hackers.pub · 1014 following · 723 followers

Hi, I'm who's behind Fedify, Hollo, BotKit, and this website, Hackers' Pub! My main account is at @hongminhee洪 民憙 (Hong Minhee) :nonbinary:.

Fedify, Hollo, BotKit, 그리고 보고 계신 이 사이트 Hackers' Pub을 만들고 있습니다. 제 메인 계정은: @hongminhee洪 民憙 (Hong Minhee) :nonbinary:.

Fedify、Hollo、BotKit、そしてこのサイト、Hackers' Pubを作っています。私のメインアカウントは「@hongminhee洪 民憙 (Hong Minhee) :nonbinary:」に。

Website
hongminhee.org
GitHub
@dahlia
Hollo
@hongminhee@hollo.social
DEV
@hongminhee
velog
@hongminhee
Qiita
@hongminhee
Zenn
@hongminhee
Matrix
@hongminhee:matrix.org
X
@hongminhee
0
0
0
bgl gwyng @bgl@hackers.pub
Public
Shared by 洪 民憙 (Hong Minhee)

난 요거 반대의 도구를 찾고 있는데, remote로 electron이나 tauri등을 띄운다음에 웹뷰를 브라우저로 볼수있게하는 것이다. 안그래도 지금 GitButler 깔았는데 remote 사용을 지원안해서 난감해졌다.

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

난 요거 반대의 도구를 찾고 있는데, remote로 electron이나 tauri등을 띄운다음에 웹뷰를 브라우저로 볼수있게하는 것이다. 안그래도 지금 GitButler 깔았는데 remote 사용을 지원안해서 난감해졌다.

0
0
0
Jaeyeol Lee @kodingwarrior@hackers.pub
Public

블로그에 글 쓸만한게 생각나서 브레인스토밍 중인데, CLI 도구 중에 출력을 csv, yaml, json으로 내뱉는게 어떤거 어떤거 있을까요?

Ruby로 one-liner 스크립트 작성하고, CLI 도구 조합해서 나만의 요술봉 만드는 가이드 작성할것입니다요

0
1
0
0
0
0
Lionhairdino @lionhairdino@mastodon.social
Public

오버라이딩 을 재정의라 번역하는데, 왜 "(덮을 복)정의"라 안했을까? (물론 나도 어색하다) 재정의는 뭔가 기존 것을 치워버리고, 다시 정의하는 것이고, 오버라이딩은 기존 것을 그대로 두고, 그 위에 레이어를 두는 느낌이라 같은 듯 다르다.

만일 복정의라 번역한다면, 오버로딩을 중(거듭 복) 정의라 하는데, 이 것과 같은 글자를 쓰는 문제가 생길 수 있겠다.

재정의, 중복 정의는 나도 번역이 마음에 들긴 한데, 늘 재정의가 살짝 걸리적 거린다.

닉스 공부하며 노트하다가 비슷한 듯 다른 오버레이, 오버라이딩의 적당한 번역어가 떠오르지 않아 잡생각으로 빠졌다.

널리 알려진 적당한 짧은 번역 단어(보통 한자 한 두 글자)가 없으면, 그냥 원문이 낫지 않을까? 표기만 Overlay가 아니라 오버레이로.

0
0
0
Lionhairdino @lionhairdino@mastodon.social
Public

오버라이딩 을 재정의라 번역하는데, 왜 "(덮을 복)정의"라 안했을까? (물론 나도 어색하다) 재정의는 뭔가 기존 것을 치워버리고, 다시 정의하는 것이고, 오버라이딩은 기존 것을 그대로 두고, 그 위에 레이어를 두는 느낌이라 같은 듯 다르다.

만일 복정의라 번역한다면, 오버로딩을 중(거듭 복) 정의라 하는데, 이 것과 같은 글자를 쓰는 문제가 생길 수 있겠다.

재정의, 중복 정의는 나도 번역이 마음에 들긴 한데, 늘 재정의가 살짝 걸리적 거린다.

닉스 공부하며 노트하다가 비슷한 듯 다른 오버레이, 오버라이딩의 적당한 번역어가 떠오르지 않아 잡생각으로 빠졌다.

널리 알려진 적당한 짧은 번역 단어(보통 한자 한 두 글자)가 없으면, 그냥 원문이 낫지 않을까? 표기만 Overlay가 아니라 오버레이로.

0
0
0
Lionhairdino @lionhairdino@mastodon.social
Public
Shared by 洪 民憙 (Hong Minhee)

오버라이딩 을 재정의라 번역하는데, 왜 "(덮을 복)정의"라 안했을까? (물론 나도 어색하다) 재정의는 뭔가 기존 것을 치워버리고, 다시 정의하는 것이고, 오버라이딩은 기존 것을 그대로 두고, 그 위에 레이어를 두는 느낌이라 같은 듯 다르다.

만일 복정의라 번역한다면, 오버로딩을 중(거듭 복) 정의라 하는데, 이 것과 같은 글자를 쓰는 문제가 생길 수 있겠다.

재정의, 중복 정의는 나도 번역이 마음에 들긴 한데, 늘 재정의가 살짝 걸리적 거린다.

닉스 공부하며 노트하다가 비슷한 듯 다른 오버레이, 오버라이딩의 적당한 번역어가 떠오르지 않아 잡생각으로 빠졌다.

널리 알려진 적당한 짧은 번역 단어(보통 한자 한 두 글자)가 없으면, 그냥 원문이 낫지 않을까? 표기만 Overlay가 아니라 오버레이로.

0
2
0
0
1
0
0
1
0
0
0
0
Juntai Park @arkjun@hackers.pub
Quiet public

Hackers' Pub 에서 좋아요 느낌을 표현하고 싶을 때

  • 공유 혹은 댓글을 다는 방법이 있겠고
  • 그냥 지나치기는 아쉬워서
  • (우선은) 공유를 하고 있기는 한데,

잘하고 있는건가 싶은 생각이 들 때도 있다.

개인적으로 공유는 팔로워들에게 공유하고 싶을 때 쓰고 싶은 기능인데… 최근에 다소 남발하게 된다.[1]

서로 멘션 주고 받다가, 답글 마지막에 좋아요 하트 느낌으로 마무리 짓고 싶은 마음 뿜뿜할 때에도, 그냥 아무말 안하고 마무리 하기도 하고. (이모티콘 댓글 정도를 남긴다거나 하는 방법은 있음)

@hongminhee洪 民憙 (Hong Minhee) 님이 이모티콘 좋아요 기능을 고민중이라 하시니, 그때까지는 좀 더 공유 기능을 남발해 보는 걸로. 😂

결론 : 이 글은 무차별 공유에 대한 자기 합리화를 위한 글이었던 것입니다. 😅

  1. 좋아요 느낌의 표현으로도 병행해서 사용하고 있으므로 ↩︎

0
1
0
Juntai Park @arkjun@hackers.pub
Quiet public
Shared by 洪 民憙 (Hong Minhee)

Hackers' Pub 에서 좋아요 느낌을 표현하고 싶을 때

  • 공유 혹은 댓글을 다는 방법이 있겠고
  • 그냥 지나치기는 아쉬워서
  • (우선은) 공유를 하고 있기는 한데,

잘하고 있는건가 싶은 생각이 들 때도 있다.

개인적으로 공유는 팔로워들에게 공유하고 싶을 때 쓰고 싶은 기능인데… 최근에 다소 남발하게 된다.[1]

서로 멘션 주고 받다가, 답글 마지막에 좋아요 하트 느낌으로 마무리 짓고 싶은 마음 뿜뿜할 때에도, 그냥 아무말 안하고 마무리 하기도 하고. (이모티콘 댓글 정도를 남긴다거나 하는 방법은 있음)

@hongminhee洪 民憙 (Hong Minhee) 님이 이모티콘 좋아요 기능을 고민중이라 하시니, 그때까지는 좀 더 공유 기능을 남발해 보는 걸로. 😂

결론 : 이 글은 무차별 공유에 대한 자기 합리화를 위한 글이었던 것입니다. 😅

  1. 좋아요 느낌의 표현으로도 병행해서 사용하고 있으므로 ↩︎

0
0
0
0
1
0
0
0
0
0
0
0
Jaeyeol Lee @kodingwarrior@hackers.pub
Public

Vim/Neovim의 시대가 가고, Vibe Coding 내지는 LLM 에이전트의 도움을 얻는 시대가 왔다지만, 난 아직까지는 전적으로 동의하지는 않음(부분적으로는 동의한다는 의미) 아직까지는 수제로 직접 코드를 짜는 것도 의미가 있고, CLI 기반의 에디터도 저마다의 발전을 하고 있다고 자신있게 말할 수 있음.

내가 생각하는 요오즘 시대 개발의 장점도 언급하면서 CLI 기반의 에디터는 어떤 위치에 있는지도 얘기해보고자 한다.

  1. 신뢰구간이 넓지 않아도 되는 작업을 할때는 AI를 사용하는 코드가 분명 시간을 확 줄여주고 결과적으로 생산성을 향상시키는 경향은 있지만, "정확함"을 위해서 프롬프트를 넣어야 하는데 그 프롬프트를 넣는 작업이 품이 많이 들때(넣어야 하는 맥락이 너무 많을때) 그렇게 정확하지는 않을뿐더러 맥락을 넣는 시간 때문에 차라리 내가 직접 짜는게 나을때가 많음. 수제로 직접 짜기 vs AI한테 전적으로 맡겨버리기 두 세계를 적절하게 오가면서 작업하는게 베스트이지 않나 싶음.

  2. GUI 에디터 특유의 장점도 분명 있긴 있다. GUI 에디터가 올인원 기능을 갖추고 있는 경우도 많고 편의성 면에서 미니멀리즘을 추구하는 CLI 기반의 에디터보다 가진 기능이 많다. 남이 차려준 밥상이 그렇게 달달하지 않을 수 없다. 하지만, 그런 기능들을 제공하는 플러그인이나 자체 기능들의 내부 구현을 막상 까보면 CLI 도구에 의존하는 기능들이 많다. 특히, LSP/린터/포매터가 그렇다. 다만 추상화레이어를 어떻게 감쌌느냐 정도의 차이가 있는데, 그 추상화레이어를 커스터마이징하는데 있어서의 진입장벽은 CLI 기반의 에디터가 상대적으로 낮은 편이다. 왜냐면, 인고의 시간을 거쳐서 해온게 딱 그거라서(.....)

  3. 바이브 코딩은 분명 압도적인 속도로 코드가 짜여질 수 있게 하고, 단위시간당 코드가 짜여지는 양 자체도 어마어마하다. 특히, scaffolding을 할때 더더욱 빛을 발휘한다. 그렇기 때문에, 코드를 짜는건 기계/인공지능에 위임하고, 자세한 디테일을 채우는건 유저리서치를 하거나 와이어프레임을 그려서 기획을 더 보강하는 등 중요한 영역에 집중할 수 있게 된다. 코드를 짜는데 드는 시간은 최소한으로, 중요한 영역에 집중하기 위해 생각하는 시간을 더 많이 가지는 것은 분명 좋은 일이다. 관련해서는 이 글도 읽어보면 좋을 것 같다. https://two-wrongs.com/typing-fast-is-about-latency-not-throughput

물론, 코드를 짜는데 있어서 중요한 것은 리터러시이다. LLM이 코드베이스의 이해를 빠르게 할 수 있도록 도와주긴 하지만, 위에서 언급했듯 어느 정도 시점이 되면 결국엔 직접 짜고 직접 수정하는 일도 있어야 한다. 로컬 LLM이 발전한다 하더라도, LLM을 사용할 여력이 되지 않는 환경에서도 동일한 생산성을 유지할 수 있을까? 생산성이 일관적이지 않다면, 그렇지 않은 환경에 노출이 되었을때 어떻게 대응할 수 있을지가 중요한 포인트일 수 있다고 생각한다. 인자강, 즉, 사람 자체가 강해질 필요가 있다고 생각한다.

인공지능에 전적으로 의존하지 않고 수제로 직접 코드를 짜는 사람들이 기계/인공지능에 저항해서 어떻게 살아남을까를 생각해보면 인간공학에 기반해서 편집하는 테크닉이 더 연구될 필요가 있다.

GUI 기반의 에디터가 날이 갈수록 좋아지고 있는 상황 속에서 CLI 기반의 에디터가 살아남으려면 더더욱 CLI 기반의 도구와 궁합이 좋은 것을 내세워서 차별점을 내세울 필요가 있다. Neovim은 그런 관점에서 IDE와 유사한 경험을 제공하는 쪽으로 잘 발전되어 왔다고 보고 있다.

Vim/Neovim 생태계는 아직까지는 미래가 낙관적이라고 본다.

Typing Fast Is About Latency, Not Throughput

entropicthoughts.com

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

@kodingwarriorJaeyeol Lee 저는 VS Code를 오래 써서, Cursor든 Windsurf든 VS Code 포크들은 아무 비용없이 갈아탈수 있었는데요. 사실 저런 툴들의 진짜 강점은 API 요금제인거 같습니다. Claude Code 붙여서 종량제로 쓰면 그게 제일 퍼포먼스 좋겠지만 돈이 계속 나간다는게 상당한 압박인데, Windsurf 한달에 15달러 내면 그냥 채팅용으로도 쓸수있고, 개발자 입장에서 단 한개의 AI 구독이 되는게 가능해요. 그러니까 에디터 자체는 별로 안중요하고 그 뒤에 묶여있는 AI 상품이 매력적인 거죠.

Aider같은 걸로 비슷한 요금제를 구현하는게 가능할지 모르겠네요. 또는 로컬 LLM 성능이 궤도에 오르면 그때 또 많이 달라질거라 봅니다.

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

참고로 Hackers' Pub은 딱 한 번 뿐이긴 하지만 핸들을 바꿀 수 있답니다.

사실 ActivityPub이나 WebFinger 명세에서는 핸들을 바꿀 수 없다는 제약이 있지는 않아요. 다만 대부분의 ActivityPub 구현들이 액터 ID에 핸들의 일부를 포함시키기 때문에 바꿀 수 없게 되었을 뿐…[1]

자세한 설명은 Fedify 문서의 Actor identifier and WebFinger username 항목을 읽어보시면 됩니다.

  1. Misskey는 안 그렇기 때문에 기술적으로 나중에 핸들 변경 기능을 추가하려면 추가할 수 있긴 합니다. ↩︎



RE: https://serafuku.moe/notes/a6199pgz4v

0
0
0
0
1
0

洪 民憙 (Hong Minhee) shared the below article:

hoonie-blog v1.1.1 등장!

카미유 @renegade_v00@hackers.pub

개선된 기술 블로그 1.1.1 버전이 공개되었습니다. 이번 업데이트에서는 사용자 경험을 향상시키기 위한 다양한 개선 사항들이 적용되었습니다. 특히, 사이트 성능 최적화를 통해 로딩 속도를 개선하고, 반응형 디자인을 강화하여 다양한 기기에서 일관된 사용자 인터페이스를 제공합니다. 또한, 새로운 기능들을 추가하여 블로그 탐색 및 콘텐츠 접근성을 높였습니다. 이번 업데이트는 마치 게임 패치노트처럼 작성되어, 개발 과정과 변경 사항을 더욱 재미있게 확인할 수 있습니다. 블로그를 방문하여 새로운 기능들을 직접 경험하고, 개선된 사용성을 느껴보세요.

Read more →
0
0
0
洪 民憙 (Hong Minhee) :nonbinary: @hongminhee@hollo.social
Public

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 !

Highlighting journalism on Mastodon

Today we're launching a new feature that will highlight writers and journalists that are active on the fediverse when their articles are being shared.

blog.joinmastodon.org · Mastodon Blog

Link author: Eugen Rochko@Gargron@mastodon.social

Julian Fietkau @julian@fietkau.social
Quiet public
Shared by 洪 民憙 (Hong Minhee)

@hongminhee洪 民憙 (Hong Minhee) :nonbinary: @MastodonEngineering I did a little bit of digging. The tag is read here and stored unchanged for later processing: github.com/mastodon/mastodon/b

It is then passed to the account resolver, still as an unchanged string: github.com/mastodon/mastodon/b

The account resolver calls its internal function "process_options" to parse the string, which is supposed to strip the leading "@" here: github.com/mastodon/mastodon/b

So it's correct that both variants should work the same. I wonder what's going wrong.

Your self-hosted, globally interconnected microblogging community - mastodon/mastodon

mastodon/app/lib/link_details_extractor.rb at b4e56822c72db54ba338940e2517a4e25e2159a6 · mastodon/mastodon

Your self-hosted, globally interconnected microblogging community - mastodon/mastodon

github.com · GitHub

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

참고로 Hackers' Pub은 딱 한 번 뿐이긴 하지만 핸들을 바꿀 수 있답니다.

사실 ActivityPub이나 WebFinger 명세에서는 핸들을 바꿀 수 없다는 제약이 있지는 않아요. 다만 대부분의 ActivityPub 구현들이 액터 ID에 핸들의 일부를 포함시키기 때문에 바꿀 수 없게 되었을 뿐…[1]

자세한 설명은 Fedify 문서의 Actor identifier and WebFinger username 항목을 읽어보시면 됩니다.

  1. Misskey는 안 그렇기 때문에 기술적으로 나중에 핸들 변경 기능을 추가하려면 추가할 수 있긴 합니다. ↩︎



RE: https://serafuku.moe/notes/a6199pgz4v

0
0
0
Jaeyeol Lee @kodingwarrior@hackers.pub
Public
Shared by 洪 民憙 (Hong Minhee)

Vim/Neovim의 시대가 가고, Vibe Coding 내지는 LLM 에이전트의 도움을 얻는 시대가 왔다지만, 난 아직까지는 전적으로 동의하지는 않음(부분적으로는 동의한다는 의미) 아직까지는 수제로 직접 코드를 짜는 것도 의미가 있고, CLI 기반의 에디터도 저마다의 발전을 하고 있다고 자신있게 말할 수 있음.

내가 생각하는 요오즘 시대 개발의 장점도 언급하면서 CLI 기반의 에디터는 어떤 위치에 있는지도 얘기해보고자 한다.

  1. 신뢰구간이 넓지 않아도 되는 작업을 할때는 AI를 사용하는 코드가 분명 시간을 확 줄여주고 결과적으로 생산성을 향상시키는 경향은 있지만, "정확함"을 위해서 프롬프트를 넣어야 하는데 그 프롬프트를 넣는 작업이 품이 많이 들때(넣어야 하는 맥락이 너무 많을때) 그렇게 정확하지는 않을뿐더러 맥락을 넣는 시간 때문에 차라리 내가 직접 짜는게 나을때가 많음. 수제로 직접 짜기 vs AI한테 전적으로 맡겨버리기 두 세계를 적절하게 오가면서 작업하는게 베스트이지 않나 싶음.

  2. GUI 에디터 특유의 장점도 분명 있긴 있다. GUI 에디터가 올인원 기능을 갖추고 있는 경우도 많고 편의성 면에서 미니멀리즘을 추구하는 CLI 기반의 에디터보다 가진 기능이 많다. 남이 차려준 밥상이 그렇게 달달하지 않을 수 없다. 하지만, 그런 기능들을 제공하는 플러그인이나 자체 기능들의 내부 구현을 막상 까보면 CLI 도구에 의존하는 기능들이 많다. 특히, LSP/린터/포매터가 그렇다. 다만 추상화레이어를 어떻게 감쌌느냐 정도의 차이가 있는데, 그 추상화레이어를 커스터마이징하는데 있어서의 진입장벽은 CLI 기반의 에디터가 상대적으로 낮은 편이다. 왜냐면, 인고의 시간을 거쳐서 해온게 딱 그거라서(.....)

  3. 바이브 코딩은 분명 압도적인 속도로 코드가 짜여질 수 있게 하고, 단위시간당 코드가 짜여지는 양 자체도 어마어마하다. 특히, scaffolding을 할때 더더욱 빛을 발휘한다. 그렇기 때문에, 코드를 짜는건 기계/인공지능에 위임하고, 자세한 디테일을 채우는건 유저리서치를 하거나 와이어프레임을 그려서 기획을 더 보강하는 등 중요한 영역에 집중할 수 있게 된다. 코드를 짜는데 드는 시간은 최소한으로, 중요한 영역에 집중하기 위해 생각하는 시간을 더 많이 가지는 것은 분명 좋은 일이다. 관련해서는 이 글도 읽어보면 좋을 것 같다. https://two-wrongs.com/typing-fast-is-about-latency-not-throughput

물론, 코드를 짜는데 있어서 중요한 것은 리터러시이다. LLM이 코드베이스의 이해를 빠르게 할 수 있도록 도와주긴 하지만, 위에서 언급했듯 어느 정도 시점이 되면 결국엔 직접 짜고 직접 수정하는 일도 있어야 한다. 로컬 LLM이 발전한다 하더라도, LLM을 사용할 여력이 되지 않는 환경에서도 동일한 생산성을 유지할 수 있을까? 생산성이 일관적이지 않다면, 그렇지 않은 환경에 노출이 되었을때 어떻게 대응할 수 있을지가 중요한 포인트일 수 있다고 생각한다. 인자강, 즉, 사람 자체가 강해질 필요가 있다고 생각한다.

인공지능에 전적으로 의존하지 않고 수제로 직접 코드를 짜는 사람들이 기계/인공지능에 저항해서 어떻게 살아남을까를 생각해보면 인간공학에 기반해서 편집하는 테크닉이 더 연구될 필요가 있다.

GUI 기반의 에디터가 날이 갈수록 좋아지고 있는 상황 속에서 CLI 기반의 에디터가 살아남으려면 더더욱 CLI 기반의 도구와 궁합이 좋은 것을 내세워서 차별점을 내세울 필요가 있다. Neovim은 그런 관점에서 IDE와 유사한 경험을 제공하는 쪽으로 잘 발전되어 왔다고 보고 있다.

Vim/Neovim 생태계는 아직까지는 미래가 낙관적이라고 본다.

Typing Fast Is About Latency, Not Throughput

entropicthoughts.com

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

요즘 주의 깊게 보고 있는 두 언어:

  • Gleam: Erlang의 OTP 런타임에서 돌아간다는 점에서 Elixir와 비슷한데, 처음부터 정적 타입 언어로 설계되었다. 아, JavaScript 타깃도 지원한다. Haskell의 타입클래스(typeclass)나 Rust의 트레이트(trait)에 해당하는 기능이 없다는 게 개인적으로는 조금 아쉬운 점.

  • MoonBit: 중국 쪽에서 주도해서 만들고 있는 WebAssembly 타깃 언어로, 이지 모드 Rust에 가까워 보인다. 다만 개발 과정이 완전히 오픈 소스는 아니고, (오픈 소스 라이선스이긴 하지만) 소스만 공개하는 형태라 거버넌스 측면에서 아쉬움이 있다.

Gleam Language

The Gleam programming language

gleam.run

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

요즘 주의 깊게 보고 있는 두 언어:

  • Gleam: Erlang의 OTP 런타임에서 돌아간다는 점에서 Elixir와 비슷한데, 처음부터 정적 타입 언어로 설계되었다. 아, JavaScript 타깃도 지원한다. Haskell의 타입클래스(typeclass)나 Rust의 트레이트(trait)에 해당하는 기능이 없다는 게 개인적으로는 조금 아쉬운 점.

  • MoonBit: 중국 쪽에서 주도해서 만들고 있는 WebAssembly 타깃 언어로, 이지 모드 Rust에 가까워 보인다. 다만 개발 과정이 완전히 오픈 소스는 아니고, (오픈 소스 라이선스이긴 하지만) 소스만 공개하는 형태라 거버넌스 측면에서 아쉬움이 있다.

Gleam Language

The Gleam programming language

gleam.run

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

📢 Haskell 생태계에서 안정성이란 무엇일까요?

Haskell 재단의 안정성 작업 그룹(SWG)이 생태계의 변화를 효과적으로 관리하기 위해 어떤 노력을 기울이고 있는지 소개합니다. GHC 언어 확장 분류, 컴파일러 안정성 기능 개선, 커뮤니티 소통 촉진 등 우리가 진행한 작업과 앞으로 나아갈 방향에 대해 이야기합니다. 함께 Haskell 생태계를 더 강하게 만들어가요! 💪🚀

🔗 자세히 보기

Introducing the Haskell Foundation Stability Working Group | The Haskell Programming Language's blog

blog.haskell.org · The Haskell Programming Language's blog

박준규 @curry@hackers.pub
Public
Shared by 洪 民憙 (Hong Minhee)

ChatGPT에게 링크 주고 요약문 작성을 부탁했다. SNS에 공유할 거라고 했더니 이모지도 막 달아주네⋯ 글쓴이는 하스켈 안정성 작업 그룹(SWG) 의장인 테일러 님인데 학부 때 과목에도 없는 하스켈 쓰다가 교수님이 “너 그런 거 쓰면 취업 못한다.”라고 했다고⋯

About

About Howdy! My name is Taylor Fausak. I am a software developer living in Texas. The best way to reach me is by sending an email to taylor@fausak.me. Projects These are things that I have worked o...

taylor.fausak.me · taylor.fausak.me

0
1
1
박준규 @curry@hackers.pub
Public
Shared by 洪 民憙 (Hong Minhee)

📢 Haskell 생태계에서 안정성이란 무엇일까요?

Haskell 재단의 안정성 작업 그룹(SWG)이 생태계의 변화를 효과적으로 관리하기 위해 어떤 노력을 기울이고 있는지 소개합니다. GHC 언어 확장 분류, 컴파일러 안정성 기능 개선, 커뮤니티 소통 촉진 등 우리가 진행한 작업과 앞으로 나아갈 방향에 대해 이야기합니다. 함께 Haskell 생태계를 더 강하게 만들어가요! 💪🚀

🔗 자세히 보기

Introducing the Haskell Foundation Stability Working Group | The Haskell Programming Language's blog

blog.haskell.org · The Haskell Programming Language's blog

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

많은 분들이 인용 방법을 혼란스러워 하셔서, 인용 버튼을 추가했습니다. 게시글이나 단문 아래의 아이콘들 중에 왼쪽에서 세 번째 아이콘을 누르시면 해당 콘텐츠를 인용한 글들이 나열되고, 그 위에 인용 글 입력란이 뜨게 됩니다. 거기서 인용 글을 쓸 수 있습니다. 아, 종래의 인용 UI도 그대로 사용하실 수 있습니다.

참고로 인용 아이콘은 @xtjuxtapose 님께서 수고해 주셨습니다. 감사합니다.



RE: https://hackers.pub/@xt/0195eb06-9f50-763d-85c8-5600ec78c539

Hackers' Pub의 게시글이나 단문 아래에 표시되는 아이콘들. 인용 버튼이 강조되어 있다.
0
0
2
Jaeyeol Lee @kodingwarrior@hackers.pub
Public

vim.kr 디스코드에도 물어보긴 했는데, 해커스펍에도 공개적으로 물어봅니다.

Git 관련 유틸리티 중에 이런거 없을까요?

개발된 기능들은 어지간하면 싹 다 Staging 브랜치에 합쳐서 개발망에 배포중인데, 개발망에 배포된 기능/버그픽스 중에 몇개 컨펌된 것만 프로덕션에 배포하고 싶어요. 커밋을 가능하면 잘게 쪼개서 하는 편이긴 한데, 컨펌된 것만 한땀한땀 골라서 체리픽하다보니까 관리하는게 여간 귀찮은게 아니네요. 오죽하면 스프레드시트로 관리할 정도입니다 -_-;;;

커밋 중 몇개는 서로 독립적이긴 한데, 몇개는 비엔나소세지마냥 줄줄이 의존성이 엮여있어요. 줄줄이 의존성이 엮여있긴해도, 가만히 보면 A기능 / B기능 잘개 쪼개져있긴 해서, 그걸 좀 더 보기좋게 시각화하고 싶어요. staging 브랜치에 PR 머지할때도 일부러 Squash and merge로 머지합니다.

한줄 요약

  • 의도적으로 커밋 간의 연결관계를 디펜던시 그래프 형태로 가시화할 수 있는 Git 유틸리티 추천받습니다.

main page

next.vim.kr · vim.kr

0
0
0
박준규 @curry@hackers.pub
Public
Shared by 洪 民憙 (Hong Minhee)

ChatGPT 덕분에 우연히 하찮은 버그 하나를 발견했다.

ChatGPT에게 소스 코드 보여주고 주석으로 문서 작성을 부탁했는데 다음과 같이 알아서 파이썬 doctest와 같은 코드를 출력했다.

>>> prefixLength "key=value"
3
>>> prefixLength "a=b"
1
>>> prefixLength "noequals"
8

이 함수는 입력 문자열에서 ‘=’ 왼쪽에 있는 문자열의 길이를 리턴한다. 그런데 ‘=’가 없을 경우는 미처 생각을 못했는데 ChatGPT가 출력한 코드를 보고 그 사실을 깨달았다.

덕분에 코드 패치하고 난생 처음 메이저 업데이트라는 것도 해본다.(원래 리턴 타입이 Int였는데 Maybe Int로 바꿔서 브레이킹 체인지가 되었다.)

https://hackage.haskell.org/package/align-equal-0.1.1.1/docs/Data-Text-AlignEqual.html

Data.Text.AlignEqual

DescriptionA module providing functions for text alignment and padding.

hackage.haskell.org

0
0
1

洪 民憙 (Hong Minhee) replied to the below article:

Hello, World!

clastneo @clastneo@hackers.pub

이 글은 프로그래밍을 처음 접하는 사람들을 위한 "Hello, World!" 프로그램의 중요성을 설명합니다. 간단한 코드를 통해 프로그래밍 언어의 기본 문법과 개발 환경 설정 방법을 익힐 수 있으며, 이는 프로그래밍 학습의 첫걸음이 됩니다. "Hello, World!"는 단순한 시작이지만, 컴퓨터와 소통하고 문제를 해결하는 프로그래밍 여정의 문을 여는 열쇠와 같습니다. 이 글을 통해 독자들은 프로그래밍의 기초를 다지고 더 복잡한 코딩 세계로 나아갈 자신감을 얻을 수 있을 것입니다.

Read more →
0
0
0
0
1
0
Jaeyeol Lee @kodingwarrior@hackers.pub
Public

vim.kr 디스코드에도 물어보긴 했는데, 해커스펍에도 공개적으로 물어봅니다.

Git 관련 유틸리티 중에 이런거 없을까요?

개발된 기능들은 어지간하면 싹 다 Staging 브랜치에 합쳐서 개발망에 배포중인데, 개발망에 배포된 기능/버그픽스 중에 몇개 컨펌된 것만 프로덕션에 배포하고 싶어요. 커밋을 가능하면 잘게 쪼개서 하는 편이긴 한데, 컨펌된 것만 한땀한땀 골라서 체리픽하다보니까 관리하는게 여간 귀찮은게 아니네요. 오죽하면 스프레드시트로 관리할 정도입니다 -_-;;;

커밋 중 몇개는 서로 독립적이긴 한데, 몇개는 비엔나소세지마냥 줄줄이 의존성이 엮여있어요. 줄줄이 의존성이 엮여있긴해도, 가만히 보면 A기능 / B기능 잘개 쪼개져있긴 해서, 그걸 좀 더 보기좋게 시각화하고 싶어요. staging 브랜치에 PR 머지할때도 일부러 Squash and merge로 머지합니다.

한줄 요약

  • 의도적으로 커밋 간의 연결관계를 디펜던시 그래프 형태로 가시화할 수 있는 Git 유틸리티 추천받습니다.

main page

next.vim.kr · vim.kr

0
0
0
Jaeyeol Lee @kodingwarrior@hackers.pub
Public
Shared by 洪 民憙 (Hong Minhee)

vim.kr 디스코드에도 물어보긴 했는데, 해커스펍에도 공개적으로 물어봅니다.

Git 관련 유틸리티 중에 이런거 없을까요?

개발된 기능들은 어지간하면 싹 다 Staging 브랜치에 합쳐서 개발망에 배포중인데, 개발망에 배포된 기능/버그픽스 중에 몇개 컨펌된 것만 프로덕션에 배포하고 싶어요. 커밋을 가능하면 잘게 쪼개서 하는 편이긴 한데, 컨펌된 것만 한땀한땀 골라서 체리픽하다보니까 관리하는게 여간 귀찮은게 아니네요. 오죽하면 스프레드시트로 관리할 정도입니다 -_-;;;

커밋 중 몇개는 서로 독립적이긴 한데, 몇개는 비엔나소세지마냥 줄줄이 의존성이 엮여있어요. 줄줄이 의존성이 엮여있긴해도, 가만히 보면 A기능 / B기능 잘개 쪼개져있긴 해서, 그걸 좀 더 보기좋게 시각화하고 싶어요. staging 브랜치에 PR 머지할때도 일부러 Squash and merge로 머지합니다.

한줄 요약

  • 의도적으로 커밋 간의 연결관계를 디펜던시 그래프 형태로 가시화할 수 있는 Git 유틸리티 추천받습니다.

main page

next.vim.kr · vim.kr

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