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

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?

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

2015-09-20

confirm password 필드는 더 이상 필요 없는가

 비밀번호는 보안상의 문제로 ""으로 표시되기 때문에 오타를 냈어도 확인할 수 없고 잘못 입력하면 앞으로 로그인할 수도 수정할 수도 없어 계정을 그대로 버리는 문제를 발생시킨다. 따라서 비밀번호의 오타는 다른 정보들과는 다르게 큰 문제가 된다.
 그래서 일반적으로 회원가입을 할 때, 비밀번호를 두 번 입력하도록 한다. 하지만 이런 방식이 UX를 크게 저하한다면서 다른 방식을 사용해야 한다고 주장하는 글이 있었다. 이 글에서는 비밀번호를 두 번 입력하는 대신 입력한 비밀번호를 읽을 수 있게 보여주는 토글 버튼이 있어야 한다고 주장한다.

 언뜻 들으면 그럴싸해 보이지만 결론부터 말하면 절대 좋은 방식이 아니다. 최소한 웹 환경에서는 절대 해서는 안 되는 방식이다. 비밀번호를 보여줄 수 있게 만드는 방법은 다음과 같은 문제가 몇 가지 있다.

 우선 브라우저에서 지원하지 않는다. 현재의 웹 스펙에 password input을 보여주는 방법은 없다. 따라서 text input을 이용해야 한다. 문제는 브라우저, 최소한 제대로 된 브라우저(심지어 I.E조차도)는 text input과 password input을 완전히 별도로 처리한다는 것이다. 이 둘의 차이는 단순히 내용이 눈에 보이는가 아니면 ""으로 보이는가의 차이가 아니다.
 일단 당장 눈앞의 문제로 text input은 password input과 다르게 브라우저가 캐싱하고 자동 완성 한다는 것이나, 브라우저의 비밀번호 저장 기능을 생각해볼 수 있다. 캐시와 관련한 것은 autocomplete를 이용해서 조정할 수 있지만, 비밀번호 저장 기능은 password input만을 저장하기 때문에, text input을 이용한 상태에서는 어떻게 할 방법이 없다.
 사실 비밀번호 저장기능이 중요한 기능이 아니기는 하다. 하지만 이 기능은 포기한다고 해도 여전히 브라우저가 password input과 text input 전혀 별개의 것으로 처리한다는 것은 문제다. 브라우저 개발자들은 비밀번호를 password input을 이용할 것을 기대하지 text input을 사용할 것으로 생각하지 않는다. 최소한 HTML 6가 나와 스펙이 변하거나, 많은 사람이 text input을 이용해서 비밀번호를 저장할 때까지는 그럴 것이다.

 게다가 비밀번호를 눈으로 확인하게 하는 시스템은 기존의 방식보다 시간이 오래 걸린다. 단순히 절차상으로 걸리는 시간이 길어지는 것뿐 아니라, 내 비밀번호와 화면에 출력되는 시간이 길어진다.
 이 시간은 보안에도 큰 문제가 된다. 내가 눈으로 내 비밀번호를 확인할 수 있다는 것은 내 등 뒤의 사람도 그 비밀번호를 볼 수 있다는 것이다. 설령 시스템이 아무리 안전하게 구성되어 있다고 해도 정작 다른 경로로 비밀번호가 노출될 가능성이 있다면, 이 시스템은 안전하지 않은 시스템이다. 즉, 비밀번호를 눈으로 보고 확인하게 하는 방식은 보안적으로 안전하지 않은 방식이다.

 그다음 문제는 강력한 비밀번호일수록 사람의 눈으로 읽고 확인하는 것이 좋은 확인 수단이 아니라는 것이다. 짧고 간단한 비밀번호라면 금방 확인할 수 있다. 하지만 특수기호와 영대소문자를 섞어가면서 20글자의 비밀번호를 만들었다면? 그 비밀번호를 눈으로 보고 자신이 의도한 대로 친 것이라고 확신할 수 있을까?
 기존의 비밀번호를 확인하는 방식으로 잘못된 비밀번호를 확인 못 하는 경우도 있다. Caps lock 키가 눌려서 대소문자가 바뀌어서 입력된 경우는 기존의 방식으로 잘못된 비밀번호를 확인할 수 없다. 하지만 이는 caps lock 키가 눌렸는지를 확인해서 해결해야 할 문제이지 위와 같은 문제를 감수하고 비밀번호를 보여주는 옵션을 추가해서 해결할 문제는 아니다.

 즉, 비밀번호를 보여주는 방식은 기존의 방식에 비해서 제대로 된 비밀번호를 적었을 것을 보장하지도 않고, 안전하지도 않고, 플랫폼에서 지원하지도 않는다. 물론 이것은 웹에서의 이야기이고 위의 문제가 발생하지 않는 환경이라면 딱히 상관없다. 예를 들면, 데스크탑 OS나 서버 프로그램의 설치 화면이라면 그래도 상관없다고 생각한다. 하지만 이것은 오히려 특수한 경우이고 일반적으로 특히나 웹 환경에서 쓸만한 이야기는 아니라고 생각한다.

 하지만 비밀번호를 두 번 타이핑하는 것이 사용자에게 안 좋은 UX를 제공할 수 있다는 의견에는 동의한다. 그렇지만 이를 해결하는 방법이 비밀번호를 보여주는 것은 아니다. 최소한 웹에서 쓸만한 방법은 아니다.
 게다가 사실 비밀번호를 다시 타이핑하지 않고 가입하는 좋은 방법은 이미 나와있다. 이미 github이나 facebook이나 twitter 등에서 사용하고 있다. 가입 시 이메일을 받고 이메일을 통해서 인증받도록 하는 것이다. 이렇게 가입을 받으면 비밀번호를 잘못 입력했더라도 이메일을 통해 바꾸도록 하면 되니 문제 없고, 이메일을 잘못 입력하였더라도 일정 기간 내로 인증을 받지 않은 회원가입은 무효화 하면 되니 잘못 타이핑할 걱정을 하지 않아도 된다.