프론트엔드 개발자는 일반적으로 개발 프로세스에서 QA이전의 단계를 담당하는 것 같다. 물론, 백엔드 개발과 짧은 개발 사이클을 가지며 프론트엔드 개발을 할 수 있지만, 많은 경우에 백엔드의 어느정도의 기반이 다져놓아야 프론트엔드의 기능을 실제 서비스에 반영하고 테스트할 수 있다. 구현사항이 복잡할 수록 백엔드에서 구현작업이 오래걸리는 경우가 많은데, 이런 경우에는 백엔드 부분도 어느 정도 직접 구현하거나 프론트엔드 로직을 어느정도 작성해놓는 것 같다. 아무튼 핵심은 프론트엔드 개발은 프로젝트의 후반부에 위치한 동작이고 마감기간이 정해져있기 때문에, 더 이상 미루는 것은 사실 힘들다. 그래서 프론트엔드 개발자에게 마감기한 내에 요구사항에 맞게 구현을 하는 능력은 중요하다. 그러면서 코드의 퀄리티까지 챙길 ..

다라쓰의 로그인 인증방식은 refreshToken을 발급받음으로서 accessToken을 서버로부터 받을 수 있는 방식으로 구현되어 있습니다. (기존에는 cookie등의 클라이언트 저장소에서 accessToken을 가지고 있는 방식이었는데, 보안상 취약점이 걱정되어 수정했습니다.) 그리고 accessToken을 재발급받을때마다 서버에서의 refreshToken은 새롭게 갱신됩니다. 처음에는 refreshToken의 갱신이 잦음으로 보안이 뛰어날 것이라는 생각에 동의했었습니다. 그런데 지금에서야 뭔가가 이상함을 깨달았습니다. 동시에 로그인했을 경우 어떻게 하지? 지금껏 모든 가정은 한 곳에서 로그인하는 상황만 가정되었습니다. 또한, 테스트를 할때에도 로그인 vs 비로그인, 비로그인 vs 비로그인, 네이버 ..

다라쓰에는 오래전부터 한가지 문제가 있었다. 새로 고침할때마다 image보다 alt가 먼저 보이고 있다. 바로, 새로고침해서 이미지를 로드할때 이미지가 로딩되기 전에 alt가 먼저 노출되는 것이었다. 이제 기능추가나 코드를 예쁘게하는 시점보다 사용자가 좀더 쾌적하게 서비스를 이용할 수 있도록 해야했기 때문에 많은 고민이 되었다. 이것때문에 SSR을 도입을 많이 고민헀다. SSR은 서버에서 렌더링할 요소들을 모두 적용해주기 때문이다. 하지만 데모데이까지 남은시간은 불과 1~2일. next js도 안니고 쌩으로 SSR을 적용하기엔 시간이 부족하다고 판단했다. 버그가 터지면 그것도 큰일.. 그래서 다른 방법을 리서치해보고 있었다. 그러다가 한 크루가 아이디어를 던져주셨다. 바로 인라인으로 BASE64 형식의 ..

https://github.com/woowacourse/javascript-own-ui-library/pull/20 [2단계 - Virtual DOM 만들기] 도비(김정혁) 미션 제출합니다. by zereight · Pull Request #20 · woowacourse/javas https://musing-lamport-6e9960.netlify.app/ WebComponent 기반으로 동작합니다. Step1 심화 요구사항인 JSX 파서를 만들었습니다. (버그 존재) Step1의 Vdom 알고리즘을 개선했습니다. 이제 한번에 변경사항 모아서 github.com 지난 3일동안 우테코 미션을 했다. 나만의 ui 라이브러리를 만들어보는 것인데, 기한이 내일까지라 버그가 있음에도 제출을 했다. 버그는 대부분 ..

좋은 회사? 돈 많이 주는 회사? 망하지 않는 회사? 직원을 안자르는 회사? 평균 연봉이 높은 회사? 시가 총액이 높은 회사? 사람들에게 갓기업이라고 소문난 회사? 블라인드 평점 4.0이 넘는 회사? 사람들의 기준은 모두 다를 것 같다. 그리고 그것에 정답도 없을 것 같다. 왜나하면 좋다라는 사전적인 의미도 다양하고 주관적으로 해석될 수 있기 때문이다. 그래서 지금부터 내가 하는 말은 오로지 나의 주관이다. 좋은 회사란 - 직원이 행복한 회사 - 실패자체의 책임을 묻지않고, 새로운 시도를 장려해주는 회사 - 성과에 따른 보상이 확실한 회사 - 충분한 기술력을 가지고, 시장의 흐름과 기술 트렌드에 잘 대응하는 회사 로 정의할 수 있을 것 같다. 1. 직원이 행복한 회사 일의 만족도가 높고, 직원이 삶을 살..

우테코의 미션으로 나만의 UI 라이브러리를 만드는 미션이 있습니다. 첫 미션은 Virtual DOM을 구현하는 것이었고, 완전한 Virtual DOM을 구현해내진 못했었습니다. 그래도 렌더링된 요소 중 바뀐 요소만 렌더링 시키는 것에는 성공했었습니다. 그래서 이제 다음미션인 상태관리 부분을 구현하려했습니다. 근데 개인적으로 vDom의 구현과 jsx 파서를 구현안해보고 넘어간다는게 마음에 걸렸습니다. (사실 다음 미션인 상태관리 구현하기는 쉬워보였습니다.) 그래서 JSX 파서를 만들어보기로 했습니다. jsx 파서는 tagged template literal 을 이용해서 구현을 하면되었었는데요. 제가 지금까지 구현한 코드는 다음과 같습니다. const TAGGED_TEMPLATE_LITERAL_PARAM_F..

불과 하루 전, 다라쓰에 커스텀 ui를 적용할 수 있는 기능이 추가가 되었다. vs code를 4개를 키고해야하는 개발과 테스트를 완료했다. 그리고 배포를 하고 몇가지 이슈가 있긴 했지만, 기능 자체는 정확하게 동작했었다. 문제는 기존에 다라쓰를 사용하던 블로그에서 발생했다. 커스텀 UI 기능은 다라쓰 script에 data-* 속성을 넣어주면 그에 맞는 쿼리스트링을 넘겨서 댓글모듈을 렌더링하는 방식으로 구현되었었다. 근데, 기존 사용자들은 스크립트를 새로 넣지 않는 이상, 새로추가된 data-* 속성이 없을 것이고 undefined 값으로 들어갔을 것이다. 당시 코드에서는 이렇게 처리하고 있었다. $darass.dataset.isShowSortOption === "false" ? false : true..

모든것은 다른 프로젝트를 하고있는 크루로부터 부탁을 받은 시점이었다. 자신이 진행하고 있는 팀프로젝트의 어떤 파트에 다라쓰 댓글 서비스를 삽입할 계획인데, 댓글 색상 테마를 변경하고, 몇가지 UI를 제거하고 싶다는 의견이었다. (물론 그런기능이 있으면 좋겠다고 생각하고 있었지만, TODO로만 있을 뿐 실제로 개발이 이루어지지는 않았었다.) 부탁을 받는순간 고민에 빠졌다. 현재 기능을 고정하고, 리팩터링과 테스트코드를 작성하는것에 집중할 것이냐, 아니면 기능을 추가로 구현해서 사용자의 만족을 줄것이냐였다. 프론트엔드 개발 인력도 팀내에 나 뿐이라서, 분업할 여력도 되지 않았다. 하지만 빠른시일내에 해주기로 했다. 모든 서비스는 고객을 만족시키는 방향이 우선시되어야한다고 생각했기 때문이다. 그래서 어떻게 문..