일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- android
- 커스텀상태
- 알고리즘
- 회고
- Rxjava
- 테스트
- 자바
- 안드로이드스튜디오
- k8s
- Coroutine
- 책
- 스레드
- ReactiveProgramming
- 병렬프로그래밍
- g 단위테스트
- 디자인패턴
- 글또
- theming
- 코루틴
- Kotlin
- mockito
- 안드로이드강좌
- 알게되는
- Gradle
- Compose
- 코틀린
- 병럴프로그래밍
- kotlin강좌
- viewmodel
- 안드로이드
- Today
- Total
목록전체 글 (154)
선생님, 개발을 잘하고 싶어요.
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/b8qIBN/btruRNpBa5W/F5cuxzoDpvyJtKVkFsDZNK/img.png)
역할과 책임의 구분이 명확히 이해되지 않습니다. 작은 프로젝트나 쉽게 변경될 수 있는 서비스 코드, 특히 UI를 만드는 입장에서 역할 처럼 구현체의 Slot 처럼 동작하는 게 필요할지 의문입니다. 전체적으로 추상적인 내용이였다고 생각합니다만, 코드를 짤 때 역할, 책임, 협력을 좀 생각해보게 되는 것 같습니다. 아, 그나저나 협력의 과정에서 다른 객체에게 단순히 메시지를 보낸다는 개념은 너무 좋은 것 같습니다. 서버 객체 레벨에서 캡슐화를 얘기할 때는 감이 잘 안왔는데, 클라이언트 객체가 메시지를 보낸다는 개념을 생각하니 클라이언트 입장에서 서버의 세부 구현이 캡슐화 된 것이더군요. 객체지향 패러다임의 관점에서 핵심은 역할, 책임, 협력 (role, responsibility, collaboration)..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/b3e03c/btruG05MLcS/agnRVmQruItC0ZkNLxXxt1/img.png)
무조건 유연한 설계도, 무조건 읽기 쉬운 코드도 정답이 아니라고 합니다. 올바른 구현이라는 망령에 시달린 것 같습니다. 상황에 따라서 트레이드 오프를 적절히 취사선택 하며 개발할 줄 아는 개발자가 되어야겠습니다. 아직 이 책에서 말하는 "적절한 책임"이 무엇인지는 잘 모르겠습니다 영화 예매 시스템 객체지향 프로그래밍을 향해 클래스가 아닌 객체에 초점을 맞춰야 한다. 어떤 객체가 필요한지 고민하라. 협력하는 공동체의 일원으로 봐야 한다. 💡 객체, 협력으로 부터 클래스를 도출하라. 요구사항과 프로그램을 객체라는 동일한 관점에서 바라볼 수 있다. (도메인을 따르는 프로그램) 클래스를 구현하거나 사용할 때 가장 중요한 것은 클래스의 경계를 구분 짓는 것이다. 객체는 상태와 행동을 함께 가지는 복합적인 존재 스..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/kxDym/btruRNb3wdy/KekKFFa9saC8vEjSEFWXh0/img.png)
요즘 오브젝트라는 책을 읽는 중입니다. 한동안 방법론의 노예가 되서 생각 없이 아키텍쳐 공부를 하지 않았나 반성하게 되는 일이 많았는데, 그 때 마침 스터디 기회가 찾아와서 읽고 정리하는 중입니다. "적절한"이 너무 많이 나오는데... 적절한 객체에 적절한 책임은 도대체 무엇일까요? 이 책을 읽어보고 토론해보며 나만의 적절함을 알아갈 수 있으면 좋겠습니다. 이 책은 훌륭한 객체지향 프로그램을 설계하고 유지보수하는 데 필요한 원칙과 기법을 설명하기 위해서 쓰인 책이다. 훌륭한은 무슨 의미인가? 티켓 판매 애플리케이션 모듈의 목적 3가지 제대로 동작 간단하게 변경가능 특별한 훈련 없이도 개발자가 쉽게 읽고 이해가능 이해 가능한 코드 예상에서 크게 벗어나지 않는 코드 코드를 보는데 한꺼번에 기억해야하는 게 적..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/dTQvL4/btrusOKyP2u/TZBNHQSAHpJU5k8vmYVSvK/img.png)
val keyboardController = LocalSoftwareKeyboardController.current keyboardController?.hide()
안드로이드 styling 바로알기(theme vs style) 좋은 자료 공유 style은 Widget이 가지는 개별 attr에 대한 내용이다. (Single View에 적용) theme은 resource에 대한 semantic한 이름을 지정하는 내용이다. (App Level에 적용) theme이 interface라는 메타포가 좋았다. 코드를 작성할 때 interface 기반으로 작업하면 실제 구현체를 쉽게 교체할 수 있듯이 (일종의 OCP 처럼) theme attribute 기반으로 Widget을 설계하고, style을 구현하면 다른 resource set에 대해서 실제 값을 편하게 바꿀 수 있다. 노션에 정리한 거: https://greedy0110.notion.site/Android-Theme-Th..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/K4GC3/btrqMj8LxRu/jpKKYVAMMEjB5fSlksyXlK/img.png)
URL 기본구조 ://:@:/;?# scheme 리소스를 어떻게 접근하는가? 어떤 프로토콜을 사용하는가? (ex. http, https, ftp...) host, port 리소스에 접근할 수 있는 서버가 어디 있나? (www.greedy0110.tistory.com) path 리소스가 서버의 어디에 있는지 알려준다. 서버가 리소스의 위치를 찾는 데 사용하는 정보 / 로 구분 (https://.../path1/path2) parameter 앱이 서버에 정확한 요청을 하기 위해 필요한 입력 파라미터 ; 로 시작 query 리소스 형식의 범위를 좁히기 위한 정보 ?로 시작 (https://.../path?query1=hello) & 로 별도의 query 키값 구분 (https://.../path?query1=..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/bTcLd4/btrnB8bCAMW/nLjGIvY1XzRHeDXkAk0buk/img.png)
에러는 어디서 처리하는가? 다음 코드는 getImage가 에러를 던진다면 어떻게 될까요? fun main() = runBlocking { try { val deferredImage = scope.async { getImage("path") } deferredImage.await() } catch (e: Exception) { // ignore all exceptions } } kotlin 문서를 참조하면 async 내부에서 에러가 발생하는 경우 await 시점에 잡히기 때문에 getImage에서 발생한 에러는 위의 catch 구문에 의해서 처리되게 됩니다. 그렇다면 다음 코드는 어떻게 동작할까요? scope.launch { try { val deferredImage1 = async { getImage("..
선택 선택할 일이 너무나 많다. 샤워할 때 머리를 먼저 감을까 먼저 이를 닦을까, 점심은 무엇을 먹을까 같은 일상적인 선택도 있지만 한번 선택하면 일정 기간의 내 시간을 투자해야 하는 선택도 많다. 이 영어 강의를 들을까 말까, 저 모임에 가입할까 말까 하는 선택 말이다. 이번에 다음 회사를 찾으며 머릿속에서 이런 고민이 끝나지 않았다. "어떻게 하면 옳은 선택을 할 수 있을까?" 그래서 올해에 내가 했던 선택을 돌아봤다. 올해 한 선택들 졸업 프로젝트 꽤 숙고하고 결정한 일이었다. 기왕 학술 공부에 시간을 투자하는 거, 내가 생판 모르는 분야를 해보자고 생각했다. 그래서 소프트웨어 개발과 아예 관련 없는 영역을 골랐다. 정말 스트레스를 많이 받았고 시간을 낭비했다. 거의 반년의 시간을 내가 관심 없는 ..