Profile img

bgl gwyng

@bgl@hackers.pub · 93 following · 117 followers

GitHub
@bglgwyng
0

Gemini Pro 2.5 엄청 똑똑하다... 기존 모델들은 대화가 길어지고 내용이 깊어지면 그냥 뻔한소리를 반복하기 시작하던데, 얘는 계속 생각해서 아이디어를 살려준다.

0
0
0
0
0
1
0

설치형으로 블로그 만들어서 가꾸고, 메일 서버도 직접 띄워서 쓰고 이런 개발자들보면 왠지모를 호감이 간다. 근데 막상 나는 저런거 귀찮아서 절대 안하고 맨날 공짜만 찾아다닌다.

0

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

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

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

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

---

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

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

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

1
0
0
0
0
0
0
0

해키지(Hackage)[1]에 패키지를 업로드하면 자동으로 빌드, 문서 생성, 테스트가 진행된다. 그런데 이게 시간이 좀 걸린다.(체감상 10분 정도) 이 과정이 자동으로 완료되기 전에 참지 못하고 수동으로 문서를 업로드하면 자동으로 진행되던 것들이 모두 중단된다. https://github.com/haskell/hackage-server/issues/1376


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

0

bgl gwyng shared the below article:

닉스의 derivation 생성식과 derivation의 차이

lionhairdino @lionhairdino@hackers.pub

이 글은 Nix를 처음 접하는 사람들을 위해 `derivation` 개념을 명확히 하고자 합니다. Nix에서 `derivation`은 패키지 빌드를 위한 명세서로 간단히 설명되지만, 실제로는 `derivation 생성식`과 `derivation 객체`를 구별하는 것이 중요합니다. Nixpkgs는 `derivation` 자체가 아닌 `derivation 생성식(.nix)`들의 모음이며, 이 생성식을 평가해야 `derivation`이 만들어집니다. `.drv` 파일은 평가 결과를 캐싱한 파일입니다. 저자는 Nix가 의존성들을 `derivation 생성식`들의 관계로 표현하고, 최종적으로 하나의 생성식이 하나의 패키지를 표현한다는 점을 강조합니다. 흔히 `derivation`이라 부르는 것은 런타임에 메모리에 올라온 `derivation 데이터 타입` 객체이며, 이는 `derivation 생성식`을 평가한 결과입니다. 이러한 구분을 통해 Nix 코드를 함수형 관점에서 더 명확하게 이해할 수 있다고 주장합니다. Nix의 `derivation` 개념을 더 깊이 이해하고 싶다면 이 글이 좋은 출발점이 될 것입니다.

Read more →
0
0
0
0

조던 엘렌버그라는 수학자가 쓴 '틀리지 않는 법'이란 책이 있는데, 재밌고 읽어볼만하다.

그 책에서 컴퓨터가 수학자가 하던일을 할수 있게되면 어떡하냐에 대해 저자의 해결책을 제시하는데 원래 하던일을 컴퓨터한테 맡기고 수학자들은 더 고차원적인 일을 하면 된다고 한다. 한 10년 전에 읽었을때도 그냥 대책없고 나이브한 생각으로 보였다. 근데 요즘은 (실제로 어떻게 될지랑은 상관없이) 저런 나이브한 마음가짐을 일부러라도 가지고 일해야 뭐라도 해낼듯.

0
0
0
0

@bglbgl gwyng 네 직접 논리를 정의해서 쓰시면 할 수 있습니다. 수업에서는 뮤텍스 프로토콜 검증을 위한 증명을 했었고요. GitHub나 논문 발표 선에서 동시성이나 암호화 관련 증명하는데 가끔 보이는 것 같습니다. 저도 인터랙션 플로우를 상상하며 정의할 때 엣지케이스를 미리 시뮬레이션(물론 현실은 쉽지 않음) 해 보는데 활용합니다.

0

@bglbgl gwyng 네 직접 논리를 정의해서 쓰시면 할 수 있습니다. 수업에서는 뮤텍스 프로토콜 검증을 위한 증명을 했었고요. GitHub나 논문 발표 선에서 동시성이나 암호화 관련 증명하는데 가끔 보이는 것 같습니다. 저도 인터랙션 플로우를 상상하며 정의할 때 엣지케이스를 미리 시뮬레이션(물론 현실은 쉽지 않음) 해 보는데 활용합니다.

0
0
0

실용적인 프로그램을 만들 수는 없겠지만, Maude와 같은 정형 명세 언어도 재미있습니다. 저는 실제 코드를 쓰기 전에 데이터 흐름을 정리하고 추상화 하여 스펙을 명확히 하는데 사용합니다. 단점은 GitHub에서 무슨 언어인지 몰라서 통계가 안 잡힙니다.

0

bgl gwyng replied to the below article:

셸 언어는 때로 추하길 요구 받는다

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

이 글에서는 명령줄 인터페이스(CLI)를 지배하는 셸 언어의 독특한 설계 철학을 탐구하며, 셸 언어가 왜 때로는 "추함"을 받아들여야 하는지에 대한 이유를 설명합니다. Bash와 PowerShell을 비교하며, PowerShell이 가독성을 높이기 위해 장황해진 반면, Bash는 간결함을 유지하여 빠른 상호작용에 더 적합함을 지적합니다. 현대적인 셸인 Nushell이 이 균형을 맞추기 위해 노력하는 점을 언급하며, 셸 언어의 성공은 "아름다운 코드"와 "효율적인 상호작용" 사이의 균형에 달려 있음을 강조합니다. 마지막으로, 모든 도구는 사용 맥락에 맞게 설계되어야 한다는 더 넓은 소프트웨어 설계 원칙을 제시하며, 셸 언어의 맥락은 키보드와 사용자 사이의 빠른 대화임을 강조합니다. 이 글은 셸 언어 설계에 대한 흥미로운 통찰력을 제공하며, 소프트웨어 설계 시 맥락의 중요성을 일깨워 줍니다.

Read more →
0
0
0
0

실용적인 프로그램을 만들 수는 없겠지만, Maude와 같은 정형 명세 언어도 재미있습니다. 저는 실제 코드를 쓰기 전에 데이터 흐름을 정리하고 추상화 하여 스펙을 명확히 하는데 사용합니다. 단점은 GitHub에서 무슨 언어인지 몰라서 통계가 안 잡힙니다.

0

bgl gwyng shared the below article:

셸 언어는 때로 추하길 요구 받는다

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

이 글에서는 명령줄 인터페이스(CLI)를 지배하는 셸 언어의 독특한 설계 철학을 탐구하며, 셸 언어가 왜 때로는 "추함"을 받아들여야 하는지에 대한 이유를 설명합니다. Bash와 PowerShell을 비교하며, PowerShell이 가독성을 높이기 위해 장황해진 반면, Bash는 간결함을 유지하여 빠른 상호작용에 더 적합함을 지적합니다. 현대적인 셸인 Nushell이 이 균형을 맞추기 위해 노력하는 점을 언급하며, 셸 언어의 성공은 "아름다운 코드"와 "효율적인 상호작용" 사이의 균형에 달려 있음을 강조합니다. 마지막으로, 모든 도구는 사용 맥락에 맞게 설계되어야 한다는 더 넓은 소프트웨어 설계 원칙을 제시하며, 셸 언어의 맥락은 키보드와 사용자 사이의 빠른 대화임을 강조합니다. 이 글은 셸 언어 설계에 대한 흥미로운 통찰력을 제공하며, 소프트웨어 설계 시 맥락의 중요성을 일깨워 줍니다.

Read more →
0
0
0
0

역시 모든 것들은 직접 데여봐야 는다... React의 useContext가 뭐하려고 쓰는지 실감이 잘 안났었는데, prop drilling하지 않고 디펜던시를 주입하고 싶을때 유용한듯.

특히, 어떤 특정한 데이터를 다루는 복잡한 컴포넌트를 다룬다고 가정하면 요렇게 프로바이더에 넘겨주면 되고 하위 컴포넌트에서는 useContext에서 그 값을 가져오면 코드도 굉장히 깔끔해지게 되는 듯

  <PostContext.Provider value={{ currentUser }}>
     <Post.Title post={post} />
     <Post.Comments>
       {comments.map(comment =>
          <Post.Comment  comment={comment} />
        )}
     </Post.Comments>
  <PostContext.Provider>

이런 글도 있다.

https://testdouble.com/insights/react-context-for-dependency-injection-not-state-management

0

Hackers' Pub에 이제 알림 기능이 생겼습니다. 우상단 프로필 사진 바로 왼쪽에 알림 아이콘이 추가되었고, 이제 읽지 않은 알림이 있을 경우 그 위에 빨간 동그라미가 표시됩니다. 알림의 종류는 현재 다음 다섯 가지입니다:

  • 누가 날 팔로했을 때
  • 누가 날 언급했을 때
  • 누가 내 글에 답글을 달았을 때
  • 누가 내 글을 인용했을 때
  • 누가 내 글을 공유했을 때
Hackers' Pub의 우상단에 표시되는 아이콘들. 왼쪽부터 새 게시글 아이콘, 읽지 않은 알림 아이콘, 프로필 사진.
0

소수의견: 프로그래밍 언어의 identifier에서 그냥 소문자만 남기고 대문자를 아예 금지시켜야한다. 그리고 하이픈이나 언더바 둘중에 하나만 허용한다. 둘다 허용하면 취향에 따라 섞어쓰게된다. 진작에 이렇게 했으면 뭐시기 case 논쟁으로 시간낭비 안 했을것이다.

그리고 남은 대문자를 identifier와 충돌할 걱정없이 자유롭게 keyword에 쓰면 된다. 내가 생각하는 멋진 응용으로는, 객체 생성에 대표적으로 쓰이는 new 대신에 A를 쓰는 것이다. x = A user, 쏘쿨하지 않습니까.

0
0

@hongminhee洪 民憙 (Hong Minhee) @curry박준규 제가 Rust 유저한테 하스켈을 영업해본적은 없지만, Rust 유저들은 하스켈을 고를수 있는 선택지에서 이미 결정을 내리고 지나온 사람들이라고 생각했거든요. HKT, 모나드? 그런거보다 포인터 직접 만지고 최적화하는게 좋아.

근데 생각해보니 Rust가 언어덕후들이 파던 언어였던것도 이미 오래전 얘기고, 이제는 하스켈 등의 옵션을 고려하지 않은채로 Rust를 써야할 환경에 놓인 사람들도 많겠다 싶네요.

0

해커스 펍에 남기는 첫 글로 진.짜. 술을 파는 해커스 펍을 소개하겠습니다… 도쿄 히가시나카노에 위치한ハッカーズバー(hackers bar)에 가시면 바텐더 분의 라이브코딩을 구경하며 블루스크린, 커널 패닉 등의 이름이 붙여진 칵테일을 마실 수 있어요… 모두가 각자의 랩탑을 들고 와서 자유롭게 코딩하고 이야기 나누는 분위기! 도쿄에서 손에 꼽게 인상적이었던 바였습니다. 도쿄에서 술도 마시고 코딩도 하고 싶으신 분들은 한 번 들러보심이~~!

긴 술 잔에 파란색 술이 담겨있다.술집 천장에 달린 세개의 모니터를 사람들이 보고 있다.
1
0
2
0

bgl gwyng shared the below article:

함수형 프로그래머한테 닉스 패키지 매니저의 derivation 소개하는 글

lionhairdino @lionhairdino@hackers.pub

이 글은 닉스의 핵심 개념인 derivation에 대해 설명합니다. Derivation은 패키지 빌드에 필요한 속성들의 집합으로, 닉스는 이를 통해 의존 관계를 순수하게 표현합니다. 패키지 A가 B에 의존한다면, A의 derivation이 B의 derivation에 의존하는 방식으로 명세서를 작성하고, 실제 패키지가 필요할 때 realize 동작을 통해 이펙트들의 영향을 받습니다. 이러한 선언적인 명세서 덕분에 닉스는 선언형 패키지 매니저라고 불립니다. Derivation 이름에 내용 기반 해시를 붙여 캐싱과 재현성을 높이지만, 작은 변화에도 해시값이 달라져 디스크 용량과 빌드 시간이 늘어나는 단점도 있습니다. Nixpkgs는 derivation 자체가 아닌, derivation을 생성하는 표현식들의 모음으로 구성됩니다.

Read more →
0
0
0

Hackers' Pub 행동 강령을 관통하는 큰 키워드가, 존중배려라고 느꼈고, 그래서 더욱 Hackers' Pub 을 응원하고 있는데, 오랜 시간이 흘러도 추구하는 가치에 흔들림이 없으면 좋겠고, 여기에 더해 긍정적이고 밝은 에너지가 가득한 공간이 되기를 소망한다.

한가지만 더 첨언하자면, 개발자의 소소한 일상 얘기들도 많이 공유되었으면 좋겠다. (우선 나부터도 해야겠지만)

0

bgl gwyng shared the below article:

deno-task-hooks: Git 훅을 Deno 태스크로 쉽게 관리하기

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

안녕하세요! 오늘은 제가 개발한 deno-task-hooks 패키지를 소개해 드리려고 합니다. 이 도구는 Deno 태스크를 Git 훅으로 사용할 수 있게 해주는 간단하면서도 유용한 패키지입니다.

어떤 문제를 해결하나요?

Git을 사용하는 개발 팀에서는 코드 품질 유지를 위해 커밋이나 푸시 전에 린트, 테스트 등의 검증 작업을 실행하는 것이 일반적입니다. 이러한 작업은 Git 훅을 통해 자동화할 수 있지만, 기존 방식에는 몇 가지 문제가 있었습니다:

  • Git 훅 스크립트를 팀원들과 공유하기 어려움 (.git 디렉토리는 보통 버전 관리에서 제외됨)
  • 각 개발자가 로컬에서 훅을 직접 설정해야 하는 번거로움
  • 훅 스크립트의 일관성 유지가 어려움

deno-task-hooks는 이러한 문제를 해결하기 위해 Deno의 태스크 러너를 활용합니다. Deno 태스크는 deno.json 파일에 정의되어 버전 관리가 가능하므로, 팀 전체가 동일한 Git 훅을 쉽게 공유할 수 있습니다.

어떻게 작동하나요?

deno-task-hooks의 작동 방식은 간단합니다:

  1. deno.json 파일에 Git 훅으로 사용할 Deno 태스크를 정의합니다.
  2. hooks:install 태스크를 실행하면, 정의된 태스크들이 자동으로 .git/hooks/ 디렉토리에 설치됩니다.
  3. 이후 Git 작업 시 해당 훅이 트리거되면 연결된 Deno 태스크가 실행됩니다.

설치 및 사용 방법

1. hooks:install 태스크 추가하기

먼저 deno.json 파일에 hooks:install 태스크를 추가합니다:

{
  "tasks": {
    "hooks:install": "deno run --allow-read=deno.json,.git/hooks/ --allow-write=.git/hooks/ jsr:@hongminhee/deno-task-hooks"
  }
}

2. Git 훅 정의하기

Git 훅은 hooks: 접두사 다음에 훅 이름(케밥 케이스)을 붙여 정의합니다. 예를 들어, pre-commit 훅을 정의하려면:

{
  "tasks": {
    "hooks:pre-commit": "deno check *.ts && deno lint"
  }
}

3. 훅 설치하기

다음 명령어를 실행하여 정의된 훅을 설치합니다:

deno task hooks:install

이제 Git 커밋을 실행할 때마다 pre-commit 훅이 자동으로 실행되어 TypeScript 파일을 검사하고 린트 검사를 수행합니다.

지원되는 Git 훅 종류

deno-task-hooks는 다음과 같은 모든 Git 훅 타입을 지원합니다:

  • applypatch-msg
  • commit-msg
  • fsmonitor-watchman
  • post-update
  • pre-applypatch
  • pre-commit
  • pre-merge-commit
  • pre-push
  • pre-rebase
  • pre-receive
  • prepare-commit-msg
  • push-to-checkout
  • sendemail-validate
  • update

이점

deno-task-hooks를 사용하면 다음과 같은 이점이 있습니다:

  1. 간편한 공유: Git 훅을 deno.json 파일에 정의하여 팀 전체가 동일한 훅을 사용할 수 있습니다.
  2. 설정 용이성: 새 팀원은 저장소를 클론한 후 한 번의 명령어로 모든 훅을 설치할 수 있습니다.
  3. 유지 관리 용이성: 훅 스크립트를 중앙에서 관리하므로 변경 사항을 쉽게 추적하고 적용할 수 있습니다.
  4. Deno의 안전성: Deno의 권한 모델을 활용하여 훅 스크립트의 보안을 강화할 수 있습니다.

마치며

deno-task-hooks는 작은 패키지이지만, Git과 Deno를 함께 사용하는 팀의 개발 경험을 크게 향상시킬 수 있습니다. 코드 품질 유지와 개발 워크플로우 자동화를 위해 한번 사용해 보세요!

패키지는 JSR에서 다운로드할 수 있으며, GitHub에서 소스 코드를 확인할 수 있습니다.

피드백과 기여는 언제나 환영합니다! 😊

Read more →
0
0

아잇 오늘 확인해보니까

  1. emacs native-comp 잘 쓰고 있던 메인 맥은 macOS 15.3
  2. 새로 세팅한 맥은 하필 어제 업데이트를 누르는 바람에, 하필 어제 릴리즈된 macOS 15.4를 깔아버린 것

어쩐지 이슈가 없더라

0
0

요즘 OTT에서 미드보다 보면(영드,한드 보다 특히 미드) 정말 질떨어지는 시나리오들이 많다. 제대로된 갈등 구조도 없이, 그냥 성질 더럽고 의사소통 못하는 캐릭터들을 다수 등장시켜 걔네들끼리 언성높이고 투닥거리는 걸로 시간을 다 보낸다.

0

@hongminhee洪 民憙 (Hong Minhee) 음 표현이 좀 잘못된거 같네요. 버전에 constraint들 명시하면 그거 resolve해서 설치하겠죠. 제가 말하려고 했던건 lock이 개별 패키지 별로 안남고 indexed-state로 스냅샷 시간을 명시하는 방식이 마음에 안든가 거였습니다. cabal.freeze 또한 암호해시가 안 남고요.

0
0

근데 cabal처럼 기본이 스냅샷 모드인건 별로 같다. cabal로 locking하려면 시간으로(스냅샷을 특정할) 해야한다;; npm같이 각 패키지 버전과 lock이 있는 편이, 일단 심리적으로 더 든든하고, 또 가장 원자적인 동작을 더 확실하게 만든단 점에서 좋다.

대신 그 위에서 스냅샷(이라고 해야하나, 다른 이름이 있던거 같기도한데)을 다시 구현할수 있다. Expo같은 경우에 expo 패키지에 따라 나머지 expo-* 들의 버전이 결정되도록 한다.

0