Uing? Uing!!

서론 삼성서울병원에서 코로나19 검사를 받았다. 이번이 두 번째이고, 두 번 다 자발적인 검사로 진행했다. 한 번도 위험지역에 가지 않았으며, 확진자 접촉도 없었으며, 문제가 되는 교회의 교인도 아니다. 그저 가족 중 의료인이 있어서 혹시라도 환자분들께 피해가 갈까봐 하루이틀 열이 나면 검사를 받았다. 두 번의 검사 전후로 후기를 검색해 보았는데, 검사대상자 입장에서의 주관적인 정보를 얻기가 의외로 힘들었다. 나처럼 대학병원에서의 코로나 검사 과정이 궁금하실 분들을 위해 후기를 남기기로 했다. 첫번째 검사(3월) 첫 검사는 지난 3월이었다. 1월 말에서 2월 초에 유럽에 다녀왔는데 귀국하자마자 유럽에서 코로나로 난리가 났다. 그리고 3월 초에 갑자기 38도정도로 열이 올랐다. 귀국 후 최대한 약속도 잡지..

서론 나는 SourceTree를 이용해서 git 관리를 한다. Git은 버전관리하기가 참 좋은 것 같다. 버전관리를 하는 방법은 다양하겠지만, 나 같은 경우에는 작은 기능 하나를 추가할 때마다 커밋&푸시를 한다. 본론 개인적인 드라이브처럼 쓰다 보니 commit&push를 한 번에 하다 보니, push 이후에서야 커밋 메시지를 잘못 입력했다는 것을 알게 되는 경우가 있다. 오늘 같은 경우가 그렇다. 개인적인 프로젝트를 제작하는 중에 map 기능을 추가했다. 그리고 작은 에러가 발생해서 이 에러를 잡은 뒤에 'remove map duplicate error'라는 메시지로 커밋을 했다. 푸시 이후에 깨달았다. 으악! 'add map' 이후에 커밋을 안 했다. 추가한 기록도 없는 기능에서 에러를 잡았다고 메시..

나는 이 블로그를 2012년에 만들어서, 2017년에 처음 글다운 글을 썼고, 2019년에서야 정착하기로 마음먹었다. 구버전 에디터에 대한 기억은 어렴풋하다. 지금 새로 작성하는 글들은 기본적으로는 구버전으로 작성할 수 없게 되어 있는 듯하다. 하지만 그 당시 작성한 글들을 수정하려 하면 구버전 에디터가 나타난다. 신버전 에디터는 정말 깔끔하고 예쁘지만, 아직까지는 몇몇 단점들이 있는 것 같다. 개인적으로 느낀 장단점들에 대해서 글을 작성하고자 한다. 새 에디터의 장점 1. 깔끔한 UI : 깔끔하고 예쁘다. 처음 에디터 화면에 들어온 감상이다. 이전 버전과 비교했을때 UI가 이렇게 다르다. 확실히 옛날 버전에 비해 보기 좋고 세련되면서 화면에 착 감긴다는 느낌이 든다. 2. 간결한 UX : 직관적이고 학..

소프트키와 화면 변화 EditText는 정말 빈번하게 사용되는 뷰이다. 이 EditText를 터치하면 키보드(소프트키)가 화면 하단에서 나타난다. 그런데 가끔, 이 소프트키가 화면을 가리는 경우가 있다. 아래와 같은 상황이 그 예시이다. (가장 처음으로 만들었던 '지나가리라'라는 어플리케이션의 화면이다.) 가장 왼 쪽의 레이아웃에서 키보드가 나오더라도 맨 오른쪽처럼 버튼을 유지하고 싶은데, 가운데의 스크린샷처럼 화면을 반쯤 가리면서 필요한 뷰들이 숨어 버린다. 앗 재난문자가 windowSoftInputMode windowSoftInputMode를 이용하면 키보드가 나타나고 사라졌을 때의 화면 변화 방식을 지정해 줄 수 있다. 가장 대표적인 설정값은 "adjustResize"이다. 이 값은 소프트키가 올라..

사건의 발단 지난 달, openCV를 활용해 이미지처리 기능을 구현하고 있었다. 이미지처리 과정이 상당히 복잡해서, Core 연산이 아주 많이 들어갔다. 메서드 여러 개로 나누어서 작업하고 있는데도 한 메서드가 몇백 줄이 넘어가는 길이였다. 연산이 복잡하기 때문에 어떤 줄에서 초 단위로 느려지는지 눈으로 확인하고 싶었다. 안드로이드 스튜디오의 프로파일러를 활용하면 큰 틀에서의 네트워크나 메서드 단위는 확인할 수 있지만, 한 줄 한 줄의 실행속도를 측정하는 것은 어려워 보였다. 삽질의 과정 그래서 직접 코드로 실행 시간을 확인하기로 했다. 처음에는 일반 예제에서 많이 하듯이 System.currentTimeMillis()만을 활용해 보려고 시도했다. prevTime과 curTime이라는 Long타입의 변수..

사건의 발단 기존에 생각하고 있던 개인 SNS 프로젝트를 시작하려고 기본 틀을 잡는 중이었다. 서버사이드를 따로 배워서 시작하자니 기간이 오래 걸릴 것 같아 우선 많이들 사용한다는 Firebase를 써보기로 했다. 내가 예상한 공부 순서는 이랬다. 1. Firebase 활용 예제에 대한 강의를 수강한다. 2. 기본 틀을 새로운 프로젝트로 옮긴다. 3. 코드를 다시 한 번 보면서 꼼꼼히 이해한다. 4. 열심히 손으로 구조를 짜본다. (이 부분은 오래 걸릴 것 같은데 이동안 포스팅은 어떻게 하지? 헤헤) 5. 4에서 작성한 내용의 화면 단을 제작한다. 6. 데이터베이스 기능들을 하나씩 추가한다. 오늘은 2번 단계를 마쳤다. 그리고 이 과정에서 이런저런 사소한 문제들이 발생했다. 대부분은 간단한 방법으로 해결..

스플래시(Splash) 화면과 그 목적 스플래시 화면은 앱의 본격적인 화면이 나오기 전에 1~2초 간 잠시 나타나는 화면이다. 일반적으로 단색 배경에 어플리케이션의 로고가 중앙에 표시되는 경우가 많다. 이 화면은 왜 필요한 걸까? 일단 디자인적인 이유가 있을 수 있다. 브랜드나 앱 이미지를 각인시키기 위해서. 하지만 Splash 화면의 주 목적은 따로 있다. 스플래시 화면이 없는 어플리케이션을 열어 보면, 메인 화면이 표시되기 전에 0.x초동안 텅 빈 화면이 나타난다. 짧은 시간이지만 이렇게 텅 빈 화면이 나타나는 것은 분명히 보기 좋은 현상은 아니다. Splash 화면은 이러한 공백을 채우기 위해 제작된다. Q. 왜 빈 화면이 뜨는 것일까? 공백을 지우기 위해 Splash를 만들기 전에, 이 공백은 왜..

빅 오 표기법(Big-O notation)의 정의Big-O(또는 Big-Oh) notation은 알고리즘의 시간 복잡도를 나타내는 표기법이며, O(f(n))으로 나타낸다. 알고리즘의 시간 복잡도알고리즘의 복잡도를 판단하는 척도로는 시간 복잡도와 공간 복잡도 두 가지가 있는데, 빅 오 표기법은 시간 복잡도를 다룬다. 당연하게도 알고리즘은 연산이 많아질수록 그 속도가 오래 걸린다. 따라서 시간 복잡도는 알고리즘 내 연산의 횟수와 관계가 있다. 가령 아래의 코드를 보면, 바깥 루프의 1부터 n까지의 각 i에 대해서, 안쪽 루프를 i번씩 방문한다.즉 i가 1일 때 1번, 2일 때 2번, 3일 때 3번...n일 때 n번 result++;를 방문하게 된다. 그런데 이 코드는 사실 루프 내에서 총 ∑i번이나 ++연산..