Gukhanmun: 國漢文을 한글로 바꾸기

2026-06-20T00:29:53-04:00

Haskell로 作成되었던 國漢文을 한글로 바꿔주는 소프트웨어 Seonbi를 Rust로 再作成하고 改善시킨 Gukhanmun에 對한 發表입니다.

Nobody's job, everybody's problem: F/OSS in the age of AI

2026-05-13T07:57:21-04:00

A guest lecture for KAIST CS350 Introduction to Software Engineering. Most CS students use free/open source software every day. Fewer have seen what happens after a project has users, bug reports, security expectations, and downstreams. The first half looks at why engineers choose free/open source software, why shared infrastructure often has no clear owner, and how maintainers pay for the work. The second half turns to AI-generated code, using contribution policies from Zig, Ghostty, and Fedify to show how maintainers are responding.

Fedify: Building ActivityPub servers without the pain

2026-01-31T07:24:44-05:00

The slides for my talk Fedify: Building ActivityPub servers without the pain at FOSDEM 2026.

Optique: TypeScript의 타입 추론으로 CLI 유효성 검사를 대체하기

2025-12-06T01:39:45-05:00

Optique는 TypeScript를 위한 타입 안전 조합형 CLI 파서 라이브러리로, “Parse, don't validate” 원칙에 따라 런타임 유효성 검사 대신 파서 구조 자체로 제약을 표현합니다. 이 발표에서는 의존적 옵션, 상호 배타적 옵션, 태그된 공용체라는 세 가지 핵심 패턴을 통해 Optique의 접근 방식을 소개합니다. 원본: https://hongminhee.codeberg.page/optique-liftio-2025/

Embracing yak shaving

2025-11-10T00:46:54-05:00

Yak shaving refers to the situation where you're working on a task, but you stop to start another task with the justification that it will “make the original job easier.” This can lead to starting yet another task to accomplish the second one, creating a cascade of work. While the term often carries a negative connotation—implying that one gets endlessly sidetracked and never completes the original task—yak shaving is not necessarily a bad thing. The speaker, Minhee Hong, is an avid supporter of the fediverse, a decentralized social network. To fix personal inconveniences they encountered while using the fediverse, they started a chain reaction of creating several open source projects two years ago, including Hollo, Fedify, LogTape, Hackers' Pub, Upyo, Optique, and BotKit. What began as an attempt to solve a very minor inconvenience gradually resulted in the creation of various byproducts. In this talk, the speaker reflects on the past two years to discuss the yak shaving spirit that became the driving force for numerous new open source projects, and will make the case that this approach can work for others as well.

야크 셰이빙: 새로운 오픈 소스의 원동력

2025-11-10T00:42:37-05:00

야크 셰이빙(yak shaving)이란 원래 하려던 일을 하려다 “그 일을 더 수월하게 하기 위해서”라는 명목으로 원래 하던 일을 멈추고 다른 일을 시작하고, 또 그 일을 하기 위해 또 다른 일을 시작하는 식으로 일을 잔뜩 벌리는 것을 뜻합니다. 원래는 그렇게 일을 벌리기만 하다 결국 원래 하려던 일을 하지 못한다는 부정적인 뉘앙스를 품고 있지만, 야크 셰이빙이 반드시 나쁜 것만은 아닙니다. 발표자 홍민희는 분산형 소셜 네트워크인 연합우주(fediverse)의 열렬한 지지자로, 연합우주를 사용할 때 개인적으로 불편했던 점들을 고치기 위해 2년 전부터 Hollo, Fedify, LogTape, Hackers' Pub, Upyo, Optique, BotKit과 같은 여러 오픈 소스 프로젝트들을 연쇄적으로 만들게 되었습니다. 처음에는 아주 사소한 불편함을 해결하기 위한 것이었지만, 하다 보니 점차 다양한 부산물을 만들게 된 것입니다. 발표자는 지난 2년을 돌아보며 다양한 새로운 오픈 소스 프로젝트의 원동력이 될 수 있었던 야크 셰이빙 정신에 대해 이야기하고, 이 방식이 다른 사람들에게도 통할 수 있다는 이야기를 하려고 합니다.

BotKit by Fedify：誰でも簡単に作れるActivityPubボット

2025-08-02T22:48:54-04:00

BotKit by Fedifyの紹介資料です。 BotKitは、ActivityPubボットを簡単に作ることができるTypeScriptフレームワークです。従来のMastodon・Misskey APIを使ったボットとは異なり、ActivityPubを直接実装する独立型ボットを数行のコードで作成できます。 OSC 2025 京都での発表資料として作成しました。 🔗 ドキュメント：https://botkit.fedify.dev/ 🔗 ソースコード：https://github.com/fedify-dev/botkit

国漢文混用体からHolloまで

2025-04-04T02:52:20-04:00

本発表では、韓国語の「国漢文混用体」（漢字ハングル混じり文）を自分のフェディバース投稿に実装したいという小さな目標から始まった旅路を共有します。この目標を達成するために、ActivityPubのJSON-LDの複雑さやHTTP Signatures、WebFingerなどの仕様を理解する必要性に直面し、それがFedifyというActivityPubサーバーフレームワークの開発につながりました。その後、Fedifyを使用して御一人様向けのActivityPubサーバーソフトウェアHolloを実装する過程、そして漢字に「振りハングル」を付ける機能をMastodonやMisskeyなどの主要なActivityPub実装と互換性を持たせるための取り組みについて説明します。最後に、Fedifyを利用した新しいプロジェクトHackers' Pubについても紹介します。小さな問題から始まり、オープンソースコミュニティの支援を受けながら大きなプロジェクトへと発展していった経験を通じて、分散型SNSの技術的な課題と可能性を探ります。

Fedify — ActivityPub 서버 프레임워크

2024-11-21T23:21:21-05:00

Open Contribution Jam 2024에서 Fedify 프로젝트에 대한 소개

여러 .NET 구현과 플랫폼을 두루 지원하는 라이브러리 (오픈 소스로) 만들기

2019-10-02T10:27:14-04:00

.NET Conf 2019 @ Seoul에서 발표한 〈여러 .NET 구현과 플랫폼을 두루 지원하는 라이브러리 (오픈 소스로) 만들기〉 슬라이드.

첫 이더리움 스마트 콘트랙트 개발 이야기

2018-07-05T08:59:09-04:00

스포카 · 캐리 프로토콜 홍 민희

작년까지 하던 일

서버 프로그래밍

범용 프로그래밍 언어 (파이썬, C/C++, 하스켈)
비동기 네트워킹
관계형 데이터베이스 (PostgreSQL)

운영

리눅스
스크립팅 (bash, 파이썬)

캐리 프로토콜

2018년 6월 토큰 프리세일 첫 스마트 콘트랙트 개발

알고 있던 것들

튜링 완전한 기계 위에서의 프로그래밍 일반
암호학적 프리미티브에 대한 개괄적 이해
- 암호학적 해시 함수 아이디어
- 비대칭 암호화 아이디어
- 서명, 검증, 암호화, 복호화 등의 아이디어
주력 프로그래밍 언어의 툴체인
- Python: pip, virtualenv 등
- Haskell: Cabal, Stack 등
애자일 프랙티스

도움이 된 것들

튜링 완전한 기계 위에서의 프로그래밍 일반
암호학적 프리미티브에 대한 개괄적 이해
- 암호학적 해시 함수 아이디어
- 비대칭 암호화 아이디어
- 서명, 검증, 암호화, 복호화 등의 아이디어
주력 프로그래밍 언어의 툴체인
- Python: pip, virtualenv 등
- Haskell: Cabal, Stack 등
애자일 프랙티스

새로 배워야 했던 것들

튜링 완전한 기계 위에서의 프로그래밍 일반
암호학적 프리미티브에 대한 개괄적 이해
- 암호학적 해시 함수 아이디어
- 비대칭 암호화 아이디어
- 서명, 검증, 암호화, 복호화 등의 아이디어
주력 프로그래밍 언어의 툴체인
- Python: pip, virtualenv 등
- Haskell: Cabal, Stack 등
애자일 프랙티스

생각을 바꿔야 했던 것들

튜링 완전한 기계 위에서의 프로그래밍 일반
암호학적 프리미티브에 대한 개괄적 이해
- 암호학적 해시 함수 아이디어
- 비대칭 암호화 아이디어
- 서명, 검증, 암호화, 복호화 등의 아이디어
주력 프로그래밍 언어의 툴체인
- Python: pip, virtualenv 등
- Haskell: Cabal, Stack 등
애자일 프랙티스

이더리움 가상 머신 (EVM)

익숙한 특성들…

튜링 완전
고수준 언어로부터 바이트코드로 컴파일한다 (예: 솔리디티)

이더리움 가상 머신 (EVM)

생소한 특성들…

결정적(deterministic)이다. → 같은 입력(nonce 포함)에 대해서는 항상 같은 결과 → 암시적인 맥락에 의존적이지 않다
네트워크에 붙은 분산된 노드들에 의해 중복되어(redundantly) 실행된다 → 이러기 위해 결정적

이더리움 가상 머신 (EVM)

다른 비용 모형…

가스: 공공 자원인 분산 컴퓨팅을 이용하기 위한 수수료 → EVM은 물리적인 성능의 편차가 큰 다양한 컴퓨터에서 돌아가므로, 컴퓨팅 비용에 대한 일관적 모형이 필요하므로, 가스 같은 추상적 단위를 정의할 필요가 있음
가스 가격: 1 가스 소모에 몇 이더(주로 gwei 단위)를 지불할지 정한다
가스 리미트: EVM에서 돌아갈 스마트 콘트랙트 프로그램 코드가 얼만큼의 가스 이하로만 소모할 거라는 보장 → 리미트를 초과하여 가스를 태우려고 하면 프로그램이 종료 → 튜링 완전한 EVM에서는 정지 문제(halting problem)를 풀 수 없으므로 생긴 우회적 제약 개념
트랜잭션이 실패해도 가스 비용은 소모된다
컴파일러들은 수행 시간과 메모리 공간이 아니라 가스 소모를 최적화한다

개발 환경 차이

“로컬에서 충분히 개발하고 테스트한 다음 스테이징 서버에 올린다”

로컬에서 돌리기 위한 개발용 이더리움 싱글 노드 네트워크를 이용 (예: 가나슈) → 기본 제공되는 계정들이 존재 → 각 계정에 보통 100 이더 정도가 들어있음 → 로컬넷이라도 가스비는 발생
스테이징 용도로 퍼블릭 메인넷과 테스트 네트워크를 이용 (예: 롭스텐) → 필요한 이더는 각종 포시트에서 얻을 수 있다 → 테스트넷이라도 가스비는 발생

풀 노드 (full node)

한국 평균 인터넷 속도가 주어졌을 때, 평범한 랩탑 컴퓨터(예: 최신 맥북 프로)에서, 퍼블릭 메인넷의 풀 노드를 구성하는 데에 한 달이 걸린다. 😱

인푸라 (Infura)

클라우드로 제공되는 풀 노드 HTTP API 서비스
이름과 이메일 정도만 입력하는 것으로 가입 및 이용 가능
실제로 계정당 하나의 풀 노드를 제공하는 것이 아니라, 풀 노드들 앞에 로드 밸런서가 있는 방식 → 배포를 하거나 스크립트를 실행할 때 이전 트랜잭션을 만들 때 붙은 풀 노드와 이후 트랜잭션을 만들 때 붙은 풀 노드가 다를 수 있음 → 두 풀 노드 사이에 동기화가 완료되지 않은 상태일 경우 nonce가 달라서 오류가 나기도 함 → HTTP API 대신 웹 소켓 API를 쓰거나, 트랜잭션 사이에 시간 간격을 둬서 해결

디버깅

스마트 콘트랙트 개발에서도 디버거는 있다
하지만 gdb 같은 전통적인 디버거보다 더 낫다
리액트 등의 시간 여행(time travel) 디버거에 더 가까운 개념
모든 스마트 콘트랙트의 실행은 트랜잭션 형태로 기록이 남고, 입력으로부터 동작이 일과되게 동작되기 때문에 리플레이 가능
개념적으로는 더 편하지만, 아직 도구의 성숙도가 낮다는 단점은 존재

암호 화폐

블록체인은 암호학 프리미티브 위에서 만들어진 기술
이더리움도 여러 개념에 암호학 프리미티브가 녹아있다
계정은 비대칭 암호화의 공개키 및 비밀키 관계
주소는 공개키(로부터 유도된 다이제스트)
지갑은 비밀키들의 집합
트랜잭션은 디지털 서명

사이먼 싱 《비밀의 언어》

솔리디티

https://github.com/ethereum/solidity

EVM 바이트코드로 컴파일되는 고수준 언어
하지만 파이썬이나 자바스크립트처럼 고수준은 아니다
예를 들어 정수 자료형은 오버플로 등에서 자유롭지 않다
mapping(k => v) 자료형은 딕셔너리가 아니다 → k에 대해 가능한 모든 값이 이미 존재한다는 아이디어 → 따라서 길이 등을 가질 수 없고, 반복도 불가능
애초에 가스 때문에 추상화 수준을 한없이 올리긴 힘든 한계가 있다
오류가 나면 트랜잭션이 중단된다 → 자바/파이썬 예외처럼 잡을 수는 없다

트러플 스위트

http://truffleframework.com/

노드/자바스크립트 기반의 이더리움 개발 툴체인
솔리디티 소스 트리 통합 빌드
로컬 개발용 이더리움 싱글 노드 네트워크
테스트 프레임워크
“마이그레이션” 기반 배포 시스템
애드혹 스크립트 실행기
디버거

오픈 제플린

https://openzeppelin.org/

웹 개발로 치면 장고, 레일스 같은 위치에 있는 프레임워크
현재 수요가 많은 다양한 케이스들의 구현을 제공
- ERC 20/ERC 721 토큰
- 토큰 세일
- 접근 제한 (화이트리스트 등)
일부 동작을 커스터마이즈하기 쉽게 설계되어 있다
계약이라는 관점에서는 표준 계약서 같은 역할
직접 짜는 것보다, 조금 눈에 안 들어오더라도 오픈 제플린의 코드를 읽고 파악하여 활용하는 것을 추천 → 보안 측면에서 이미 검증되어 있다 → 계약은 당사자들 사이의 합의이므로, 알려진 코드가 합의하기 낫다
솔리디티 코딩의 베스트 프랙티스를 배울 수 있는 코드. 읽는 것 추천

아직 미숙한 개발 도구

역사가 짧기 때문에, 경쟁하는 언어·빌드 툴체인·프레임워크 등의 수도 적고, 아직 성숙도도 다소 떨어진다.

반면, 표준화가 시급한 부분에서는 미숙한 도구들이 난립하고 있기도.

유닉스 CLI 관례

truffle deploy --help

도움말 출력하는 대신 진짜 배포됨
트러플 스위트 공식 웹사이트의 문서를 찾을 것
문서화되지 않은 기능이 많기 때문에 현업에서는 코드를 읽는 것이 필수

산술 오버플로 (arithmetic overflow)

+ - * /

(솔리디티) 산술 오버플로·언더플로 발생 가능
오픈제플린의 SafeMath를 쓸 것

테스트 픽스처 (test fixture)

트러플 스위트의 테스트 러너는 픽스처의 재현성을 보장하지 않음
이전에 실행된 테스트 케이스가 블록체인에 가한 변경이 사라지지 않음
J유닛 등 일반적인 테스트 프레임워크의 테스트 픽스처처럼 repeatable하다고 가정하고 테스트를 작성하면 실패하므로 주의
예: 입금이 제대로 됐는지 확인할 때는 입금 직전의 잔고를 변수에 담고, 입금 후의 잔고와 차액을 계산해서 테스트한다.

자바스크립트

트러플 테스트 프레임워크는 테스트 코드를 솔리디티 또는 자바스크립트로 짤 수 있게 지원한다
솔리디티로는 표현력의 한계로 테스트하기 어려운 것들이 많다
자바스크립트로 테스트 코드를 짤 때는 자바스크립트에 정수형이 없고, number 타입은 부동소수점이라는 것을 염두에 둘 것
number는 쓰지 말고 web3.BigNumber를 최대한 활용한다

애자일?

종래의 프로그래밍에서 당연하게 생각하던 애자일 방법론을 그대로 적용하기는 힘들다
애자일의 가정은 “소프트웨어는 건축과 달리 수정 비용이 싸다”는 것
하지만 스마트 콘트랙트는 배포하고 나서는 고칠 수 없다 (어렵다)

수정 애자일

그렇다고 애자일의 모든 것을 버릴 필요는 없고, 애자일의 일부 프랙티스를 다른 프랙티스로 바꾸거나, 특정 프랙티스를 더 철저히 실천하는 것으로 극복 가능
더 많은 테스트 코드는 언제나 도움이 되지만, 스마트 콘트랙트에 대해서는 하면 좋은 게 아니라 필수다
스마트 콘트랙트 개발은 동료의 코드 리뷰가 더욱 빛을 발하는 분야
스마트 콘트랙트가 구현하려 하는 명세에 대해서 팀 모두의 합의 수준이 높아져야 한다
Solium, solhint 같은 정적 분석 도구도 많은 도움이 된다
배포하기 전까지 테스트넷을 최대한 활용할 것 → 시간 뿐만 아니라 거액의 비용을 아낄 수 있다

질문과 답변

발표 자료 링크: https://bit.ly/blockparty2-hong

Python and Diaspora

2017-08-11T17:26:26-04:00

How other languages have influenced Python for 25+ years

파이썬과 다이아스포라

2017-08-11T17:25:47-04:00

Python and Diaspora (English slides: https://speakerdeck.com/minhee/python-and-diaspora) 25여 년간의 다른 언어들이 파이썬에 준 영향 How other languages have influenced Python for 25+ years

RPC 프레임워크 제작 삽질기

2016-08-13T13:41:26-04:00

스포카에서 사내 RPC 프레임워크를 직접 만들어 쓰고 오픈 소스로 공개하게 된 경위와 그 과정에서 겪었던 어려움을 공유합니다. https://github.com/spoqa/nirum https://youtu.be/bnxpEgHlql4?list=PLZPhyNeJvHRnSJ2sAnqCGFnVRKo98EgCp

All docs lead to Sphinx

2015-11-22T14:12:04-05:00

The slide of All docs lead to Sphinx, a talk presented at SphinxCon JP 2015.

유니코드 스터디

2015-06-18T00:53:59-04:00

스포카 크리에이터팀에서 발표한 유니코드 소개 자료입니다. 대상은 디자이너와 프로그래머입니다. 의도적으로 너무 기술적인 내용은 뺐습니다. 이하는 발표자 노트입니다. Slide 1: 스포카 크리에이터팀이 다같이 듣는 유니코드 소개. 발표자는 Hong. Slide 2: 지난해 말 일본 지사 설립하고, 올해부터 일본에서도 영업중. 일본 외에도 이른바 “중국말하는 일본”인 대만이나, 대표 Richard가 유년기를 보낸 홍콩, 혹은 그 외 동남아 국가에도 도도 포인트를 팔아보자는 얘기가 회사 안에서 종종 들리고 있음. Slide 3: 작년부터 우리 팀 모든 사람이 항상 씨름하고 있는 주제. Slide 4: 우선 지역화란 제품을 특정한 언어·문화권에서 쓸 수 있도록 고치는 작업을 말한다. 즉 한국어 버전 도도 포인트라는 제품이 우리에게 있는데, 이걸 일본에서도 팔기 위해서 일본어로 번역하고 일본 현지 사정에 맞게 기능을 손본 뒤에 일본어 버전 도도 포인트라는 제품으로 만드는 것. 이렇게 되면 제품은 둘이 된다. 한국어 버전 도도 포인트에 기능을 추가할 때마다 일본어 버전에서도 그걸 배껴서 붙여야 한다. 제품 유지 보수 비용 증가. “L10n”으로도 표기. Slide 5: 반면 국제화는 하나의 제품이 여러 언어·문화권에서 쓸 수 있도록 만드는 것. 즉, 제품의 수를 늘리는 것이 아니라, 하나의 제품 안에서 지원하는 언어 등을 늘리는 것. 국제화 역시 제품의 유지 보수 비용을 증가시킨다. 하지만 지역화를 하는 것만큼 무리하게 증가시키는 것은 아니다. “I18n”으로도 표기. 우리 팀이 취해야 하는, 그리고 전부터 취해온 방식. Slide 6: 유니코드가 다루는 대상 자체가 세계의 다양한 문자 및 표기들이고, 이는 우리가 제품을 만들 때도 활용할 수 있는 구성물들. 유니코드를 배우다보면 다른 나라 사람들은 글자를 오른쪽에서 왼쪽으로 쓰는구나, 세로 쓰기를 하는구나, 띄어쓰기를 안 하는구나, 소수점에 컴마를 쓰고 자릿수 구분에 오히려 점을 쓰는구나 같은 사실들을 자연스럽게 알게 된다. 유니코드는 복잡하고 방대하지만 다루려는 대상의 복잡함에 비하면 감당할 수는 있을만큼 간단해지도록 잘 통제되어 있다. 이렇게 복잡하고 다양한 요구사항을 어떻게 대하는 지혜를 엿볼 수 있다. Slide 7: 오늘은 디자이너도 참석하셨기 때문에 UTF-8니 BOM이니 하는 바이트 인코딩 문제 같은 것들은 뺐습니다. Slide 8: Slide 9: 유니코드 컨소시엄에는 우리가 잘 아는 세계적인 소프트웨어 기업들이 두루 참여하고 있음. 요는, 우리보다 경험도 많고 지혜도 많은 사람들이다. 유니코드 컨소시엄의 전문가들은 우리보다 더 잘 안다. Slide 10: 유니코드가 다루는 대상은 주로 문자에 관계된 것으로 한정된다. 컴퓨터에 문자를 저장하고, 컴퓨터가 그 문자들을 다른 문자로 가공하는 일을 도와준다. 가령 모든 대문자를 소문자로 바꾸려고 하면 프로그래머들은 영어에서 쓰는 알파벳 문자는 금방 떠올리지만, 독일 등에서 쓰는 Ä 같이 움라우트 붙은 대문자들을 ä 같은 움라우트 붙은 소문자로 바꿔야 한다는 것은 쉽게 놓친다. 이러한 지식의 부재는 소프트웨어를 국제화할 때 문제를 만든다. 유니코드는 그러한 구체적인 지식을 모든 프로그래머가 알고 있지 못해도 문자를 가공하는 프로그램을 올바르게 짤 수 있게 도와준다. CLDR은 나중에 다룬다. Slide 11: 반면 유니코드는 언어에 관해서는 크게 다루지 않는다. 유니코드는 “가” 문자가 한글이라는 정보는 가지고 있지만, 한국어를 표기할 때 쓰인다는 정보는 가지고 있지 않다. 로마자는 영어, 프랑스어, 독일어 등에서 두루 쓰이지만, 유니코드는 A 문자가 그러한 언어들을 표기할 때 쓰인다는 정보는 갖지 않는다. 그냥 A가 로마자라는 정보만 갖는다. 또, 유니코드 표준 문서를 뒤지면 자주 나오는 표현이 “유니코드는 글리프가 아니라 문자를 부호화한다”, “유니코드는 글리프가 아니라 문자의 의미만 인코딩한다” 같은 것이다. 유니코드 표준 차트에는 예시를 위한 문자별 레퍼런스 글리프를 제공하긴 하지만, 문자의 글리프가 어떤 모양이어야 하는지에 대해서는 보장하지도, 요구하지도 않는다. 유니코드 문자를 어떤 글리프로 표현하는지는 전적으로 서체 디자이너가 결정한다. 따라서 당연히 유니코드는 서체 또한 다루지 않는다. 다만, 컴퓨터 서체 포맷은 내부적으로 각 글리프가 어떤 유니코드 문자를 표현하는 것인지 연결해둔 표를 갖고 있다. Slide 12: “유니코드는 글리프가 아닌 문자를 부호화한다.” Slide 13: 왜 유니코드는 수많은 같은 모양 글리프를 다른 문자로 만드는 걸까? 가령 로마자 비(B)와 그리스 문자 베타(Β)는 같은 글리프이며, 둘 모두 페니키아 문자에서 파생된 공통의 유래를 가지고 있으니 같은 문자도 봐도 무방한 것처럼 보인다. Slide 14: 하지만 해당 문자를 소문자로 바꾸려고 하면 양상이 달라지며 문제가 드러난다. 로마 대문자 B와 그리스 대문자 Β는 같은 글리프지만, 그와 대응되는 각각의 소문자는 아주 다른 글리프로 표현되기 때문이다. 글리프 자체는 문자가 담는 의미 정보를 손실하기 때문에 그와 관계된 문자적 맥락이 사라져 버린다. 이는 연락처를 텍스트 대신 레스터 이미지로 만들면 긁어서 복사할 수도 없고 검색도 못하게 되는 것과 비슷한 문제이다. 당연하지만 로마 대문자 B와 그리스 대문자 Β가 같은 글리프여야 하는 것도 아니다. 폰트 디자이너는 그 둘에 서로 다른 글리프를 그려도 괜찮다. Slide 15: 유니코드의 모든 문자는 코드포인트라 불리는 고유한 번호와, 고유한 이름이 부여되어 있다. 코드포인트는 보통 앞에 U+ 접두어를 붙이고, 그 뒤에 16진수를 써서 표기한다. 10진수가 아닌 16진수를 쓰는 이유는 프로그래머에게 그쪽이 경계를 구분하기 좋기 때문이다. 당연하지만 문자와 코드포인트를 외울 필요는 없다. 유니코드 사이트에 올라와 있는 차트에 다 나와 있고, 뒤에서 소개할 여러 프로그램이나 웹사이트로 쉽게 검색할 수 있다. Slide 16: 이 외에도 상당히 다양한 성질이 있음. 프로그래머들 사이에서는 property라는 말이 더 친숙할지도. Slide 17: 이렇게 배경이 까만 슬라이드는 프로그래머들만 보면 되는 내용. 가령 파이썬 3에서는 문자열이 모두 유니코드이다. 그래서 단순히 영어에서 쓰이는 알파벳 뿐만 아니라, 움라우트가 들어간 알파벳 같이 유럽의 여러 언어에서 쓰이는 모든 알파벳에 대해 case 처리가 된다. 다만 case라는 게 없는 문자에서는 아무런 변화도 없음. Slide 18: 파이썬에서는 아라비아 숫자만 판별하는 str.isdigit() 메서드와 별개로, 유니코드에서 숫자로 보는 모든 문자를 판별하는 str.isnumeric()이 존재. Slide 19: 파이썬 표준 라이브러리에는 unicodedata라는 모듈이 있는데, 이걸 사용하면 문자를 분해해볼 수 있다. Slide 20: 히라가나와 가타카나가 일본어라는 하나의 스크립트에 묶이지 않고, 각각의 스크립트로 나뉘어 있는 것에 주의. 다시 강조하지만 유니코드는 언어를 다루는 것이 아니라 문자를 다룬다. Slide 21: PyPI에 올라와 있는 uniscripts 패키지를 설치하면 어떤 유니코드 문자 혹은 문자열이 어떤 script에 포함되어 있는지 확인 가능. Slide 22: 꼭 필요하면 쓰지만, 안 쓰는 게 좋음. 고정폭 서체를 쓸 때나 유용. Slide 23: 역시 표준 라이브러리의 unicodedata 모듈을 쓰면 너비 계산도 가능. Slide 24: 간단한 도구 실습도… Slide 25: 죄송하다는 말씀밖에 드릴 말이 없습니다.

하스켈과 타입

2015-04-03T13:55:09-04:00

하스켈과 타입에 대해 설명합니다. 2015년 4월 4일 하스켈 프로그래밍 다섯번째 모임 http://haskell.kr/meetup/2015-04-04/

Geofront 개발 후기: Python 2와 작별하고 Python 3로 개발하기

2014-08-30T04:03:54-04:00

Geofront는 소규모 팀에서 운영하는 서버에 인증하는 SSH 키를 관리하기 위한 오픈 소스 소프트웨어입니다. (Geofront 자체에 대한 설명은 스포카 개발팀 블로그에 올라온 “Geofront: 소규모 팀을 위한 SSH 키 관리 서비스”를 읽어주세요. http://spoqa.github.io/2014/07/09/geofront.html) Geofront는 Python 3 전용으로 작성되었는데, Python 3만 사용하여 개발하며 경험한 바를 공유합니다. 주로 Python 2를 쓸 때에 비교해서 Python 3를 쓰면 어떤 점이 좋은지, 과연 이제 정말 Python 3를 써도 괜찮은 것인지, Python 3를 쓸 때 유의해야할 것이 무엇이 있는지를 다루려고 합니다.