Juntai Park

@arkjun@hackers.pub · 65 following · 75 followers

中年(중년)中小企業(중소기업) 開發者(개발자), 90年代(년대) Console Gamer(콘솔 게이머). 좋은 하루를 繼續(계속)해 나아간다. 좋은 하루가 모이면 좋은 人生(인생)이 된다.

韓国人のプログラマー、40代、小学生の息子とゲームするのが幸せ😃💕龍が如く 、ゼルダの伝説、マリオ、ピクミン好き

「いい1日を続ける」
いい1日を続けていけば、いい人生になる!

threads
@rkjun
x
@rkJun
uri.life
@arkjun@uri.life
GitHub
@arkjun

닉스(Nix)를 써보려고 Nix Pills라는 글을 읽기 시작했다. 화면에 Hello, world!를 출력하는 패키지 hello를 닉스로 설치하는 방법이 나오더라.

nix-env -i hello

저런 하찮은 프로그램이 패키지로 존재하는지 처음 알았다.

혹시 해키지에도 저런 게 있는지 검색을 해봤는데 있더라.[1] 2010년에 Simon Marlow가 업로드했다. 그런데 특이한 점이 이 패키지의 소스 코드 저장소 주소가 darcs.haskell.org라는 것이다. darcs를 호스팅하는 곳은 hub.darcs.net만 있는 줄 알았는데 haskell.org에도 있었구나⋯ 그런데 이 사이트 UI도 아예 없고 그냥 디렉터리 리스팅이 나오는데 hub.darcs.net으로 이전하시면 안 되려나.


  1. https://hackage.haskell.org/package/hello-1.0.0.2 ↩︎

0
0

正體中文翻譯現已可用!

我們很高興地宣布,Hackers' Pub 現在支援正體中文(zh-TW)!這意味著我們的介面將更加親近使用正體中文的軟體工程師和技術愛好者。

關於 Hackers' Pub

Hackers' Pub 是一個專為軟體工程師共同分享知識和經驗的平台。我們不僅是一個社區,還是一個啟用了 ActivityPub 的社交網路,讓您可以在聯邦宇宙(fediverse)中關注您喜愛的開發者,並在您的訂閱流中獲取他們的最新貼文。

我們的特色:

  • 開放的技術交流:自由分享您的知識、經驗和見解
  • 多語言支援:現在包括正體中文在內的多種語言
  • 聯邦互連:通過 ActivityPub 協議與其他平台(如 Mastodon)互通
  • 程式碼分享:支援 Markdown 和程式碼語法高亮
  • 包容性社區:遵循我們的行為準則,確保所有人都受到尊重

如何切換到正體中文

要將介面切換到正體中文,請按照以下步驟操作:

  1. 登入您的 Hackers' Pub 帳戶
  2. 前往「Settings」頁面
  3. 選擇「Language settings」標籤
  4. 在左側「Languages to select:」列表中找到並點擊「Chinese (Taiwan) 中文(台灣)」
  5. 該選項會移至右側的「Selected languages:」列表
  6. 如果您希望將正體中文設為主要介面語言,可以使用箭頭按鈕將其移至已選擇語言列表的最上方
  7. 點擊頁面底部的「Save」按鈕保存設定

我們也提供了正體中文版的 Markdown 指南,幫助您以最佳方式格式化您的貼文和文章。

加入 Hackers' Pub

Hackers' Pub 目前採用邀請制。如果您希望加入我們的社區,可以通過直接發送私人訊息(DM)給我來請求邀請碼。我們非常歡迎正體中文使用者的加入!

幫助我們改進

這是我們首次推出正體中文介面,可能仍有需要改進的地方。如果您發現任何翻譯錯誤或有改進建議,請透過以下方式聯繫我們:

感謝您成為 Hackers' Pub 社區的一員,讓我們一起建立一個更加包容、多元的技術交流平台!


附言:如果您對其他語言的翻譯感興趣,請查看我們的翻譯貢獻指南(英文)。

0
0
0
1

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

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

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

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

---

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

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

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

0
0
0

내가 AI 코드 편집기 사용을 중단한 이유
------------------------------
- 처음 AI 코드 도구를 사용할 때는 놀라움과 효율성에 감탄했음
- 특히 C++ 컴파일 에러 분석에 도움을 줘 마치 마법처럼 느껴졌음
- GitHub Copilot과 다양한 LLM 기반 에디터 통합 도구를 사용하면서 개발 워크플로우의 일환이 되었음
- 그러나 2024년 말에는 모든 LLM 통합 기능을 코드 에디터에서 제거했음 …
------------------------------
https://news.hada.io/topic?id=20145&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

0

@hongminhee洪 民憙 (Hong Minhee) Twitterはイーロンされててもうだめだ、ActivityPub対応のアカウントが欲しい → この「ハッカーズ・パブ」がよさそうだな → 会員登録がない → 管理者に申し込み → 管理者にメッセージを送るには、ActivityPub対応のアカウントが必要

😂

0
0
0
0
0
0

この「ハッカーズ・パブ」(Hackers' Pub)は、ハッカーたちが集まるネット上の場所であって、各自ブログも出来て、レスも出来て、掲示板みたいにも使えて、ユーザーの望みであればFediverseなる世界中の 変人 みんなのネットワークとも繋がりうる、言わばハッカーたちのための新しいツイッターみたいなサイトらしい。

ツイッターより優れた部分は何かというと、技術的に何時間も喋れそうだが、私が注目するのは、まずここの創立者および主任開発者である洪 民憙 (Hong Minhee)先生はイーロンなどよりかはずっとましな方で、頼れる方だということ。ユーザーの自由に関する彼の哲学、このサイトの設計思想などは信用できる。多分。なにしろ彼は今やFLOSS(Free/Libre/Open-Source Software)の開発を専業としておられるのだ。

なお、例えひょんな事で洪さんがイーロン並みに暴走する、由々しき事態でも、ここはツイッターみたいにはならないということ。この「ハッカーズ・パブ」はソースコードに限らず、プロトコルや作動原理も全部FLOSSなので。まあ洪さんの暴走なんてないでしょうけどね。

エンジニアとして生きてきた分、こういうサービスを運営する側の負担を大体把握しているので、自分ではやらないと思うし、ここが盛り上がったところで (盛り上げたところで) 自分の人生に役立つかというと、そうも言えない。が、「みんながTwitterとかFacebookとかInstagramなどを使っている」今の状態と比べれば、ハッカーズ・パブがもっと使われる未来の方が好ましいことに違いはない。そう考えると、洪さんの努力に感謝せざるをえない。

で、パブに日本語圏のユーザーをもっと招くのが創立者の方針というかご希望らしく、衝動的に参加してみる。これから機会あれば、日本語でも面白い話をここに残すのを目指してみる。自分日本語全然下手ですが。よろしく。

0
0
0

Hackers' Pubは現在、韓国語中心のコミュニティが形成されていますが、日本語のコミュニティも拡大することを希望しています。Hackers' Pubは、まるでQiitaやZennの様なソフトウェア開発者の為のブログプラットフォームであると同時に、MisskeyやMastodonの様なマイクロブログプラットフォームでもあり、何よりもActivityPubをサポートしているので、Mastodonや Misskey等とも交流が出来ます。(このアカウントもHackers' Pubのアカウントです!)

Hackers' Pubに興味の有る方は、私にDMでメールアドレスをお知らせいただければ、招待状を送らせていただきます。 是非、ご参加をお待ちしております。宜しくお願いします。

0

Juntai Park shared the below article:

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

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

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

Read more →
0
0
0

【拡散希望】

Hackers' Pub(ハッカーズ・パブ)は現在開発中の、ソフトウェアエンジニアと技術愛好家の為のActivityPub対応ソーシャルネットワークです。現在は韓国語中心のコミュニティが形成されていますが、日本のエンジニアの方々にも参加していただきたいと考えています。

Hackers' Pubは短文の投稿[1]と長文の記事[2]の両方をサポートしています。日常的な会話や簡単な質問は短文投稿で、詳細な技術解説やチュートリアルなどは長文記事で表現できます。QiitaやZennのような技術ブログ機能と、MastodonやMisskeyのようなタイムライン機能を兼ね備えた一つのプラットフォームで、両方の利点を享受できます。何よりもActivityPubプロトコルに対応している為、Mastodon、Misskey、Akkoma等と連携可能です。(このアカウントもHackers' Pubから投稿しています!)

技術的な特徴として、拡張Markdownによるテーブル脚注警告ボックスダイアグラム数式などの多様な記法をサポートし、構文ハイライト行ハイライト、差分表示などの強力なコードブロック機能も備えています。また、様々な言語での投稿が可能で、将来的には自動翻訳機能も予定しています。

Hackers' PubはAGPL-3.0ライセンスの下で開発されているオープンソースプロジェクトです。コードの貢献や機能提案も歓迎しています。

現在はまだ開発段階のため招待制となっています。Hackers' Pubに興味がある方は、DMや返信でメールアドレスをお知らせいただければ、招待状をお送りします。技術コミュニティの一員として、ぜひご参加をお待ちしております。よろしくお願いいたします。


  1. 「投稿」はActivityPubのNoteオブジェクトタイプに対応しています。 ↩︎

  2. 「記事」はActivityPubのArticleオブジェクトタイプに対応しています。 ↩︎

2
0
1

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

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

이거 사서 읽긴 했는데, 문서에서 설명하는 내용이랑 거의 비슷해요. 액티비티펍이 왜 생겨났고, 액티비티펍으로 어떤 미래를 기대하는가 같은 내용 위주로 읽으면 좋을 것 같아요. 다만, 여기에 실습 예제는 따로 실습 안하고 슥 하고 보기만 했는데, 실용적인 뭔가를 만들거면 Fedify 문서를 정독하는게 낫지 않나 싶습니다



RE: https://hackers.pub/@curry/0195f6ee-df39-7af7-b388-495fcc0d0789

0

몇 년 전에 취미로 프로그래밍 책 제본을 했다. 인터넷에서 업체에 PDF 파일을 전달하면 제본해서 택배로 받았다. 그렇게 읽지도 않는 책은 쌓여만 갔다. 결국 몇 달 전에 하스켈 학교 모르는 분에게 한 권만 나눔하고 모두 버렸다.

그런데 프로그래밍 책은 펼쳐 놓고 노트북을 켜서 실습할 때가 많기 때문에 잘 펴져야 한다. 떡제본은 펼침성이 나빠서 불만이었고 여러 제본 방식을 알아보다가 바인더 형식을 써보기로 했다. 적당한 업체를 찾아서 첫 주문을 했는데 오늘 도착했다. 원래 표지 디자인을 직접 해서 업체에 PDF를 전달해야 하는데 하는 법도 모르고 시간도 없어서

“그냥 대충 알아서 해주세요.”

했는데⋯

너무 이쁘게 잘 뽑아 주셨다. 책등 문구 디자인도 알아서 센스 있게 해주셨는데 너무 마음에 든다. 과연 이 책은 끝까지 읽을 수 있을까!

책등 이미지책의 목차 일부주문 제작한 B5 크기의 3공 바인더
0
0

회사에서 거의 10년 동안 운영한 서버를 교체 중이다. 고생 많으셨습니다. 서버님⋯ 새로 오신 서버님에게는 돼지 머리랑 막걸리 준비는 못했지만 절이라도 올려야겠다.

0
0
0
0

"그런 백엔드 기술로 괜찮은가?"

  • 대상 : 다양한 기술과 도메인에서의 실무 문제 해결 사례를 통해 실질적인 인사이트를 얻고자 하는 개발자
  • 일시 : 2025.04.20(일) 13:00 ~ 17:00 KST
  • 장소 : 테크살롱 (서울 강남구 테헤란로 411, 성담빌딩 13층)
  • 기타 : 주차 지원이 어려우니 대중 교통 이용을 권장드립니다.

https://www.inflearn.com/course/offline/게으른게발자컨퍼런스-2025

0

Chrome Built-In AI (EPP)で変更

Canary 136.0.7103.0* 以降、すべての組み込み API に新しいエントリ ポイントがあります。 self.ai.* ではなく、self.* で直接 API を見つけることができるようになりました。静的 create() メソッドを使用して、これらの API をインスタンス化します。

await LanguageModel.create();
await Summarizer.create(); 
await Writer.create();
await Rewriter.create();
await LanguageDetector.create();
await Translator.create();

同様に、静的 availability() メソッドが追加されました。

await LanguageModel.availability();
await Summarizer.availability();
await Writer.availability();
await Rewriter.availability();
await LanguageDetector.availability();
await Translator.availability();
0

그것 아십니까? 國立國語院(국립국어원)漢字(한자)()】에 本音(본음)인 「다」 말고는 慣用音(관용음) 「차」가 있다는 것을 認定(인정)하지 않습니다. 그 代身(대신), 【차】가 이미 固有語化(고유어화)된 낱말이라고 봅니다. 그래서 《標準國語大辭典(표준국어대사전)》에서도 【다례】는 【茶禮(다례)】라고 밝히면서도 【차례】는 【차()】라고 밝히고 있습니다…

0

Juntai Park 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

사실 Hackers' Pub은 저희 집 홈 서버인 Mac mini M4 깡통 모델에서 돌아가고 있을 뿐만 아니라, 배포도 compose.yaml 파일의 image: 필드를 매번 손으로 고친 뒤 docker compose up -d를 치는 전근대적인 방식으로 이뤄지고 있습니다… 뭔가 자동화를 하고 싶긴 한데 귀찮은 마음이 커서 아직까지 이대로 살고 있네요.

0
0
0

https://learnbyexample.github.io/learn_perl_oneliners/one-liner-introduction.html https://learnbyexample.github.io/learn_ruby_oneliners/one-liner-introduction.html

대화형 쉘 환경에서 Perl / Ruby 한줄짜리 스크립트를 짜는 방법을 소개. awk/sed 같은 스크립트를 쓰지 않고도, stdin으로 넘어온 입력을 가독성 있는 코드로 처리하기 좋음.

0

인용한 글의 내용과는 상관 없는 이야기인데, 현재는 단문에서는 단문이든 게시글이든 인용할 수 있는 반면, 게시글에서는 단문도 게시글도 인용을 못 하게 되어 있다. 별 생각을 안 하고 그렇게 만든 거긴 한데, 잘 생각해 보니 오히려 인용 기능은 게시글에서 더 유용할 것 같다.

하루 빨리 게시글에서도 인용이 가능하게 개선을 하도록 하겠습니다…



RE: https://hackers.pub/@xt/2025/stackage-why

0
0

"pub"의 외래어 표기법에 따른 표기는 ""이 아니라 "퍼브"입니다. 유성음으로 끝나는 단어라서 "ㅡ"를 붙입니다. 이것은

  • log: ""이 아니라 "로그"
    • blog: "블록"이 아니라 "블로그"
  • tag: ""이 아니라 "태그"
  • egg: ""이 아니라 "에그"
  • dog: ""이 아니라 "도그"
  • mug: ""이 아니라 "머그"
  • hub: ""이 아니라 "허브"
  • pad: ""이 아니라 "패드"
  • lid: "릿"이 아니라 "리드"
  • mud: ""이 아니라 "머드"

등등, 유성음으로 끝나는 영어 단어에 일관적으로 적용되는 규칙입니다.

보통 외래어 표기법의 규칙이 무시되는 사례를 보면, 규칙이 모호성을 낳는다는 이유로 기피되는 경향이 있는데요. 예를 들어 "seat"와 "sheet"를 구분하려는 욕망으로 인해 /ʃiː/를 "시"로 표기하는 원칙을 깨고 후자를 "쉬트"로 적는 것이 있죠.

그런데 유성음으로 끝나면 "ㅡ"를 붙인다는 규칙은 원어의 유성 음가를 반영하는 동시에, 대체로 모호성을 해소하는 방향으로 표기를 만들어 주는 좋은 규칙입니다. 이 규칙이 없었으면 꼼짝없이

  • "dog"와 "dock"이 "독"이라는 동음이의어가 되고
  • "pig"와 "pick"도 "픽"이라는 동음이의어가 되고
  • "rug"와 "luck"도 "럭"이라는 동음이의어가 되고
  • "tag"와 "tack"도 "택"이라는 동음이의어가 되고

영 좋지 않았겠죠.

0
0
0

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

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

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

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

한줄 요약

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

Juntai Park shared the below article:

hoonie-blog v1.1.1 등장!

카미유 @renegade_v00@hackers.pub

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

Read more →
0

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 생태계는 아직까지는 미래가 낙관적이라고 본다.

7