Uing? Uing!!

9월에 입사하고 이제 한 달이 지났다. 입사 첫 날부터 재택근무에, 중간에 긴 추석 연휴까지 있어서 한 달이 지났는데도 아직 실감이 잘 안 난다. 첫 월급이 들어와서 부모님께 선물을 드리려고 포장까지 다 해 놨는데, 집에서 집밥 먹으며 노트북을 만지는 모습이 여전히 백수만 같아서 선뜻 드리지를 못하고 있다 ㅠㅠ 아직 재택으로 과제만 열심히 굴리고 있어서 회사생활이나 업무에 대해서 이야기하기엔 아직 한참 이른 것 같다. 대신 재택으로 근무하고 몇 번 출근하면서 느끼고 생각한 것들을 떠오르는 대로 나열해 보려고 한다. - 왠지 삐까뻔쩍하고 귀엽게 장식된 거대한 건물일 줄 알았는데 의외로 그냥 무난하게 생겼다. - 대신 내부는 끝내준다. 특히 휴게공간이랑, 팀별 업무공간들의 구획이 문 없이 개방적으로, 색감이..

서론 이전 글에서 언급했듯이 과제를 Fork하는 방법에 대해 고민하다가, 어찌어찌 Fork를 하고 작업을 시작했다. BUT, git과의 전쟁은 여기서 끝이 아니었다. 나는 또 이런 말을 듣게 된다. "작업한 내용은 PR 올려주시면 좋을 것 같아요." ? 그게 뭔데... 그거 어떻게 하는 건데... PR... PT같은 건가? 발표? 아 뭐지? 뭘 어떻게 준비해야 되는 거지? 응 그거 아니야 PR이 무엇인지에 대해 물어보면 이 정도도 모른다고 안 좋게 보실까봐 잠깐 고민했으나, git과 관련된 개념이라는 것조차 떠올리지 못했던 나는 구글에 검색할 키워드조차 알 수가 없었다. 결국 팀원분께 여쭈어 보아서 PR이 Pull Request라는 것을 알게 되었고, 이 Pull Request를 하는 구체적인 방법에 대..

서론 입사 직후에는 간단한 온라인(ㅠㅠ) 온보딩과 팀원분들과의 온라인(ㅠㅠ) 티타임이 있었다.그 이후에 내가 맡게 된 일은 실제 서비스에 적용되는 업무는 아니고, 트레이닝 목적의 두 달짜리 과제였다. 그런데 팀장님이 이렇게 말씀하셨다. "이 프로젝트를 개인 리포지토리로 Fork를 뜨고 Clone해서 Remote 브랜치로 작업하는 걸로 합시다." ? 그게 뭔데... 그거 어떻게 하는 건데... 깃을 개인적인 프로젝트 버전관리용으로만 간단하게 사용하던 나로서는 처음 들어보는 용어였다. 뭔가... Fork면... OS에서 새 프로세스 fork()하는 거랑 비슷한 맥락 같기도 하고... (대충 맞는 듯하다) 그럼 이거를... 원래 작업을 내 개인 저장소에 복사해서... 뭔가... 작업... 대충 뭔가 느낌은 왔..

꿈에 그리던 회사의 문턱 안으로 들어섰다.서류 등록부터 최종 면접까지는 총 5개의 절차가 있었고, 절차를 다 밟기까지는 무려 2달이라는 긴 시간이 걸렸다.매 절차마다 무언가를 준비했고 또 무언가를 배웠다. 그걸 잊지 않고자 이 글을 작성한다.(혹시라도 팀원분이 이 글을 발견하게 된다면 몹시 부끄러워질 것 같아서 기업명은 검색에 안 잡히게 줄였다.) 지원 계기8월 수료를 앞두고 5월쯤 취준을 시작했다.아직 수료까지 3달이 남은 데다, 수료하고 졸업을 미뤄도 되는 상황이어서 마음이 꽤 여유로웠던 것 같다.경력도 없는 주제에 새내기때부터 늘 꿈만 꾸던 기업의 경력 수시채용을 바로 기웃거렸으니 말이다. 홈페이지의 수시채용란에는 안드로이드 개발 관련 채용공고가 여러 개 올라와 있엇다.그중 몇몇은 내 관심분야와 맞..

사건의 발단 깃 브랜치를 옮겨 가면서 작업하고 있었는데, 어느 날 갑자기 빌드 에러가 떴다. No cached version listing for androidx.room:room-common:[2.2.0-rc01] available for offline mode. 오잉? 삽질의 과정 다시 한번 빌드도 해 보고, clean-rebuild도 해 보고, 스튜디오도 껐다 켜 보고, 브랜치도 다시 옮겨 보았지만, 똑같았다. 결국 아래 StackOverflow 답변을 참고하여 해결했다. stackoverflow.com/questions/22607661/no-cached-version-available-for-offline-mode 삽질의 결과 1. View -> Tool Windows -> Gradle 2. to..

빈 문자열 확인 코틀린으로 문자열을 활용하다 보면 이 문자열이 빈 문자열인지 아닌지 확인해야 할 경우가 있다. 빈 문자열을 확인할 때에는 isEmpty() 또는 isBlank()를 사용할 수 있다. someString.isEmpty() someString.isBlank() 두 메소드는 비슷해 보이지만 미묘하게 차이점이 있다. isEmpty() isEmpty()는 특정 문자열이 ""인지 아닌지를 확인한다. val s1 = "" s1.isEmpty() // true val s2 = " " s2.isEmpty() // false 따라서, 위의 두 문자열 중 s2는 empty하지 않다는 결과를 돌려준다. isBlank() isBlank()는 특정 문자열이 비어 있거나, 또는 공백으로만 이루어져 있는지를 확인한다..

늦은 초기화 가끔 클래스 안에서 '내가 이 변수를 쓸 것이다'라고 선언만 해 놓고, 나중에 값을 사용할 수 있게 되면 그 때 값을 입력해 주고 싶을 때가 있다. 이럴 때 사용 가능한 방법 중에는 아래와 같이 일단 null로 설정해 준 뒤 나중에 바꾸는 방법이 있기는 하다. var x : String? = null 하지만 두 가지, 마음에 걸리는 상황이 생길 수 있다. 1) x의 값이 변할 수는 있지만, 절대 null이어서는 안 되는 경우 -> 처음에 nullable한 으로 초기화해주는 것이 부적절함 2) x의 값이 처음 한 번만 정해지면 다시는 변하지 않는 경우 -> x가 var일 이유가 없음 애초에 '나중에 쓸 것'이라는 걸 알고 있는데, '왜 처음에 null로 고정을 해 주어야 하냐?' 라는 문제다...

서론 작업을 하다가 여태까지 계정을 제대로 설정하지 않은 상태로 잔뜩 push했다는 것을 깨달았다. 계정 정보가 잘못되어 다른 서비스로의 연동이 되지 않는 상황이었다. 결국 적절한 이름과 계정으로 여태까지의 commit들을 수정하게 되었다. 방법은 이전에 올렸던 'Git push 이후에 커밋 메시지를 수정하고 싶을 때'와 상당히 비슷하다. (그래서 이전 게시글을 복붙해서 몇 부분만 수정하였다 ㅎㅎ) 본론 1. 커맨드 창에서 rebase를 사용해 수정 모드로 들어간다. 아래 줄은 '바로 직전'의 commit을 수정하고 싶을 때의 예시이다. 만약 바로 직전이 아닌 조금 더 전의 내용을 수정하고 싶다면 HEAD~2, HEAD~3처럼 HEAD~{지금보다 몇 번째 전의 commit부터 수정할지} 식으로 입력하면 ..