Managing Deployments Using Kubernetes Engine 퀘스트 정리 Quest Outline을 따라서 Managing Deployments Using Kubernetes Engine에 접속하면, 좌측 상단에 Start Lab버튼을 볼 수 있다. 좌측 상단에 위와 같은 Start Lab 버튼과, 1시간으로 설정된 타이머를 볼 수 있다. Start Lab 버튼을 누르면 타이머가 동작하기 시작하며 Google Cloud Console에 접속할 수 있는 계정정보가 표시된다.(Username, Password로 구글 계정에 접속하면 된다.) 타이머가 0이 되거나 혹은 End Lab버튼을 누르게 되면 더 이상 Google Cloud Console에 해당 계정으로 접속할 수 없으니, 주의하도..

RFC2617의 Digest 인증방식은 obsolates되고 RFC7616이 나오기는 했지만, 요즘에는 Digest인증을 사용하기보다는 폼 베이스 인증방식을 쓰기도 하고, 브라우저에서 RFC7616의 Digest 인증방식을 지원하지 않아서 nginx-http-auth-digest모듈에 RFC7616방식을 구현한 브랜치가 없지 않나 싶다. 아무튼 현재로써는 구현이 필요한 상황이다. 시간나면 구현해봐야겠다. RFC2617 문서는 HTTP Authentication: Basic and Digest Access Authentication에서, RFC7616 문서는 HTTP Digest Access Authentication에서 확인이 가능하다. RFC2617기준의 Digest 인증방식에 대해 간단하게 설명하자면..

예전에 아톰을 사용할 때, Activate Powermode라는 플러그인을 재밌게 사용한 적이 있었다. 한동안 재밌게 사용하고 있었는데, 아무래도 타이핑을 할 때마다 애니메이션 처리를 하다 보니 성능상의 문제가 발생했다. 단순히 Activate Powermode뿐만 아니라, 플러그인을 하나 둘 추가하다 보니 느려진 감이 있었다. 그러다가 Visual Studio Code를 사용하게 됐는데, 아톰보다 가벼워서 상당히 좋기는 했지만 Activate Powermode가 제대로 동작하지 않았다. 결국 눈물을 머금고 포기한 Activate Powermode는 몇 년동안 잊게 됐다... 가 어제 갑자기 생각나서 Market place에 검색해보니 Powermode라는 이름으로 등록되어있었다. ^ ㅈ^(쑻) Make..

폼 베이스 인증에 다이제스트 인증을 적용하기 #1 에서 싱겁게 끝내긴 하지만, 팀장님을 회유하는데 완벽하게 실패해버린 나는 다이제스트 인증을 따로 구현하는 수밖에 없었다. 야! 회사다닐 맛 난다! ^ ㅈ^)(쑻) 일단 가능한지부터 검토하기위해 Basic Authentication을 구현해봤다. 일단 HTTP Authentication, MDN web docs를 참조하여 Basic Authentication에 대한 내용을 파악하도록 하자. 크게 어렵지 않다. 일단 서버에서 인증정보 없이 접근을 시도하는 상대에게 401 에러와 함께, 헤더에 WWW-Authenticate값을 Basic Realm="[Realm]"와 같이 전달하여 Basic Authentication을 사용하고 있음을 알려준다. 401 응답을..

이상하게 요즘 삽질을 계속해서 하는 느낌이다. 이번에는 구글의 정책으로 인해 64bits를 지원하도록 NDK 라이브러리를 수정하는 과정에서, Colorspace Conversion의 문제로 삽질을 하게 됐다. 일단 현재 GPU를 사용하지 않고 Colorspace Conversion을 처리하기때문에 성능상에 문제가 있기는 하지만, 어느정도 안정적으로 처리하는 것 까지만 확인하고 삽질기를 작성하기로 했다. 2019년 8월 1일부터 64bits를 지원하지 않는 앱은, 구글 플레이에 업데이트 할 수 없다. NDK를 사용하지 않는다면 상관이 없겠지만, 영상 스트리밍과 관련된 기능을 사용하고 있었기 때문에 필요한 라이브러리를 ARM64-v8a 칩셋에 맞게끔 다시 빌드할 필요가 있었다. 대표적인 예가 바로 FFmpe..

프로그램을 작성하다보면 여러개의 작업을 병렬로 처리해야 할 경우가 있다. 네트워크를 통해 영상 데이터를 전송받아서, 디코딩한 후 재생하는 경우가 대표적이다. 아무튼 이번에는 BlockingQueue를 사용한 코드를 수정하다가, 몹시 곤혹스러운 상황을 맞딱드리게되서 기록을 남기려고 한다. Thread.wait()이나 Thread.sleep()을 호출하지 않는데도 Thread의 상태가 WAIT으로 변경되고, notify()나 notifyAll(), Thread.start()를 호출하지 않아도 Thread의 상태가 RUNNING으로 변경된다. 내가 작성한 코드라면 금방 단서를 찾을 수 있거나 혹은 이런 경험이 있다면 원인을 찾기 좀 쉬울 것 같은데, 심지어 Thread의 상태를 검색해보면 위에서 언급한 메서드..