흔한 개발자 이야기

PHP Best Practices를 읽다가 내친 김에 번역을 했는데, 이걸로 모던PUG에서 "UTF-8 in PHP"라는 주제로 발표까지 하게 되었다. 별 내용은 아니라서 발표할 것까지는 없다고 생각했는데, 발표 준비를 한 덕분에 PHP의 UTF-8 지원에 대해서 정리해볼 수 있었다.

PHP7에서 기본 문자열이 유니코드(UTF-8)로 되는 것으로 알고 있었기때문에 곧 필요없어질 내용이라고 생각했는데, 조사하다보니 PHP7에서도 유니코드 지원 상황은 변함이 없는 것으로 확인되었다. RFC에 UString 클래스 제안이 있던 정도였지만, 이마저도 통과되지 않았다.

가장 흥미로웠던 것은 MySQL의 "utf8mb4" 인코딩이었다. UTF-8에서 4바이트를 사용하는 문자가 있다는 것은 어렴풋이 알고 있었지만, 보통 사용하는 "utf8" 인코딩은 4바이트 문자를 저장하지 못한다는 사실은 모르고 있었다. 이것 때문에 UTF-8의 "Plane"이라는 것에 대해서도 알아보게 되었다.

별 내용은 없지만, 아래는 발표때 사용한 슬라이드이다.

뭐라고 불러야할지 잘 모르겠지만, 옛날에 책을 읽다가 'A라면 XX페이지로, B라면 OO페이지로'라는 문구가 나오면 원하는 선택지를 골라서 페이지를 넘겨보던 책이 있었다. 말하자면 비주얼 노블 게임의 원조라고 할만한데, 이 책도 그런 형식으로 만들어졌다.

이 책을 읽다보면 페이지를 선택해야할 시점이 오는데, 잘못된 선택을 하게되면 불행한 결말을 맺게 된다. 책을 읽으면서 애자일 컨설턴트로서 "드림팀"이 살아남을 수 있도록 올바른 선택을 해서 도와야한다. 그러면서 자연스럽게 애자일을 팀에 정착시키는 방법을 마치 옆에서 지켜보듯이 엿볼 수 있다.

책을 읽고나서 일을 진행하는 것도 역시 사람이기 때문에 일을 하기 위해서는 동기를 부여하고, 신뢰를 얻는 일이 무척 중요하다는 생각이 들었다.

---

드림팀의 악몽 애자일로 뒤엎기

저자

포샤 텅 지음

출판사

한빛미디어 | 2014-05-20 출간

카테고리

컴퓨터/IT

책소개

매 순간 두 가지의 갈림길, 서로 다른 여덟 가지 결과, 당신의...

---

어쩌다보니 코딩 호러의 이펙티브 프로그래밍을 읽고나서 바로 이 책도 읽어야겠다고 생각한지 1년 이상 지나서야 읽게 되었다. 이 책 역시 블로그를 책으로 만든 것이라서 링크들이 많이 있는데, 책 소개 페이지의 관련 자료 항목에 잘 정리되어있어서 찾아보기 편하게 해 놓았다.

이 책 역시 재미있고 유용한 정보들이 많이 있었다. 몇가지만 여기에 적어본다.

... 나는 아이폰에 있는 버튼이 나로 하여금 너무나 자주 생각하게 만들기 때문에 아예 사용하지 않는 단계에 이르렀다. 하나밖에 없는 그 버튼이 너무나 자주 오용된 것이다.

"단 한개의 버튼이라는 신화" 중에서(p.140)

... 하지만 사용자들은 뭔가를 입력하기 전에 아무것도 읽으려고 하지 않는다. 심지어 우리와 같은 소위 전문적인 컴퓨터 사용자들조차 말이다.

"그렇지만 그저 하나만 더 있을 뿐이다." 중에서(p.161)

---

코딩 호러가 들려주는 진짜 소프트웨어 개발 이야기

저자

제프 앳우드 지음

출판사

위키북스 | 2013-11-28 출간

카테고리

컴퓨터/IT

책소개

코딩 호러 블로그 운영자이자 스택 오버플로우의 공동 창업자가 들...

---

Windows 7에서 네트워크 드라이브가 표시되지 않을때 대체방법을 포스팅한 적이 있는데, Windows 8에서 동일한 문제가 발생했지만, 이 방법으로도 해결되지 않는 사례가 있었다. 이번에는 아래와 같이 다른 방법으로 해결했다.

1. 제어판을 열어서, 관리도구를 열고, 로컬 보안 정책을 실행한다.
2. 좌측의 트리에서 로컬 정책 - 보안 옵션을 선택한다.
3. 우측 목록에서 "네트워크 보안: LAN Manager 인증 수준"을 클릭하고 나오는 팝업에서 "LM 및 NTLM 응답 보내기"를 골라서 설정한다.
4. 우측 목록에서 "네트워크 보안: NTLM SSP기반(보안 RPC 포함) 서버에 대한 최소 세션 보안"을 클릭하여 나오는 팝업에서 "128비트 암호화 필요"를 체크 해제한다.
5. Windows 리부팅
   

참고 : http://www.eightforums.com/network-sharing/18056-w2k3-server-can-access-w8-w8-computer-cant-see-w2k-server.html

월의 몇 주차를 어떻게 계산해야할지 찾아보았지만, 마땅한 표준은 존재하지 않았다. 하지만, 해당 년도의 첫 주 계산은 ISO 8601 표준에 정해져있다는 것을 알게되었다. ISO 8601 표준의 위키피디아 해당 항목을 보면 매 해의 첫주의 정의는 아래와 같이 설명될 수 있다고 한다,

• the week with the year's first Thursday in it (the formal ISO definition),
• the week with 4 January in it,
• the first week with the majority (four or more) of its days in the starting year, and
• the week starting with the Monday in the period 29 December – 4 January.
  

가장 간단한 설명은 1월 4일이 포함된 주가 첫주라고 보면 된다는 것이다. 년에 관한 것만 나와있어서 그다지 도움은 안됐지만, 한가지 또 알게 된 사실은 ISO 8601 표준에서 "주"는 월요일에서 시작해서 일요일로 끝나는 것으로 본다.

하지만, 달력에는 주로 일요일이 시작인 것처럼 나와있는 경우가 많아서 한주의 시작요일을 변경할 수 있도록 해서 한번 만들어봤다.

MySQL의 Replication에서 쿼리에 문제가 생겨서 중지되는 경우가 가끔 있다. 그때마다 재시작하는 방법이 생각나지 않으면 찾아보는게 귀찮아서 여기에 간단히 정리해둔다.

mysql> SHOW SLAVE STATUS \G
(문제된 쿼리 확인)
mysql> STOP SLAVE;
(문제된 쿼리 처리)
mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
mysql> START SLAVE;

참고 : https://www.howtoforge.com/how-to-repair-mysql-replication

fstab 파일의 가장 위에 보면 보통 아래와 같은 설명이 달려있다.

# <file system> <mount point>   <type>  <options>       <dump>  <pass>

앞의 네 항목은 딱 보면 알만한 내용들이라 그렇게 어렵지 않다.

1. file system : 마운트 할 파일 시스템 (/dev/sda, UUID=BLAHBLAH..., proc 등)
   
2. mount point : 마운트할 경로 (/, /mnt/usb 등)
3. type : 마운트할 파일 시스템의 타입  (ext4, ntfs 등)
4. options : 마운트할 때 줄 옵션 (rw, ro, noexec 등)

문제는 마지막 두 항목은 dump나 pass라는 이름만 보고는 어떤 역할을 하는지 알기 힘들다는 것이다. 이미 설정되어있는 값을 보아도 0이나 1같은 숫자 뿐이다. 이런걸 알아보려면 역시 Manpage가 우선이다. Manpage를 보면 마지막 두 항목은 다음과 같이 설명되어 있다.

The fifth field (fs_freq).
This field is used for these filesystems by the dump(8) command to  determine which filesystems need to be dumped.  If the fifth field is not present, a value of zero is returned and dump will assume that the filesystem does not need to be dumped.

The sixth field (fs_passno).
This field is used by the fsck(8) program to determine the order in which filesystem checks are done at reboot  time. The root filesystem  should be specified with a fs_passno of 1, and other filesystems should have a fs_passno of 2.  Filesystems within a drive will be checked sequentially, but filesystems on different drives will be checked at the same time to utilize  parallelism available in the hardware.  If the sixth field is not present or zero, a value of zero is returned and fsck will assume that  the filesystem does not need to be checked.

다시 말하자면, dump라고 되어있는 다섯번째 항목은 해당 파일 시스템이 dump가 필요한지 여부를 설정하는 것이고, 마지막 여섯번째 항목은 리부팅시에 파일시스템을 검사할지 여부를 설정하는 것이다. 파일 시스템을 dump해야한다면 다섯번째 항목을 1로, 아니면 0으로 하면 되고, 파일 시스템을 리부팅 시에 검사하려면 여섯번째 항목을 1보다 큰 값으로, 필요없으면 0으로 하면 된다. 검사는 1부터 순서대로 한다.

운영하는 서버에 /tmp 디렉토리 용량이 필요해져서 추가 디스크를 붙여서 마운트해서 사용할 필요가 생겼다. 아무래도 임시 파일을 저장하는 곳이니, 루트 파일 시스템으로 사용하고 있는 ext4보다 적당한 것이 있지 않을까 싶어서 검색을 좀 해보았다. 하지만, 그런 건 없었다.

램 디스크를 사용하는 "tmpfs"가 있기는 한데, 이건 용량이 제한되기 때문에 내가 사용하려는 용도와는 맞지 않아 사용할 수 없었다.

그냥 ext4를 사용하되, 마운트 옵션으로 다음 옵션들을 사용하면 좋다고 한다.

barrier=0,noatime

"barrier=0" 은 몇몇 경우에 파일 쓰기 성능을 향상시켜 준다고 하고, "noatime"은 파일 접근 시간을 업데이트하는 것을 막아서 파일 입출력 속도를 높일 수 있다.

참고 : http://askubuntu.com/questions/1637/good-filesystem-for-tmp

# vi /etc/passwd

(앞의 vi는 다른 에디터를 쓸 수도 있지만) passwd 파일을 편집하기 위해서는 항상 위와 같이 했었다. 그런데, 저 역할을 하는 간단한 명령어가 있었다.

# vipw

이런 간단한 작업을 위해서 일부러 명령어를 따로 익힐 필요는 없겠지만, 너무 간단해서 이미 알게된걸 일부러 안 쓸 필요도 없으니, 필요할때 사용해야겠다.

PHP에서 논란이 많은 것 중에 하나가 Exception 이외에 핸들링하기 어려운 Error가 또 있다는 것이다. 작은 규모의 웹 애플리케이션에서는 별 문제가 되지않고, 오히려 장점도 있을 수 있겠지만, 규모가 조금 큰 웹 애플리케이션에서는 문제가 될 수 있고, 특히 서버 콘솔 프로그램을 만들었다면 치명적일 수 있는 문제이다.

물론 Error도 set_error_handler()를 사용해서 핸들링할 수 있다고는 하지만, Exception 처리와는 별개로 처리하다보면 코드 흐름이 엉망이 되기가 쉽기도 하고 해서 Exception으로 변환해서 처리를 하는게 낫다고 생각이 들때가 있는데, 그럴때는 아래와 같은 코드를 사용하면 된다.

set_error_handler(function ($errno, $errstr, $errfile, $errline) {

    throw new ErrorException($errstr, $errno, $errno, $errfile, $errline);

});

참고 : http://www.sitepoint.com/forums/showthread.php?632913-Converting-native-PHP-errors-to-Exceptions