개발 첫달에 발견된 버그를 확인해 보니 한 분에게서 전체 버그의 80%(스무명 중 하나이니 평균인 5%가 아니라)가 나온 것입니다. 이렇게 놀라운 수치가 나올 경우 보통은 뭔가 잘못된 것이죠. 그 분이 맡은 부분이 굉장히 복잡한 부분일 수도 있고, 혹은 다른 개발자들은 코딩을 별로 안한 것일 수도 있고 하지만, 그런 경우가 아니었을 뿐더러, 여러 정황을 고려해도 그 정도 비율은 지나치다는 판단이 들었죠. 그 분의 업무속도와 버그 생산 속도, 버그 심각도(severity), 디버깅 시간 등을 고려해 전체적 계산을 해보니 음의 생산성이 나왔습니다.

한마디로, 그 분이 일을 하면 할 수록 전체 팀이 할 일의 양이 늘어난다는 결론이었습니다.

애자일 이야기 – 음의 생산성

서문부터 시작해서 사례 하나하나가 모두 충격적일 내용. 마음 같아서는 모든 문장을 인용하고 싶었지만 그건 곤란할 테니 꼭 원문을 읽어보시는 것을 추천합니다. 개인적으로는 더닝-크루거 효과가 인상적이었음.

유토피아天國가 있다면 그것은 Facebook에 가까울 것이다.1

— 다카노 가즈아키 저, 13계단을 읽고


  1. 즉, 물리 세계에서는 불가능하다. 

Xcode 6 beta 3에서의 Swift 변경점 요약

주의: 이 내용은 Swift와 Xcode beta 발표 초기의 변화 내용을 담고 있습니다. 이 글이 쓰여진 이후로도 Swift에는 많은 변화가 있었고, 2014년 9월 현재 Xcode 6 정식 버전이 출시된 상태이므로, 정확한 정보를 얻기 위해서는 Apple에서 제공하는 Swift 최신 문서를 참조해주시길 바랍니다.

※ 자세한 변경점은 릴리즈 노트를 참고 (Mac Dev Center에 로그인 필요)

  • Array<T>를 선언하는 또 다른 방법인 T[]가 이제 [T]로 변경됨. 또한, 이제 Dictionary<K, V>[K:V]로 선언할 수 있다.
  • 혼란스러웠던 Array<T>의 변경 가능성(mutability)과 복사 관련 동작이 DictionaryString, struct와 같이 값으로서의 의미론(value semantic)을 따르도록 고쳐짐.
    • 이전에는 배열을 let으로 선언해도 배열의 길이를 바꾸는 연산1만 금지될 뿐, 배열 원소를 수정하는 건 가능했으며, var로 선언했을 때도 배열 원소를 수정하는 연산으론 배열이 복제되지 않았었다.
    • 이제는 배열을 let으로 선언하면 완전한 읽기 전용이 되어 길이 변경은 물론 원소 수정도 불가능한 상태가 되고, var로 선언하고 배열 원소를 수정하는 것도 변경으로 간주되어, 길이를 바꿀 때와 마찬가지로 별개의 배열로 복사되게 됨.
  • 1부터 10 이전(즉 1부터 9)까지를 의미하는 1..10과 1부터 10까지를 의미하는1...10이 서로 혼동되는 문제를 피하기 위해, .. 연산자가 ..<으로 변경됨.
  • 외부에서 불러온 C 함수가 CInt, CFloat 등의 타입 대신 Int32, Float 등을 쓰도록 바뀜
  • 외부에서 불러온 C 함수가 사용할 포인터 값에 관한 API가 좀 더 간단하게 바뀜
  • nil이 단순한 상수 이름에서 언어 리터럴로 편입. NilLiteralConvertible 프로토콜을 구현하면 nil을 받을 수 있는 타입을 만들 수 있음.

이외에 Swift 언어 자체의 변경점은 아니지만, Swift 소스 코드 안에 ASCII가 아닌 문자가 들어 있으면 자동 완성이 안 되던 Xcode 버그가 이번 베타에서 고쳐졌다고 한다.


  1. .append(), .removeLast() 등. 

어중간한 타입 시스템은 코드 재사용에 도움이 되지 않을 뿐더러 오히려 Ctrl+C와 Ctrl+V를 조장할 수 있다. 완전히 똑같은 일을 하는 코드 두 개가 단지 타입 이름이 조금 다르다는 이유로 섞어 쓸 수 없게 되기 때문이다. 동적 타입 언어가 비집고 들어온 틈 중에는 이런 점도 있었으리라 본다.

그렇다면 현 세대의 정적 타입 언어들은 이 부분에서 동적 타입 언어에 대한 경쟁력을 갖고 있을까? Go의 interface나 Rust 및 Swift의 확장 가능한 타입, C# 등이 가진 향상된 제네릭 타입 등은 이 문제를 해결하는가? Haskell의 type class는 어떤가? 최근까지 학술계의 전유물에 가까웠던 dependent type이 도입된다면 타입 시스템의 이상을 깨지 않고 동적 타입에 비할 만한 유연성을 얻을 수 있을까? 오히려 반대의 일이 일어나진 않을까?

실용화된 타입 이론만 생각해도 이미 C가 태어났던 80년대 시절에 비한다면 비약적인 향상이 있었지만, 이것으로 충분한지 나는 아직 회의적이다.

(Reblogged from hongminhee)
만약 다른 무엇보다 더 긴요하게 개정을 필요로 하는 헌법의 원리가 있다면 그것은 사상의 자유 — 우리가 지지하는 것에 대한 사상의 자유가 아니라 우리가 증오하는 사상에 대한 자유일 것이다.

1929년에 있었던 미합중국 대 슈치빔메르 소송에서 재판관 올리버 웬델 홈즈 2세가 제기한 반대 의견 중에서 인용.

평화주의자였던 로시커 슈치빔메르는 미국에 귀화하기를 원했지만, 인터뷰 도중 “나라를 지키기 위해 개인적으로 무기를 집어들 것”을 자신의 신념에 의해 거부했고, 그 결과 위 소송이 제기되게 되었다. 올리버 홈즈의 의견에도 불구하고 최종 판결은 슈치빔메르에게 미국 시민권을 부여하는 것을 거부하기로 결정되었지만, 이 판결은 훗날 1946년 기로워드 대 미합중국 소송에서 다시 뒤집어지게 된다.

참조: 파리13구님의 이글루 — 사상의 자유란?

2014-03-07 수정: 인용문을 좀 더 매끄러운 문장으로 고침

그건 다들 틀려먹었기 때문이다. GUI 라이브러리를 일반화하려면, 창이나 위젯보다는 좀 더 높은 수준에서 해야 한다. 다시 말해, 작업 흐름을 플랫폼별로 연관된 관례에 맞게 해석한다는 관점으로 라이브러리를 구성해야 한다.

문제는 이 방법으론 라이브러리의 유연성을 상당수 버리게 된다는 거고, 그러면 그 애플리케이션은 솔직히 둔하고 단조로운 게 될 수밖에 없게 된다. 이게 바로 훌륭한 크로스 플랫폼 GUI 라이브러리가 존재하지 않고, 앞으로도 존재할 수 없는 이유이다.

/r/programming 서브레딧에 올라온, Xwt라는 라이브러리를 소개하는 글에 달린 댓글, “나는 모든 플랫폼에 딱 어울리는 크로스 플랫폼 GUI 라이브러리를 본 적이 없다”고 쓴 댓글에 덧붙여서.

위에서는 크로스 플랫폼에 대해서만 언급했지만, 나는 이 문제가 GUI 일반에 대해서도 여전히 유효한 문제라고 본다. 내가 봤을 때 아직도 대부분의 GUI 애플리케이션들은 커맨드라인 인터페이스로 치면 모든 글자를 터미널 화면 기준으로 어느 좌표에 찍을지 애플리케이션이 일일이 계산해서 출력하고, 다른 프로그램은 그걸 도로 일일이 어디까지가 같은 줄이고 어디서 줄이 끊기는지 계산해서 입력으로 받는 꼴과 비슷한 수준으로 만들어진다. 상식적인 커맨드라인 프로그램은 이런 짓을 하는 대신 표준 입출력을 쓰지 않는가? ‘창과 위젯’들은 물론 픽셀보다는 훨씬 추상화된 단위임이 틀림없지만, 대다수 애플리케이션엔 너무 큰 단위일뿐더러, 애플리케이션 사이의 협업을 돕는 도구가 되기에도 적합하지 않다. 물론 어떤 프로그램들은 여전히 픽셀 수준의 도구가 필요할 것이다. 게임이 그런 것처럼. 하지만 그런 프로그램들마저도 핵심을 제외한 나머지 부분들은 충분히 일반화된 작업 흐름을 뽑아낼 부분이 있다고 본다.