flurry.olaf.kr 릴리즈 후기

Screen Shot 2017-10-13 at 2.42.14 PM.png
https://flurry.olaf.kr

0.

회사를 다닐 때에는 상관이 없었는데 복학하고 학교를 다니면서 아침에 등교하냐, 점심에 등교하냐에 따라 햇빛의 위치가 달라지는 것을 다시 경험하게 됐다. 아무 생각 없이 학교를 다닐 때에는 그냥 햇빛을 맞으면서 탔는데, 어느 순간 사람들이 버스의 한 쪽에만 앉아있는 것을 발견했고, 사람들이 모여있는 쪽이 햇빛이 닿지 않는다는 것을 알기까지 꽤 오랜 시간이 흘렀다.

적당히 버스에 타기 전, 방향과 현재의 햇빛의 방향으로 판단하면 어디로 앉아야겠거니 판단이 서긴 했지만, 그대로 가끔 계산에 미스가 종종 있어서 한 번 관련된 서비스를 만들어보면 어떨까 생각했다.

1.

해가 어디에 위치하는 지 알 수 있는 방법을 찾아야했다.

지구과학에 관심이 없는 것은 아니었으나 직접 계산하는 것은 내 취향이 아니거든. API로 제공하는 부분이 있나, 라이브러리가 있나 찾다보니 적당히 npm에 올라와있는 라이브러리를 찾았다. 시각과 위도-경도를 입력하면 각종 결과가 나오는 식.

시각이야 현재 시각을 new Date()로 때려넣으면 되겠거니 했지만, 위도 경도를 사용자에게 소숫점 n자리 까지 직접 입력하게 하는 것은 비인간적이라고 판단했다. 이러나 저러나 지도 API를 갖다 붙여야했는데, 이 서비스를 비단 한국에서만 사용할 수 있는 것이 아니라 먼나라에서도 사용가능한 간단한 아이디어이기 떄문에, 최대한 글로벌한 API이면서 쓰기 쉬운 Google Map API를 살펴보니, 내가 필요로 하는 기능이 모두 포함되어 있었다. 낙찰!

2.

다음은 이번 개발을 하기 전에 세운, 하면서 명확해진 원칙들이다. (이렇게 문서화를 해놓진..ㅎ)
아무리 마음에 안 들더라도 컨벤션은 명확하게 있는게 편하니까.

  1. CSS
    1. Bootstrap의 디자인 / 컴포넌트를 크게 변경하지 않고 그대로 사용한다.
    2. 일단 구현하고 컨텐츠와 레이아웃이 잡힌 뒤에 margin, padding, font-size를 조절한다.
    3. 필요한 경우가 아니면 vue의 style을 scoped로 지정하지 않는다.
    4. scss로 작성한다.
    5. 페이지에 한 번만 등장하는 Vue component의 경우
      최상위 div에 id를 항상 넣고, 그 밑에서 scss를 작성한다.
    6. 페이지에 여러 번 사용되는 Vue component의 경우
      최상위 div에 class를 항상 넣고, 그 밑에서 scss를 작성한다.
  2. Layout
    1. Bootstrap의 그리드 시스템을 최대한 활용한다. semantic-ui를 사용하지 않은 가장 큰 이유가 media-query의 부실한 지원 때문이며, 이 서비스의 target device도 iPhone7의 환경 (내 핸드폰ㅎ) 이었으니, mobile first로 개발하며, 혹시 데스크탑과 모바일 사이에 충돌이 나는 레이아웃이 생긴다면, 모바일 웹페이지에서의 사용성을 더 우선시 하여 작성한다.
    2. navbar를 사용하지 않는다. navbar를 사용할 만큼 복잡한 서비스가 아니니, 굳이 navbar로 불필요하게 화면의 가용공간을 줄이지 않는다. 만약에 navbar의 settings page에 들어갔으면 좋았을 법한 기능들은 Floating Action Button (이하 fab)으로 대체한다.
    3. Floating Action Button의 비직관성은 어쩔 수 없으니, 최대한 액션을 설명하는 아이콘을 넣고, 그것을 confirm하는 bootstrap modal을 사용한다.
  3. Overall
    1. 최대한 공개되어있는 라이브러리를 사용한다. 개발속도에 가장 큰 우선순위를 둔다.
    2. 시각장애인 지원과 같은 접근성 관련 개발 / 컨텐츠들은 우선순위를 가장 낮춘다. (1번과도 연관됨)
    3. 처음은 pure front-end로 개발한다. 이후에 로그를 모으든 뭘 하든 나중의 일이다.
    4. 개발속도를 크게 해치지 않는 선에서는 적당히 심미성을 신경쓴다. 하지만, 심미성보다 직관성이 더 중요하다. 심미성을 놓치지 않으려고 속도와 직관성을 모두 잃는 일은 절대 피한다.
    5. 이미지는 unsplash에서 가져다 쓴다.
    6. 개발은 코어파트가 가장 중요하다.
    7. ubuntu, mac에서 development, production 빌드들이 정상적으로 동작해야한다.

3.

(1) 햇빛 정보 계산

Screen Shot 2017-09-22 at 2.06.29 PM.png

출발지와 목적지를 하드코딩으로 때려넣고 정상적으로 햇빛 방향이 계산되는지 확인했다.
radian & degree에서 오는 혼란과, 좌하단 기준으로 배운 데카르트 좌표계를 html canvas의 좌상단 기준으로 변환하는 혼란 등으로 애먹었고, (euc-kr 인코딩 다음으로 짜증난다)

이후에는 tangent 함수의 주기가 2π가 아닌 π여서 정반대로 계산되는 버그도 이후에 수정했다.

(2) Change log? To-do List!

Screen Shot 2017-09-23 at 1.38.45 AM.png

뭐.. 부르기 나름이겠지만, 공개된 trello나 jira를 판다고 사람들이 참여할 것 같지도 않고 소스를 공개할 생각도 없었으니 개발 히스토리와 플랜을 동시에 보여주는 공간이 필요하다고 느껴져 만들었다.

(3) 출발지 / 목적지 선택 Modal

Screen Shot 2017-09-24 at 12.45.50 PM.png

모달을 띄우는 버튼을 넣었다. 그냥 버튼만 덩그러니 있으니 허전해서 뭔가 시작과 끝의 느낌을 주는 이미지를 unsplash에서 한 시간동안 찾았다. (나름 고심했다는 뜻ㅎ)

(4) 출발지 / 목적지 선택 Card

Screen Shot 2017-09-24 at 1.17.05 PM.png

출발지와 목적지를 고르는 데에는 Card를 써봤다. 모바일 화면에서는 크게 상관 없지만 본문 컨텐츠의 길이에 따라 카드의 높이를 맞춰주는 게 참 번거로운데, 부뚜수뚜랩 넘나 감사한 것ㅎ

이 때 까지도 서비스명을 정하지 못해서 작업중이라고만 달아놨다는 것은 함정ㅎ…

Screen Shot 2017-09-24 at 3.48.09 PM.png

이후에 지도에서 Google Map API를 사용하여 출발지와 목적지를 고르는 뷰를 Modal에 넣었고,
(우 하단의 에러는 브라우저의 추적방지 옵션으로 구글에 날아가는 로그가 막혀서 발생)

Screen Shot 2017-09-24 at 8.04.30 PM.png

출발지와 목적지가 선택되고 난 뒤에는 장소 선택 버튼을 숨기고, 옆에 리셋 버튼을 작게 달았다.

(5) FAB

Screen Shot 2017-09-25 at 3.29.03 AM.png

일단 카드로 출발지와 목적지를 감싸버리니, 두 장소를 swap하는 액션을 넣기가 너무 애매했다. 두 카드에 넣기에는 싫었고, 카드 사이에 넣자니 모바일-데스크탑 사이의 직관성 / 일관성이 형편없었다.

그래서 Vue기반의 Floating Action Button을 찾았는데(vue-fab), 크롬 이외의 브라우저에서 제대로 css가 적용되지 않는 버그를 발견했다. 아마 absolute 안에 위치한 relative한 녀석들이, 크롬에서는 부모의 정 중앙에 위치하게 짜여져있고, 사파리에서는 우하단에 위치하게 된 것은 아닐까 (부모의 bottom-right를 따라간 것은 아닐까) 고 추정.

PR을 날리더라도 받아줄 것 같지도 않고, 그럴 열정도 없어서 (사이즈 별로, 위치 별로 테스트할 열정ㅎ..) 올라와있던 이슈에 코드만 달고 말았다.

겸사겸사 다른 설정들도 필요했으니, 언어 선택, 사이트 소개 숨기기 등과 같은 기능을 넣기에 아주 적절한 공간이었다.

(6) Release?

Screen Shot 2017-09-26 at 5.05.12 AM.png

MVP가 나왔으니, 이 블로그가 돌아가고 있는 바로 그 서버에 배포를 시작했다. 겸사겸사 페이스북과 자주 방문하던 사이트에 수..줍..게 올렸더니 생각보다 훨씬 많은 사용자가 유입됐다.

Screen Shot 2017-10-13 at 2.37.40 PM.png

덕분에 하단에 링크되어 있던 이 블로그도 덩달아 많은 방문자가 유입됐다. (감..격..)

Screen Shot 2017-10-13 at 2.39.39 PM.png

최근에는 일주일에 400명 정도의 소규모 이용자가 유입되는 상황이고, 추가적인 홍보 계획은 없으니 여기서 감소했으면 했지, 증가하진 않을 것 같다.

4.

사이트와 지인들로부터 생각보다 많은 피드백을 받았다.
참신/신박하다, 피부 노화 방지에 좋겠다, 기차나 장거리 버스탈 때도 좋겠다, 채광 확인할 때 참고하겠다, 감사하다, 개발은 잉여력이 높아야 한다(?) 등..ㅎㅎ

그 외에도 문제점으로 지적받은 (개발 외적인) 부분은 다음과 같다:

  1. simply -> simplely typo:
    영문 번역을 하던 중에 영어 실력의 바닥을 드러내버렸다ㅎ…
  2. 적녹색약(맹)에 대한 배려가 부족하다:
    Screen Shot 2017-10-13 at 3.07.55 PM.png
    일단 바로 파란색으로 바꾸면 되는 문제로 생각하고 있는데, 실제로 파란색으로 바꾼다고 개선되는 부분인지 정확하게 모르겠으며, 다음 개선 부분이 여기가 될 예정이라 계속 미루고 있다.
  3. 태양의 고도도 표시해줬으면:
    아주 새벽이나, 사진 찍기 좋다는 일몰 1시간 전, 골든 아워 때에는 햇빛 반대편에 앉는다고 햇빛을 피할 수 있지가 않다. 차라리 햇빛쪽 창가에 앉아서 커튼을 컨트롤 하는 것이 더 나을 때도 있다는 피드백을 받았다! (아주 초기에 친구로부터 피드백을 받아 바로 반영했다)
  4. 직선 경로로 짜도 괜찮은가, 실제로는 구불구불하게 이동할 텐데 그 보정은?:
    정말 애매하다. 사용자에게 경로를 입력받는 것이 가장 큰 문제이고, 거기서 평균 변위를 구하는 것은 크게 어렵지 않지만, 버스나 기차에서 자리를 유동적으로 움직이는 상황이 많냐 하면 그것은 또 아니거든. 개발의 난이도, 그리고 편리한 경로 입력 도구 등의 한계로 기획이 전혀 없다.
  5. 비행기와 같이 날짜 변경선을 넘어가며 빠르게 이동하는 이동수단을 탄 경우는?:
    현재 햇빛의 정보를 계산하는 데에는 출발지의 시각, 위도, 경도만을 사용하는데 항공과 같이 빠르게 이동하는 중에는 햇빛의 위치가 지속적으로 변할 수 있다는 한계점은 인지했다. 하지만 결국엔 이것도 마세라티 문제인 것 같아서 안타깝지만 패스.

5.

개발하면서 느낀 점:

  1. 간단한 페이지에는 vue가 react보다 생산성이 꽤 괜찮구나.
  2. 생각보다 많은 사람이 유지되고 있구나.
  3. Bootstrap은 위대하구나.
  4. jQuery 없이 짜니까 너무 좋구나.
  5. 하나의 포스팅에 세부적인 개발얘기 까지 넣으려니 내용이 너무 난잡해지는구나.

그래서, 더 자세한 개발 후기는 다른 포스팅에서 이어가볼까 한다.
(느낀 점의 1번 항목도 더 자세하게 써볼 예정!)

읽어주셔서, 그리고 서비스에 관심을 가져주셔서 감사감사! ^0^b

Leave a Reply