제가 생각하는 해커즈 퍼브 기능 우선순위
- 글 올리면서 "댓글 안 받기" 설정 (트위터 킬러 피처, 트위터 역사상 가장 훌륭한 기능 추가라고 생각)
- 인용 (quote) 금지 설정
- 공유 (renote) 금지 설정
😅
@xt@hackers.pub · 5 following · 29 followers
juxtapose - Wiktionary, the free dictionary
juxtapose (third-person singular simple present juxtaposes, present participle juxtaposing, simple past and past participle juxtaposed)
제가 생각하는 해커즈 퍼브 기능 우선순위
😅
악용 사례가 발견되어 긴급 패치: 실존하는 위협에 벌벌 떨어야 함
악용 사례는 발견되지 않음: 존재가 확인되지 않은 위협에 벌벌 떨어야 함
해커즈 퍼브의 favicon 이야기가 나왔을 때 잠깐 생각나는 대로 대충 낙서해 본 것이 있습니다. (말 그대로 대충 낙서입니다. 이대로 쓰자는 뜻은 아닙니다. 너무 진지하게 받아들이지는 마시고, 브레인스토밍 정도로 생각해 주시길...)
다른 분들이 여러 가지 말씀을 해 주셨습니다만 저도 첨언하자면,
"의업과 약업의 현실적 관계"도 한 가지 중대한 이유입니다. 제약회사 직원이 의사에게 굽실거리다 못해 예비군 훈련을 대신 가거나, 수술을 대신 한다는 기상천외한 뉴스 다들 한번쯤 보셨을 텐데요.
원론적으로는 의사가 약에도 빠삭해야 하지만, 현실적으로는 자기 전공분야도 너무 방대하고 약학도 너무 방대해서 그러기 어렵습니다. 마치 소프트웨어 엔지니어 중에 하드웨어 덕질까지 하는 경우는 소수이고 대부분은 그냥 맥북 사는 것과 비슷하게, 의사들의 약 지식도 한계가 있는 거죠. 어떤 약을 안 쓰는 게 무슨 이유가 있어서가 아니라 진짜로 그 약의 존재를 몰라서인 경우가 허다합니다. 그러니 약 성능 똑같아도 영업에 따라 억 단위가 왔다갔다 하고, 그러니 제약회사의 영업이 엽기뉴스의 영역으로 가는 것이죠.
이런 시장환경에서 의사들에게 약 이름과 성분 이름의 대조표를 매년 새로 외우라고 하면 망하겠죠? 그래서 어떻게든 이름만 보면 성분을 알게 하려고 발버둥치는 것입니다.
그러면 반대로 성분명과 전혀 무관한 약 이름은 어떻게 나오는지도 짐작이 되시죠? 그렇습니다. "처방전 필요없는" 약은 성분명 쿨하게 버리고 일반소비자에게 호소하는 작명을 하는 경향이 있습니다. 그리고, 처방전이 필요하더라도 동일성분의 약이 많거나 저네릭 경쟁이 벌어지는 경우에도 튀는 이름으로 차별화를 꾀하는 경향이 있죠.
RE: https://serafuku.moe/notes/a6lapo16c2
저도 두 가지 쟁점 모두 동의하는 편입니다. 그리고, 별개의 이야기입니다만, $
를 가르칠 때에는 그냥 문법이라고 가르치는 게 학습자의 이해와 응용이 압도적으로 빠르고 좋았습니다.
"이건 여기서부터 뒤로는 다 괄호로 감싸겠다는 뜻이라고 생각하세요."
이러면 한 방에 설명이 끝나고, 필요성이나 편리성에 대해서도 알아서들 납득하는 것이죠. 연산자 우선순위나 좌결합 우결합 등은 그게 되고 나서 얘기하고요. 그러면 "아, 이게 그래서 이렇게 되는 거였군요?" 하면서, 훨씬 쉽게 이해합니다. 이걸 거꾸로 좌결합 우결합 어쩌고부터 가르치려고 하면 다들 꾸벅꾸벅 졸아요... ㅋㅋ ㅠㅠ
(결국 "모나드란 무엇인가"부터 배우면/가르치면 안 된다는 주장과 같은 맥락입니다.)
RE: https://hackers.pub/@bgl/01963c3b-98fa-7432-a62f-0d2dfc0691bf
드디어 @xtjuxtapose 님이 기다리시던 차단 기능이 구현되었습니다. 차단할 사용자의 프로필 페이지에 가서 팔로·언팔로 버튼 오른쪽에 보이는 말줄임표 아이콘에 마우스 커서를 갖다 대면 (모바일에서는 터치하면) 상세 메뉴가 나오는데, 그 안에 팔로워 삭제 버튼과 차단 버튼이 생겼습니다.
ActivityPub 프로토콜 수준에서는 차단은 Block
액티비티를 차단한 액터에게 보내며, 차단을 해제할 경우 Undo(Block)
액티비티를 보냅니다. 그러나, 그 액티비티를 받은 인스턴스의 구현이 차단한 사용자의 콘텐츠를 볼 수 없도록 막지 않을 수도 있습니다…만, 실질적으로는 모든 구현이 막고 있습니다. 아, 당연하지만 차단은 자동적으로 상호 언팔로를 수행합니다. 차단을 해제하더라도 풀렸던 팔로 관계는 자동적으로 회복되지 않습니다.
@xtjuxtapose 일단은 한 번 더 물어보도록 하긴 했습니다만… 이걸로는 부족할까요?
@hongminhee洪 民憙 (Hong Minhee) 저는 부족하다고 생각합니다...! ㅋㅋㅋㅋㅋ 유저들이 그냥 일반적인 Yes/No 다이얼로그는 조건반사적으로 Yes 해 버리는 실수를 많이 한다고 생각합니다... ㅋㅋ ㅠㅠ
UI로 노출하는 건 나중에 만드려고 했지만, 어차피 테스트도 해야 해서 UI로도 노출했습니다. 자신의 팔로워 목록 페이지에 가시면 각 팔로워마다 오른쪽 위에 X 모양 아이콘이 생겼을 겁니다. 그걸 누르면 팔로워를 삭제할 수 있습니다. (X로 치면 “블언블”한 효과.)
@hongminhee洪 民憙 (Hong Minhee) 방금 신기능 확인하러 들어가 봤는데, 실제 렌더링 결과를 보니 드는 생각이 있어 의견 드립니다. 그냥 🗙 를 쓰는 것은 좀 위험하지 않을까 하는... 🗙 는 단순한 "창 닫기"의 의미로도 많이 쓰이기 때문에, 팔로어 목록도 일종의 인박스("이 사람이 당신을 팔로했습니다" 같은)로 여겨서, 각각의 상자를 대수롭지 않게 🗙 를 눌러서 없애 버리려고 하는 일이 발생하지 않을까 싶습니다.
"블언블"에 해당하는 강력한 조치이니만큼, 함부로 누를 수 없게 "빨간 버튼" 급의 경고가 있어야 하지 않나 하는 생각입니다. 이상적으로는 ellipsis 메뉴 안에 숨기고, ellipsis 눌러서 메뉴를 띄우면 적어도 "빨간 버튼"에 준하는 (즉 딱 봐도 위험해 보이는) 항목으로 등장하면 좋겠네요.
읔ㅋㅋㅋㅋㅋㅋㅋㅋㅋ
Hackers' Pub에 차단 기능을 만들고 있는데, A가 B를 차단했을 때 A가 B의 콘텐츠를 볼 수 있어야 한다고 생각하시나요? 물론 타임라인 등에서는 기본적으로 다 가려지겠지만, B가 올린 콘텐츠의 퍼머링크를 굳이 찾아서 들어갔을 때 말이죠. 아, 당연히 B 입장에서는 A의 콘텐츠는 전혀 볼 수 없고요. (A가 공개로 올린 콘텐츠를 B가 로그인하지 않은 채 볼 수야 있겠지만…)
@hongminhee洪 民憙 (Hong Minhee) 트위터 같은 경우는 내가 차단한 사용자의 페이지를 퍼머링크 등으로 굳이 찾아 들어갔을 때 경고 다이얼로그 형태의 UI 를 띄우고, 거기서 확인을 누르면 비로소 내용을 보여주는 식으로 동작하더군요. 괜찮은 해법이라고 생각했었습니다.
해커즈 퍼브에서 "사용자"에 해당하는 부분에 스타일시트 적용 전후 비교
생각해 보니 에모지 반응 찍을 때 게시물이 Mastodon에서 작성된 경우에는 선택지를 없애는 게 나으려나…? Like
액티비티로 표현되는 ❤️ 이외에는 모두 Mastodon이 받아들이지 않는 EmojiReact
액티비티로 표현되기 때문에, 게시물 작성자가 어차피 에모지 반응을 볼 수 없으므로…
@hongminhee洪 民憙 (Hong Minhee) 이게 혹시 대상이
EmojiReact
를 받아들이는지 아닌지도 스펙에 의해 식별되는 것인가요? 만약 그렇다면 즉시 그렇게 하셔도 좋을 것 같습니다. 그런 것이 아니라 대상이 마스토돈인지 아닌지를 가지고 직접 판단을 내려야 하는, 즉 프로토콜에 없는 정보인데 하드 코딩으로 대응해야 하는 것이라면 조금 더 고민하실 여지가 있을 것 같네요...
'악플'이라는 말이 그 자체로 암시하는 바가 있다. 악글, 악메시지 같은 황당한 조어는 없다. 그러나 '악플'은 아주 당당하게 한국어 언중의 삶에서 확고한 위상을 점유하고 있다. 이 근본 없는 신조어가 뉴스 헤드라인에 박혀 있어도 아무도 토를 달지 않을 정도다.
오직 댓글만이 이럴 수 있다. 오직 댓글만이 사람을 자살로 몰고 가는 죄악의 주범으로 번번이 지목될 수 있고, 오직 댓글만이 정치 여론 조작의 혐의로 관계자들을 징역에 처할 수 있다. 자기 블로그에 글 썼다고 이렇게까지 지탄을 받거나 처벌을 받는 일은 없다. 이것은 의미심장하다. 이것은 개개인의 품성 문제가 아니다. 댓글이라는 시스템이 갖는 구조적 원인이 분명히 있는 것이다.
그런 의미에서 트위터 역사상 가장 훌륭한 기능 추가도 "댓글 안 받기" 기능이라고 생각한다. 그러므로 해커즈 퍼브에 댓글 안 받기 기능이 생기기만 기다리는 중...
@kodingwarriorJaeyeol Lee
@xtjuxtapose
@lionhairdino 언급된 사용자 이름 스타일에 변화를 줘 봤습니다.
쿠버세란 옵스 엔지니어 연봉을 뜻한다
@kodingwarriorJaeyeol Lee
@lionhairdino 지금 생각해 보니 그냥 두꺼운 글씨를 안 쓰면 좀 낫지 않을까 싶기도 하네요.
@hongminhee洪 民憙 (Hong Minhee)
@kodingwarriorJaeyeol Lee
@lionhairdino 저는 그냥 "유저"에 해당하는 부분 그 자체에 별도의
background
와 border
를 부여하는 것이 가장 일반적이면서 직관적이고 식별성도 좋다고 생각합니다만... (스크린샷은 각각 border-radius
를 사용한 경우와 box-shadow
를 사용한 경우입니다.)
쿠버네티스도 간단하게 쓸 수 있죠. 요즘 k3s 같은거 쓰면 구성도 쉽고, 사용도 그냥 kubectl apply -f deployment.yaml
하면 끝인데. 이렇게만 쓰면 도커컴포즈랑 그렇게 다르지 않습니다.
근데도 쿠버를 쓰지 말라는 이유는, '잘못 쓸 여지'가 많기 때문입니다
쿠버를 쓰다 보면, 괜히 GitOps 하고 싶어서 ArgoCD 깔고, 서비스 메시 한다고 Istio 깔고, prometheus 깔고, thanos 셋업하고, EFK 스택 만들고, 이러다보면 아무도 유지보수 못하는 쿠버네티스 클러스터가 완성됩니다. 아니면 옵스 엔지니어가 주 40시간 전체를 이거를 간신히 존속시키는데에만 다 쓰고 나머지 아무것도 못 합니다.
이런거 다 참을 수 있고 k3s로 깔고 kubectl apply -f
만 치고 살거면 쿠버 쓰셔도 됩니다.
첨부한 사진이 무슨 링크드인에 '2025년 쿠버네티스 표준 구성' 이라고 돌아다니던데, 제발 이러지 마세요.
도커컴포즈 쓰면 이런걸 아예 못 하게 되니까 오히려 장점인거죠. 잘못 쓸 여지가 없음.
Hackers' Pub의 에모지 반응 기능은 Mastodon의 좋아요, Misskey 계열, Pleroma 계열, kmyblue 및 Fedibird의 에모지 반응 기능과 호환됩니다. 기술적으로는 기본 에모지인 ❤️는 Like
액티비티로 표현되며 그 외 나머지 에모지는 EmojiReact
액티비티로 표현됩니다. Mastodon, kmyblue, Fedibird의 좋아요는 ❤️ 에모지 반응으로 변환됩니다 (Misskey의 동작과 유사). 또한, Misskey 계열과 달리 한 사람이 한 콘텐츠에 여러 에모지 반응을 남길 수도 있습니다 (Pleroma 계열의 동작과 유사). Hackers' Pub 사용자가 남길 수 있는 에모지 반응은 ❤️, 🎉, 😂, 😲, 🤔, 😢, 👀 이렇게 7종이며, 그 외의 에모지 및 커스텀 에모지는 보낼 수는 없고 받는 것만 됩니다.
@hongminhee洪 民憙 (Hong Minhee) 일곱 가지 에모지 선정은 탁월하다고 생각합니다. 널리 쓰이는 👍 나 🚀 은 의미적으로 ❤️ 와 중복되므로 넣지 않으신 걸로 이해하였습니다. 😅 와 💔 는 추가하면 어떨까요?
@sunwoo1524 그 이야기 하면 도미노피자 스쿠터를 빼놓을 수 없죠
https://www.youtube.com/watch?v=n17B_uFF4cA
똑같은 얘기를 닉스, 닉스오에스, 닉스옵스로도 할 수 있어요. "아 이거 걍 선언형으로 파일 작성하고 nixops deploy --check
하나만 때리면 알아서 이것저것 다 뜨고 다 설정될 텐데 괜히 귀찮게 왜 쿠버네티스를"
근데 현실적으로는 그냥 도커 컴포즈가 제일 삽질의 총량이 적죠...
@campanulaLuminα 축산업계에서 콩고기 등 비건고기에 아예 "고기"나 "육" 등의 말을 쓰지 못하게 해야 한다고 강력 반발하고 있다는 얘기를 봤는데요. 전통적 육류업계의 위기감은 이해하지만 도저히 대체할 만한 말이 마땅치 않을 텐데... 라는 생각이 들더라고요.
쿠버는 마세라티 문제가 맞음! 제발 쿠버 섣불리 쓰지마!
어케어케 쿠버를 쓰기로 결정했다면
istio 같은거 제발 쓰지마!!!!!!
(도커도 쓰기 싫고 그냥 샌드박스된 바이너리 하나 돌리면 전부 알잘딱 돌아갔으면 좋겠어요)
RE: https://hackers.pub/ap/notes/01961970-a29f-78ff-baaf-1db2056a78e1
@saschanazKAGAMI🏳️🌈🏳️⚧️ 그게 제일 바람직하다는 것에 저도 동의해요. 다만 현실적으로는 아무래도 DB라든지 MQ라든지 이것저것 같이 띄워야 하다 보니, 서비스 운영을 하려다 보면 그런 전체 형상 관리를 위한 추상화 계층이 있기는 있어야 하는 것 같아요. 물론 도커 컴포즈를 안 쓰고 앤서블로 그런 모든 것을 관리할 수도 있고, 아예 닉스나 닉스오에스를 써서 더 아름답게 할 수도 있겠습니다만... 도커 컴포즈 정도면 타협 가능한 것으로...
저, 저도 90% 이상의 경우 도커 컴포즈 정도가 적당한 추상화 수준이라고 생각해요...
실제로 쿠버네티스 쓰는 팀에서 일해 본 경험도 그렇고, 주변 이야기 들어 봐도 그렇고, 도입하면 도입한 것으로 인해 증가하는 엔지니어링 코스트가 분명히 있다는 점은 누구도 부인하지 않는 것 같은데요. 쿠버네티스를 제대로 쓰는 것 자체도 배워야 할 것도 많고, 엔지니어가 유능해야 하고, 망치도 들여야 하고... 웬만하면 전담할 팀이 필요하지 않나 싶어요. (전담할 '사람' 한 명으로 때우기에는, 그 사람 휴가 가면 일이 마비되니까.)
엔지니어만 100명이 넘는 곳이라면 확실히 도입의 이득이 더 크겠지만, 반대로 혼자 하는 프로젝트라면 도무지 수지타산이 안 나올 것이라고 생각합니다. 따라서 쟁점은 그 손익분기점이 어디냐일 텐데... "대부분의" 서비스는 대성공하기 전까지는 도입 안 해도 되지 않나, 조심스럽게 말씀드려 봅니다. 즉 쿠버네티스가 푸는 문제는 마세라티 문제인 것이죠...
특히 클라우드 남의 컴퓨터 를 쓰지 않고 베어메탈 쓰는 경우는 더더욱...
RE: https://hackers.pub/@hongminhee/019618b4-4aa4-7a20-8e02-cd9fed50caae
에모지 반응 기능이 배포되었습니다. 당분간 버그가 좀 있을 수도 있지만 양해 바랍니다. 전 이제 차단을 구현하러 가겠습니다…
@xtjuxtapose
@hongminhee洪 民憙 (Hong Minhee) so are we all 랜선인연 here?
@liaizonwakest
@hongminhee洪 民憙 (Hong Minhee) You made my day 😂 I'd say that's correct
@liaizonwakest Oh, also there are another terms like 現實 (hyeonsil; “reality”) or 現生 (hyeonsaeng; “real life”) in Korean.
@hongminhee洪 民憙 (Hong Minhee)
@liaizonwakest Also interesting is the Korean neologism 실친 which almost exclusively means "real-life friend as opposed to a cyberspace friend."
Even more interesting is 랜선인연, an antonym of 실친. A rough direct translation of 랜선인연 would be "LAN cable relationship."
이 농담보다 더 블랙 코미디 같은 현실: 한국 아직도 트럼프랑 단 한 번도 통화 못함.
https://news.jtbc.co.kr/article/NB12241795
지금 트럼프 취임 후 석 달이 돼 가는데 한국-미국 수반 간 통화 한 번도 없었음.
RE: https://planet.moe/users/SiLVER01/statuses/114277521678428010
패치 릴리스할 때 되도록이면 많은 버그 수정을 하나의 릴리스에 담고 싶은 충동.
@hongminhee洪 民憙 (Hong Minhee) (소근소근) 보는 사람들은 대개 더 잘게 쪼갤수록 좋아합니다. 체인지로그 한 덩어리가 너무 길면 읽을 엄두가 안 나서요. 더 자주 릴리스하면 더 활발하고 더 건강한 프로젝트처럼 보이게 되는 것은 덤...
@hongminhee洪 民憙 (Hong Minhee)
@arkjunJuntai Park
@xtjuxtapose 앗! 저도 4월 3일에 그분에게 DM을 받았습니다! 유명하신 분인가요?
@curry박준규 그냥 스팸이에요. 하도 연합우주에 자신을 "fediverse chick"이라고 소개하는 스팸을 많이 뿌리고 다녀서 유명합니다.
언어의 사회성! 중요합니다
하지만 이게 언어의 영원한 떡밥인데
바로 규범주의 vs 기술주의 입니다
사회성만을 인정하면 기술주의가 됩니다. 그러면 온갖 문법 파괴, 해괴한 표현 등을 사람들이 많이 쓴다는 이유로 인정하게 됩니다.
그게 뭐가 나쁘냐? 사람들이 많이 쓰면 되는거 아니냐? 라고 할 수도 있지만,
의미를 명확하게 전달하는 목적으로써의 언어에서는 이런 식으로 언어가 변화하게 되면 의미를 전달하기가 힘들어집니다.
예를들어 같이
라는 단어를 사람들이 하도 가치
라고 소리나는 대로 적어서 가치
도 표준어로 인정해버리면, 가치
(價値) 와 같이
를 적힌 글로만 봤을 때 구분할 수 없어집니다. 문맥으로 파악해야하죠.
그렇기 때문에 규범주의가 등장합니다. 명확한 뜻을 잘 전달하기 위해, 언어가 가진 여러가지 규칙성을 존중하고 이 규칙에 맞게 적어야한다는 것입니다.
띄어쓰기를 잘 해야 "아버지가방에들어가신다" 같은 모호한 문장이 안 생긴다는 것이죠.
하지만 이러면 대부분의 사람들은 남사스럽다
라고 하는데 국립국어원만 혼자서 남우세스럽다
가 표준어라고 주장하면 현실과 괴리가 있겠죠
그래서 규범주의와 기술주의 세계관 최강자들의 싸움은 이거 보여주려고 어그로끌었다 영원한 떡밥인 것입니다
그리고 에모지 vs 이모지 는 규범주의뿐만이 아니라 언어의... ethnicity 라고 표현해야하나..? 와도 관련이 있습니다에모지
는 원래 일본어입니다. 그림문자인 에모지에서 왔으니까 에모지라는 것이죠.
이걸 서양권에서 이모지라고 발음한다고 우리도 이모지라고 부르면 원어를 존중하지 않는 꼴이 됩니다
세인트 피터스버그, 워쏘우, 조안 오브 아크 등등의 예시가 있습니다
미국/영국인이 그렇게 부르는 것은 이해할 수 있지만 우리가 그걸 따라갈 필요는 없잖아요?
의견: 해커즈 퍼브에 정말로 시급한 기능은 에모지 반응 기능이 아니다. 차단 기능과, 댓글 안 받기 기능이다. 당장 스팸에 대응할 방법이 없다.
간혹 "이모지"가 아니라 "에모지"라고 쓰는 이유에 대한 질문을 받습니다. 여기다 써 두면 앞으로 링크만 던지면 되겠지?
요약: 에모지라서 에모지라고 씁니다.
"이모지"라는 표기는 아마도 "emoji"가 "emotion"이나 "emoticon"과 관련이 있다고 생각해서 나오는 것으로 보이는데요. "emoji"와 "emoticon"은 가짜동족어(false cognate)입니다. "emoji"는 일본어 絵文字(에모지)를 영어에서 그대로 받아들여 쓰고 있는 것입니다. 심지어 구성원리도 에모+지가 아니고 에+모지(絵+文字)입니다. "emotion"과 유사해 보이는 것은 순전히 우연일 뿐, 계통적으로 전혀 아무 상관이 없습니다. "이모티콘"과 "이미지"의 합성어가 아닙니다. (그랬으면 "-ji"가 아니라 "-ge"였겠죠.)
그리고 그렇기 때문에 에모지를 에모지로 표기할 실익이 생깁니다. :)
, ¯\_(ツ)_/¯
, ^_^
등은 이모티콘입니다. 반면 😂는 명확히 에모지입니다.
프로그래머에게 이건 정말 중요한 구분입니다. "이모티콘을 잘 표현하는 시스템"과 "에모지를 잘 표현하는 시스템"은 전혀 다른 과제이기 때문입니다. 에모지는 "그림 문자"라는 원래 뜻 그대로, 어떤 문자 집합(예를 들어 유니코드)에서 그림 문자가 "따로 있는" 것입니다. 내부 표현이야 어떻든, 적어도 최종 렌더링에서는 별도의 글리프가 할당되는 것이 에모지입니다. "무엇이 에모지이고 무엇이 에모지가 아닌가"는 상대적으로 명확합니다(문자 집합에 규정되어 있으니까).
반면 이모티콘은 "무엇이 이모티콘인가?"부터 불명확합니다. 우선 대부분의 이모티콘은 이모티콘이 아닌 문자를 조합하여 이모티콘이 만들어지는 형식입니다. 예를 들어 쌍점(:
)이나 닫는 괄호()
)는 그 자체로는 이모티콘이 아니지만 합쳐 놓으면 :)
이모티콘이 됩니다. 하지만 조합에 새로운 의미를 부여했다고 해서 다 이모티콘이라고 부르지도 않습니다. -_-
같은 것은 대다수가 이모티콘으로 인정하지만, ->
같은 것은 이모티콘이라고 부르지 않는 경향이 있습니다.
-
문자와 >
문자에는 화살표라는 의미가 없기 때문에, ->
조합과 화살표의 시각적 유사성에 기대어 화살표라는 새로운 의미로 "오용"한 것은 이모티콘의 구성 원리에 해당합니다. 하지만 화살표는 인간의 특정한 정서(emotion)에 대응하지 않으므로 이모티콘이라고는 잘 부르지 않습니다. 그렇다고 얼굴 표정을 나타내야만 이모티콘인가 하면 그렇지도 않습니다. orz
같은 것은 이모티콘으로 간주하는 경향이 있어 보입니다. 오징어를 나타내는 <:=
는 이모티콘인가? 이모티콘이 맞다면, 왜 ->
는 이모티콘이 아니고 <:=
는 이모티콘인가? 알 수 없습니다. ㅋㅋ
과 ㅠㅠ
는 둘 다 정서를 나타내는데, ㅠㅠ
만이 아이콘적 성질을 가지므로 이모티콘이고 ㅋ
는 이모티콘이 아닌가? 알 수 없습니다. 만약 ㅋ
만 이모티콘이 아니라고 한다면, ㅋ큐ㅠ
에서 큐
는 이모티콘인가 아닌가?? 알 수 없습니다. 이 알 수 없음은 이모티콘의 생래적 성질입니다. 어쩔 수 없죠.
(명언)
@hongminhee洪 民憙 (Hong Minhee) 멋진 발표 잘 해 내시길 기원합니다. 근데, 발표를 하시는군요? 전에 발표를 앞두고 고통의 메시지를 남기셨길래 발표 싫어하시는 줄 알았는데? 그것도 일본어로?
普段、日本語を読む時、漢字の意味だけを見て韓国の漢字音で読む事が多く、意味は分かっていても正確な読み方が分からない事が多いのだが、明日の発表を控え、私の拙い日本語力が借りを背負って帰ってきた。発表の原稿で、読み方がよく分からない単語に一々振り仮名を付ける中。😮💨
@hongminhee洪 民憙 (Hong Minhee) ご苦労様です。応援しております。そういえば、振り仮名をつけるのって「LLMに任せたら人間より迅速かつ正確にやってくれる」仕事の例ですね。原稿に振り仮名をつけるシステムは自動化する甲斐があるかもしれませんね
@xtjuxtapose 現時点では私が手動で招待状を送っていますが、正式に申請フォームが必要な様ですね…
@hongminhee洪 民憙 (Hong Minhee) Twitterはイーロンされててもうだめだ、ActivityPub対応のアカウントが欲しい → この「ハッカーズ・パブ」がよさそうだな → 会員登録がない → 管理者に申し込み → 管理者にメッセージを送るには、ActivityPub対応のアカウントが必要
😂
ふと疑問。ここ、招待制なので、興味を示す日本語圏のハッカーさんがいても、合流できないのでは…?
すると、一般登録はまだ早いとしても、登録申し込みフォームとかが必要なのか?
創立者さんには別の計画がおられるだろうか
この「ハッカーズ・パブ」(Hackers' Pub)は、ハッカーたちが集まるネット上の場所であって、各自ブログも出来て、レスも出来て、掲示板みたいにも使えて、ユーザーの望みであればFediverseなる世界中の 変人 みんなのネットワークとも繋がりうる、言わばハッカーたちのための新しいツイッターみたいなサイトらしい。
ツイッターより優れた部分は何かというと、技術的に何時間も喋れそうだが、私が注目するのは、まずここの創立者および主任開発者である洪 民憙 (Hong Minhee)先生はイーロンなどよりかはずっとましな方で、頼れる方だということ。ユーザーの自由に関する彼の哲学、このサイトの設計思想などは信用できる。多分。なにしろ彼は今やFLOSS(Free/Libre/Open-Source Software)の開発を専業としておられるのだ。
なお、例えひょんな事で洪さんがイーロン並みに暴走する、由々しき事態でも、ここはツイッターみたいにはならないということ。この「ハッカーズ・パブ」はソースコードに限らず、プロトコルや作動原理も全部FLOSSなので。まあ洪さんの暴走なんてないでしょうけどね。
エンジニアとして生きてきた分、こういうサービスを運営する側の負担を大体把握しているので、自分ではやらないと思うし、ここが盛り上がったところで (盛り上げたところで) 自分の人生に役立つかというと、そうも言えない。が、「みんながTwitterとかFacebookとかInstagramなどを使っている」今の状態と比べれば、ハッカーズ・パブがもっと使われる未来の方が好ましいことに違いはない。そう考えると、洪さんの努力に感謝せざるをえない。
で、パブに日本語圏のユーザーをもっと招くのが創立者の方針というかご希望らしく、衝動的に参加してみる。これから機会あれば、日本語でも面白い話をここに残すのを目指してみる。自分日本語全然下手ですが。よろしく。
@hongminhee洪 民憙 (Hong Minhee) Thank you for your amazing work that just goes on and on. By the way, here's one of the reasons I think "blocking" is the first-priority feature in Hackers' Pub. (sigh)
https://hackers.pub/@rollbacks74@occm.cc/0195f7ec-5551-7df6-ba9e-b7716a9214b2
Of course, blocking alone won't really address the issue. I guess we're already being targeted by spammers...
@hongminhee洪 民憙 (Hong Minhee) 이 포스트를 해커즈 퍼브에 공유했더니, 본문에 있는 링크 중 마지막의 "실제로 ArcGIS 의 동남아시아 지진 지도를 보면" 부분의 링크만 없어지네요. 해커즈 퍼브 쪽 버그일까요?
마인어에는 지진을 뜻하는 고유어가 없다...?
마인어는 사용인구로 따지면 오스트로네시아어족의 맹주라 할 수 있는 큰손이다. 오늘날 말레이시아와 인도네시아를 비롯한 지역에서 쓰이며, 총 화자는 2억 5천만 명이 넘을 것으로 추산되니, 한국어는 명함도 내밀 수 없는 규모다. 언어학계는 마인어의 조상이 PAn(Proto-Austronesian language, 오스트로네시아조어)이라는 것을 거의 확신하고 있다.
PAn 은 수천 년 전 타이완섬에 살던 사람들이 썼을 것으로 추정되는 언어다. 이 사람들은 거대한 타이완섬에 살다가, 어째 답답했는지 아니면 거기 계속 살다가는 먼 미래에 정체자를 배워야 하는 운명을 예감한 것인지, 바다로 뛰쳐나갔다. 이들은 유유히 배를 타고 대양을 누비며 세계 곳곳에 정착한 것으로 추정된다.
전근대에 원양 항해라니 죽음을 자초하는 행위 아닌가? 게다가 타이완섬 앞으로 나가면 약속의 열대저기압 지옥태풍존이잖아? 그런데 PAn 으로부터 분화한 언어들, 오스트로네시아어족의 분포 범위를 보면 무시무시하다. 동으로는 태평양 건너 남미에서, 서로는 인도양 건너 아프리카 대륙 앞 마다가스카르에 이른다! 유럽인들이 "Age of Discovery" 운운하기보다 수천 년 전에, 나침반도 육분의도 없던 시절에, 지구에서 가장 큰 바다를 건너 다닌 비결? 현대의 학자들은 이런저런 짐작만 할 뿐이다. 이들의 항해술은 주로 문자가 아니라 구술로 전승되었기 때문이다.
그런데 아무튼 기원이 타이완섬이고, 타이완섬은 환태평양 지진대의 영향권에 있으므로, PAn 에도 "지진"을 뜻하는 어근이 있는 것은 거의 확실시된다. 현재 언어학계의 다수설은 linuʀ 이다. 여기서 많은 파생형이 발생하였는데 예를 들어 linog 만 봐도 수우우많은 오스트로네시아계 언어들이 이 말을 "지진"으로 쓰고 있음을 알 수 있다.
하지만 마인어에는 이 "linuʀ"에서 파생한, "지진"을 뜻하는 고유어가 전혀 보이지 않는다. 어떻게 된 것일까? 당장 지리적으로나 언어계통적으로나 마인어와 인접한 자바어에도 linuʀ 에서 왔음이 분명해 보이는 ꦭꦶꦤ꧀ꦝꦸ (lindhu) 가 있는데, 마인어에서는 뜬금없이 gempa bumi 라는 표현을 쓴다. 알고 보면 이것은 산스크리트어(?!) भूमिकम्प (bhūmikampa) 에서 온 것이다.
마인어의 조상인 고대 말레이어에 산스크리트어 차용 단어가 많은 것은 사실이다. 하지만 아무리 그래도 "지진"은 인간 생활에 직결되는 중요한 단어이고, 바로 근처의 다른 모든 오스트로네시아어족 정착지에서 모두 "linuʀ" 파생형을 쓰고 있는데, 왜 고대 말레이어는 "지진"의 고유어를 버리고 산스크리트어를 썼을까?
흥미로운 가설은, 하필 마인어가 분화 형성된 지역만 지진대를 멋지게 비켜 가면서, 지진이 너무 오랫동안 없었기 때문에 (!) 고유어가 사멸했다는 것이다.
마인어는 오늘날에는 말레이시아와 인도네시아 전역에서 널리 쓰이지만, 옛날에는 말레이 반도와 말레이 제도에서 주로 쓰는 언어였고, 그보다 더 아주 먼 옛날에는 보르네오 섬의 서부에서 쓰인 것으로 추정된다. 실제로 ArcGIS 의 동남아시아 지진 지도를 보면, 이 지역들만 절묘하게 지진대에서 벗어나는 것을 볼 수 있다...!
오버라이딩 을 재정의라 번역하는데, 왜 "(덮을 복)정의"라 안했을까? (물론 나도 어색하다) 재정의는 뭔가 기존 것을 치워버리고, 다시 정의하는 것이고, 오버라이딩은 기존 것을 그대로 두고, 그 위에 레이어를 두는 느낌이라 같은 듯 다르다.
만일 복정의라 번역한다면, 오버로딩을 중(거듭 복) 정의라 하는데, 이 것과 같은 글자를 쓰는 문제가 생길 수 있겠다.
재정의, 중복 정의는 나도 번역이 마음에 들긴 한데, 늘 재정의가 살짝 걸리적 거린다.
닉스 공부하며 노트하다가 비슷한 듯 다른 오버레이, 오버라이딩의 적당한 번역어가 떠오르지 않아 잡생각으로 빠졌다.
널리 알려진 적당한 짧은 번역 단어(보통 한자 한 두 글자)가 없으면, 그냥 원문이 낫지 않을까? 표기만 Overlay가 아니라 오버레이로.
@lionhairdino 말씀하신 접두사들에 덧붙여서, 이른바 "연산자 오버로딩"처럼 두 정의가 하나의 이름에 동시에 붙어 있는 경우 竝(나란히 병)을 쓰는 것도 고려함 직하다는 생각을 해 봤습니다. "병행", "병립", "병치" 등에 쓰이는... "오버레이"의 경우는 疊(겹쳐질 첩)이 먼저 떠오르네요. "중첩"이라든지 "첩첩산중" 등에 쓰이는 그거요.
그리고 꼭 한자어에는 한자 접두사를 붙여야 한다는 법이 있는 것은 아니니, 과감하게 고유어를 쓰는 것도 생각해 볼 수 있겠습니다. "겹정의"라든지, "덮정의"라든지... 아예 "겹뜻"이라든지...
쿨엔조이 M.2 SSD 방열판 벤치마크 4년이 넘은 글이긴 한데...
@hongminhee洪 民憙 (Hong Minhee) 프로필 사진으로 쓸 수 있는 그림 형식 중에 SVG가 없는데, 혹시 액티비티퍼브의 한계인가요? (갑자기 궁금해서)
juxtapose @xt@hackers.pub
인용: https://hackers.pub/@bgl/0195f0eb-88dd-77e3-a864-f0371e85b270
스태키지(Stackage)는 하스켈이 (의외로) 성공하여 해키지(Hackage)가 거대해지자, 그 거대함 때문에 발생하는 불편을 해소하는 한 방책으로 고안되었습니다. 그런데 당시에 해키지만큼 거대한 생태계를 갖추고 있으면서 동시에 "컴파일이 성공한다면 실행도 아마 성공할 것"이라는 훌륭한 속성을 갖는 언어는 달리 없었죠. 러스트가 있지 않으냐? 스태키지가 처음 나온 게 2012년입니다. 러스트는 아직 crates.io 도 자리잡기 전이었죠. (사실 이 시점의 러스트는 지금과는 언어 자체가 많이 다른 언어였고요.)
하스켈의 패키지 버저닝 정책에 따르면, 후방호환성 깨지는 변경은 반드시 메이저 버전을 올려야 하고, 마이너 버전만 올리는 변경은 후방호환성 유지될 때에만 가능합니다. 이런 정책 당연히 좋지만, 사람이 내용을 잘 숙지하고 지켜야 의미가 있습니다. 후방호환성을 깨면서 마이너 버전만 올리는 실수는 어떤 개발자든 할 수 있죠.
그런데 하스켈의 경우, 인간이 실수해도 기계가 잡아 줄 여지가 처음부터 매우 큰 언어이고, 예를 들어 어떤 함수가 핵미사일을 발사할 수 있는지 아닌지를 함수 실행 없이도 식별할 수 있는 언어라고들 하죠. 하스켈의 마지막 표준이 2010년에 나왔으니 2010년을 기준으로 하면, 당시 하스켈이 제공하는 "컴파일 시간 보장"의 범위는 그야말로 독보적이었습니다. (하스켈보다 더 강한 보장을 제공하는 언어들은 있었지만, 그만한 라이브러리 에코시스템이 없었고요.)
그래서 스태키지라는 모형이 의미가 있었습니다. A라는 패키지의 새 마이너 버전이 해키지에 올라오면, 스태키지에서 자동으로 가져갑니다. 스태키지는 같은 큐레이션에 포함된 다른 패키지들 중 A에 의존하는 패키지들을 추리고, 얘네한테 A의 새 버전을 먹여도 빌드가 잘 되는지 검사합니다. 이들 중 하나라도 깨지면? A 패키지는 해키지에서는 버전이 올랐으나, 스태키지에서는 버전이 오르지 않게 됩니다. 그리고 A 패키지의 제공자에게 자동으로 깃허브 멘션 알림이 갑니다!
("패키지 저자"와 "패키지를 스태키지에 제공하는 제공자"가 같은 사람이 아니어도 된다는 점도, 노동력의 효과적 분담에 한몫했습니다.)
이 모든 과정이 자동화되어 있는데, 이것만으로도 99.99%의 호환성 문제가 사라지고, 그러면서도 웬만한 라이브러리들은 충분히 최신 버전으로 쓸 수 있습니다. LTS와 나이틀리가 구분되어 있는 것도, LTS가 GHC 버전에 대응하여 여러 버전이 유지되는 것도, 실제 개발에서 아주 편리하고요.
스태키지가 개쩌는 부분은 "버저닝 정책에 완벽하게 부합하는데도 현실적으로 후방호환성 파괴를 일으키는" 변경점들도 잡아낸다는 것입니다. 아주 단순한 예시로 "많이 쓰이는 이름"이 있습니다. 예를 들어 어떤 라이브러리가 아주 널리 쓰이는데, 제공하는 네임 바인딩은 몇 개 안 되고, 그래서 대부분의 사용자가 그걸 그냥 전역 네임스페이스에 다 반입해서 쓴다고 칩시다. 어느 날 이 라이브러리가 process
라든지 f
같은 새 네임을 추가 제공하기 시작하면? 정책 규범에 따르면, 이것도 마이너 버전만 올려도 되는 변경점이 맞습니다. 하지만 현실에서는 많은 패키지들을 박살내겠죠. 언어를 막론하고 있을 수 있는 일인데, 이런 것들까지 스태키지에서 아주 높은 확률로 다 잡힙니다.
그리고... 이런 게 잘 된다는 것은 언어 그 자체의 특성도 있지만, 생태계 전체의 문화적인 특성도 있는데요. 하스켈도 라이브러리 제작자가 충분히 악독하다면, 컴파일러에게 안 잡히면서 인류문명멸망시키는 코드 변경을 얼마든지 슬쩍 끼워넣을 수 있습니다. 악의가 아니더라도 부주의로 후방호환성을 깰 수 있고요. 그런데 하스켈은 대부분의 라이브러리 설계자들이 "되도록 많은 것을 컴파일 시간에 잡고 싶다"라는 명확한 욕망으로 설계를 하는 경향이 뚜렷합니다. 그래서 호환성 문제는 웬만하면 스태키지 선에서 잡히고, 스태키지 큐레이션은 지난 10년 동안 실무상 아주 유용한 도구로 기능해 온 것이죠.
어지간하면 큐레이션만 잘 고르고 잘 갱신하면 되고, 종속성 목록에는 mypkg >= 2.1.1 && < 2.1.2
이런 거 하나도 관리 안 하고 그냥 mypkg
라고만 써도 된다는 것이, 솔직히 개짱편합니다. 다행히 지난 10년 동안 "문제의 소지는 컴파일 시간에 검출하는 게 좋다"라는 생각이 더 널리 받아들여져서, 다른 언어들도 이런 접근을 더 시도할 여지가 생긴 것 같군요.
@xtjuxtapose 제보 감사합니다. 🙇🏻♂️
@hongminhee洪 民憙 (Hong Minhee) 엥 제가 제보한 거 아닙니다 (???)
많은 분들이 인용 방법을 혼란스러워 하셔서, 인용 버튼을 추가했습니다. 게시글이나 단문 아래의 아이콘들 중에 왼쪽에서 세 번째 아이콘을 누르시면 해당 콘텐츠를 인용한 글들이 나열되고, 그 위에 인용 글 입력란이 뜨게 됩니다. 거기서 인용 글을 쓸 수 있습니다. 아, 종래의 인용 UI도 그대로 사용하실 수 있습니다.
참고로 인용 아이콘은 @xtjuxtapose 님께서 수고해 주셨습니다. 감사합니다.
RE: https://hackers.pub/@xt/0195eb06-9f50-763d-85c8-5600ec78c539