2일
- jank - 화면이 랜더링 되거나 Animate 될때 짧게 짧게 일시 정지 되듯 하는 것. 한국에서는 ‘랙’ 이라고 부르는 것과 유사하다. janky 하다. 처럼 쓸수 있다.
6일
firewall-cmd
http service를 허용하려면 다음과 같이 한다. sudo firewall-cmd –add-service=http
14일
link 정리
- [Unity] Procedural Object Placement (E01: poisson disc sampling)
- What’s new in JavaScript (Google I/O ’19)
- From Shore to Horizon: Creating a Practical Tessellation Based Solution
- 헬로 월드 - 머신 러닝 비법 #1
- Supercharged Live Live Live! (Polymer Summit 2017)
- Deep Learning: A Crash Course
- The New Bar for Web Experiences (Chrome Dev Summit 2017)
- 소형 컨테이너 생성하기(쿠버네티스 베스트 프랙티스)
- What’s New in ARCore (Google I/O’19)
- WordPress + PWAs = 💖 (Chrome Dev Summit 2017)
- Next-generation web styling (Chrome Dev Summit 2019)
- Practical Istio
- Introduction to Service Management with Istio Service Mesh (Cloud Next ‘18)
- Istio: Up and Running: Using a Service Mesh to Connect, Secure, Control, and Observe
- Debugging Istio: How to Fix a Broken Service Mesh (Cloud Next ‘19)
- Service Meshes
- Canary Deployments With Istio and Kubernetes Using Spinnaker (Cloud Next ‘19)
16일
KV Store의 대한 짧은 생각
KV 에서 각 KV 간의 관계를 나타내는데는 몇가지 문제점이 있다.(애시당초 KV 쓰면서 한 KV 가 Atomic 하게 만드는게 가장 좋지만 종종 그러기 힘든경우가 있다.)
특히 1:n 관계에서는 Indexing(Listing), Dangliing, Duplicate가 연관되는 문제가 있다.
Object A, B가 1:N관계라고 하면, 1:n 을 표현하는데는 다음과 같은방법이 있다.
- A의 필드에 B의 Key의 List 를 저장한다.
- A가 가진 B를 쉽게 표현 할수 있다.
- B가 속한 A는 확인하기 힘들다.
- 대신 B에 대한 연산을 하다보면 B가 Duplication/Dangliing 될수 있다.(Transtion이 없다면..)
- B의 필드에 A의 Key를 저장한다.
- A가 가진 B는 조회 하기 어렵다.
- Object내의 Field 에 대한 index 가 없기 때문.
- B가 속한 A는 확인 하기 쉽다.
- A가 가진 B를 조회 하기 위해서는 별도의 Index 를 별도의 KV 로 정의 해야 한다.
- 대부분의 경우 설계하기 귀찮고, Index KV 에 대한 일관성을 지킬 방법을 별도로 생각해야 한다.
- 다 직접 구현 한다고 해도 그냥 RDB 쓰는게 이득인 상황이 된다.
- A가 가진 B는 조회 하기 어렵다.
Cloud Next ‘19
- https://www.youtube.com/watch?v=W16iHlo2TuE&list=PLIivdWyY5sqIXvUGVrFuZibCUdKVzEoUw&index=2
- jenkins 에서 GCE로 옯기기
- 돌림판 돌려서 문제 시뮬레이션
20일
- APIs, Microservices, and the Service Mesh (Cloud Next ‘19)
- The Two Types of Random | Game Maker’s Toolkit
- Istio Gateway: getting traffic into your cluster
28일
sql 관련 단편적인 지식
- prepared statement는 SQL Driver 단의 구현이다.
- DB에서 SQL 구문 분석을 해서 execute plan을 작성 하는데, perepared statement가 있어야지만 해당 구문을 매번 분석하지 않고, cache 해둘수 있기 떄문이다.
- ‘OR’은 성능에 치명적일수 있다. in 을 쓰는 편이 좋다.
- prepared statement에서 변수(‘?’)의 갯수는 가변적이 될수 없다.