1/13

점심을 먹으며 동료들과 주말에 읽었던 책 '데이터 중심 애플리케이션 설계'에 대해 이야기를 나눴다. 첫인상과 달리, 난이도가 그렇게 높지 않은 것 같다는 것과(yey!), 과거와는 달리 요즘 웹 애플리케이션의 대다수가 계산 중심이 아니라 데이터 중심이라는 것에 대해.

내가 다니는 회사는 엄청나게 많은 데이터를 보여주고 분석하고 수집한다. 이런 회사에서는 인프라 엔지니어나 데이터 사이언티스트처럼 특수한 직군이 아니라 나처럼 프론트엔드를 자주 다루는 웹 개발자라고 해도 데이터를 어떻게 보여줄지, 읽어올지, 어떤 간격으로 업데이트를 할지와 같은 고민을 해야 한다.

데이터를 다루고 만지는 일이 점점 재밌어 진다. 사업팀에서 요청한 데이터를 뽑아내려고 꽤나 많은 시간을 쿼리를 고민하는 데 사용했다.

1/14

오전에 QA 시트를 받았는데, 이럴수가. 버그가 너.무.많.았.다. 그런데 하나하나 고쳐나갈 수 있어 다행이었다. 진도가 쫙쫙 나가는 이 느낌, 너무 좋다. 설계할 때와는 다른 이 기분...

기획자분이 '버그가 하나도 없는 게 더 무서운 일이지요. QA의 목적은 버그가 없는 완벽한 상태를 만드는 게 아니라고 했습니다!'라고 해주셨다.

1/15

오전 내내 좀 더 나은 UX를 고민하면서 이런저런 스타일링을 손보았다.

오후에는 새롭게 등장한 버그를 손봤다. 처음 버그를 알게 되었을 때는 굉장히 막막했는데, 조금 고민해보니 상태를 초기화해야 하는 부분을 놓쳤다는 것을 깨달았다. 다른 기능에 사이드이펙트가 발생한 것이었는데, QA가 없었다면 발견하지 못했을 것 같다. 기획자분이 짚어주셔서 감사했다.

1/16

배열의 중복을 제거할 때는 역시 set 객체. 데이터 뽑아달라는 요청이 있어 드렸는데 중복 제거 해달라기에 어떻게 할까 고민했는데 set으로 간단하게 해결했다. IE 지원이 안되는 메서드가 있으니 주의하기!

const set1 = new Set([1, 1, 2, 3, 4, 7, 7])
console.log(set1.has(1)) // true
console.log(set1.has(6)) // true
console.log(set1.add(8)) // 새로운 요소 추가하기
console.log(set1.size) // 5

새로 컬럼을 만들면서, 기존에 존재하는 데이터를 해당 컬럼으로 UPDATE 해야 하는 일이 생겼다. 컬럼의 VARCHAR 길이를 몇으로 설정해야 할지 찾아보고 싶어 MySQL에서 문자열 길이를 확인할 수 있는 함수를 찾아봤다. LENGTH와 CHAR_LENGTH이다. LENGTH는 문자의 byte 길이를 가져오기 때문에, 한글을 사용하는 경우에는 정확하게 길이를 알 수 없다. 이때, byte 수가 아니라 문자가 몇 개인지를 가져오려고 하면 CHAR_LENGTH를 사용하면 된다.

1/17

1 구글이 크롬 브라우저에서 user-agent(UA) string을 점진적으로 폐기할 예정이라는 기사가 갑자기 등장했다. user agent에는 사용자 운영체제, 브라우저 등의 정보를 담고 있는데, 굉장히 많은 회사들에서 해당 정보를 필수적으로 읽어 웹 서비스를 제공하고 정보를 수집하고 있을 것이다. 내가 다니는 회사도 그렇고. 크롬의 입장은, UA string이 사용자의 정보를 과도하게 담고 있어 사생활 침해 문제가 있어 단계적으로 철폐해 나갈 것이라는 거다.

하지만, UA string을 제거하는 대신 Client Hints라는 별도의 매커니즘으로 해당 정보를 정리해 제공할 예정이라고 한다. 즉, 요청한 정보값만 정리하여 제공하겠다는 뜻 같다. 하여간 브라우저 회사들에서 사용자의 프라이버시를 꽤나 신경쓰고 있지만 너무 걱정할 필요는 없다는 의미이다.

2 MySQL에서 성능을 제대로 측정하는 것은 쉽지 않다. 검색결과를 캐싱해놓거나, 최적의 실행계획을 옵티마이저에서 수립하기 때문이다.