SUEATY 발은 개발

첫 배포를 마치고 얼마 지나지 않아 v1.1.0를 제출했다. v1.1.0 에서는 다국어 지원(영어, 한글)을 했고 iOS 오픈카톡방에서 선배 개발자 분들이 얘기 해주신 점들을 모두 반영했다. 가령 pan gesture로만 picker view를 움직이는게 아니라 tap gesture도 적용해서 더 편하게 움직일 수 있도록 했고, 첫 화면에서 사용한 아이콘이(+ 모양이었음) 어떤 action을 trigger하는 것 같이 느꼈다는 피드백에 아이콘 교체로 사용자 경험을 향상시켰다. 내가 기획, 디자인, 개발까지 다 직접 한 작업물이라 비록 단순해 보일지라도 소중했다. v1.1.0을 내보내고 나서도 뿌듯했다. 그러나 평점이 1점이라니. 굳이 평점을 남기기위해 앱 스토에서 별 하나를 눌렀다니. 어지간히 마음에 안..

드디어 제 앱이 세상 밖으로 공개 되었습니다. 와아~~ 한 번 리젝 당하고 출시를 하게 되었는데요, 뭔가 기분이 새롭고 왜 사람들이 토이프로젝트를 하는지 알겠고 업데이트 할 것들이 눈에 보이고, 새로운 것도 또 만들어보고 싶고 그러네요! 그래서 오늘은 리젝 경험, 출시 된 앱 그리고 소소하게 받아 본 피드백에 대해 적어보려고 합니다. ## 한 번의 리젝 리젝을 당하는게 어쩌면 당연한 것이었어요. 사용자의 카메라나 사진첩에 접근하려면 권한 요청을 해야하는 것은 여러분들이 모두 아실 것 같아요. 대부분 plist에서 key를 설정하실텐데, 이 때 요청 메세지를 value 값에 써 놓아야 합니다. 요청 메세지에는 어떤 목적으로 사용자의 데이터를 사용할 것인지를 분명하게 명시해 두어야 한다고 HIG 문서에도 나..

오늘은 제 토이 프로젝트 경험을 공유해보고자 글을 쓰려고 앉았답니다~ 처음 기획했던 부분까지는 다 개발을 한 것 같고, 개발자 계정도 만들었고(12만원이라니!), 리젝도 받아보고 다시 제출도 완료한 상태에서 이 글을 쓰고 있는데요, 요 몇 일 (속되게 표현해서) 빡.세.게 개발한 것 같네요. 이 강도로 쭉 했으면 2~3주면 충분했을 것 같은데 이런 저러 핑계로 조금씩 미뤘던게 후회되네요. 간략하지만 차례로 살펴볼게요! 기획 : 어쩌다 Pixel Palette를 만들게 되었나 친구와 홍대에서 신나게 놀고 퇴근 시간 즈음에 2호선을 타고 집으로 돌아가던 길이었어요. 퇴근 시간이라 사람도 많고, 뒤에 아저씨가 밀어서 짜증도 나는 상태였는데 순간 환해진 창 밖을 바라보는데 해가 지고 있는 한강이 보고 있더라구요..

버그 리포트 #11 에 올렸던 내용으로, NSAttributedString이 문제인 줄 알았으나 결국은 (아니나 다를까) collection view의 잘못이었던 문제에요. 간단히 살펴보면 아래와 같습니다. (Bug Report Issue #11 https://github.com/Sueaty/PixelPalette/issues/11 ) ## 문제상황 오른쪽과 왼쪽이 다른 것 보이시나요? 첫번째, 두번째 cell을 자세히 보면 보이실 것 같아요~! 두 상황 모두 비정상이에요. 언제나 하나의 레이블만 highlight 되어야 하거든요. cell의 배경색에 따라, 밝으면 아래 label에 어두우면 위 label에 highlight가 됩니다. 전 highlight를 위해 NSAttributedString을 사용..

현재 주요 기능에 대한 개발은 끝 마친 상태지만 다양한 use case를 토대로 실험을 해보니 고려하지 못한 부분들에서 버그들이 속출하네요. 아차차 아차차! 속.출. 까지는 아니고, 좀 거슬리게 눈에 보이네요ㅎㅎ 버그가 아니더라도 사용성을 조금 헤치는 것 같은 것들도 있고 해서 고치고 있어요. 깃헙에서 이슈 리포트 템플릿을 만들어서 지금 계속 활용하고 있어요. 효과적으로 버그 리포팅을 할 수 있는 양식들이 다양하지만 저는 깃헙 양식을 조금 수정해서 따르고 있네용! 직접 사용해보니 Description, How to Reproduce, Expected Behavior 는 필수로 작성을 하게 되고 Screenshot이나 Additional Context는 필요에 따라 쓰고 있어요! 위의 예시에는 Screen..

가끔 의도하지 않은 결과물이 웃음을 주는 경우가 있는 것 같다ㅋㅋ 작업하던 프로젝트의 디자인(?)을 바꾸기로 결심했다. 뭔가 키노트로 직접 그려보니까 바꾸는게 더 이뻐 보일 것 같아서. 바보같은 오뱅미니를 이렇게 확대해서 보는게 더 좋을 듯 하여 기존에는 aspect fit 으로 작업하며 사진 크기만큼만 받게 하였으나 꽉 채운 다음 pan gesture와 pinch gesture로 확대와 이동을 가능하게 하는게 더 좋을 것 같았다. 그래서 image view에 gesture recognizer 걸고 했는뎈ㅋㅋㅋㅋㅋ 이미지 뷰 전체가 움직여버리네ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 아 진짴ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 스크롤 뷰에 넣어보면 되려나? 다시 작업하러 총총ㅋㅋ

2021/01/19 - [Firebase] Firestore ① NoSQL Database란 2021/01/20 - [Firebase] Firestore ② Firestore의 구조 지난 글에서는 NoSQL database에 대해 간략히 알아봤습니다. 이번 글부터는 본격적으로 Cloud Firestore에 대해 이야기를 나눠보려고 합니다. 이번 글은 Cloud Firestore의 구조에 대해 다루려고 합니다. NoSQL이 무엇인지 모르시다면 지난 글을 훑어보고 오시면 좋을 것 같습니다. Firebase의 공식 유튜브에서 제공하는 영상을 번역했고 커피 한 잔은 와방 큰 힘이 됩니다? 깔깔>< 혹시나 오류 발견 시 댓글로 꼭 말씀해주세요! 시작해볼까요? 일단 결론 급할 수도 있으니 결론부터 보고 가겠습니다...

2021/01/19 - [Firebase] Firestore ① NoSQL Database란 2021/01/20 - [Firebase] Firestore ② Firestore의 구조 Cloud Firestore는 NoSQL database입니다. (NoSQL이 무엇인지 아시는 분은 영상의 10분대로 넘어가시거나 다음 글로 넘어가시면 됩니다~) 그래서 이번 글은 NoSQL에 대해 다뤄보려고 합니다. Firebase의 공식 유튜브에서 제공하는 영상을 번역하는 형식으로 진행해볼까 합니다! 커피 한 잔은 와방 큰 힘이 됩니다? 깔깔>< 혹시나 오류 발견 시 댓글로 꼭 말씀해주세요! 시작해볼까요? 관계형 DB는 테이블 형태로 구성이 되어 있죠? 각 테이블의 행(row)은 정해진 규칙을 따라 채워나가게 됩니다. 예..

내가 눈 앞에 처리했어야 하는 일 : [ 웹 - flask - iOS ] 이렇게 연결된 구조 만들기. 지난 글을 썼을 때는 웹-flask만 연결 된 상태였고 iOS 프로젝트와는 연결하지 못한 상태였다. 그래서 스트레스가 쌓여 있었고 하기 싫어 자꾸만 미뤘다. 언제까지나 미룰 순 없다는 것을 잘 알고 있었다. 너무 늘어졌던 것일까? iOS가 힘들면 그냥 웹으로 하자는 의견이 나왔다. iOS가 되었던 웹이 되었던 맡게 될 역할이 데이터 분석의 결과를 플롯으로 그려주는 것이기 때문에 프로젝트 전체에서 큰 비중을 차지하지 않는다. 그래서 언제든지 대체가 될 수 있었던 것이다. iOS를 하겠다고 말한 내 입장이 곤란해졌다. 아니지, iOS를 하겠다고 말한 내 입장이 곤란해진 것이 아니라 뭔가 '패배자'가 된 기분..

(9월 1일 노션에 쓴 글) 지금 내가 벅차서 막막하다고 느끼는 것인지는 잘 모르겠다. 플라스크로 간단히 서버도 구현해 놓았고, 엑코에 간단한 프로젝트를 하나 만들어 놓긴 했는데 1. 부스트캠프 챌린지 때 마지막 네트워크 문제를 완벽히 해결하지 못했다는 자책(아닌 자책) 2. 분석 결과를 어떻게 플롯팅을 할 것인가에 대한 (앞서도 한참 앞선)걱정 3. 부스트캠프 멤버쉽 과정으로 시간 부족 등 머릿속이 복잡~하다. 그래도 그나마 기부니가 좋을 수 있는 이유는 난 '휴학생' yo