분류 전체보기

(지난 줄거리...) 현재 돌아가고 있는 앱 서비스의 어드민 웹을 리뉴얼하는 외주 프로젝트를 시작했다. 타입스크립트 스터디를 같이 하면서 탬플릿 컴포넌트를 작성하는게 적지 않은 도움이 되었다. 그리고 야심차게 회사에 첫 지원서를 냈다. 최종 면접에서 떨어졌고, 그게 2분기 회고의 마지막이었다. (푸슝.. 하고 나오는 타이틀). 주 2회 방영하는 드라마들을 보면, 한 주가 지난 뒤에 방송하는 회차에서 '지난 줄거리'로 시작하는 경우가 많다(무빙보다 이런 생각했음). 뭐 이런 느낌이랄까. 겨우 4-5일 지난 드라마도 다 까먹어서 줄거리 요약해주는데, 하물며 3개월마다 내는 회고글을 막 쓴다는건 참 불친절하다. 여러분은 지금 세상 친절하지만 수요없는 기술 블로그를 보고 계십니다. 리쿠르팅 1 토스인슈어런스 개..

한달에 삼만얼마 짜리 요금제를 쓰고 있다. 처음에 제공된 데이터 몇기가를 전부 소진하면 그 이후론 속도제한이 걸린 채 무제한으로 사용할 수 있다. 말이 무제한이지, 웹서핑과 음악 스트리밍을 동시에 못하는 대역폭. 그럴 때 휴대폰으로 두둥을 들어가면 로딩이 굉장히 느려 답답했다. 포스터 이미지를 많이 불러오는 홈화면은 특히 그랬다. 웹 성능 최적화를 해보기로 했다. 그리고 이번 글은 그에 대한 기록. 초기 lightHouse 점수이다. 다행히 막 크게 안좋은 점수는 아니었다. 1. 폰트 최적화 * 웹폰트가 로드되는 동안 텍스트가 계속 표시되는지 확인하기 웹폰트를 렌더링하는 방식에는 두가지가 있다.  대체 글꼴이 새 글꼴로 바뀜 (FOUT - 스타일이 지정되지 않은 텍스트 플래시). "보이지 않는" 텍스트..

매 분기 회고를 쓰기 전엔 항상 이전에 썼던 글들을 쫙 읽는다. 그러다보니 처음에 썼던 '전역 후 1년 회고'는 정말 여러번 읽었다. 1년동안 열심히 달려왔다는 뿌듯함과 온갖 뽕에 가득차서 썼던 글이었다. 단순히 재미 외에도 이력서나 포트폴리오를 정리할 때, 내가 어떤 생각을 했었는지 참고를 하기위해 종종 찾아온다. 지금도 그때와는 별반 다를 건 없다. 내가 운이 좋은 케이스라는걸 여전히 자각하고 있고, 개강은 일년에 두번씩 매번 찾아온다. 계속 새로운 무언가를 시작한다. 그리고 매번 다음 분기를 기약하면서 이런거 해야지 - 하면서 글을 끝내고. 그 다음 분기 회고에선 아쉬움을 토로하면서 시작. 이번 글도 똑같다. 알고리즘 스터디는 하나가 파토났고, 개발자 글쓰기 소모임도 지금은 돌아가지 않고 있다. 스..

프론트엔드 개발을 하다보면 흔히 마주할 수 있는 상황이다. Select, Toggle 또는 DatePicker 등의 인풋 컴포넌트들을 설계할 때, 그 컴포넌트들을 핸들링할 커스텀훅도 같이 작성해 사용할 수 있다. 보통은 useToggle, useSelect 등의 이름으로 쓰고 [value, onChange] 같은 배열을 return해 사용한다. 외주 개발을 하면서 초기에 이런 컴포넌트 작업을 해야할 일이 많았다. import useSelect from '~hooks/useSelect'; import Select from '~components/Select'; const App = () => { const [value, handleSelectValue] = useSelect(); return ( ); };..

귀찮은 일은 꽤나 자주 일어난다. 외주 작업 중 테이블 컴포넌트를 구현해야하는 일이 있었고, 기존 코드는 Core UI라는 라이브러리를 사용하고 있었다. 라이브러리가 4.0버전으로 업그레이드 되면서 PRO버전이 새로 생겼고, 그를 위한 급나누기에 테이블 컴포넌트가 걸려버렸다. 기존에 사용하던 onRowClick, scopedSlots등의 기능들이 사라졌고 직접 구현해야 했다. { navigate(`/notices/${data.id}`); }} customCellItem={{ info: data => alert(data.index)}>커스텀cell, date: data => {data.date}, }} />; 추상화된 Table은 상위 컴포넌트는 위와 같이 사용할 수 있다. 컬럼과 data 배열을 넘겨주면..

타입스크립트가 결국 타입을 위한 언어이기 때문에, 변수를 선언할 때마다 타입을 명시해야 한다고 생각할 수 있다. 그러나 타입스크립트의 많은 타입 구문은 사실 불필요하다. 이렇게 아무 생각없이 명시했던 타입들이 있다. 하수의 코드. 타입 추론이 된다면 명시적 타입 구문은 필요하지 않다. 오히려 코드가 길어지고 가독성이 안좋아질 수 있기 때문에. 하지만 타입이 추론될 수 있음에도 타입을 명시하는 것이 더 좋은 몇가지 상황들이 있다. 더 정확한 위치에 오류를 표시하기 위함이다. 객체 리터럴을 정의할 때 함수의 반환값을 명시할 때 타입 넓히기 let 으로 선언하는 경우. 값이 재할당될 가능성이 있다. 따라서 처음 초기화한 값을 가지고 할당 가능한 값들의 집합을 유추해야 함. 어느정도 가능성을 열어주기 위해서 타..

개발자로성장하기 (23.04.06) 제 이름이 소개될때 뭐 두둥 프론트 리드 어쩌구 써있더군요. 창피해서 그거 빼달라고 했는데 결국 안빼준것 같습니다. 부끄. 제가 뭐 대단한걸 만들어서 창업한것도 아니고, 대단한 기업에 취업한거도 아니에요. 심지어 아직 취준이란걸 제대로 시작 안해봤습니다. 취준준생이에요. 말 그대로 취준을 준비하는.. 그래서 주제에 대해서 고민을 좀 했어요. 어떨때는 새내기와 초심자분들이 많아서 기술적인 이야기를 했다간 쉽게 지루해질 수 가 있고요. 경험 많고 잘하시는 분들이 들으시기엔 별로 도움이 되지 않거나, 오히려 번데기 앞에서 주름 잡는 꼴이 될 수도 있겠죠. 어쨌든. 그러다가 대충 개발자로 성장하기 라는 제목을 들고왔습니다. 요즘 유튜브에서 흔히들 희화화 하는 ‘동기부여 강사’..

책을 이용한 스터디를 하면서 평소에 쓰지 않는 (경험이 아닌 책 내용을 정리하는) 글을 쓰면서 많은 고민을 하게 된다. 어떻게 해야 완벽히 이해하고, 정리하고, 기록할 수 있을까. 책의 순서 그대로 쓰지 않고 내가 이해한 흐름대로 재구성해서 글을 쓰도록 노력해보려고 한다. 효율적인 방법인지는 모르겠지만. 지난주에 공부했던 구조적 타이핑의 관점에서 보면 아래의 코드는 오류가 발생하지 않는다. interface Room { numDoors: number; ceilingHeightFt: number; } const obj = { numDoors: 1, ceilingHeightFt: 10; elephant: 'present', } const r: Room = obj; 추론된 obj의 타입은 Room타입의 부분 ..