JEP's Diary

오늘 개발하면서 SwiftUI에 적합한 아키텍쳐는 MVVM이 맞나?! 라는 의문이 들었다. 의문을 들게 했던 이슈를 먼저 나열해보자면... 요즘은 앱에 신규 기능을 추가 하기 전에, 퍼포먼스를 올리기 위해 데이터를 구성하는 시점을 변경하고 있던 중에 이슈가 생겼다. 기존방법 기존에는 리스트에 표시할 데이터를 모두 구성한 후 뷰에 그리는 방법이었다. 컬렉션 조회 REST API를 호출한 후 추가적인 정보가 있어서각각의 컬렉션에서 3개의 API를 더 호출하여 최종적인 컬렉션 데이터 리스트를 구성하고 있었다. 기존방법의 이슈 이렇게 했을때 리스트의 갯수가 많아질수록 데이터를 구성하는데 시간이 오래 걸리는 이슈가 생기기 시작했다. 변경해보기 컬렉션 조회 API를 호출하여 컬렉션 데이터 리스트를 먼저 만들고 뷰에..

간헐적인 이슈가 수정 하기 어려운데.. 간헐적으로 리스트의 아이템이 갱신이 되지 않는 이슈를 만났다! 이슈현상 1.A 계정의 컬렉션 데이터 리스트를 LazyVStack을 이용하여 리스트를 보여준다. 2.계정을 B로 변경하여 컬렉션 데이터 리스트를 다시 구성한 후 같은 뷰에 데이터를 갱신한다. 3. 1,2번 과정을 반복하다보면 간헐적으로 A계정의 리스트 세번째 Row에 변경 직전 B계정의 세번째 Row가 보이는 이슈가 발생했다. 또는 B계정의 컬렉션 리스트 세번째 Row에 A 계정의 세번째 Row가 보이기도 했다. 특이하게도 세번째 Row가 이슈였다. 해결해보자 원인을 찾아야 하는데 솔직히 정확한 원인은 못찾았다...ㅜ 느낌적인 느낌은 LazyVStack의 각 Row를 스크롤할때 화면에 표시되는 부분정도의..

이슈 50개의 병렬작업을 하는데 측정한 시간이 꽤나 오래 걸리는 이슈를 만났다. 데이터가 50개가 있고, 이를 각각 API 콜을 해서 데이터를 구성한 다음 하나의 리스트 데이터로 구성해야 한다. 한개의 API 콜을 하는시간이 1초도 되지 않기 때문에, 50 개를 병렬로 콜 해도 1초정도 걸리겠거니를 기대했었는데, 대략 7~8초가 걸리는 것이었다. Concurrency로 병렬작업으로 처리를 했고, 코드에도 이상이 없는 것 같은데 예상보다 오래 걸려서, 어렴풋이 쓰레드는 코어 갯수의 X2를 생성한다라고 알고있던 지식으로, 아 이건 속도를 더 높일 수 없다. 라고 결론을 지었다가.. 진짜 왜 속도가 느린건지에 대해 검토해보려한다. ChatGPT에게 물어보았다. 질문 Concurrency에서의 쓰레드를 최대 몇..

지금까지 개발자 일을 하면서 배포날, 데모날, 행사날에 하나씩 이슈가 터졌던 경험이 있었는데... 이번 이슈는 처음 경험했던 거라 기록해본다. 다음에 또 이런일이 발생하지 않기 위해! 이슈의 원인은 각 앱에서 개발한 시간 기준이 달랐던 것. 정상 시나리오 앱A 와 앱B 가 있고 이는 서로 연동된다. 앱A에서 만료시간을 만들어서 QR 코드를 띄워주면 앱B에서 이를 읽고 데이터를 파싱하여 만료시간을 읽어낸다. 앱B가 만료시간을 읽어내는 과정은 QR 코드에 심어져 있는 만료시간 데이터가 long 값이어서 long 값을 다시 시간 타임스탬프로 변경해야 한다. 이때 앱A에서 만든 만료시간과 앱B에서 읽어낸 만료시간이 서로 같아야 하는데 개발하고 테스트하는 단계에서 문제없이 잘 동작했던 부분이다. 이슈 발생 행사가..

오늘 개발팀 회의에서 얘기가 나왔던 Copilot! GitHub Copilot 이란? 깃허브 코파일럿(GitHub Copilot)은 2021년 GitHub에서 출시한 자동 코드 완성 인공지능이다. OpenAI의 GPT-3 모델을 이용하여 깃허브의 수많은 레포지토리들을 학습시키는 방식으로 개발되었다. 주석이나 함수 이름에 담긴 의미를 파악하여 코드를 자동 완성해, 단순하고 번거로운 작업을 자동화한다는 점이 특징이다. 현재시점으로 두달 무료사용이 가능하다. 아이폰 앱 개발할때 copilot을 사용하고싶다면 VS Code를 사용할것! 간단한 세팅 절차는? 요기에서 Visual Studio Code에서 GitHub Copilot 시작하기 - GitHub Docs GitHub Copilot 사용해 보기 GitHu..

작년에는 회사에서 앱을 개발하는데 시간을 다 보낸 것 같다. 상반기에는 안드로이드 앱. 하반기에는 아이폰 앱. 앱을 출시한 후에는 추가 기능 개발 하는데 집중하면서 리팩토링이나 더 디벨롭하거나 자동화 같은 것들은 시간을 핑계로 쌓아두게만 되었다. 그래서 올해는 CI/CD 를 구축해놓는 걸 목표로 한다. CI/CD (Continuous Integration/Continuous Delivery)는 자동화하여 앱을 더욱 짧은 주기로 고객에게 제공하는 방법이고 CI/CD의 기본 개념은 지속적인 통합, 지속적인 배포이다. 작년 하반기에 아이폰 앱을 만들면서 쭉 아이폰 앱 추가 개발을 맡고 있었기 때문에 아이폰 앱의 빌드,필수 테스트 통과,자동화 배포 구축할 것이다. 특히나 우리 앱은 자산 이동을 할 수 있기 때문..

오늘 얘기가 나왔던 내용인데, 팀 내에서 해보고자 하는 git flow 전략을 정리해본다. 정리하면서도 100% 이해가 된 상태가 아니라서 직접해보고 수정할 부분이 생긴다면 수정하는걸로~! 브랜치 역할 및 사용 방법 main 릴리즈 배포 브랜치 release 다음 릴리즈 배포할 버전을 준비하는 브랜치 main 에서 1.0.0이 배포되면 다음 배포버전인 1.1.0을 준비하는 브랜치이다. develop에서 배포할 기능을 release에 rebase하여 배포할 버전을 준비한후 배포할때 main브랜치로 머지한다. QA 에서 나온 이슈들을 이 브랜치에서 수정하고 이 부분들을 develop에도 머지해주어야 한다. develop 다음 출시할 버전을 개발하는 브랜치. feature에서 개발이 완료된 작업들을 PR을 통..

상태 호이스팅 구성 가능한 함수에서 여러 함수가 읽거나 수정하는 상태는 공통의 상위 항목에 위치해야 합니다. 이 프로세스를 상태 호이스팅이라고 합니다. 호이스팅이란 들어 올린다 또는 끌어올린다라는 의미입니다. 상태를 호이스팅할 수 있게 만들면 상태가 중복되지 않고 버그가 발생하는 것을 방지할 수 있으며 컴포저블을 재사용할 수 있고 훨씬 쉽게 테스트할 수 있습니다. 이에 반하여, 컴포저블의 상위 요소에서 제어할 필요가 없는 상태는 호이스팅되면 안 됩니다. 정보 소스는 상태를 생성하고 관리하는 대상에 속합니다. 슬롯 기반 레이아웃 슬롯 기반 레이아웃은 개발자가 원하는 대로 채울 수 있도록 UI에 빈 공간을 남겨 둡니다. 슬롯 기반 레이아웃을 사용하면 보다 유연한 레이아웃을 만들 수 있습니다. https://..

web3swift 2.6.6 사용중에 type encode 관련 이슈가 있었기도 했고 그 다음 버전이 3.0.4까지 나와있는 상황이라 적용을 검토했다. 라이브러리 변경 후 빌드 에러를 없애기 위해 3시간 정도 소요했고, 그 이후에는 라이브러리를 가져다가 사용하는 기능들은 테스트 코드에서 모두 확인해보려 했다. ReadOperation 먼저 klay, token 잔액 조회는 성공! 두개의 케이스는 ReadOperation을 이용한다. WriteOperation 그 다음에 klay, token 전송 테스트 코드를 작성했는데, 자꾸 Web3Error.dataError를 만났다. 아직 web3swift document가 공사중인 상태라서, 처음에는 web3 세팅 provider 세팅 parameter 값들 세팅..

지난 8월에 겪었던 이슈와 그 해결 방법을 적어본다. web3swift를 이용하여 ios 지갑앱을 개발중이었다. 클레이 전송시 사용자에게 받는지갑주소/전송수량/예상 가스비의 정보를 표시해주는 기능을 메인넷/바오밥에서 모두 개발을 완료 했었다. 그러던 곧 배포가 얼마 남지 않았던 8월중순에 갑자기 예상 가스비 호출시에 노드단에서 에러가 났다. 충분한 잔액이 있는데도 불구하고! 예상 가스비 호출시 에러 발생 nodeError: (1 element) desc: “err: insufficient balance of the fee payer to pay for gas (supplied gas 500000010499)” 특이했던 현상 메인넷에서는 정상 작동, 바오밥에서만 해당 에러 발생! 원인을 검색 해보던 중 바..