오랜만에 장고..
Django에서 조건에 따라 컨텐츠를 일부 바꿔야 하는 일이 생겼다. 그리고 조건에 의해 한번 정해진 값은 애플리케이션을 이용하는 동안 유지될 필요가 있었다. (참고로 사내에서만 사용하는 프로그램이라 동작이 우선인 상황.)
고민하지 않고 쿠키에 값을 실어 처리하기로 했다. 찾아보니 HttpRequest에는 딕셔너리 타입으로 COOKIES 속성이 제공되고, HttpResponse에는 set_cookie 메서드가 제공된다.
HttpResponse.set_cookie(key, value='', max_age=None, expires=None, path='/', domain=None, secure=None, httponly=False, samesite=None)
[link: https://docs.djangoproject.com/en/2.2/ref/request-response/]
쿠키를 세팅하는 방법은 그리 어렵지 않다. 호출되는 view 함수에서 render의 반환 값을 바로 리턴하지 않고 값을 지정해주면 된다. 그리고 페이지에 처음 진입할 때에도 화면을 올바르게 렌더링 해야하기 때문에 render()를 호출하기 전에 request 객체에 쿠키 값을 지정해 주었다.
request.COOKIES['app_type'] = 'v1'
response = render(request, 'template.html', context)
response.set_cookie(key='app_type', value='v1')
return response
템플릿에선 request의 COOKIES 값을 읽어서 처리하면 된다.
{% if request.COOKIES.app_type and request.COOKIES.app == 'v1' %}
...
+ 마지막으로 나의 경우 쿠키 값을 읽어서 로그인, 로그아웃 이후의 리다이렉트를 고려해야 했는데 그냥 settings.py의 LOGIN_REDIRECT_URL에 별도의 view 함수를 정해주고, 해당 view 함수에서 쿠키 값을 읽어 분기되도록 하였다.
2019년 7월 24일 수요일
2019년 7월 17일 수요일
WPF의 DIU(Device-Independent Units)
WPF는 DIU(Device-Independent Units) 좌표 단위를 사용한다. DIU의 값은 1/96 Inch이고 WPF는 항상 1/96 Inch에 해당하는 값을 좌표 단위로 사용한다. 따라서 Width와 Height 값이 96인 WPF Rectangle은 프린터로 출력했을 때 가로 세로가 1 Inch 크기의 사각형으로 출력된다.
재미있는건 Microsoft Windows에서도 특별한 설정을 하지 않으면 기본 DPI 값은 96이라고 한다. DPI는 Dots per Inch의 약자로 1 Inch 당 점이 몇개 들어가지는지를 나타내는 단위이다. 기본 설정인 경우 WPF의 DIU 단위와 Windows의 DPI 단위가 같아서 1DIU = 1pixel 관계가 된다. 물론 Windows에서 DPI 설정을 바꿀 수 있다.
요약해 정리하면,
1. WPF는 1/96 Inch에 해당하는 값을 좌표 단위로 사용한다. 이를 장치 독립적 픽셀 값이라고 표현한다.
2. WPF의 DIU 값과 Windows의 기본 DPI 값이 같기 때문에 1 DIU는 1 pixel로 표시된다. 단, Windows의 DPI 설정이 바뀌면 1 DIU는 1보다 작거나 큰 pixel 값을 갖게 되어 화면이 번져 보이게 된다.
http://www.charlespetzold.com/blog/2005/11/250723.html
재미있는건 Microsoft Windows에서도 특별한 설정을 하지 않으면 기본 DPI 값은 96이라고 한다. DPI는 Dots per Inch의 약자로 1 Inch 당 점이 몇개 들어가지는지를 나타내는 단위이다. 기본 설정인 경우 WPF의 DIU 단위와 Windows의 DPI 단위가 같아서 1DIU = 1pixel 관계가 된다. 물론 Windows에서 DPI 설정을 바꿀 수 있다.
요약해 정리하면,
1. WPF는 1/96 Inch에 해당하는 값을 좌표 단위로 사용한다. 이를 장치 독립적 픽셀 값이라고 표현한다.
2. WPF의 DIU 값과 Windows의 기본 DPI 값이 같기 때문에 1 DIU는 1 pixel로 표시된다. 단, Windows의 DPI 설정이 바뀌면 1 DIU는 1보다 작거나 큰 pixel 값을 갖게 되어 화면이 번져 보이게 된다.
http://www.charlespetzold.com/blog/2005/11/250723.html
In WPF, you always draw in units of 96 DPI. For example, if you want to create a one-inch square Rectangle object, you make it 96 units wide and 96 units high. If the program runs on a video display set at 96 DPI, the object will be drawn 96 pixels square. In the most common case device-independent units map directly to pixels. If the program runs on a video display set at 120 DPI, the object will be drawn as 120 pixels square. That's a fairly clean 3 units-to-4 pixels mapping.
2019년 7월 14일 일요일
스트리트 패션 다큐멘터리 [PERCENTAGE%]
https://youtu.be/YFhuMiYS72E
돈주고 봐야할 수준의 다큐멘터리가 유투브에 아무론 조건 없이 공개됨.
김종선(JAYASS)님을 중심으로 하여 지난 10년의 한국 스트리트 패션 문화에 대해 다룬다.
사실 BA나 휴먼트리에 대해선 잘 모르지만 어렸을 적 이런 문화와 문화를 이끄는 인물에 대해선 막연한 동경심이 있었다.
밤 늦게 시청했음에도 한 번에 클리어.
2019년 7월 11일 목요일
대칭키 암호화, 비대칭키 암호화
암호화
1. 대칭키 암호화
→ 암호화하고 복호화 하는데 같은 키를 사용하는 방식.
대칭키 암호화 기법은 2개의 키를 사용하는 비대칭키 암호화 기법에 비해 간단한 반면 A와 B가 메시지를 주고 받기 전에 동일한 내용의 대칭키를 미리 알고 있어야 하는 문제가 있다. 이 대칭키는 쉽게 바꿀 수도 없고 사전에 공유하기 어려운 성질을 갖는다. A와 B가 대칭키 암호화 방식으로 데이터를 주고 받기 결정했다면 A 또는 B 중 한사람은 암호키를 만들어서 상대방에게 전달해야 한다. 그런데 전달 과정에서 누군가 이 암호키를 가로챈다면 그 누군가는 언제든 암호화된 메시지를 복호화 해서 내용을 확인할 수 있게 된다.
2. 비대칭키 암호화
→ 암호화하고 복호화 하는데 공개키/비밀키의 한 쌍을 사용하는 방식.
대칭키 암호화 기법에서 대칭키 교환의 문제를 해결하기 위해 고안된 기법이다. 비대칭키 암호화 기법은 공개키와 비밀키 한쌍의 암호화 키를 이용해 암복호화를 수행한다. 무슨 얘기인가 하면 공개키로 암호화된 메시지는 Pairing된 비밀키로만 복호화할 수 있고, 비밀키로 암호화된 메시지 또한 Pairing된 공개키로만 복호화할 수 있다는 말이다.
비대칭키 암호화 방식의 단점은 CPU 리소스를 대칭키 암호화 방식에 비해 많이 쓴다는 점이다. 따라서 일반적으론 비대칭키 암호화 방식을 이용해 대칭키를 서로 공유한 뒤에 이후의 암호화는 대칭키 방식을 사용한다.
3. 웹 암호화
SSL/TLS 기반의 웹 사이트에 접근하게될 때, 웹 서버는 공개키가 포함된 인증서를 사용자에게 보내주어 이 공개키를 이용해 암호화 하면 된다고 알려준다. 앞선 예와 유사한 이유로 수신한 공개키의 진위 여부를 가릴 필요가 있다.
만약 해커가 인증서와 인증서에 포함된 공개키를 조작해 전달한 것이라면 사용자의 암호화된 패킷을 자유롭게 열어볼 수 있을 것이다. SSL/TLS 기반의 통신을 지원하는 웹 서버는 웹 서버가 사용자에게 전달하는 공개키가 진짜라는 것을 보증받기 위해 신뢰할 수 있는 인증 기관 (Certificate Authority)에 공개키를 등록하게 된다.
인증서가 만들어지는 목적은 공개키의 무결성을 검증하기 위함이고, 신뢰할 수 있는 인증기관에 의해 보증된다. (*신뢰할 수 있는 인증 기관 목록은 이미 브라우저가 알고 있다.)
1. 대칭키 암호화
→ 암호화하고 복호화 하는데 같은 키를 사용하는 방식.
대칭키 암호화 기법은 2개의 키를 사용하는 비대칭키 암호화 기법에 비해 간단한 반면 A와 B가 메시지를 주고 받기 전에 동일한 내용의 대칭키를 미리 알고 있어야 하는 문제가 있다. 이 대칭키는 쉽게 바꿀 수도 없고 사전에 공유하기 어려운 성질을 갖는다. A와 B가 대칭키 암호화 방식으로 데이터를 주고 받기 결정했다면 A 또는 B 중 한사람은 암호키를 만들어서 상대방에게 전달해야 한다. 그런데 전달 과정에서 누군가 이 암호키를 가로챈다면 그 누군가는 언제든 암호화된 메시지를 복호화 해서 내용을 확인할 수 있게 된다.
2. 비대칭키 암호화
→ 암호화하고 복호화 하는데 공개키/비밀키의 한 쌍을 사용하는 방식.
대칭키 암호화 기법에서 대칭키 교환의 문제를 해결하기 위해 고안된 기법이다. 비대칭키 암호화 기법은 공개키와 비밀키 한쌍의 암호화 키를 이용해 암복호화를 수행한다. 무슨 얘기인가 하면 공개키로 암호화된 메시지는 Pairing된 비밀키로만 복호화할 수 있고, 비밀키로 암호화된 메시지 또한 Pairing된 공개키로만 복호화할 수 있다는 말이다.
비대칭키 암호화 방식의 단점은 CPU 리소스를 대칭키 암호화 방식에 비해 많이 쓴다는 점이다. 따라서 일반적으론 비대칭키 암호화 방식을 이용해 대칭키를 서로 공유한 뒤에 이후의 암호화는 대칭키 방식을 사용한다.
3. 웹 암호화
SSL/TLS 기반의 웹 사이트에 접근하게될 때, 웹 서버는 공개키가 포함된 인증서를 사용자에게 보내주어 이 공개키를 이용해 암호화 하면 된다고 알려준다. 앞선 예와 유사한 이유로 수신한 공개키의 진위 여부를 가릴 필요가 있다.
만약 해커가 인증서와 인증서에 포함된 공개키를 조작해 전달한 것이라면 사용자의 암호화된 패킷을 자유롭게 열어볼 수 있을 것이다. SSL/TLS 기반의 통신을 지원하는 웹 서버는 웹 서버가 사용자에게 전달하는 공개키가 진짜라는 것을 보증받기 위해 신뢰할 수 있는 인증 기관 (Certificate Authority)에 공개키를 등록하게 된다.
인증서가 만들어지는 목적은 공개키의 무결성을 검증하기 위함이고, 신뢰할 수 있는 인증기관에 의해 보증된다. (*신뢰할 수 있는 인증 기관 목록은 이미 브라우저가 알고 있다.)
2019년 7월 8일 월요일
[SQL] WITH (NOLOCK)
http://www.sqler.com/bColumn/870643
SQL Server에서 잠금(LOCK)은 지극히(?) 정상적인 동작이다. 특정 데이터 영역에 INSERT나 UPDATE 작업이 일어나면 해당 영역엔 LOCK이 걸리게 된다. 데이터의 일관성을 유지하기 위한 것으로 동시에 이 영역을 참조하는 SELECT 작업은 LOCK이 해제될 때까지 대기해야 한다.
문제는 사용자 입장에서 불필요하다고 느낄 때가 있다는 것인데, 정말 단순한 데이터라 일관성은 뒤로하고 그저 빠르게 읽어오고 싶은 경우가 있기 때문이다.
이럴 때 잠금 힌트 중 NOLOCK을 사용한다. NOLOCK 힌트는 커밋되지 않은 트랜잭션이나 읽는 중 롤백된 데이터에 대한 조회를 가능하게 한다. 즉, 커밋되지 않은 읽기가 가능하므로 LOCK이 걸려있어도 대기하지 않고 데이터를 가져올 수 있다. (READUNCOMMITTED) 단, 다시 언급하지만 데이터의 일관성이 보장되진 않으므로 데이터 성격을 감안해서 써야 한다.
사용 방법은 FROM 절 뒤에 WITH (NOLOCK)을 붙여주면 된다.
ex) SELECT * FROM EMPLOYEE WITH (NOLOCK)
SQL Server에서 잠금(LOCK)은 지극히(?) 정상적인 동작이다. 특정 데이터 영역에 INSERT나 UPDATE 작업이 일어나면 해당 영역엔 LOCK이 걸리게 된다. 데이터의 일관성을 유지하기 위한 것으로 동시에 이 영역을 참조하는 SELECT 작업은 LOCK이 해제될 때까지 대기해야 한다.
문제는 사용자 입장에서 불필요하다고 느낄 때가 있다는 것인데, 정말 단순한 데이터라 일관성은 뒤로하고 그저 빠르게 읽어오고 싶은 경우가 있기 때문이다.
이럴 때 잠금 힌트 중 NOLOCK을 사용한다. NOLOCK 힌트는 커밋되지 않은 트랜잭션이나 읽는 중 롤백된 데이터에 대한 조회를 가능하게 한다. 즉, 커밋되지 않은 읽기가 가능하므로 LOCK이 걸려있어도 대기하지 않고 데이터를 가져올 수 있다. (READUNCOMMITTED) 단, 다시 언급하지만 데이터의 일관성이 보장되진 않으므로 데이터 성격을 감안해서 써야 한다.
사용 방법은 FROM 절 뒤에 WITH (NOLOCK)을 붙여주면 된다.
ex) SELECT * FROM EMPLOYEE WITH (NOLOCK)
Apache Commons DBCP 설정
https://commons.apache.org/proper/commons-dbcp/configuration.html
# 초기엔 initialSize, maxIdle, minIdle 값을 maxTotal 대비 낮은 값을 지정해 적정 커넥션 수치를 모니터링한 뒤 값을 Fix하는 것이 권장된다.
- MS-SQL : select 1
- MySQL : select 1
- initialSize (default: 0) : BasicDataSource 클래스 생성 후 최초로 getConnection()을 호출할 때 커넥션 풀에 채워지는 커넥션 개수
- maxTotal (default: 8) : 동시에 사용할 수 있는 최대 커넥션 개수
- maxIdle (default: 8) : 커넥션 풀에 반납할 때 유지될 수 있는 커넥션 개수
- minIdle (default: 0) : 최소한으로 유지할 커넥션 개수
# 초기엔 initialSize, maxIdle, minIdle 값을 maxTotal 대비 낮은 값을 지정해 적정 커넥션 수치를 모니터링한 뒤 값을 Fix하는 것이 권장된다.
- maxWaitMills : 커넥션 풀 안의 커넥션이 고갈됐을 때 커넥션 반납을 대기하는 시간. 단위는 밀리초. 이 값이 너무 짧으면 불필요한 오류가 생기고 너무 크면 사용자가 과도하게 대기하는 증상이 발생해 좋지 않다. (10초(10000ms) 권장)
- validationQuery : 커넥션 풀에서 연결의 유효성을 검사하는데 사용할 SQL 쿼리를 지정한다. 형식은 적어도 하나의 행을 반환하는 SQL SELECT 문이어야 한다.
- MS-SQL : select 1
- MySQL : select 1
- testOnBorrow (default: true) : 커넥션 풀에서 커넥션을 얻어올 때 테스트 실행
- testOnReturn (default: false) : 커넥션 풀로 커넥션을 반환할 때 테스트 실행
- testWhileIdle (default: false) : 유휴 객체 제거기(object evictor)에 의한 유효성 검증을 할 것인가에 대한 설정. validate에 실패하면 커넥션이 풀에서 삭제된다. testOnBorrow는 getConnection()을 호출할 때마다 테스트를 한다면 이 설정은 특정 주기로 여러 개의 커넥션을 모아서 테스트한다. (by object evictor thread.)
- timeBetweenEvictionRunsMillis (default: -1) : object evictor 쓰레드 실행 간격. object evictor를 활성화 시키려면 양수 값을 갖어야 한다. Tomcat DBCP는 이 값을 5초 정도로 해도 괜찮지만 Commons DBCP에선 성능 저하의 위험이 있다. Commons DBCP에선 기본 설정이 아예 false인 것으로 봐도 짧은 시간을 지정하는건 무리가 있는듯. (30초 ~ 60초 권장)
- numTestsPerEvictionRun (default: 3) : object evictor 쓰레드가 실행할 때마다 검사할 커넥션 개수. 검사 시간 동안 커넥션 풀에 락이 걸린다고 한다. 기본값 권장.
- minEvictableIdleTimeMillis (default: 1000 * 60 * 30, 30분.) : 커넥션이 축출 대상이 되기 전에 커넥션 객체가 풀에서 유휴 상태로 있을 수 있는 최소 시간.
- removeAbandoned (default: false) : 오랫동안 열려만 있고 close() 메서드가 호출되지 않는 커넥션을 임의로 닫는 기능을 설정. (removeAbandonedOnBorrow / removeAbandonedOnMaintenance)
2019년 7월 3일 수요일
Conquer and divide
In XP, We don't divide and conquer. We conquer and divide. First we make something that works, then we bust that up and and solve the little parts.
- Kent Beck.
애자일이나 TDD에 대한 가장 흔한 오해 중 하나는 그 방식들이 divide and conquer를 장려한다는 생각이다.
...
고객에게 가치를 전달하는 측면을 보자면 divide and conquer는 제대로 가치를 주지 못할 수 있습니다. 왜냐하면 experience를 주기보다 feature를 주기 때문입니다.
...
- 김창준님 페이스북
- Kent Beck.
애자일이나 TDD에 대한 가장 흔한 오해 중 하나는 그 방식들이 divide and conquer를 장려한다는 생각이다.
...
고객에게 가치를 전달하는 측면을 보자면 divide and conquer는 제대로 가치를 주지 못할 수 있습니다. 왜냐하면 experience를 주기보다 feature를 주기 때문입니다.
...
- 김창준님 페이스북
피드 구독하기:
덧글 (Atom)