spatial_AI

최근에 3차원 모델링으로 NeRF가 많은 관심을 받으면서 예전에 3차원 복원에 활용되었던 SLAM과 SfM 기술 간의 차이가 모호하게 해석되는 상황이 발생하고 있다. 실제로 필자는 관련 질문을 랩실 후배에게 받기도 했으니....... 이번 차례에 한 번 정리해보자. 1. NeRF는 기본적으로 들어가는 인풋이 camera pose값과 rgb이미지 값이고 아웃풋이 novel view synthesis, 즉 새로운 2D 이미지를 만들고 이를 통해 3차원을 덴스하게 radiance field 할 수 있게되는거라(원래 NeRF 논문 제목도 NeRF: Representing Scenes as Neural Radiance Fields for View Synthesis임) sfm이나 slam이 사전적으로 활용됨! 왜냐..

“Nobody wants to show you the hours and hours of becoming. They'd rather show the highlight of what they've become.” by Anela Duckworth, grit 정말 이번 과제를 하면서 정말 주구장창 고민했던 부분들은 다음과 같다........ 정말 이런 부분들을 같이 해결하고 싶은....ㅠㅠ 1. 패키지 분리 기준 + 이름 2. 클래쓰 분리 기준 + 이름 3. 테스트 케이스 안 빼먹고 추가하기 방법 4. 테스트 케이스가 통과 안 할 때 통과하게 코드 변경하는 법 + 테스트 코드 이해하기 (runexception, throwerror 등) 5. 구글링 했을 때 원하는 답이 안 나올 때 문제 해결 법..... 6...

이번 3주차 과제에서 가장 큰 허들이자 가장 많은 고민을 던져준 부분은 아마 Application의 테스트 케이스를 통과하지 못하는 부분이었을 것이다. 해당 부분들을 다른 우테코 크루 분들의 논의 한 것을 기반으로 정리하였다. 실제 크루 분들의 말씀들 try catch 사용 목적이 예외 발생으로 인한 비정상 종료를 방지하는 것이라는 걸 알았고, 예외를 catch하고 메시지를 출력 후 정상 종료되는 것이 요구사항의 의도라는 결론을 내렸습니다. (물론 여기까지 오는데 수시간 소요..)그래서, 에러 메시지 출력 후 더이상 실행할 코드가 없으면 되겠다고 생각했고, main 메서드에 try catch 구문을 사용했더니 테스트가 동작 하더라고요 휴 notNumber를 확인하는 부분에서는 throw만 던지고, 나중에..

이번 우테코 과정을 겪으면서 가장 많이 보이는 코드 구조가 있었다. 바로 패키지 명을 Model, View, Controller의 형태로 만들고 개별 기능들을 각 패키지에 맞게 구분한 것이었다. 나는 도대체 왜 이렇게 구분하는지 의문을 갖게 되었고, 그때 마침 슬랙에서 다른 분들이 MVC를 말씀하시곤 했다. 그때 아 설마 MVC가 Model, View, Controller였어?가 되었고...... 마침 테크톡으로 MVC 패턴이 있었어서 이를 찾아보게 되었다. 그리곤 눈을 뜬 리신 모드!! damn~을 외치는 나......핳 이 패턴에 맞게 더 코드를 4주차는 해봐야겠다!! 모든 내용과 사진 이미지는 영상 링크에서 가져왔습니다. 참고한 영상: (코틀린이 아니라 자바로 설명되어있지만 설명은 너무 좋았다!) ..

스똬뚜! 본 글은, 왜 코틀린 공식 다큐멘트가 이런 순서로 작성되어있는지 작성자의 마음에서 이해하고자 노력하였다. 그래서 매 문단은 질문형으로 시작함을 참고하여 읽어주면 너무탱큐베리캄사! 자, 그러면 본격적으로 정식 다큐멘트 본격 해부! 정식 다큐멘트 링크: https://kotlinlang.org/docs/coding-conventions.html#directory-structure 참고한 추가 블로그들 (일부 코드들은 해당 블로그들을 참고했습니다.): https://medium.com/mj-studio/코틀린-이렇게-작성하시면-됩니다-94871a1fa646 https://medium.com/@joongwon/kotlin-코딩-컨벤션-정리-7681cde920ce 1. Configure style in ..

솔직히, 평균의 기준치가 무척이나 높은 한국에서 뭔가 남들보다 특별나게 잘하지 않는 것을 공개적으로 얘기하는 것은 쉽지가 않다고 느껴진다. ( 한국의 취미에 대한 기준이나 중산층의 기준이 무엇인지 생각하면.......ㅎㅎ 단적으로 수능성적만 봐도 5등급이면 평균인데 그 대우는....핳) 거기에 코드를 정말 잘 짜시는 분들이 계신 우테코 프리코스 과정에서 개인적인 얘기를 한다는 게 마냥 쉽지만은 않다! 그렇지만 이런 곳일수록 더욱더 자신을 드러내야 한다는 것을! 그래서 완벽한 모습을 보여주자는 생각을 버렸다. 완벽주의에 빠지지 말자. 그것이 우리가 해야할 것이다. 완벽주의자는 자신이 두려워하는 것으로부터 보호 받고 안전해지고자 하며, 바로 이것이 (탁월해지기 위해 노력조차 하지 않는 것이) 사람들이 완벽주..

우선 과제에서 요구하는 사항에 맞게 코드를 짰지만, 우선 코드가 작동을 함에도 아직 해결해야할 문제들이 무척이나 많아 보였다. 월요일 날 기준으로 해결해야 하는 문제들은 다음과 같았다. (모가 이렇게 많냐ㅠㅠㅠ) 1. 코드 위치들 옮기기, 패키지 조정해서 application 파일 크기 줄이기 2. 테스트 케이스 추가하기, 안되는 경우의 수 뭐가 있을지 고민하고 추가하기 3. 지금 통과 못하고 있는 테스트 케이스 추가하기 (runexception 예외처리 이해하기) 4. 리드미 체크하고 수정하기 5. 전반적으로 inline 맞추기 위해 단축키 통해 수정하기 6. 함수 이름 클라쓰에 맞게 중복된 건 없는지 확인하기 7. 15줄 이내인지 체크 8. 도메인 로직 설명 고려하기 9. 피어리뷰하기 개별적인 것들이..

You don't have to be great to start, but you have to start to be great.” by Zig Ziglar. 우선, 공통 피드백은 1주 차부터 다 잘 수행했는지 PR전에 마지막으로 확인하자...... 사실 1주차 피드백들을 보고 나서 너무나도 잘 알겠다 싶었던 내용들이 2주 차 PR을 할 때 급하게 과제를 마무리한다고 제대로 반영이 되지 못한 시간들이 있었다. 이런 시간들을 적극 개선하는 게 우선적으로 필요하다ㅠㅠ 2주 차 과제를 사실 처음에 구현할 때는, 그냥 주먹구구로 눈에 보이는 식으로 코딩을 했었고, 그 결과 main에서부터 제대로 프로그램이 실행되는 과정이 가시적으로 잘 보이지가 않았다. 이런 부분들을 개선하기 위해 전반적으로 코드를 다시 짰어야 ..

우선 무엇보다!!! 회고 글을 잘 써야 한다는 부담을 버리자. 중요한 것은 글을 예쁘고 멋지게 쓰고 공유하는 것이 아니라 나 스스로가 부족했던 부분들을 찾고 그 부분들을 보완하는 것이기 때문에!! 글은 매우 가볍게 핵심들만 쓰자. 결국 글도 나중에 refactoring하면 되는 것 아닌가!!ㅎㅎㅎ 1주 차 과제를 간신히 제출하고 나서 1주 차 공통 피드백을 받았는데, 그 피드백들이 정말 실제 코딩할 때 크게 필요하고 의미가 많은 부분들이라고 느껴져서 무척이나 새로웠다. 그중에서도 디테일이 빛나는 부분들이 있었는데 일부만 가져오면 다음과 같다. 1. 커밋 메세지를 유의미하게 작성하라. 이 부분은 2주차 피드백에서도 보다 더 디테일하게 컨벤션과 함께 제시가 되는데, 무척이나 와닿는 부분이었다. 그전까지는 사..

“Doubt kills more dreams than failure ever will.” 이런 지극히 개인적인 얘기를, 전부 나보다 잘하는 사람들만 그득한 것처럼 보여 합격할지도 모르는 상황에서, 전혀 모르는 사람들이 있는 커뮤니티에 공유한다는 것이 무척 부끄럽고 어색하지만....... 그럼에도 나와 같은 고민들을 분명 이번 코스를 준비하면서 많은 분들이 했을 것이라 생각하고, 나와 같은 고민을 한 분들께 "아 저런 사람도 있으니 나도 힘내 봐야겠다"는 작은 위로의 메시지가 되었으면 하는 작은 바람에 작게 공유해보아요:) 밀려오는 우선순위 속 오는 혼란....... 우테코를 지원하면서 솔직히 정말 많은 고민을 했다. 29살에 미필에 학부 문과, 대학원 공대 석사 졸업 예정으로 내년에 전문 연구요원으로서의..