첫 개인 풀사이클 프로젝트
KBO 선수들의 기록을 스크래핑 하기 위해 셀레니움 패키지를 사용하였다. 타겟사이트는 statiz.co.kr
현 프로젝트는 원페이지 형식이 여전히 매력적이라 생각하여 간단하게 틀만 만들어보았다.
Ajax를 이용하여 연도, 팀, 포지션, 선수 선택을 할때마다 DB에서 데이터를 불러와 바로바로 반영하도록 하였다.
라인업에 선수를 추가하기 위해 라인업 테이블에 접근을 해야하는데 이런저런 방법을 써도 접근하기가 쉽지 않았다. 수 많은 시도 끝에 eq 선택자로 데이터를 append 하는데에 성공했다. Ajax로 데이터를 불러와 선수를 추가하는데에는 큰 무리가 없었다. 선수선택
하다보면 자잘한 ui를 고치고 싶거나 자잘한 기능을 추가하고 싶어서 그거 하다가 시간이 다 가는 경우가 있다. 근데 다 하고 나면 뿌듯하다. 메인은 선수 검색창을 띄워서 추가까지 하는것이었으나, 하다보니 대대적인 ui공사를 했다. 원래는 검색을 모달창을 띄우려 했으나
같은 선수끼리 팀을 짤 수 있도록 포지션 중복을 허용하려다가 나중의 방향성을 위해 포지션 중복을 막도록 하기로 했다.
가장 핵심이 되는 타자와 투수의 맞대결 알고리즘을 짜기에 나섰다.
또 하나의 최대 난제,안타에 따른 베이스 세팅을 어떻게 하느냐의 고민을 수 일동안 한거같다.
이거 연결 하는데 2일동안 끙끙 앓고 꿈에서까지 코딩을 했다.
프론트와 백 연결까지 마치고, 이제 금방 끝낼 수 있겠다 생각했던 내가 우스웠다.
처음 해보는 작업이고 숙련되지 않은 일이라 여러번 반복해봐야 할 듯 하다.
고마운 지인들의 테스팅 덕에 많은 버그를 찾을 수 있었고 피드백도 받았다.
리스트 안에 딕셔너리 형태로 있을 때 조건부 정렬을 하려면
이렇게 해야 말을 듣는다. 이거 때문에 엄청 고생했다...
특정 문자 사이의 문자열을 반환하고 싶을 때
#멘토링
#typescript #CRA
#정규식
사내 세미나가 약 두 달 만에 열렸다.주제는 TDD. 워낙 핫하다 보니 그 동안 관심만 있었지,,
회사에서는 Vue를 쓰고 있다. 그 중에서도 Vue2 버전을 쓰고 있다.
CSS Selector 사용 문법이 달라졌다.
어느날 미국팀으로부터 이슈가 하나 넘어왔다.
mxGraph 타일 정렬 알고리즘 구현
PM측에서 편집 중인 타일의 포트에 불이 깜빡거리는 애니메이션이 있으면 좋겠다고 하셨다.
라인을 연결할 때 UX적 요소로 화살표가 나왔으면 좋겠다고 하셨다.
새로운 요구사항이 들어왔다. 라벨이 라인의 방향 & 각도에 따라서 같이 회전해야 한다.
Workbench는 SMS 마케팅을 그래프로 유저가 쉽게 자동화하여 사용할 수 있도록 제공하는 서비스이다. 나는 이를 고도화 하는 작업에 투입되어 하는 중이다. 그 동안 신나게 기능 추가에만 열을 올렸으나 워크벤치 사용자들이 많아짐에 따라 성능을 신경쓰기 시작했다.
성능 최적화 (2) - 라인 생성 시 동작
mxGraph에는 cell의 스타일 변화에 애니메이션을 적용하기가 쉽지 않다.
사용자의 요구사항이 생겼다. 전체적인 플로우를 쉽게 보고 싶어 한다.
오래된 팬들이 말하는 '그 때' 그 선수들이, 현재 선수들의 평가의 잣대가 되는 것을 보며 '얼마나 잘 했길래?' 그저 옛 감상에 젖어 하는 소리 아닌가? 라는 궁금증을 가졌다.
KBO 리그의 원년부터 지난시즌, 즉 2023년까지의 모든 시즌의 모든 선수의 데이터를 스크래핑 해서 데이터 가공을 해야한다.
데이터를 뽑아 쓰기 위해 Firebase의 Firestore를 연동시키려 한다.
매치를 진행할 때 마다, 기본적으로 필요한 데이터들의 초기값을 세팅시켜놔야 한다.
데이터에 의한 확률로 값을 도출해야 한다.
5년째 활동하고 있는 풋살 동호회가 있다.
구글 시트에 기록돼있던 데이터를 옮겨와야 한다.
기존 기록 방식이 어땠느냐?
기록을 하다보면 기록하는 사람이 계속 보고 있는 것이 아니기 때문에 정확히 누가 어시, 골을 기록했는지 몰라서 잘못 기록하거나 누락되는 경우가 있다.
지금껏 나는 테일윈드와 스타일드컴포넌트 두 개의 선택지 중에서 항상 스타일드 컴포넌트를 고집해왔다.
Atomic 디자인이란?
Why Jotai?