Profile img

박준규

@curry@hackers.pub · 320 following · 175 followers

darcs hub
hub.darcs.net/vincent
Hackage
hackage.haskell.org/user/JoonkyuPark

박준규 shared the below article:

일본 서버를 한국과 거의 비슷한 속도로 원격 접속하기

고남현 @gnh1201@hackers.pub

이 글에서는 한국에서 일본 서버를 사용할 때 발생하는 네트워크 지연 문제를 다루고, 해저 케이블망을 활용하여 이를 개선하는 방법을 소개합니다. 저렴한 일본 서버를 선택했지만, 실제 한국에서의 통신 속도가 예상보다 훨씬 느린 250ms에 달해 미국 시애틀보다도 못한 상황을 겪었습니다. 하지만 Microsoft Azure의 한국 리전을 중간 서버로 활용하여 데이터 센터 간 통신을 시도한 결과, 핑 시간을 30ms대로 크게 단축시키는 데 성공했습니다. 이는 86%의 속도 향상으로, RDP를 통해 원격 데스크탑을 사용하는 환경에서 체감 속도를 극적으로 개선했습니다. 이 글은 해외 서버를 사용할 때 네트워크 지연을 줄이는 실질적인 해결책을 제시하며, 독자에게 더 빠르고 효율적인 원격 작업 환경을 구축하는 데 도움을 줄 수 있습니다.

Read more →
8
1
0

그나저나 Slidev는 소프트웨어 프로그래머를 ()한 정말 잘 만든 發表(발표) 슬라이드 作成(작성) 소프트웨어 같다. ()히, 슬라이드에 TypeScript 코드를 꽤 包含(포함)해야 하는 發表(발표) 資料(자료)를 만든다면 Slidev를 使用(사용)해 볼 것을 ()한다. Twoslash가 支援(지원)된다…!

꼭 TypeScript 코드가 아니더라도 特定(특정) 줄들을 順序(순서)대로 強調(강조)하는 것도 되고, 라이브로 코드를 고칠 수도 있다. 비포 애프터로 두 코드를 比較(비교)할 때도 매직 무브로 괜찮은 演出(연출)可能(가능)하다.

아무튼 Slidev 最高(최고)…!

5

System.IO.readFile 쓰지 마세요.

System.IO.readFile 쓰지 마세요.

System.IO.readFile 쓰지 마세요.

첫째, System.IO.readFileString 을 반환합니다. 이건 심각한 문제입니다. String 을 쓰지 마세요. 외부 세계와 I/O 를 할 때에는 ByteString 을 써야 합니다. 유니코드 문자열을 다룰 때에는 Text 를 쓸 수 있습니다. String 은 시간적으로도 공간적으로 비효율적입니다. 이건 어쩔 수 없습니다. 하스켈은 리눅스 커널보다 오래됐습니다. 그리고 하스켈이 String 을 만들 때에는 아직 하스켈에 모나드도 없던 시절이며, 타입 클래스가 과연 유용하겠는가를 두고 의견이 분분하던 시절이며, 파일 하나가 100 메가바이트가 넘어간다는 것이 과대망상으로 여겨지던 시절입니다. 특히 유니코드보다 더 먼저 나온 언어에 적절한 유니코드 문자열 타입이 있을 수는 없었습니다. 아무튼 String 은 레거시입니다. System.IO.readFile 로 그림 파일을 읽는 프로그래머는 사후세계에서 JPEG XL 파일을 십육진법 표기로 1 바이트씩 읽은 뒤 종이에 그려 내는 형벌에 처해집니다. String 을 쓰지 마세요.

둘째, System.IO.readFileFilePath 를 요구합니다. FilePath 도 사실 String 입니다. 그냥 별명(type synonym)이에요. 이것은 String 이기 때문에 비효율적이며, String 은 문자열이지 바이트열이 아니기 때문에 (인코딩을 전혀 통제할 수 없기 때문에) 파일 경로를 표현하는 타입으로 부적절합니다.

해결책: 먼저 System.OsPath 의 설명을 읽어 보세요. 그리고, file-io 패키지의 System.File.OsPath 모듈을 읽어 보세요. 여기 있는 함수들의 설명을 openBinaryFile 부터 하나씩 읽어보고 쓰세요. 이것들은 파일 경로에 OsPath 를 쓰기 때문에 String 의 비효율이 없고 인코딩도 올바르게 처리할 수 있습니다. 입출력 데이터에는 ByteString 을 씁니다. 바이트열을 유니코드 문자열로 변환할 때에는 예를 들어 Data.Text.Encoding.decodeUtf8Lenient 를 쓸 수 있습니다. 그럼 이제

  • 간단히 System.File.OsPath.readFile' 에게 OsPath 를 넘기고 ByteString 을 효율적으로 받아 와서 국밥처럼 든든하게 메모리에 올려 두고 작업을 하든지
  • 전국구 마법사라면 복대는 기본이라고 외치며 withBinaryFile앙갓썸Iteratee I/O 로 절묘하게 엮어서 뭔가 개멋있게 하든지
  • 하스켈 갓고수이기 때문에 흑마법사답게 보일러실 문을 따고 지하로 들어가 포… 포… 으악! P 로 시작하는 그것을 획득하여 누구도 예상할 수 없는 타이밍에 hGetBuf 의 암기를 슉. 슈슉. 슈슈슉. 슉. 날리든지

아무튼 이제는 String 을 놓아주어야 합니다.

7

탐라에 개발자분들이 많은거 같아서 여쭤봐요...

DBA나 데이터 엔지니어, 데이터 애널리스트, 쿼리 전문가에 대해서 어떻게 생각하시나요...!!!

꼭 필요한 존재는 아니라고 생각하시나요...!

3

12() 6() 서울에서 開催(개최)되는 liftIO 2025에서 〈Optique: TypeScript에서 CLI 파서 컴비네이터를 만들어 보았다〉(假題(가제))라는 主題(주제)發表(발표)를 하게 되었습니다. 아직 liftIO 2025 티켓은 팔고 있으니, 函數型(함수형) 프로그래밍에 關心(관심) 있으신 분들의 많은 參與(참여) 바랍니다!

11
4
2
3
0
1
2

박준규 shared the below article:

"expression"은 "표현식"이 아니라 그냥 "식"

蛇崩 (じゃくずれ) @ja@hackers.pub

이 글은 프로그래밍 용어 "expression"을 "표현식"이 아닌 간결한 "식"으로 번역해야 한다고 주장합니다. 필자는 "expression"이 수학에서 유래되었으며, 수학에서는 이미 "식"으로 번역되어 사용되고 있음을 지적합니다. 또한, 프로그래머들이 "표현식"을 선호하는 이유로 사전적 정의와 초·중등 교육에서 비롯된 선입견을 들지만, 실제로는 "식"으로 번역해도 의미 전달에 전혀 문제가 없다고 강조합니다. 오히려 "표현식"은 "representation"의 번역어인 "표현"과 혼동될 수 있으며, "정규표현식"과 같이 불필요하게 긴 용어를 만들어낼 수 있다고 비판합니다. 결론적으로, 필자는 "expression"을 "식"으로 번역하는 것이 더 정확하고 간결하며, 전산학 용어의 일관성을 유지하는 데 도움이 된다고 주장하며, "정규식"이라는 간결한 용어 사용을 옹호합니다.

Read more →
10
0
0

박준규 shared the below article:

안녕 세계!

김태희 (탐정토끼) @stelo_kim@hackers.pub

일론 머스크에 대항하여 자유/오픈소스 생태계를 지키기 위해 Fediverse 활동을 시작하려는 여정을 소개합니다. 기존 해커스펍 계정을 활용하여 글을 작성하고, 트위터에는 미리보기 링크를 공유하는 방식으로 소통할 계획입니다. Fediverse에서의 활동을 통해 자유와 오픈소스 가치를 옹호하고, 더 많은 사람들과 교류하며 기여할 수 있기를 기대합니다.

Read more →
12
21
4
0
3
1

@arkjunJuntai Park 이번에는 국토교통부로 이송되었습니다.

본 민원은 국도77호선 관련 내용으로, 민원처리법 제16조(민원문서의 이송)에 따라 순천국토관리사무소로 이송합니다.

G 한국도로교통공단 한국도로교통공단 여수시 여수시 한국도로교통공단->여수시 국토교통부 국토교통부 여수시->국토교통부

@arkjunJuntai Park

귀하께서 요청하신 둔병대교 VMS 운용 프로그램 사용자 접속 제한에 대해서는 최초 VMS 설치 시 운용하여 비밀번호가 노출됐던 프로그램은 삭제하고 내부 운용 프로그램 사용을 통해 관리자만 접근 할 수 있도록 조치하였음을 알려드립니다.

와, 진짜 이제 접속 안 됩니다! 국토교통부 공무원 여러분 고생하셨습니다.

8

http://logitext.mit.edu/main 재미있는 웹 앱 중 하나. 논건 대수(Sequent Calculus)를 사용해 1차 논리("모든 대상에 대해"나 "어떤 대상이 있어"를 서술할 수 있는 논리)의 명제를 상호작용을 통해 증명해 볼 수 있다. 예를 들어 A /\ B -> A (A 그리고 B이면 A이다)를 증명하려면

  • 위 명제를 입력칸에 넣는다.
  • ->를 눌러 명제 안의 "이면"을 증명에서 쓸 수 있는 가정(|-의 왼쪽에 있는 것)으로 바꾼다.
  • 가정의 A /\B를 눌러 "그리고"의 양 측에 해당하는 가정 AB 각각을 얻는다.
  • 가정이나 결론의 A를 눌러 가정을 사용하는 것으로 증명을 끝낸다.

보다 입문자에게 친절한 설명은 http://logitext.mit.edu/tutorial 에서 읽어볼 수 있다.

4
4

연구자로서, 또한 한 명의 개발자로서 현 세대에 항상 궁금한 것은 AI가 얼마나 도움이 되느냐이다.

Haskell, OCaml은 말할 것도 없고, JavaScript, Python도 AI와 써 본 경험으로는 그들이 큰 도움이 되느냐는 질문에 자신있게 "그렇다"고 하기 힘든 경험만 해봤기 때문이다.

내가 코드의 형식에 대한 집착이 너무 심한 것이 원인일 수는 있겠으나... AI가 준 결과를 여기 바꾸고 저기 바꾸다보면 결국 내가 쓴 처음부터 코드가 된다.

얼핏 드는 생각으로는 거의 "타입도 없고 문서화도 잘 안되어 있는 환경에서는 사람들이 기능을 이해하기 어려우니 AI를 쓰겠다..."싶다가도, "그러면 내가 잘 아는 분야에 대해서 왜 AI를 써야하지?"하는 생각도 떨치기 힘든 상황이 자주 찾아온다.

결과적으로 나는 AI를 사용하려는 시도를 (적어도 일시적으로는) 멈추었다.

7

박준규 shared the below article:

내가 LLM과 함께 코딩하는 방식

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

이 글은 저자가 LLM(Large Language Model)을 활용하여 코딩하는 방법에 대한 개인적인 경험과 팁을 공유합니다. LLM 코딩 에이전트 사용 시 맥락 제공의 중요성을 강조하며, Claude Code 모델을 선호하는 이유와 그 장단점을 설명합니다. 세부적인 지시를 위해 GitHub 이슈를 활용하고, 설계는 사람이, 구현은 LLM이 담당하는 역할 분담을 제안합니다. 또한, 프로젝트 지침을 담은 *AGENTS\.md* 파일의 중요성과 Context7을 활용한 문서 제공 방법을 소개합니다. 계획 모드를 통해 LLM이 스스로 피드백 루프를 돌도록 유도하고, 필요한 경우 손 코딩을 병행하여 코딩의 재미를 유지하는 전략을 제시합니다. 이 글은 LLM을 단순한 도구가 아닌 협력적인 동료로 활용하여 개발 효율성을 높이는 방법을 모색하는 개발자들에게 유용한 인사이트를 제공합니다.

Read more →
37
0
1

그래서 KT는 LTE 주파수 확보 문제를 해소하기 위해 펨토셀을 울며 겨자먹기로 보급하게 됩니다. 미창부와 KT, SKT, 삼전 모두가 엮인 총체적 난국이었죠. 이 과정에서 시간이 지나 펨토셀이 일반화되고 알리에서도 물건을 파는 시대가 왔습니다 -_-; 그러면서 이번 사건이 터진겁니다. 당분간은 정말로 이거 해소할 방안이 없어 보이니, 꾸준히 모니터링 하면서 이상한 소액결제을 꾸준히 모니터링 하는 수 밖에 없어보입니다. 추측인데 eSIM, 듀얼 SIM이 되는 기기가 빈 SIM 공간이 있으면 취약하니, 어떻게든 채우라 하네요.

1

갑자기 불현듯 하이텔이나 나우누리 같은 옛날 PC통신이 떠올라서 난 한 번도 그 시절을 겪어본 적이 없었는데 어떤 느낌일까 싶어서 해보고 싶어가지고 검색 해봤는데 생각보다 쉽게 사설 BBS를 접속하는 프로그램을 찾아내서 탐방했음. 미국은 사설 BBS가 아직 명맥을 이어가는 것 같은데 국내 거는 사실상 멸종한 것 같다...여튼 하니깐 어릴 때 친구네집 펜티엄 컴퓨터 갖고 스치듯 했던 MS-DOS 갬성이 엄청 느껴져서 하는 내내 헤벌레 미소 지으면서 했다 ㅋㅋㅋ 나갈 때 작별인사 페이지도 따로 있어서 살짝 감동 먹음 🥹

참고로 사용한 프로그램은 MuffinTerm이고 애플 계열 기기에서 돌아간다 (아이패드 포함). 접속한 BBS는 8bit-boyz라는 미국 레트로 컴퓨팅 커뮤니티다.

8bit-boyz BBS 접속 사진
7

살짝 다른 차원에서 확장해서 바라보는 얘기이긴 한데 그냥 첨언하자면 언어학의 하위 분야인 화용론에서 전제(Presuppositions)라는 주제랑 연결되는 것 같네요. 댓글에 프랑스 왕은 머머리다 예문도 써주신 걸 보니 더욱 더 그런 것 같고요. 간단하게 설명드리자면, 일단 한국어 예문으로 하면 살짝 오해의 소지가 있어[1] 영어 예문을 갖고 쓰면 다음과 같이 생각해볼 수 있습니다.

  • P: The King of France is bald.[2]
  • Q: There exists an entity that is King of France.

이 때 P의 명제가 참일 수 있는 이유는 Q를 전제로 깔고 가기 때문입니다. 이렇게 Q를 전제로 갖고 가면 P에 부정을 넣어도 (The King of France is not bald 혹은 ¬(The King of France is bald)) 여전히 그 명제는 참입니다. 하지만 실제 현실에서 Q는 거짓입니다. 왜냐하면 오늘날 프랑스는 군주국가가 아니니깐요. 그럼에도 불구하고 P는 여전히 참을 진리값으로 가지죠.

따라서 실제로 전제를 이렇게 정의하기도 합니다 (Levinson, 1983, p. 175).

  • A sentence P sematically presupposes a sentence Q iff:
  • (a) P ⊨ Q
  • (b) ~P ⊨ Q

참고로 여기서 "⊨"는 "함의한다"를 지칭하는 기호입니다 (예: "하스켈은 함수형 언어다."란 문장은 "하스켈은 언어다"란 걸 함의하죠.).

그렇다면 Q가 전제되는 건 알겠는데, 이 진리값이 무엇이느냐에 대한 질문이 생길 수 있습니다. 이에 대해서 언어학자들은 보통 크게 두 가지로 봅니다. 하나는 참으로 간주하는 거고, 다른 하나는 참도 거짓도 아니다라고 보는 거죠. 전자같은 경우엔 어떻게 보면 기계적으로 바라보는 거고, 후자의 경우엔 참/거짓이라는 기존 이치논리(two-valued logic) 혹은 1 또는 0으로 하는 불 논리에서 확장해서 Kleene의 삼치논리(three-valued logic)로 가게 되죠.

참고로 전제 성립 여부 포함 화용론 전체에서 깔고 가는 가장 큰 가정이 하나 있는데, 이 경우에는 바로 해당 발화(utterance) P, 즉 '프랑스왕은 머머리다'라는 명제가 이루어질 때 화자와 청자가 프랑스에는 왕이란 개체가 존재한다(=Q)라고 암묵적으로 서로 동의한다라는 가정입니다.


  1. 사실 문제가 영어 관사 'The'에서 시작되기 때문이라서 그렇습니다. ↩︎

  2. 논리형으로 치환하면 다음과 같습니다: ∃x(KoF(x) & ∀y(KoF(y) → y=x) & Bald(x)) where KoF stands for "King of France". ↩︎

5

Ailrun (UTC-5/-4) replied to the below article:

공허한 참

박준규 @curry@hackers.pub

하스켈의 `all` 함수에 빈 리스트를 넣었을 때 왜 `True`가 반환되는지에 대한 의문을 "공허한 참(Vacuous truth)"이라는 개념을 통해 탐구합니다. 흔히 '구현이 그렇게 되어 있으니까'라고 생각할 수 있지만, 저자는 이 현상을 논리적으로 분석합니다. `all` 함수의 구현 방식과, 빈 리스트에 대한 연산 결과가 전체 결과에 미치는 영향을 설명하며, 공집합의 모든 원소가 짝수라는 명제가 참인 이유와 유사한 논리적 근거를 제시합니다. 이를 통해 코드와 수학 간의 연결고리를 발견하고, 마지막으로 ChatGPT가 생성한 유머러스한 이미지를 곁들여 독자에게 즐거움을 선사합니다.

Read more →
5

@curry박준규 all을 다음과 같이 정의하면 문제가 무엇일까요?

all p [] = False
all p [x] = p x
all p (x:xs) = p x && all xs

이 질문에 대한 대답 중 all의 의미에 관한 것이 있을 겁니다. 논리적으로 "모든 ...에 대해"를 어떻게 이해해야 하는냐에 대한 것 말이지요.

공집합을 직접 사용하는 것이 가장 간단한 예시겠지만, 좀 더 논리학에서 자주 사용되는 예시로는 "20세기의 모든 프랑스 왕은 대머리다"가 있겠습니다. 이는 무의미하게 (Vacuously) 참인데요, 왜냐면 19세기를 마지막으로 프랑스에는 더 이상 왕이 없기 때문이지요. 즉, 일반적으로 "모든 ...에 대해"에서 "..." 부분이 (결과적으로) 공집합일 경우 "모든 ..."에 의해 수식된 본문이 어떤 문장인지와는 상관 없이 참이라고 이해한다는 것이지요.

5
0

소스코드 사이의 안정적인 하이퍼링크를 만들수 있는 기능이 없다. 가령 A.hs에서 주석을 쓰면서 B.hs의 foo란 함수의 구현의 특정 부분을 언급하고자 할때, 그냥 B.hs L:77 이렇게, 소스코드가 수정이라도 되면 바로 유효하지 않게되는 방식으로 언급할수 밖에 없다. 만약 소스 코드 어디에서든 전역적인 심볼을 자유롭게 선언할 수 있다면 이 문제를 해결할 수 있을텐데...

3

Term.everything - 터미널에서 모든 GUI 앱 실행하기
------------------------------
- Linux용 CLI 프로그램으로, *GUI 애플리케이션을 터미널에서 직접 실행* 할 수 있게 해줌
- 자체 제작한 *Wayland 컴포지터* 를 사용해 모니터 대신 터미널로 GUI 출력을 전달하는 방식
- ssh 환경에서도 실행 가능하며, *웹 브라우저, 파일 매니저, 심지어 Doom 게임까지 터미널 안에서 실행* 가능
- 터미…
------------------------------
https://news.hada.io/topic?id=23012&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

1

타입 검사는 해결책이 아니라 증상이다〉(Type Checking is a Symptom, Not a Solution).

난 이 글에 동의하지 않는데, 여러 측면에서 그렇지만, 한 측면에만 집중해서 얘기해 보자면: 좋은 아키텍처는 훌륭한 프로그래머를 요구하지만 타입 시스템은 훌륭한 프로그래머를 요구하지 않기 때문이다.

누구나 훌륭한 프로그래머가 되어야만 하는가? 혹은 될 수 있는가? 좋은 아키텍처를 그릴 수 있는 훌륭한 프로그래머가 아니라면 소프트웨어 개발을 해서는 안 될까? 좋은 아키텍처에만 의존하는 것은 잠재적으로 엘리트주의를 끌어들이기 쉽다: 「어떤 시스템이 오작동하는 것은 아키텍처가 나쁘기 때문이다. 아키텍처가 나쁜 이유는 그걸 설계한 프로그래머가 수준 미달이기 때문이다」와 같이.

반면 타입 시스템은 일단 도입만 하면 누구나 그 덕을 볼 수 있다. 팀 내의 프로그래머들의 역량이 뛰어나든 뛰어나지 않든. 훨씬 평범한 보통 사람에게 유리하다. 타입 시스템이 미봉책일 수는 있지만, 그 미봉책이 더 많은 사람들을 프로젝트에 참여할 수 있게 해준다고 생각한다.

13
1
0

最近(최근) 한창 開發中(개발중)인 Fedify 基盤(기반) ActivityPub 서비스 2():

完全(완전) 期待中(기대중)!!

6

안녕하세요, 백엔드 경력직 프로그래머 뽑고 있습니다. 로그를 모니터링하고 저장하는 시스템을 개발하는 포지션입니다. 기존 오픈소스 솔루션을 사용하긴 하지만 단순히 구축하고 운영하는 것은 아닙니다. 운영도 하지만 개발이 주된 업무 입니다. (오픈소스 솔루션 운영 포지션으로 착각하고 지원하시는 분들이 계셔서 사족을 넣었습니다) https://careers.linecorp.com/ko/jobs/2845/

8
0
0

참고로 Hackers' Pub의 행동 강령에서는 굳이 정치적인 주제를 금지하지 않고 있습니다. 정치적인 것과 그렇지 않은 것의 경계가 흐릿한 것도 있지만, 그렇게 했을 경우 기득권에 편향되기 쉽다는 점, 그리고 필요하다면 정치에 대해 이야기할 수 있어야 하기 때문입니다. 많은 커뮤니티에서 정치적 대화가 필요할 때 조차 정치적 주제를 기계적으로 금지함으로 인해 자정 능력을 잃는 것을 봐 왔습니다.

9

박준규 shared the below article:

정치적인 컨텐츠에 대한 생각

Jaeyeol Lee @kodingwarrior@hackers.pub

이 글은 사회생활에서 금기시되는 정치 이야기가 우리의 삶과 얼마나 밀접하게 연결되어 있는지를 고찰합니다. 저자는 정치적인 것이 단순히 정부나 정책에만 국한된 것이 아니라, 사람이 개입하는 모든 영역에 존재한다고 주장합니다. 다양성을 존중하는 문화를 만드는 것조차 정치적 행위로 볼 수 있으며, 정치 혐오가 만연한 사회일수록 정치에 대한 관심이 더욱 필요하다고 강조합니다. 특히, 무심코 사용하는 표현이나 접하는 콘텐츠가 특정 정치적 의도를 담고 있을 수 있음을 경계하며, 정치적 프레임에 갇히지 않기 위해서라도 사회와 정치에 대한 꾸준한 관심이 중요하다고 역설합니다. 이 글은 정치적 무관심이 오히려 위험할 수 있음을 시사하며, 독자들에게 비판적 사고와 균형 잡힌 시각을 갖도록 촉구합니다.

Read more →
15

GHCup 오랜만에 다시 설치하는데 못보던 게 생겼다.

GHCup provides different binary distribution "channels". These are collections of tools
and may differ in purpose and philosophy. First, we select the base channel.

[S] Skip  [D] Default (GHCup maintained)  [V] Vanilla (Upstream maintained)  [?] Help (default is "Skip").
2
2
1

사실 지금의 공랭식 에어컨도 언제까지 돌릴 수 있을지 모릅니다.

저는 지열 등 대기가 아닌 곳으로 열을 배출하는 냉방장치를 지금부터 개발, 도입해야 한다고 생각해요. 지금도 한여름에는 대기 열방출 부하를 못 견디고 실외기가 뻗는 경우가 나오고 있습니다.

1

진짜 디자인 하고싶은대로 다 하고 있는데, 누군가가 보다 못해서 "차라리 내가 하고 만다" 하고 자원을 해주지 않을까(?)

8
11
1
0
9

Hackers' Pub의 로고 디자인이 완료되었습니다! 디자인은 박은지 님(@murinono무리노노)께서 해주셨습니다.

연합우주라는 콘셉트에 맞게 고양이의 입 주변을 별 모양으로, 목 아래에도 고리(orbital ring) 모양으로 디자인했습니다. 고양이를 고른 이유는 소프트웨어 프로그래머 커뮤니티에서 다른 동물보다 유독 고양이가 사랑 받기 때문이기도 하고, 고양이가 호기심이 강하기 때문이기도 합니다.

로고 디자인은 CC-BY-SA 4.0 라이선스로 배포됩니다.

23
1
1
1
2

아래 npm 패키지에서 악성코드가 발견되었다고 하네요. 최근에 있었던 npm을 사칭한 피싱 메일로 인해 보안토큰을 탈취당하신 듯...

eslint-config-prettier: 8.10.1, 9.1.1, 10.1.6, 10.1.7
eslint-plugin-prettier: 4.2.2, 4.2.3
synckit: 0.11.9
@ pkgr/core: 0.2.8
napi-postinstall: 0.3.1

Active Supply Chain Attack: npm Phishing Campaign Leads to Prettier Tooling Packages Compromise - socket.dev/blog/npm-phishing-c

6
0
0
9

Ji-Haeng Huh replied to the below article:

하스켈 편지

박준규 @curry@hackers.pub

이메일 교환을 요약하면, 한국의 취미 프로그래머 박준규 님이 Haskell에 대한 관심을 표현하며 NRAO의 다니엘 님에게 연락을 시작합니다. 다니엘 님은 Haskell 경험과 NRAO에서의 Haskell 프로젝트(antioch)를 공유하며, 박준규 님의 Haskell 학습 경험과 프로젝트에 대한 질문을 던집니다. 박준규 님은 자신이 관리하는 Hackage 패키지와 Protohackers 문제 풀이 경험을 공유하고, 다니엘 님은 이에 대한 격려와 함께 Typeclassopedia와 free monad를 추천합니다. 이 대화는 Haskell에 대한 열정과 지식을 공유하며, 서로에게 영감을 주는 긍정적인 교류를 보여줍니다. 다니엘 님은 박준규 님에게 Haskell 관련 질문을 언제든지 환영하며, 이 대화를 자유롭게 공유해도 좋다고 허락합니다.

Read more →
20

@curry박준규 정말 귀한 글 올려주셔서 감사합니다.

저 역시 사람들에게 마지막 답장에 언급된 typeclassopedia를 가장 많이 추천합니다. 많은 분들이 하스켈 입문 후 당장의 코딩 경험을 쌓기보다 "모나드는 부리또다"로 대표되는 하스켈 튜토리얼류에 집착적으로 빠져들며 학습의 발란스를 깨는 경향이 보입니다. 무엇에 기인하는 현상인지 아직 확실히 파악은 못했지만 분명 안타까운 상황인 거 같아요.

물론 typeclassopedia도 튜토리얼 문서의 일종이지만 저자만의 특수한 깨달음 포인트가 아닌 정공법으로 설명해주다 보니, "저자의 창의적인 비유와 설명" -> "이제야 알 것 같은 독자" -> "그렇게 생긴 깨달음이 실제 코딩에 도움이 안됨" -> "새로운 문서를 찾아 헤맴" 의 끝없는 반복을 부숴줄 힘이 있는 것 같습니다.

4
1

박준규 shared the below article:

힙스택 보존 법칙

RanolP @ranolp@hackers.pub

이 글에서는 프로젝트 진행 시 기술 스택 선정에 대한 경험적 법칙인 "힙스택 보존 법칙"을 소개하며, 힙한 기술 스택을 과도하게 선택할 경우 프로젝트가 산으로 갈 수 있음을 경고합니다. 저자는 신기술 도입 시 발생하는 호환성 문제와 그로 인한 추가 작업의 부담을 설명하며, 커뮤니티가 크고 성숙한 기술의 중요성을 강조합니다. 힙한 기술을 사용하더라도 프로젝트를 성공적으로 이끌 수 있는 두 가지 조건, 즉 기술의 안정성과 개발자의 숙련도를 제시하며, 힙스택을 사용하기 전에 충분한 학습과 경험을 통해 기술적 내성을 길러야 함을 역설합니다. 이 글은 기술 스택 선택의 중요성과 개발자의 역량 강화 필요성을 동시에 강조하며, 균형 잡힌 기술 스택 선택이 프로젝트 성공에 미치는 영향을 시사합니다.

Read more →
14
1
1