레이블이 summary인 게시물을 표시합니다. 모든 게시물 표시
레이블이 summary인 게시물을 표시합니다. 모든 게시물 표시

2018-06-03

2018년 22번재 주 - P2P Network

이 포스팅은 그냥 지난 한 주간 읽었던 것들을 정리하는 포스트입니다. 그냥 예전에 봤던 글 중 나중에 필요한데 뭐였는지 기억 안 나는 글들이 있어서 쓰기 시작했습니다.
보통 하는 일과 관련된 글들이 올라오겠지만 딱히 정해둔 주제는 없고, 그때그때 관심 있었던 것을 읽었기 때문에 지난주에 쓰인 글일 수도 있고 몇 년 전에 쓰인 글일 수도 있습니다.

지난주에 이어 이번 주는 P2P를 주제로 발표했다. 이번에도 발표자료를 만들면서 참고한 자료를 공유하도록 하겠다.


Chord: a scalable peer-to-peer lookup protocol for internet applications

Tapestry: A Resilient Global-scale Overlay for Service Deployment

Pastry: Scalable, decentralized object location and routing for large-scale peer-to-peer systems

A Scalable Content-Addressable Network

P2P 네트워크 중에서도 네트워크 토폴로지가 특정한 규칙에 의해서 구성되는 네트워크를 structured 네트워크라고 말한다. Structured network는 unstructured network에 비해 특정 노드에 부하가 걸리거나 의존하는 것을 방지하면서 잘 분산된 네트워크를 구성할 수 있다. 위의 4 논문은 각기 Chord, Tapestry, Pastry, Content Addressable Network(a.k.a. CAN)라는 대표적인 structured 네트워크 오버레이를 제시하는 논문이다.

Kademlia: A Peer-to-Peer Information System Based on the XOR Metric

Kademlia는 위의 네 논문을 개선하는 네트워크 오버레이를 제시한다. BitTorrent, eDonkey, 이더리움 등 많은 P2P 시스템이 kademlia 방식을 이용한다. 실질적으로 P2P 네트워크에서 가장 많이 사용되는 방식이다.
Kademlia의 가장 큰 특징은 xor distance를 사용하는 것이다. Xor distance는 노드 아이디의 공통된 prefix가 길수록 가까운 노드로 판단하는 방식이다. 이 방식은 triangle inequality를 만족하며, 각 노드가 작은 라우팅 테이블만으로 전체 네트워크를 효율적으로 연결할 수 있다.
게다가 거리가 대칭적이기 때문에 TCP로 연결해야 하는 시스템에서도 사용하기 좋다.

Understanding churn in peer-to-peer networks

Churn이라는 것은 새 노드가 네트워크에 참여하거나 네트워크에서 노드가 빠져나가는 변동성을 말한다. 위 논문은 다양한 p2p 네트워크에서 네트워크 상태를 조사해서 각 네트워크가 어떤 churn을 가지는지 분석했다.
사실 churn 자체는 서비스의 종류마다 다 다를 것이다. 이 논문에서 주목할 점은 그 churn을 어떻게 분석했는지 그 방법론에 대한 것이라고 생각한다.

Low-Resource Eclipse Attacks on Ethereum’s Peer-to-Peer Network

이더리움에 가할 수 있는 eclipse attack에 관해 정리한 논문이다. 자세한 내용은 전에 쓴 적이 있으니 참고 바란다.

Eclipse Attacks on Bitcoin’s Peer-to-Peer Network

이 논문은 비트코인에서 할 수 있는 eclipse attack에 관해 정리한 논문이다. 이더리움은 2대의 머신으로 공격할 수 있었던 반면 비트코인에서는 약 400개의 머신이 필요하다. 아직 비트코인에서 이보다 적은 수로 공격할 수 있는 방법은 나오지 않았다.

BLAKE2: simpler, smaller, fast as MD5

Cryptographic hash function 중 하나인 BLAKE2를 소개하는 논문이다. SHA-3 finalist였던 blake의 개선판으로 blake보다 더 적은 메모리로 빠르게 돌아간다.

The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC)

Codechain에서는 MD5SHA-1을 이용하는 일반적인 HMAC 대신에 BLAKE2를 HMAC으로 사용한다. 이와 관련하여 이론적 분석이 있을 것이라고 생각하고 보기 시작했는데, HMAC에 관한 내용은 별로 없고, BLAKE2의 알고리즘과 구현에 관한 내용이 대부분이었다.

O(1) Block Propagation

이건 내가 발표한 내용이 아니라 양준모 님의 발표에 있던 비트코인의 Graphene의 아이디어를 줬던 제안이다. 트랜잭션은 언제나 전파하는 비트코인의 특성상 대부분 트랜잭션이 이미 전파돼있을 거라고 가정하고, IBLT라는 자료구조를 이용해서 없는 트랜잭션을 빠르게 확인할 수 있다는 것이 메인 아이디어다.

Invertible Bloom Lookup Tables

이 논문이 위에서 말한 IBLT를 제시하는 논문이다.

2018-05-27

2018년 21번째 주 - Consensus algorithm

이 포스팅은 그냥 지난 한 주간 읽었던 것들을 정리하는 포스트입니다. 그냥 예전에 봤던 글 중 나중에 필요한데 뭐였는지 기억 안 나는 글들이 있어서 쓰기 시작했습니다.
 보통 하는 일과 관련된 글들이 올라오겠지만 딱히 정해둔 주제는 없고, 그때그때 관심 있었던 것을 읽었기 때문에 지난주에 쓰인 글일 수도 있고 몇 년 전에 쓰인 글일 수도 있습니다.

회사에서 이런 거 하느라 바빠서 한동안 다른 글은 읽을 시간이 없네요. 발표는 몇 주 동안 계속할 거라서 당분간은 발표자료 만들면서 참고했던 자료들을 공유할 것 같습니다.


Impossibility of distributed consensus with one faulty process

분산 환경에서 합의 알고리즘을 말할 때 빼놓을 수 없는 논문이다. 합의 알고리즘에 필요한 기본적인 속성은 크게 safety와 liveness가 있다. Safety는 잘못된 합의가 이루어지지 않는다는 것이고, liveness는 언젠가는 합의가 반드시 이루어진다는 것이다. 위 논문은 비동기 네트워크에서 하나의 fail-stop failure 노드만 있어도 이 합의가 이루어질 수 없다는 것을 보였다. 이를 FLP impossibility라고 부른다.

Consensus in the presence of partial synchrony

첫 번째 논문이 비동기 네트워크에서 safety와 liveness를 보장하는 합의 알고리즘이 불가능하다는 FLP impossibility를 보였다. 그래서 이 논문은 partial synchronous model을 만들어 특정한 가정 아래서 safety와 liveness를 같이 보장하는 합의 알고리즘을 만들 수 있게 해줬다. Partial synchronous model은 메시지가 언젠가는 도착하는 것을 보장하지만 그 도착하는 시간이 언제인지 알 수 없는 모델이다.

The Byzantine generals problem

Byzantine failure라는 용어의 어원이 된 논문이다. 이 논문 이전 논문은 기껏해야 메시지가 드랍되는 omission failure 정도밖에 가정하지 않았다. 하지만 이 논문 이후로 악의적인 참여자에 의해 시스템이 공격당하는 경우도 고려하게 됐다.

Reaching Agreement in the Presence of Faults

어떤 시스템이 f개의 byzantine failure node가 있을 때 3f + 1개의 노드로 구성된 네트워크에서 byzantine fault tolerant(a.k.a. BFT)한 합의가 가능하다는 것을 증명한 논문이다. 3f + 1은 BFT 시스템을 구성하기 위한 최소한의 노드 수이기도 하다.

Practical Byzantine fault tolerance

위 논문은 BFT 시스템을 Network File System에서 적용했다. 내가 아는 한은 BFT 알고리즘을 인터넷 규모에서 실제로 사용하는 시스템에 적용한 최초의 논문이고, 여기서 사용된 알고리즘들이 현재 블록체인에 사용되는 BFT 계열 합의 알고리즘들의 근간이 됐다.

Blockchain Consensus Protocols in the Wild

블록체인에서 유명한 합의 알고리즘들을 partial synchronous model에서 safety와 liveness, 그리고 얼마나 많은 byzantine failure node를 버틸 수 있는지 분석했다.

Byzantine Consensus Algorithm

텐더민트에서 사용하는 합의 알고리즘에 대해서 설명한 위키 페이지다. 텐더민트는 BFT에 stake 개념을 섞어 블록체인에서 사용할 수 있도록 만들었다. 특히 여기서 말하는 Proof of Lock Change(a.k.a. PoLC) 개념은 잘 이해해두는 것이 좋다. 보통 BFT 계열 합의 알고리즘을 최적화하려는 사람들이 PoLC에서 문제가 생겨 safety와 liveness에 문제가 생긴다.

Casper the Friendly Finality Gadget

현재 이더리움에서 진행 중인 프로젝트 중 하나로 PoW로 생성된 블록체인에 safety, 블록체인 용어로는 finality를 보장하기 위한 프로토콜이다. 기본적인 방법은 텐더민트에서 사용된 개념과 유사하다. 하지만 충분한 투표를 모으지 못하면 새 블록이 생성되지 않는 텐더민트와는 다르게 캐스퍼는 finality를 보장하지 못 할뿐 블록은 계속 생성된다.

Hot-Stuff the Linear, Optimal-Resilience, One-Message BFT Devil

캐스퍼에 영향을 받아 쓰인 논문으로 캐스퍼를 더 일반화시켰다. 캐스퍼는 블록 생성과 투표와 완전 별개로 진행된다. 하지만 Hot-stuff에서는 블록의 헤더에 투표를 모은다. 다만 이 투표는 반드시 포함해야 하는 것이 아니고 투표가 없어도 블록은 생성된다.

2018-05-20

2018년 20번째 주

이 포스팅은 그냥 지난 한 주간 읽었던 것들을 정리하는 포스트입니다. 그냥 예전에 봤던 글 중 나중에 필요한데 뭐였는지 기억 안 나는 글들이 있어서 쓰기 시작했습니다.
 보통 하는 일과 관련된 글들이 올라오겠지만 딱히 정해둔 주제는 없고, 그때그때 관심 있었던 것을 읽었기 때문에 지난주에 쓰인 글일 수도 있고 몇 년 전에 쓰인 글일 수도 있습니다.

Polkadot: Vision for a Heterogeneous Multi-chain Framework

Cosmos - A Network of Distributed Ledgers

블록체인이 쏟아져 나오면서 다른 블록체인과 통신을 어떻게 할 수 없을까에 대해 고민하는 사람들이 나왔다.
예를 들어 지금은 Alice의 비트코인과 Bob의 이더리움을 교환하기 위해서는 양자가 신용하는 Ted가 필요하다. Alice는 비트코인을 Bob은 이더리움을 Ted에게 보내고, 양쪽에게 받은 트랜잭션을 확인한 Ted는 Alice와 Bob에게 이더리움과 비트코인을 보내주는 식이다. 지금은 거래소가 이 역할을 해주고 있다. 하지만 trustless를 가정하고 설계된 블록체인에서 거래소는 가장 약한 고리가 된다. 그래서 이 거래소에 해당하는 역할을 블록체인으로 구성하자는 제안이 나왔고, PolkadotCosmos가 대표적이다.

How I targeted the Reddit CEO with Facebook ads to get an interview at Reddit

어떤 사람이 공개된 페이스북 프로필을 이용해서 레딧 CEO를 타겟으로 광고를 했다고 한다. 결국, 10$만에 레딧 CEO에게 광고하는 데 성공했다고 한다. 마케터들은 페이스북이 이렇게 유용하다고 생각할 것이다. 근데 사용자 입장에서 반대로 내 신원이 이 정도로 추적된다는 것인데 이런 것을 감수하고 쓸 정도로 페이스북이 매력적인 서비스인지 이해가 안 된다. 사실 사람들이 개인 정보 보호에 그다지 관심 없는 게 아닌가 싶다.

To Type or Not to Type:Quantifying Detectable Bugs in JavaScript

JavaScriptTypeScriptflow를 사용하여 정적분석을 하는 것 만으로 15%의 버그를 예방할 수 있다는 연구다.

How a Rust upgrade more than tripled the speed of my code

Parity 팀에서 지난 5월 10일에 발표한 Rust 1.26의 128 bit 정수 타입을 이용해서 실제 성능 향상을 확인했다. 이는 이더리움이 256 bit 정수와 512 bit 정수를 많이 사용하기 때문이고, 이더리움 외의 소프트웨어에서는 128 bit 정수를 쓸 일이 없으니 크게 영향 없을 수도 있다.

Sia: Simple Decentralized Storage

Sia는 블록체인을 이용하여 분산 서비스를 구축하자는 프로젝트이다. 분산 스토리지라고 해도 데이터 전체를 블록체인에 올리는 것은 비현실적이기 때문에 블록체인에는 어떤 데이터를 어떤 노드가 가졌는지에 대한 증명과 그에 대한 보상만 블록체인에 기록한다. 결국, 실제 데이터를 원하는 클라이언트에게 서비스하지 않아도 데이터를 가지고 있다는 증명만 하면 보상을 받는다. 이 문제를 oracle problem이라고 하는데 이 문제를 어떻게 풀었는지 궁금해서 찾아봤는데 아직 못 찾았다.

2018-05-13

2018년 19번째 주

이 포스팅은 그냥 지난 한 주간 읽었던 것들을 정리하는 포스트입니다. 그냥 예전에 봤던 글 중 나중에 필요한데 뭐였는지 기억 안 나는 글들이 있어서 쓰기 시작했습니다.
 보통 하는 일과 관련된 글들이 올라오겠지만 딱히 정해둔 주제는 없고, 그때그때 관심 있었던 것을 읽었기 때문에 지난주에 쓰인 글일 수도 있고 몇 년 전에 쓰인 글일 수도 있습니다.


C Primer

Primer를 입문서라고 번역하는 게 맞는지 모르겠지만, 어쨌든 C 입문서라고 이름 붙인 문서 중에서 가장 마음에 든다. 다른 언어는 잘 추상화된 모델을 다루는 것이 중요하지만 C는 아니라고 생각한다. C는 내가 사용한 코드가 어떻게 변환되어 실행되는지 기계 단위로 이해하고 있어야 한다. 그럴 필요가 없는 상황에서는 C가 아닌 다른 언어를 써야 한다.

C Is Not a Low-level Language

C가 low-level 언어는 아니라는 글이다. 전통적으로 low-level 언어는 머신에 대한 추상화 없이 기계어와 일대일 대응되는 언어를 의미한다. 당연히 이런 의미에서 C는 low-level 언어가 아니다. C는 나름의 abstract machine을 가지고 있다. 특히 C11 이후로는 멀티 쓰레드에 대한 개념도 abstract machine에 들어갔기 때문에 전통적인 의미에서 low-level 언어는 아니다.

그렇다고 해서 C가 다른 high-level 언어와 같다는 의미는 아니다. 다른 high-level 언어들은 실제 기계어로 어떻게 번역되는지 몰라도 될 정도로 abstract machine을 정의한다. 하지만 C는 아니다. 사실 나는 C의 abstract machine도 기계를 몰라도 사용할 수 있을 정도로 잘 정의돼있다고 생각한다. 문제는 C를 사용하는 사람들이 실제 기계에서 어떻게 돌아가는지 고려하면서 코드를 작성한다. 이건 C언어 커뮤니티의 문제는 아니다. 사실 기계 레벨에서 어떻게 돌아가는지 고려하지 않아도 되는 프로젝트에서 C를 사용하는 것은 얻는 것에 비해서 비용이 크기 때문이다.

카카오스토리 웹팀의 코드리뷰 경험

코드리뷰 없는 프로젝트는 있을 수 없다고 생각한다. 하지만 발표자가 말하듯이 시스템적으로 반드시 리뷰해야 머지할 수 있는 시스템은 별로라고 생각한다. 경험적으로 이런 시스템은 반드시 문제가 생긴다. 간단한 예로 휴가철에 급하기 hotfix를 넣어야 하는데 휴가 안 간 사람이 한 명밖에 없을 때, 휴가 간 사람이 강제로 업무를 하게 되는 경우가 있다. 굳이 휴가철이 아니더라도 급한 버그를 위해 야근이나 주말 근무를 하는 경우도 마찬가지다. 시스템적으로 머지에 리뷰를 강제하게 되면, 버그를 잡고 머지 하기 위해서 버그 잡는 사람 외에 누군가가 남아있어야 한다. 결코 바람직하지 않은 상황이다.

리뷰를 받을지 말지 패치를 만든 사람의 판단으로 선택해야 한다. 그 패치가 리뷰를 받아야 할지 안 받아도 되는지는 패치를 작성한 사람이 가장 잘 안다. 이건 패치 만드는 사람의 판단을 따라야 한다. 만약 이 정도 판단을 믿지 못한다면, 그 사람에게는 코딩을 맡기면 안 된다. 바람직한 개발 프로세스는 상호 신뢰에서 나온다고 생각한다. 기본적인 신뢰 관계가 없는 팀에서는 아무리 좋은 프로세스를 선택하더라도 유지될 수 없다.

개발 스타일은 툴로 체크해야 한다는 것에도 동의한다. 툴로 체크할 수 있는 걸 사람이 보고 있는 건 시간 낭비다. 다만 윗글에서 나온 대로 수정한 코드에 대해서만 체크할 수 있는 툴은 찾기 어렵다. 그래서 나는 한 번 대대적으로 프로젝트의 스타일을 수정하고 시작하는 것을 더 선호한다. 이렇게 되면 작업하고 있던 사람들과 컨플릭이 나거나 blame으로 찾을 수 있는 이력이 더럽혀진다는 문제가 있다. 하지만 이런 문제가 통일되지 않은 스타일로 프로젝트가 계속 진행되거나, 리뷰마다 스타일을 눈으로 체크하는 것보다는 더 싸게 먹힌다고 생각한다.

By the numbers: Python community trends in 2017/2018

2017, 2018년도 python community를 분석한 글이다. 개인적으로는 Types of Python development 파트에 나오는 파이썬 사용자를 분야별로 나눈 파트다. 보면 파이썬 사용자는 크게 data scientist와 웹 개발자로 나눠진다는 것을 알 수 있다. 특히 data scientist를 다 합치면 웹 개발자보다 많은 비중을 차지한다. 이는 파이썬이 사용하기 편하다는 점도 있지만, numpy, PyTorch, TensorFlow 등 다른 언어에서는 찾기 힘든 좋은 툴들이 많이 있기 때문이라고 생각한다. 당장 나만 해도 개발할 때는 정적 타입 언어를 선호하지만, 자료 분석이나 수치 분석을 할 때 파이썬 외에 다른 언어를 사용하지 않는다.

그 다음으로 눈에 보이는 것은 파이썬과 함께 사용하는 언어로 JavaScript가 1위를 차지했다는 것이다. 개인적으로는 파이썬의 반대되는 컴파일된느 언어나 정적 타입 언어들과 함께 사용할 것이라고 생각했고, 언어적 특성이 비슷한 JavaScript와 함께 사용할 것이라고 생각하지 않았다. 2위가 HTML/CSS인 것을 보면 이는 파이썬 사용자의 절반 정도가 웹 개발을 하기 때문으로 보인다.

다음으로 인상적인 것은 Python 3의 사용자가 Python 2의 3배쯤 사용된다는 것이다. 몇 년 전만해도 많은 Python 2 사용자들이 Python 3로 넘어가지 않고 버티고 있었고, 많은 라이브러리가 Python 2만 지원했었던 것을 생각하면 시대가 많이 좋아진 것 같다.

가장 놀라운 것은 VCS를 안 쓰는 사람이 38%나 된다는 것이다. VCS를 안 쓰고 개발이 관리가 되나 싶은데 안 쓰는 사람이 38%나 된다. 심지어 테스트를 안 짜는 사람(19%)보다 많다.

Quantum resource estimates for computing elliptic curve discrete logarithms

일반적으로 현대 컴퓨터에서 elliptic-curve cryptography(a.k.a. ECC)는 같은 길이의 키를 가지는 RSA 방식보다 더 풀기 어렵다고 말한다. 예를 들어 키 크기가 256 bit인 ECC와 같은 보안 레벨을 가지려면 RSA는 3072 bit 키를 사용해야 한다고 한다. 하지만 양자 컴퓨터가 도입되면 이야기가 달라진다. 양자 컴퓨터로 쇼어 알고리즘을 사용하면 비대칭키 암호화 방식을 깰 수 있는데, 3072 bit RSA를 깨는데 6146 qubit이 필요하지만, 256 bit ECC를 깨는 데는 2330 qubit밖에 필요하지 않다. 여전히 같은 키 크기에서 RSA보다 ECC가 안전하지만, 기존에 안전하다고 여겨지던 것보다는 차이가 많이 줄어든다. 다행이도 아직은 양자컴퓨터가 수십 qubit 수준에서 연구 중이기 때문에 최소한 십 년 운 좋으면 몇십 년 내에서는 별문제 없을 것이라고 생각한다.

Announcing Rust 1.26

Rust 1.26이 나왔다. 일단 눈에 띄는 변화는 다음이 있다.

함수의 인자와 리턴 타입으로 impl Trait 허용

Rust의 trait은 크기가 없기 때문에, 함수의 인자로 받거나 리턴할 수 없었다. 이런 경우 Box로 싸거나, generic을 써야 했다. 이를 impl Trait라는 문법을 추가해서 간단하게 사용할 수 있도록 했다.

레퍼런스 타입 match 할 때, 자동으로 dereference

기존에는 레퍼런스 타입을 매칭하면 패턴 부분에도 전부 레퍼런스라는 것을 명시해야 했다. 이제는 레퍼런스를 자동으로 dereference하기 때문에 &ref를 쓸 필요가 없다.

main 함수가 Result 리턴할 수 있도록 허용

ErrDebug를 구현해야 한다는 제약이 있지만, 이제는 main 함수가 Result를 리턴할 수 있다. 리턴한 값이 Err라면 리턴한 Err를 출력하고 종료한다.

2018-05-06

2018년 18번째 주

이 포스팅은 그냥 지난 한 주간 읽었던 것들을 정리하는 포스트입니다. 그냥 예전에 봤던 글 중 나중에 필요한데 뭐였는지 기억 안 나는 글들이 있어서 쓰기 시작했습니다.
 보통 하는 일과 관련된 글들이 올라오겠지만 딱히 정해둔 주제는 없고, 그때그때 관심 있었던 것을 읽었기 때문에 지난주에 쓰인 글일 수도 있고 몇 년 전에 쓰인 글일 수도 있습니다.


3개월 전까지 C++을 쓰다가 최근에 회사를 옮기면서 Rust를 쓰고 있다. 개인적으로 느끼기에 Rust가 C++에 비해 가지는 가장 큰 장점은 cargo라고 생각한다. Cargo 덕분에 C++에 비해서 의존성 관리를 매우 쉽게 할 수 있다. 물론 최근에 나온 언어들은 대부분 패키지 매니저를 가지고 있다. 하지만 그들은 대부분 C++보다 추상화된 메모리 관리를 가정하고 있기 때문에 C++의 대안이 되지는 못한다고 생각한다.

흔히들 말하는 Rust의 메모리 안전성은 딱히 큰 장점으로 느껴지지 않는다. Modern C++에서 제공하는 기능들을 잘 사용하면 C++에서도 메모리 이슈로 문제가 될 일은 많지 않다. 물론 C++을 쓸 때는 잘 써야 한다는 전제가 있어서 Rust를 쓸 때는 때 걱정을 덜 해도 된다는 것은 큰 장점이다. 하지만 Rust가 메모리 안전성은 보장해도 false alarm을 발생하는 일도 자주 있다. Non-lexical lifetime 같은 것이 구현되면서 false alarm을 줄이고 있지만, 아직은 종종 false alarm 때문에 실제로 안전한 코드를 보기 안 좋게 수정해야 하는 경우도 있기 때문에 어느 쪽이 더 좋은지는 취향의 문제라고 생각한다.

Date format by country

우리나라를 비롯한 중국 일본은 흔히 YYYY-MM-DD 형식을 쓴다. 인도, 동남아, 유럽, 남미, 러시아는 DD-MM-YYYY 형식을 주로 사용한다. 우리나라에서 사용하는 형식을 보통 big endian이라고 부르고, 유럽 등지에서 사용하는 형식을 little endian이라고 부른다. 두 형식의 날짜를 전부 처리해야 하기 때문에 약간 귀찮기는 하지만 여기까지는 그래도 괜찮다.

근데 미국은 MM-DD-YYYY라는 괴랄한 표기법을 사용한다. 거의 인치법 이상으로 제정신이 아닌 표기법 같다. 물론 그들에게도 이유는 있다. 보통 날짜를 말할 때 연도는 중요한 것이 아니다. 오늘이 며칠인지 물어보면 5월 6일이라고 말하지 2018년인지는 말하지 않는다. 중요하지 않은 정보라서 뒤에 적는다는 것이 그들이 말하는 이유다. 근데 그럴 거면 그냥 연도를 적지 말았어야 한다고 생각한다. 내가 연도를 말할지 말지 날짜를 말할 때까지 아무 생각 안 하다가 몇 월 며칠인지 말하고 연도를 말한다는 게 잘 상상이 안 된다. 사실 상상이 되고 말고를 떠나서 middle endian의 날짜 포맷까지 처리하고 나면 짜증이 난다.

참고로 ISO 8601은 우리나라처럼 big endian을 쓰도록 규정한다. 사실 컴퓨터에서 처리하기에는 big endian이 가장 좋다. 그래서 미국이나 유럽에서 개발된 프로그램도 제대로 된 프로그램은 대부분 big endian으로 날짜를 보여준다.

A Taxonomy of Expression Value Categories

C++ 스펙에서 value category가 초안에서 어떻게 바뀌었는지 보여주는 문서다. C++ 11 이전의 lvalue, rvalue에서 xvalue가 추가되면서 어떻게 변했는지 보여준다. 개인적으로 Bjarne Stroustrup이 쓴 "New" Value Terminology와 함께 C++의 value category를 이해하는 데 가장 도움이 되는 문서라고 생각한다.

IMHO를 In My Honest Opinion이라고 받아들이는 사람이 더 많다고 한다. 리뷰나 토론할 때 많이 쓰는 표현인데 앞으로는 약자 쓰는 것도 조심해서 써야겠다.

참고로 buzzfeed가 했다는 설문은 Help Us Solve This Debate About What "IMHO" Stands For로 보인다.

2018-04-29

2018년 17번째 주

이 포스팅은 그냥 지난 한 주간 읽었던 것들을 정리하는 포스트입니다. 그냥 예전에 봤던 글 중 나중에 필요한데 뭐였는지 기억 안 나는 글들이 있어서 쓰기 시작했습니다.
보통 하는 일과 관련된 글들이 올라오겠지만 딱히 정해둔 주제는 없고, 그때그때 관심 있었던 것을 읽었기 때문에 지난주에 쓰인 글일 수도 있고 몇 년 전에 쓰인 글일 수도 있습니다.


The Configuration Complexity Clock

Configuration을 만들다 보면 Rules engine이나 심할 때는 DSL(Domain Specific Language)까지 만들기도 하는데, 어떨 때는 그냥 하드코딩 하는 것이 가장 적절한 방법일 수 있다는 글이다.

Linus's Law

given enough eyeballs, all bugs are shallow

리누스의 법칙은 위의 한 줄로 정리된다. 오픈 소스의 근간이 되는 문장이고, peer-review가 필요한 이유로도 많이 언급된다. 문제는 최근의 거대한 소프트웨어서는 버그를 발견하는 데 필요한 enough의 수가 너무 크다는 것이다. 게다가 시스템이 복잡하다면, 그 시스템을 이해하지 못한 개발자는 버그를 발견하기 위한 eyeballs 중 하나가 되지도 못한다. 그렇기 때문에 시스템을 단순하게 유지하는 것이 중요하다.

Language Health

각 언어가 오픈 소스에서 얼마나 많이 사용되는지 비교해보는 사이트다. 다만, 어디까지나 오픈소스에서 얼마나 많이 커밋이 있었는지에 대한 비교이지, 얼마나 많은 사람이 사용하는지나, 클로즈드 프로젝트에서 얼마나 많이 사용하는지는 알 수 없다.

An introduction to the GNU Core Utilities

리눅스에서 작업하다 보면 필요한 유틸리티 모음. 터미널에서 작업할 때 알면 좋은 것들이다.

REST APIs are REST-in-Peace APIs. Long Live GraphQL.

GraphQL의 장점에 관해서 쓴 글이다. 근데 여전히 GraphQL을 쓸지는 모르겠다. 복잡한 웹 서버를 짤 일이 있으면 모르겠는데 요새는 웹 서버라기보다는 그냥 간단한 툴의 UI를 웹으로 사용하는 정도로만 웹 코딩을 하고 있다. 이 정도 수준의 앱에서는 GraphQL을 사용하는 것이 오버헤드가 더 클 것 같다. 사실 반대로 말하면 뭘 써도 상관 없는 크기라서 GraphQL을 써도 된다. 하지만 다른 라이브러리에 디펜던시 없이 구현할 수 있는 REST에 비해서 GraphQL을 쓰려면 GraphQL을 구현하는 라이브러리를 써야 하므로 의존성을 추가해야 하는데 아직 그만한 필요성을 못 느끼겠다.

GO's New Brand

GO가 새 로고를 발표했다. 드디어 이상한 쥐를 버린 줄 알았는데 Gopher는 마스코트로 여전히 남겨두는 듯 하다.

Flask 1.0 Released

Flask가 드디어 1.0이 됐다. 사실 전에도 0.X인걸 신경 쓰지 않고 썼기 때문에 상관없지만 1.0을 쓰면 괜히 기분이 좋다.

2018-04-22

2018년 16번째 주

이 포스팅은 그냥 지난 한 주간 읽었던 것들을 정리하는 포스트입니다. 그냥 예전에 봤던 글 중 나중에 필요한데 뭐였는지 기억 안 나는 글들이 있어서 쓰기 시작했습니다.
 보통 하는 일과 관련된 글들이 올라오겠지만 딱히 정해둔 주제는 없고, 그때그때 관심 있었던 것을 읽었기 때문에 지난주에 쓰인 글일 수도 있고 몇 년 전에 쓰인 글일 수도 있습니다.


ISO week date

오늘이 올해의 몇 번째 주인지 정하는 기준은 말하는 사람마다 다르다. 그래서 이 요약정리 시리즈는 ISO 8601 기준으로 몇 번째 주인지 표기한다. ISO 8601에 따르면 1월 4일이 포함된 주를 그 해의 첫 번째 주로 취급한다. 다른 말로 한 주의 시작을 월요일로 봤을 때 4일 이상 포함된 첫 번째 주가 그 해의 첫 번째 주인 것이다.

TextQL

머신 러닝이나 데이터 마이닝을 할 때 데이터의 경향성을 대강 파악하고 싶을 때가 있다. 이럴 때 사용되는 데이터는 보통 매우 큰 데이터이기 때문에 에디터로 열어서 보는 것은 무리가 있고, 간단하게 스크립트를 짜서 실행하게 된다. 근데 이때 하는 일은 대부분 비슷한 일이기 때문에 꽤나 귀찮은 작업이었는데, 스크립트를 짜지 않고 파일을 SQL을 실행시켜주는 프로젝트가 있었다.

아직 사용해보지는 않아서 직접 스크립트를 짜는 것과 비교하면 어떨지는 모르겠지만 꽤 많은 사람이 쓰고 있는 것 같다.

Writing

수학을 배워야 하는 이유가 사고하는 법을 익히기 위해서이듯이, 글쓰기를 배우는 이유는 무엇을 생각했는지 명확하게 하기 위해서다. 사람은 모든 것을 기억할 수 없기 때문에 자신이 생각한 것을 써서 정리해야 한다는 것이다. 게다가 글을 쓰는 것은 내가 글 쓰는 주제에 대해 나보다 모르는 독자를 가정하고 글을 쓰게 된다. 그래서 평소에는 당연하게 생각하고 넘어갔던 것들에 대해서도 한 번 더 생각하고 넘어갈 시간을 가지게 한다.

How quantum computing could wreak havoc on cryptocurrency

양자 컴퓨터가 상용화되면 현재 사용되는 암호화 기법 중 많은 것들이 쉽게 풀리게 된다. Cryptocurrency들은 이날을 대비해서 post-quantum cryptography로 넘어갈 준비를 해야 한다는 글이다. NSA는 수십 년 안에 양자 컴퓨터가 실제 암호를 해킹할 수 있을 정도로 발전할 것이라는 보고서를 작성한 적이 있다. 하지만 윗글의 글쓴이는 수십 년까지 가지 않고 십수 년 내에 양자 컴퓨터가 암호학에 실질적인 위험이 될 것이니 대비를 해두어야 한다고 주장한다.

OLPC’s $100 laptop was going to change the world — then it all went wrong

10년 전쯤 유행했던 OLPC라는 프로젝트가 있다. One Laptop Per Child라는 이름 그대로 모든 아이에게 노트북을 제공하겠다는 프로젝트였다. XO-1이라는 100$짜리 노트북을 제작하여 개발도상국의 어린이에게 노트북을 하나 더 제공하겠다는 프로젝트였다.

하지만 모든 아이에게 XO-1을 제공하겠다는 프로젝트는 결국 실패했다. XO-1 이후 출시할 계획이었던 XO-2는 나오지도 못했다. 실패한 원인은 여러 가지 있다. 애초에 목표했던 100$ 가격에 도달하지 못하기도 했고, 인텔에서 나온 넷북이 XO-1보다는 비싸지만, 훨씬 훌륭한 성능과 보편성 때문에 더 인기 있었다.

나는 이것을 뜻은 크지만, 기술이 뒤받쳐주지 못해서 생긴 OLPC의 완벽한 실패라고 생각한다. 하지만 윗글의 저자는 OLPC가 넷북의 보급을 가지고 왔고 덕분에 저가형 노트북 시장이 커졌으므로 어느 정도 목표를 이루었다고 보는듯하다.

The latest trend for tech interviews: Days of unpaid homework

최근 유행하고 있는 테크회사들이 인터뷰 시 단순히 면접으로 끝내는 것이 아니라 시간이 오래 걸리는 과제를 내는 것을 비판하는 글이다. 말하고자 하는 바는 이해하지만, 딱히 더 좋은 해결법은 생각나지 않는다. 나는 회사에서 줄 수 있는 가장 큰 복지 중 하나는 좋은 팀을 구성해주는 것이라고 생각한다. 그런 면에서 충분히 검증되지 않은 사람과 일하고 싶지 않다. 물론 검증에 필요한 비용을 구직자에게 전가하는 방식은 옳지 못하다. 개선할 필요가 있다. 하지만 그게 윗글에서 말하는 한 시간 내외의 코딩면접인지는 잘 모르겠다.

Why Is SQLite Coded In C

SQLite가 어째서 C를 사용하는지에 관한 글이다. 개인적으로 C를 좋아하지는 않지만, 이 글에서 주장하는 바는 전부 타당하다고 생각한다.

Conceptual compression means beginners don’t need to know SQL — hallelujah!

Ruby on Rails(a.k.a. RoR)의 제작자, DHH가 쓴 글이다. RoR은 잘 만들어진 ORMActive Record로 유명하다. 사실 지금까지 Active Record 외에는 쓸만한 수준으로 동작하는 ORM을 본 적이 없다. 하지만 여전히 ORM이 SQL을 대체할 수 있는가에 대해서는 회의적이다. 아마 DHH도 완전히 대체할 것으로 생각하지는 않았는지 beginners에 한정시켜 말하기는 했다.

하지만 나는 여기에도 회의적이다. 프로그래머가 쓰는 시간 대부분은 사실 코딩이 아니라 전체적인 구조를 설계하는 것과 문제가 생겼을 때 디버깅하는데 들어간다. SQL을 모른다는 것은 사실 RDBMS(Relational database management system)의 동작을 이해하지 못했다는 것인데 아무리 적절한 수준의 추상화가 문제를 단순화시키는 데 도움을 준다고 해도, 내부 동작을 모른 채로 적절한 설계를 하거나, 문제가 생겼을 때 원인을 찾아낼 수 있다고 생각되지 않는다.

Analysis of the Bitcoin UTXO set

Bitcoin은 Unspent Transaction Output(a.k.a. UTXO) set을 이용해 현재 상태를 표현한다. 위 논문은 bitcoin에서 UTXO를 어떻게 저장하고 UTXO set이 어떻게 변해왔는지를 분석했다.

2018-04-14

2018년 15번째 주

이 포스팅은 그냥 지난 한 주간 읽었던 것들을 정리하는 포스트입니다. 그냥 예전에 봤던 글 중 나중에 필요한데 뭐였는지 기억 안 나는 글들이 있어서 쓰기 시작했습니다.

보통 하는 일과 관련된 글들이 올라오겠지만 딱히 정해둔 주제는 없고, 그때그때 관심 있었던 것을 읽었기 때문에 지난주에 쓰인 글일 수도 있고 몇 년 전에 쓰인 글일 수도 있습니다.


실제로 git을 사용하면서 단순히 커맨드를 외워서 사용하는 사람들을 많이 봤다. 보통 그 이유로 크게 두 가지를 든다. 첫 번째로 git의 mental model이 복잡하다는 것이다. git에서 변경된 내용은 크게 다음 상태 중 하나가 된다.

  1. 리모트에 존재하는 상태
  2. 로컬 브랜치에 있는 상태
  3. 브랜치에 머지되지 않았지만 add 돼 있는 상태
  4. 변경은 있지만 add 되지는 않은 상태
  5. stash에 들어있는 상태
  6. 예전에 커밋했었지만 지금은 브랜치로 따라갈 수 없는 상태

이 중에서 내가 수정했던 내용이 어떤 상태인지 모르는 것이 헷갈리게 하는 첫 번째 이유다.
하지만 반대로 왜 이렇게 많은 상태를 가지게 됐을지 생각해보면 git을 사용하는 데 도움이 된다. 이것들은 전부 그냥 추가된 것이 아니다. 애초에 git을 처음 만든 사람은 Linus Torvalds다. 그의 성격상 쓸모없는 것은 추가되지 않았다. 전부 제각각의 목적을 가지고 있다. 이 목적을 이해하는 것이 중요한데 아쉽게도 글로 잘 설명할 자신이 없다. 사실 이걸 이해하는 가장 빠르고 확실한 방법은 svn을 써보는 것이다. 쓰다 보면 불편한 부분들이 자주 생기는데, git에서는 위에서 말한 것들을 이용해 이를 쉽고 빠르게 해결할 수 있다.

사람들이 git을 어려워하는 두 번째 이유는 명령어가 복잡하다는 것이다. 이건 어쩔 수 없다. 사실 git의 명령어는 규칙성 없이 만들어졌다. 그래서 외우는 수밖에 없다. 하지만 어떤 상황에서 어떤 명령어를 써야 한다는 식으로 외우면 끝이 없다. 그보다는 각 명령어가 어떤 상태와 연관이 있는지를 보는 것이 좋다. git 명령어는 대부분 변화된 내용을 위의 상태 중 하나로 만들거나, 특정 상태로 로컬에 있는 파일을 변경하는 것이다. 따라서 현재 파일이 어떤 상태에 있고 명령어 이후 어떤 상태로 된다는 것을 인지하고 있으면 조금은 더 쉽게 적응할 수 있다.

News is bad for you – and giving up reading it will make you happier

뉴스가 사람의 정신건강에 해롭다는 기사다. 사람들이 흔히 정보를 얻으려고 뉴스를 읽지만, 실제로는 별 도움도 안 되고 시간만 낭비하게 하고 사람의 창의성을 없애고 수동적으로 만든다는 것이다.

Introduction to zkSNARKs

이더리움의 최근 움직임 중에서 zero-knowledge proof인 zkSNARKs을 도입하고자 하는 움직임이 있다. 위 자료는 이더리움 소속으로, 솔리디티 창시자 중 하나이며 zkSNARKs를 구횬하고 있는 Christian Reitwiessner이 zkSNARKs에 대해 간단히 소개한 발표자료다. 자료 이름은 zkSNARKs이지만 대부분의 내용을 zero-knwledge proof가 무엇인지에 설명하는 데 쓰고 있으므로 zero-knowledge proof가 무엇인지 알고 싶은 사람들이 보기에도 좋은 자료다.

RSS is undead

RSS는 이미 수명이 끝났고, 다시 살아날 리 없다는 글이다. 지난번에 소개했던 It's Time for an RSS Revival이나 Why RSS Still Beats Facebook and Twitter for Tracking News의 반대편에 있는 입장이다.

RSS는 소규모 사이트의 글을 구독하는 데는 적절하지만, 대형 사이트의 특정 카테고리의 글을 구독하는 데는 적당한 UX를 제공하지 못하고, 퍼블리셔 입장에서 사용자의 패턴을 파악할 수 없을뿐더러 광고수익을 얻을 수 없기 때문에 사용자와 퍼블리셔 양쪽에게 손해라는 것이다.

What is a “box model”? (UI Element layout)

Web을 비롯하여 현대의 많은 UI framework들이 box model을 사용하기 때문에 프론트엔드 개발을 하려면 한 번 읽어두는 것이 좋다.

The Science of The Job Search, Part III: 61% of “Entry-Level” Jobs Require 3+ Years of Experience

경력 같은 신입을 원하는 건 우리나라뿐 아니라 전세계 공통인듯하다.

A fork on Github is no fork

Git은 decentralized 된 version control system이기 때문에 fork를 하면 어디서 fork 해왔는지와 완전히 독립적인 repository로 존재할 수 있다. 하지만 Github의 fork는 그 모든 설정과 권한이 원본 repository에 종속적이기 때문에 진짜 fork가 아니라는 글이다.
원칙적으로 맞기는 하지만 Github Enterprise나 private repository 유료 모델을 생각해보면 어쩔 수 없는 선택이었다고 생각한다.

Uninhabited types are ZSTs despite partial initialization being allowed in safe code.

Rust 1.24.0 이후 생긴 memory safety가 깨지는 버그다.

Rust는 무한루프나 내부에서 exit 하기 때문에 return 되지 않는 함수를 표현하기 위해서 uninhabited type을 도입했다. 이 uninhabited type으로 product type을 만들면 이 타입도 uninhabited type이 돼서 크기가 0인 type으로 계산되는데, 이 product type의 다른 field를 접근하는 게 가능해서 주소 계산이 잘못되는 버그가 발생했다. Rust에 zst(zero size type)가 도입됐을 때부터 메모리 주소 계산을 잘못 하는문제가 발생하지 않을까 생각했는데 정말로 터져버렸다.

현재 두 가지 해결 방안 중에서 어느 쪽으로 해결할지 논의 중이라고 하니까 다음 버전인 1.26.0에서는 수정될 것으로 보인다.

Top 10 Bugs in the C++ Projects of 2017

소프트웨어 분석 회사인 viva64에서 2017년 동안 발견했던 버그 중 가장 인상 깊은 버그 10개를 발표하였다. uninitialized memory부터 type error나 단순 실수까지 다양하게 있다.

Don’t Give Away Historic Details About Yourself

자기 정보를 쉽게 제공하지 말라는 글. 특히 우리나라 사람들은 주민등록번호 유출에조차 익숙해져서 그런지 자기 정보를 적는데 아무런 망설임이 없다.

Why Does "=" Mean Assignment?

수학에서는 보통 대입에는 :=를 사용하고 =는 비교에 사용한다. 근데 프로그래밍에서는 왜 =를 대입에 사용하게 됐는지에 관한 글이다. 뭐 지금은 다들 =를 대입연산자로 사용하고, ==를 비교연산자로 사용하는 데 익숙하기 때문에 별 의미는 없지만, 그냥 재미로 읽어봤다.

2018-04-07

2018년 14번째 주

이 포스팅은 그냥 지난 한 주간 읽었던 것들을 정리하는 포스트입니다. 그냥 예전에 봤던 글 중 나중에 필요한데 뭐였는지 기억 안 나는 글들이 있어서 쓰기 시작했습니다.
 보통 하는 일과 관련된 글들이 올라오겠지만 딱히 정해둔 주제는 없고, 그때그때 관심 있었던 것을 읽었기 때문에 지난주에 쓰인 글일 수도 있고 몇 년 전에 쓰인 글일 수도 있습니다.

Why you should pick strong consistency, whenever possible

지난번 글에서 CP와 AP 중에서 CP를 AP보다 더 선호해야 한다고 썼었다. 이렇게 생각한 사람이 나만 있는 건 아닌 것 같다. 구글 클라우드 플랫폼 팀에서 발표한 Spanner라는 데이터베이스는 external consistency를 보장한다. 이 포스트는 Spanner가 external consistency를 사용한 이유에 관한 글인데 제목은 strong consistency라고 나와 있지만, 이는 strong consistency가 더 일반적으로 사용되는 용어이기 때문에 제목을 이렇게 쓴 것이지 Spanner는 언제나 최신 데이터를 읽을 것을 보장하는 external consistency를 보장한다.

MantisTek GK2's Keylogger Is A Warning Against Cheap Gadgets

중국 키보드에서 키로거가 검출됐다고 한다. 개인적으로 전자제품 살 때 알리익스프레스를 많이 사용한다. 같은 사양의 제품을 10분의 1도 안 되는 가격으로 살 수 있기 때문이다. 그때마다 친구들과 이거 전부 해킹당하고 있는거 아닌가라는 농담 하면서 구매하고 몇일은 외부로 나가는 네트워크를 감시하고 그랬는데 실제로 키로거 하는 제품이 있었다.

There's a biological reason you're bored at work

회사 생활에 질리고 권태감이 드는 게 생물학적으로 당연하다고 한다. 사람의 뇌는 언제나 새로운 것을 추구하도록 진화됐다고 한다. 이는 사람뿐만 아니라 동물들에게도 마찬가지다. 동물들도 주어진 먹이를 먹는 것보다 숨겨진 음식을 찾아서 먹는 것을 더 좋아한다. 숨겨진 것을 찾아내고 새로운 것을 알아가면 뇌가 자극받아 도파민을 분비하고 이게 기쁨을 느끼게 한다는 것이다.

문제는 현대의 회사 시스템은 이런 도전 정신을 자극할만한 것이 없다는 것이다. 그래서 결국 주기적으로 팀을 옮기거나 조금 더 적극적인 경우 회사를 옮기거나 회사 생활에서 못 받는 자극을 취미에서 찾거나 하는 것 같다.

개인적으로는 이런 권태감을 개인 프로젝트로 푸는 편이다. 특히 회사 일과 같은 것을 하지 않기 위해서 개인 프로젝트를 할 때는 회사에서 쓰는 것과 다른 특성의 언어를 사용하여 회사 일과 상관없는 분야를 한다.

Known-planitext attack

KPA라고 불리는 암호학 공격기법이다. 이름 그대로 공격자가 암호화되기 전의 평문을 알고 있는 암호문이 몇 개 있을 때, 이를 기반으로 어떤 알고리즘으로 암호화된 것인지, 혹은 알고리즘을 이미 알고 있다면, 어떤 키로 암호화됐는지 찾아내는 공격방법이다. 찾아낸 알고리즘이나 키를 이용하여 후에 들어오는 암호문을 복호화하는 것이 목적이다.

It's Time for an RSS Revival

지난번에 소개했던 Why RSS Still Beats Facebook and Twitter for Tracking News와 비슷한 글이다. 최근 페이스북에서 터진 이슈 때문에 많은 사람이 대안을 찾고 있어 RSS에 주목하는 글이 많이 나오고 있는 듯하다.

Metcalfe's law

네트워크의 효용성은 노드 간 컨넥션 수가 높을 수록 높으므로 노드 수의 제곱에 비례하게 된다는 법칙이다. 하지만 현실적으로는 모든 노드가 서로 컨넥션을 갖지 않는다. 따라서 크기가 작은 네트워크에서는 메칼프의 법칙이 성립하지만, 크기가 커지면 성립하지 않는다. 일반적으로 노드 수가 많은 네트워크는 complete graph도 아니고 각 컨넥션이 모두 같은 가치를 갖는것도 아니기 때문이라고 한다.

2018-04-01

2018년 13번째 주

 이 포스팅은 그냥 지난 한 주간 읽었던 것들을 정리하는 포스트입니다. 그냥 예전에 봤던 글 중 나중에 필요한데 뭐였는지 기억 안 나는 글들이 있어서 쓰기 시작했습니다.
 보통 하는 일과 관련된 글들이 올라오겠지만 딱히 정해둔 주제는 없고, 그때그때 관심 있었던 것을 읽었기 때문에 지난주에 쓰인 글일 수도 있고 몇 년 전에 쓰인 글일 수도 있습니다.


정규 표현식에서 \d가 의미하는 것이 언어마다 다 다르다고 한다.

언어가 지원하는 문자열이 single byte문자열이면, \d가 [0-9]를 의미하는 것이 맞지만, 유니코드라면 [0-9] 이외의 문자열도 처리할 것을 고려했어야 한다. 그런 의미에서 파이썬 2의 string literal은 유니코드가 아니기 때문에 [0-9]를 처리하는 것이 이상하지 않지만, Java나 JavaScript처럼 유니코드 string literal을 지원하는 언어에서 \d를 [0-9]에만 대응하는 건 조금 안일한 결정이 아니었나 싶다


자바스크립트 디자인 패턴: RORO

RORO는 Receive an Object, Return an Object의 약자로, 이름 그대로 함수에 넘기는 인자와 함수가 넘기는 인자를 object로 하자는 것이다. 함수의 인자로 object를 넘기자는 것은 꽤 옛날부터 있었던 주장이다. 최소한 내가 처음 웹 개발을 했던 2009년경에는 이미 함수의 인자로 객체를 넘기는 패턴이 유행했다. 함수의 인자로 객체를 넘겼을 때의 장점은 두 가지로 정리할 수 있었다.

하나는 default parameter를 구현하기 쉽다는 것이다. EcmaScript 5까지는 default parameter가 없었다. Default parameter를 흉내 내기 위해서 Arguments를 이용해야 했는데, 몇 번째 인자가 무슨 의미를 가지는지 코드에 표현할 방법이 없기에 새 인자를 하나 추가할 때 실수할 확률이 높았다. 이를 object를 이용하면, property 이름이 있기 때문에 Arguments를 이용하는 것보다 읽고 수정하기 쉬운 코드를 만들 수 있었다. 이는 EcmaScript 6에서 default parameter가 추가됐기 때문에 지금은 크게 장점이 아니다.

두 번째 장점은 EcmaScript에 없는 named parameter를 구현할 수 있다는 것이다. EcmaScript에는 named parameter가 없기 때문에 인자 개수 차이에 따라 몇 번째 인자가 무엇을 의미하는지 다르게 해석하는 방법을 많이 사용한다. 하지만 이는 버그를 만들기 쉬운 코드이므로 좋은 방법은 아니다. 이것도 object를 사용하면, 손쉽게 구현할 수 있다.

인자를 객체로 넘기자는 주장은 많이 있었지만, 함수의 리턴 값을 객체로 하자는 주장은 과거에는 그리 흔한 주장이 아니었다. 함수의 종류에 따라 객체를 리턴하는 값이 특정한 객체로 묶기 쉬운 경우도 있었다. 그러나 이 값을 하나의 값이라고 부를지 리턴을 위해 객체로 묶었다고 부를지는 사람마다 다를 것이다.
하지만 EcmaScript 6 이후로는 전혀 관계없는 값을 하나로 묶어서 리턴하는 코드도 자주 보인다. EcmaScript 6에 들어온 destructuring assignment 덕분으로 보인다.


Coding is bad for you

코딩하다 보면 문제가 생길만한 상황이나 너무 사소한 것에 집착하게 되기 때문에 정신 건강에 해롭다는 글.

경험적으로 잘 짠 코드는 예상치 못한 상황에 대비할 수 있도록 짜인 코드였다. 그렇기 때문에 당연히 문제가 생겼을 때를 대비하는 프로그래머가 잘 하는 프로그래머일 것이고, 그들은 사소한 문제가 될만한 상황도 잘 잡아낸다. 이걸 못 하는 사람들은 아무리 빠르게 스펙에 맞게 코드를 짜더라도 절대 잘 한다는 소리를 들을 수 없다.

근데 이게 코딩을 하다 보면 사람이 그렇게 생각하게 되는지 원래 그런 사람들이 코딩을 잘하는 건지는 잘 모르겠다.


Avoid else early return

억지로 single point return을 만들기 위해 if/else를 쓰지 말고, early return이 가능한 지점에서는 최대한 빠르게 return 하자는 글이다. 경험상 single point return이 early return보다 장점을 가지는 경우는 C를 사용할 때밖에 없었다.
Early return이 문제가 되는 경우는 결국 함수 종료 시 특정 로직을 실행해야 하는데, return 문이 많이 있어서 실수로 로직을 빼먹는 경우다. 하지만 요즘 나오는 언어는 대부분 RAII가 되거나, finally block을 지원한다. 따라서 요즘 나온 언어를 사용하면 early return을 사용할 때의 문제점을 언어 차원에서 해결책을 제공하는 것이다.

아쉽게도 C에는 아직 RAII나 finally block에 해당하는 기능이 존재하지 않는다. 그래서 함수가 끝날 때 특정 코드를 실행시킬 방법이 없고, 이런 문제로 C에서는 single point return을 쓰는 게 더 안전할 수 있다. 그래서 지금도 리눅스 커널에서는 예외 처리나 리소스 해제 등을 위해 goto를 이용하여 single point return을 만드는 방법이 권장된다.

하지만 이는 C를 쓸 때의 예외적인 상황이고 대부분의 경우에는 early return이 더 좋다.


LG launches open source version of webOS

LG 스마트 워치나 스마트 티비에 들어가는 webOS의 오픈 소스 버전이 공개됐다는 소식.
webOS는 원래 Palm에서 만든 OS로 리눅스 커널 기반이라는 점에서 안드로이드나 iOS보다 잘 되기를 바랐지만 망한 OS다.
한 5년쯤 전에 LG가 인수했다는 말은 들었는데 LG가 이것저것에 사용해본 듯한데 결과적으로 점유율이 0%인 것을 보면 확실하게 망한 듯하다. 이제 와서 오픈 소스 버전을 공개한다고 하는데 딱히 기대는 안 된다. 오픈 소스라는 게 단순히 소스를 공개한다고 끝나는 것이 아니라 사용자로부터 꾸준한 피드백을 받으며 이루어지는 커뮤니티가 핵심인데, webOS에 피드백을 줄 사용자가 있을지, LG가 그런 커뮤니티를 운영할 능력이 있을지도 의문이다. 솔직히 webOS를 사는데 든 돈이 아까워서 손절하지 못 하고 있는 게 아닐까 싶다.


Key words for use in RFCs to Indicate Requirement Levels

영어를 못 해서 스펙 문서를 작성할 때 어떤 조동사를 써야 할지 헷갈릴 때가 있는데, 그때를 위해 Network Working Group에서 규정한 가이드라인이다.

  • MUST, SHELL, REQUIRED - 반드시 해야 하는 경우
  • MUST NOT, SHELL NOT - 절대 하면 안 되는 경우
  • SHOULD, RECOMMENDED - 근거가 있으면 안 해도 되는 경우
  • SHOULD NOT, NOT RECOMMENDED - 근거가 있으면 해도 되는 경우
  • MAY, OPTIONAL - 하든 안 하든 전체 동작에 문제가 없어야 하는 경우

2018-03-25

2018년 12번째 주

이 포스팅은 그냥 지난 한 주간 읽었던 것들을 정리하는 포스트입니다. 그냥 예전에 봤던 글 중 나중에 필요한데 뭐였는지 기억 안 나는 글들이 있어서 쓰기 시작했습니다.
보통 하는 일과 관련된 글들이 올라오겠지만 딱히 정해둔 주제는 없고, 그때그때 관심 있었던 것을 읽었기 때문에 지난주에 쓰인 글일 수도 있고 몇 년 전에 쓰인 글일 수도 있습니다.

not invented here syndrome

not invented here syndrome이란 말 그대로 자신이 아닌 다른 사람 혹은 다른 팀에서 개발한 물건을 배척하는 태도를 말한다. 너무나 당연하게 이런 태도는 잘못된 것이다. 사람이 필요로 하는 것은 대부분 비슷하기 때문에 이미 그것을 만든 사람이 있을 것이다. 게다가 내가 천재가 아닌 이상 더 오랜 시간 개발되고 테스트해온 다른 라이브러리가 더 안정적으로 돌아갈 것은 당연하다.
하지만 요새는 오히려 반대의 태도. 즉, 모든 라이브러리나 툴을 외부에서 가져와서 해결하려는 태도 때문에 개발이 더 느려지게 되었다. 라이브러리 혹은 프레임웍은 일반적인 문제에 대해서 해결하고자 작성됐기 때문에 간단한 문제를 써드파티 라이브러리로 해결하려고 할 때 오히려 문제가 더 커지기도 한다. 널리 쓰이는 용어는 아니지만 이를 not invented here의 반대된다는 뜻에서 invented here syndrome이라고 부르는 사람도 있다.
결국 엔지니어링은 트레이드오프 사이에서 하나를 선택하는 것이기 때문에 직접 구현할지 써드파티 라이브러리를 사용할지 적절한 수준에서 잘 선택해야 한다.

조직문화와 리더십을 일치시키지 마라

회사 경영에서 추구하는 바를 크게 성과 지향과 관계 지향으로 나눴을 때 어느 쪽을 추구할 것인지에 대해서 조직이 추구하는 방향과 리더가 추구하는 방향을 일치시키지 말라는 글이다.
상식적으로는 리더가 성과 지향일 경우 조직 문화도 성과 지향적이어야 높은 성과를 내기 쉽고, 리더가 관계 지향일 때는 조직도 관계 지향적이어야 회사가 원활하게 돌아간다고 생각하기 쉬운데, 이를 전면적으로 부정하는 연구결과이다. 물론 성과지향인지 관계지향인지는 주관적인 것이기 때문에 단순 설문으로 잘 측정됐을지라거나, 구성원의 행복도 같은 것을 무시하고 재무제표 상에서의 성과만을 측정했다는 점에서 논란의 여지가 있을 수 있겠지만 그래도 조직을 운영할 때, 혹은 일 할 회사나 팀을 선택할 때 한 번 생각해볼 만한 주제라고 생각한다.

EditorConfig

얼마 전까지만 해도 거의 모든 작업을 vim으로만 했기 때문에, vim 설정만 잘해놓으면 됐다. 근데 최근에 Clion을 적극적으로 사용하게 되면서 둘 사이의 스타일이 달라져서 생기는 문제가 발생하게 됐다.
그래서 찾아보니 서로 다른 IDE에서 코딩 스타일을 통일하기 위한 EditorConfig라는 설정이 있다는 것을 알게 됐다. clion을 비롯한 JetBrains 제품들은 별도의 플러그인 없이도 EditorConfig 설정을 읽고 있고, vim을 위해서는 EditorConfig 팀이 제작한 플러그인이 존재한다.

2018-03-11

2018년 10번째 주

 이 포스팅은 그냥 지난 한 주간 읽었던 것들을 정리하는 포스트입니다. 그냥 예전에 봤던 글 중 나중에 필요한데 뭐였는지 기억 안 나는 글들이 있어서 쓰기 시작했습니다.
 보통 하는 일과 관련된 글들이 올라오겠지만 딱히 정해둔 주제는 없고, 그때그때 관심 있었던 것을 읽었기 때문에 지난주에 쓰인 글일 수도 있고 몇 년 전에 쓰인 글일 수도 있습니다.

Slack Is Shutting Down Its IRC Gateway

 채팅 프로그램들은 누구나 겪는 문제 중 하나가 일부 사용자가 IRC 클라이언트를 포기하지 않는다는 것이다. Slack도 마찬가지였고, 이에 대해서 Slack은 IRC Gateway를 지원하여 IRC 사용자들도 Slack에 포함시키려는 노력을 하였다.

https://xkcd.com/1782/

 하지만 이제는 Slack을 IRC 클라이언트에서 사용할 수 없다. Slack이 IRC 서포트를 중지한다고 발표했다.
 모든 플랫폼에서 같은 사용자 경험을 주고 싶은데 IRC에서 지원하지 않는 기능들이 방해되기 때문이라고 한다. 하지만 이미 Slack에서 IRC Gateway를 사용하는 사람들은 그 한정된 기능에 적응하고 사용하고 있는 사람들일 텐데, 이 사람들을 포기하면서 같은 사용자 경험을 주는 것이 그리 중요한 일일까 싶다. 그보다는 IRC Gateway를 이용하는 사람들을 Slack이 유료로 파는 기능들을 사용하지 않기 때문이 아닐까 싶다.

Why RSS Still Beats Facebook and Twitter for Tracking News

 Facebook이나 Twitter 같은 SNS가 생긴 뒤로 많은 사람이 자신의 포스팅을 SNS에 올리기 시작했고, RSS(Rich Site Summary)는 이제 사용되지 않을 것으로 생각했다. 대표적인 RSS 구독 서비스였던 Google Reader가 2013년 서비스를 종료했던 것이 RSS의 죽음을 나타내는 가장 상징적인 사건이었다.
 하지만 사람들은 여전히 RSS를 포기하지 않았다. 5년이 지난 지금까지 사람들은 여전히 RSS를 사용하고 있다. RSS는 SNS가 가지지 못 하는 장점이 여러 개 있다.
 일단 RSS를 사용하면 내가 구독하고 있는 것을 못 보고 넘어갈 일이 없다. SNS는 기본적으로 최근 포스트를 우선으로 보여준다. 내가 매일 접속하여 꾸준히 보지 않으면, 놓치는 정보가 있을 수 있다.
 게다가 SNS에서 보여주는 정보는 내가 원하는 정보라고 확신할 수 없다. RSS는 내가 RSS Reader에 구독을 원하는 주소를 등록하는 방식이지만, SNS는 자신들이 추천하는 포스트를 나에게 보여준다. 나름대로의 추천 알고리즘을 통해 정보를 뿌려주지만 내가 원하는 글이라고 확신할 수 없다.
 마지막으로 RSS는 하나의 서비스만 사용하면 되는데, SNS는 종류별로 가입해야 한다. 글을 올리는 사람이 모든 SNS에 다 올리면 좋겠지만, 현실은 그렇지 않다. 모든 글을 구독하기 위해서는 모든 SNS에 가입해야 하고, 내가 원하는 글만 보는 것이 아니라 각 SNS가 추천하는 글도 다 보게 된다.
 이런 문제들을 해결할 방법이 나오기 전에는 RSS가 죽을 일은 없을 것 같다.

static local variable


 일단 C++11 이후. 즉, 모던 C++에서는 맞는 말이다. 그 이전에서는 멀티 스레드 프로그램에서는 싱글턴을 사용해야 했는데, 그런 경우가 있으면 2018년에 모던 C++이 아닌 상황에서 이미 망한 프로젝트니까 빠르게 도망치자.
 과거에, 그러니까 C++의 abstract machine이 스레드에 대해 고려를 하지 않았던 시절에는 여러 스레드에서 동시에 static local variable을 사용하는 것이 문제가 될 수 있었다. 하지만 모던 C++에서는 abstract machine에 스레드 개념이 들어갔고, 여러 스레드가 동시에 접근하더라도 static local variable이 단 한 번만 초기화돼야 한다고 명시됐으니 그냥 컴파일러를 믿고 사용하면 된다.

2018-03-04

2018년 9번째 주

 이 포스팅은 그냥 지난 한 주간 읽었던 것들을 정리하는 포스트입니다. 그냥 예전에 봤던 글 중 나중에 필요한데 뭐였는지 기억 안 나는 글들이 있어서 쓰기 시작했습니다.
 보통 하는 일과 관련된 글들이 올라오겠지만 딱히 정해둔 주제는 없고, 그때그때 관심 있었던 것을 읽었기 때문에 지난주에 쓰인 글일 수도 있고 몇 년 전에 쓰인 글일 수도 있습니다.

Lifetime Safety: Preventing Leaks and Dangling

 Herb Sutter와 Neil MacIntosh가 쓴 C++에서 memory leakdangling pointer를 어떻게 없앨 수 있는지에 관한 글이다. 일반적으로 C++의 포인터는 매우 강력하기 때문에, memory leak이나 dangling pointer를 없애기 위해서 C++의 기능을 일부 제한하거나 새로운 문법을 추가하거나 한다. 하지만 이 글에서는 언어를 바꾸지 않으면서 런타임 오버헤드 없이 컴파일 타임에 분석할 수 있는 알고리즘을 제시한다.
 특히 이 알고리즘은 프로그램 전체를 분석하는 것이 아니라 함수 단위, 정확히는 블록 단위로 적용할 수 있고, 변수 재사용 등 많은 스타일 가이드에서 권하지 않지만 실제로는 많이 사용되는 패턴들에 대해서도 고려돼있기 때문에 레거시 코드에 적용하기도 좋다.
 기계적인 작업이기 때문에 툴을 만드는 것이 가장 좋을 것이다. 하지만 툴을 만들 여유가 없더라도 포인터나 레퍼런스를 어떻게 써야 안전한지 보여주는 좋은 글이기 때문에 일단 읽어보는 것을 추천한다.

GitHub DDoS 공격당함

 지난 2018년 2월 28일, GitHubDistributed Denial-of-Service(a.k.a. DDoS) 공격을 당해 약 10분 정도 서비스가 멈췄었다. 이 공격은 memcached를 이용한 공격으로 중국의 0kee team이 찾은 Deluge라는 기법을 이용한 공격이었다.
 Deluge는 다른 서버에 설치된 memcached에 데이터를 요청할 때 source IP를 목표가 되는 서버의 IP로 수정하여 보내, memcached 서버가 목표가 된 서버로 데이터를 보내게 만드는 공격이다.
 이런 부류의 공격을 IP spoofing이라고 하는데, 이는 Internet protocol(a.k.a. IP)OSI 7 layer에서 말하는 session layer에 관한 부분이 없기 때문에 생기는 근본적인 취약점을 이용한 것이기 때문에, 네트워크 프로토콜을 IP 위에 올린다면, 프로토콜을 작성하는 차원에서 세션 처리를 신경 쓰지 않았다면 근본적으로 막을 방법은 없다.
 IP spoofing 자체는 흔하게 사용되는 공격법이지만 memcached를 사용하는 Deluge는 그중에서도 큰 획을 그었다. 단순히 GitHub을 공격했기 때문이 아니라 적은 패킷으로 많은 데이터를 공격하게 할 수 있기 때문이다. 이 비율을 bandwidth amplification factor라고 하는데 Deluge는 지금까지 알려진 IP spoofing 공격 중에서 가장 높다.