유쾌하게 긍정적으로 유쾌하게 긍정적으로

삼호 미디어의 '니체의 말' 일부 인용했습니다. 창조적인 일을 할 때는 물론, 일상적인 일을 하는 경우에도 경쾌한 마음으로 임하면 순조롭게 잘 진행된다. 그것은 거침없이 비상하는 마음, 사소한 제한 따윈 염두에 두지 않는 자유로운 마음이 있기 때문이다. 천생 타고난 이 마음을 위축시키지 않고 지켜나감이 좋다. 그것으로 여러가지 일을 거뜬히 이룰 수 있는 사람이 될 수 있다. 그러나 본인 스스로가 경쾌한 마음을 가지고 있지 않다고 느낀다면 되도록 많은 지식과 만나고 많은 예술과 접하라. 그러면 그 마음에 서서히 경쾌함이 채워질 것이다.

개요 안드로이드의 프로세스는 Foreground와 Background로 나뉩니다. Foreground는 유저가 앱과 화면에서 인터랙션을 할 수 있는 상태입니다. Background는 유저가 앱과 화면에서 인터랙션 하지않아도 실행되는 상태입니다. 앱을 종료하는 방식은 두가지 입니다. 뒤로가기 해서 종료하거나, 모두 보기에서 앱을 날리는 두가지 경우입니다. 여기서 뒤로가기를 해서 앱을 종료하는 경우는 프로세스를 완전히 종료하는 것이 아니라 Background로 남기는 것입니다. 반면 모두 보기를 해서 종료하면 프로세스 자체가 종료가 되는 것이죠. 다운로드를 하거나 음악을 실행시키는 것과 같이, 앱은 다양한 이유로 Background에서 Task를 실행합니다. 안드로이드에서는 이러한 Background Tas..

문제 링크 : www.acmicpc.net/problem/14891 14891번: 톱니바퀴 첫째 줄에 1번 톱니바퀴의 상태, 둘째 줄에 2번 톱니바퀴의 상태, 셋째 줄에 3번 톱니바퀴의 상태, 넷째 줄에 4번 톱니바퀴의 상태가 주어진다. 상태는 8개의 정수로 이루어져 있고, 12시방향부터 www.acmicpc.net 풀이 각각 톱니가 8개가 있는 톱니바퀴 4개가 주어진다. 이를 회전시킬 때, 톱니가 어떻게 변하는지 계산하는 문제. 톱니를 회전하면 어떻게 데이터를 변경시킬지 고민해야하고, 한 톱니 바퀴를 회전시켰을 때, 맞닿는 톱니와 이에 대한 결과를 생각해야한다. 특히, 맞닿는 조건과 연쇄적으로 회전하는 부분에 대한 구현이 중요했다. 각각의 톱니가 회전하는 것은 동일하고, 톱니에 대한 데이터를 저장해야하..

정보 최창익 숭실대학교 글로벌미디어학부 18학번 네이버 웹툰 / Android Developer / 인턴 (2021.01 ~ 2021.02) 위플래닛 / Android Developer / 인턴 (2020.09 ~ 2020.12) 숭실대학교 IT 동아리 유어슈 안드로이드 개발자 YAPP 16기 안드로이드 개발자 디프만 8기 안드로이드 개발자 해병 부사관 (2013 ~ 2017) 활동 숭실대학교 IT대학 소프트웨어 공모전 / 안드로이드 앱 출품 / 금상 2020 Yourssu Connect Day / 객체지향적 설계와 아키텍처 강연 관심사 운동 농구 바이크 코딩 테스트 링크 github.com/ckddlr0610

개요 Java에서 상속을 받기 위해서는 두 가지 방법이 있는데요, 하나는 Abstract Class, 또 다른 하나는 Interface입니다. 하지만, 이 둘의 차이를 명확히 구분하기가 어렵다고 생각합니다. 예전부터 이 둘의 차이와 언제 사용해야 하는지에 대해서 궁금했었는데, 이번 포스팅을 작성하면서 정리하려고 합니다. 이펙티브 자바에서도 이와 관련한 토픽들이 있으니 찾아보면 도움이 될 것 같네요. Abstract Class와 Interface의 공통점 abstract class Animal { public abstract void attack(); public void move() { System.out.println("move!"); } } interface Talkable { public void ..

상태가 있는 모든 변수 및 데이터는 모든 상태를 고려해야한다. 모든 상태를 고려한 코드를 작성해야 안정적인 프로그램이 될 수 있다. 예외 처리를 상위 메소드에서 핸들링할지, 하위 메소드에서 핸들링할지 고민해라. 무분별하게 catch하면 코드가 더러워질 가능성이 있다.

- Pull Request는 받을 준비가 됐을 때 올리기. 완벽하게 준비하는건 비효율적일 수도 있겠지만, 되도록 진짜 받을 준비가 됐다고 판단이 설 때 Pull Request를 올리자 - 코드 리뷰를 받았을 때, 리뷰를 받은 부분만 수정할 것이 아니라, 한번 더 전체적으로 다시 검토를 하자. 리뷰를 해주는 사람 입장에서도 리뷰 후에 다시 리뷰를 할 때, 안보이던 것 이 보일 수 있다. - 리뷰는 최대 2번안에 끝내야할 것 같다. 처음 리뷰를 받은 후 다음 리뷰에서 새로운 내용을 받을 수 있다. 두번째까지는 그럴 수 있지만, 세번째부터는 신뢰에 마이너스를 준다고 생각된다. 신중하게, 확실하게 일을 끝낼 것.

- 콜백에 따라서 콜백함수를 어떻게 정의할 것인지. 가령, Response와 Failure로 결과가 나올 때, 각각의 결과에 따라 콜백 함수를 어떻게 정의할 것인지 고려해야함. - 기존에 잘 만들어진 객체를 활용하는 것이 중요함. 굳이 필요없는데 새로 만들 이유도 없다. - 코틀린에서 제공하는 api를 잘 활용하면 확실히 코드를 간결하게 작성이 가능하다. 이게 최선인지 항상 되묻기 - 분기를 통해서 조건에 대한 처리를 할 때, 조건에 대해서도 고민해봐야한다. 이 조건이 최선인지? 기능적으로 알맞은 조건인지에 대한 고민이 더 되면 좋을 듯 - 외부에서 주입받는 변수에 대해서는 항상 잘못 들어올 것을 고려해봐야한다. 이게 프로그램 내부적으로만 돌아가고 전달되는 변수라면 예외사항에 대해서 처리 안 할수도 있다..