[책] 채식주의자

채식주의자

2016년 5월 미국에 가면서 공항에서 구입한 책이다.
미국에 있는동안에는 한페이지도 읽지 않았다.
한국에 와서도 12월이 다되어서야 읽기 시작한 책이다.

책에서 손을 놓은지 오래되서인지
아니면 공감이 어려운 이야기여서 그런지
집중해서 읽기가 굉장히 어렵다고 느껴졌다.

처음엔 단편 소설집인가 했는데
실려있는 세 이야기가 모두 연관된 하나의 이야기였다.

왜 그녀는 그런 꿈을 꾸었을까.
왜 그는 그녀를 품고 싶었을까.
왜 그녀는 그녀를 포기하지 못했을까.

그녀가 누굴 말하고자 하는지
그는 누구를 대표하는지
아니면 그런게 있긴 한건지

나에겐 너무 어렵다.

* 해설은 특히나 더 어렵다. 일부러 작정하고 그렇게 쓰는 건지도.

[책] 그림으로 그리는 생각정리기술

http://book.naver.com/bookdb/review.nhn?bid=6366513

예전 윤선이가 양재에서 근무하던 시절 퇴근후에 사당에서 만나곤 했다. 해산물뷔페에 가서 배가 터져라 먹어댄 후에 지하에 있는 반디앤루니스 서점에 가서 이것 저것 책을 구경하곤 했다.

이 책은 그 때 샀던 책인데 이제야 읽어 보았다.
올해에는 꼭 그림을 내 생각을 잘 정리하는 방법을 몸으로 익혀야 겠다고 생각했는데, 우연히 이 책을 샀던 게 기억이 나서 찾아보니 책장에 고이 모셔져 있었다.

빠르게 읽어 보았는데 기본적인 내용이 잘 설명되어 있고, 그림이 많이 있어서 쉽게 읽을 수 있는 책이다.
그림을 잘 그려야 할 필요가 없다고 얘기하고 습관처럼 하는 게 중요하다고 말한다. 연습을 많이 해서 몸이 기억되게 하는 게 중요한 것 같다. UML 도 결국 코드(글자)를 그림으로 표현하는 방법에 대해서 표준을 만들어 놓은 것이다. 결국엔 다 같은 내용이다. 내가 하는 일에도 도움이 많이 되고 내 생각을 명확히 정리하고, 표현하는데 많은 도움이 될 수 있을 것 같다.

연습! 또 연습!
못나보이고 글씨를 못써서 지저분해도 계속 그림으로 표현해보자.
첫술에 배부를 수 없다.

아래 내용도 비슷한 내용이다. conference 의 강연 내용을 sketch note 로 정리.
나도 저런 경지에 올라야 할 텐데.

http://blog.sqisland.com/2015/03/sketchnoting-an-engineers-approach.html

[책] functional thinking

언제부터 읽기 시작했는지 모르겠다. 꽤 오랫동안 가방에 넣어가지고 다녔다.

함수형 방식으로 코딩하는 방법을 여러 언어를 통해서 설명한다. 

스칼라나 클로져에 대한 지식이 없어서 보기가 어려웠다. 

읽고 나면 머릿속이 functional 하게 바뀌어 있을까 기대했지만..허허허

함수형 언어, 폴리그랏등에 대한 어렴풋한 개념이 머릿속에 큰 덩어리처럼 자리잡힌다고 할까...함수형 언어에 대해서 더 공부해야겠다는 생각을 들게 만든 책이다.

좀 더 집중해서 읽어야 겠다는 생각도 들게 만든 책.

힘들게 힘들게 마지막 장을 넘겼다. 

그래서 약간은 뿌듯하기도 하다.

2016년에 읽으려고 했던 것들

2016년은 아주 의미있는 해가 될 수도 있었다. 그럴수도 있었다.
왜인지 모르겠는데 제대로 읽은 책이 거의 없다. 읽으려고 시도한 책도 몇권 안되는데다가, 끝까지 읽은 책은 기억에 없다. 뒤죽박죽으로 뭔가 책들이 생각이 날듯하면서도 기억나지 않는다. 아마도 2015년이나 2014년의 기억이 뒤섞여 있나보다.
한해가 지날때마다 딱히 기념하거나 정리하지 않아서 머릿속에서도 년도의 구분이 없나 보다.
그래서 올해와 작년은 구분하기로 하자. 작년에 읽으려고 시도했던 책들을 나열하는 것으로...

1. 틀리지 않는 법
1. 수학자의 시선으로 사회 현상을 분석한 칼럼 모음집
2. 신문에 나오는 통계를 올바르게 해석하는 것에 대한 글이 있었던 것은 기억에 난다.
2. 아내를 모자로 착각한 남자
1. 추석에 처가쪽 식구들과 여행을 가는 길에 공항에서 구입한 책
2. 심리학쪽에서는 워낙 유명한 책이라 그 전부터 읽고 싶었던 책
3. 한 챕터도 제대로 읽지 않은 책
4. 막상 읽어보니 재미가...
3. 하스켈로 배우는 함수형 프로그래밍
1. 출/퇴근길에 지하철에서 읽은 책
2. 모나드부터 너무 어려워 위키부터 먼저 봐야지 하고 손을 놓은 책
3. 인터넷으로 공부할테다.
4. 고양이와 할아버지
1. 일본, 만화책
2. 고양이를 키우는 시골 할아버지의 이야기
3. 할머니를 여의고 홀로 살아가는 할아버지
4. 가상의 일본 시골 마을
5. 딱 봐도 일본 만화
6. 얇은.. 그래서 유일하게 다 읽은 책
5. 블러드 차일드
1. 작년 구입한 유일한 해외 SF 번역본
2. 동대문의 현대아울렛의 조그만 서점에서 구입한 것으로 추정
3. 미국, 흑인, 여성 작가의 SF
4. 내가 좋아하는 SF 단편집
5. 단편 2개쯤 읽었나... 다 읽긴 어렵다.
6. 가장 빨리 만나는 자바8
1. 굉장히 오랫동안 가방에 넣고 다닌 책
2. 다 못읽었다.
3. 이제 다시 보면 다 볼 수 있을 거 같다.
7. 바이블 스토리
1. 성경, 만화책
2. 프랑스 유대인 작가, 원래는 천문학자
3. 구약을 자기의 주관적인 해석을 겯들여서 주관적으로 그림
4. 야한 그림도 조금... 원래 구약에 야한 내용이 좀...
5. 2016년 초에 읽은 건지 2015년에 읽은 건지 헷갈리는...
6. 무튼, 전체적으로 재미있음
8. 채식주의자
1. 6월달 미국에 갈때 공항에서 사고
2. 지금 읽고 있는 책
3. 맨부커상
4. 재미있는지...

채식주의자를 읽으며 느끼는 거지만, 주의력/집중력 결핍인지 소설의 이야기에 빠져들지 못하고 자꾸 주변 것들에 신경이 쓰인다. 

TV를 켜놔서 일까. 

나이가 들어 집중력이 떨어져서 일까. 

sns 를 많이 해서 긴 글을 보지 못하는 걸까.

올해는 꼭 더 많은 책을 읽으리라.

Immutability

Converter utility class 에서 convert table 에 대한 immutable collection을 사용하는 게 필요한지, 필요하다면 왜 필요한지 검토해 볼까한다. 제대로 결론이 나올지 모르겠지만...

converter utility class 란?

health project에서 clean architecture(onion architecture) 를 적용하면서 각 layer 간의 data type 변환을 위해서 만들어 놓은 utility class 이다.
일반적으로 다음과 같은 형태를 가진다.

class XXXConverter {
   final Map<A, B> XXXMap = Map.create().put(a, b).put(a1, b1).put(a2, b2);

   B convert(A a) {
       return XXXMap.get(a);
   }

   A convert(B b) {
       return XXXMap.reverse().get(b); // guava bimap 사용시
   }
}

health project의 production code 에서는 Map<A, B> 대신에 Guava library 의 ImmutableMap / ImmutableBiMap 을 이용하여 코드가 작성되어 있다.

Guava ImmutableCollections

Guava library 에서 설명하는 guava 의 immutable objcet 의 장점은 아래와 같다.
(https://github.com/google/guava/wiki/ImmutableCollectionsExplained)

• Safe for use by untrusted libraries.
• Thread-safe: can be used by many threads with no risk of race conditions.
• Doesn't need to support mutation, and can make time and space savings with that assumption. All immutable collection implementations are more memory-efficient than their mutable siblings (analysis)
• Can be used as a constant, with the expectation that it will remain fixed

이에 비해서 jdk 에서 제공하는 Collections.unmodifibleXXX() 는 다음과 같은 단점이 있다고 한다.

• unwieldy and verbose; unpleasant to use everywhere you want to make defensive copies
• unsafe: the returned collections are only truly immutable if nobody holds a reference to the original collection
• inefficient: the data structures still have all the overhead of mutable collections, including concurrent modification checks, extra space in hash tables, etc.

Converter에서 ImmutableCollections

다시 converter 로 돌아와서 converter 에서 ImmutableMap 을 사용하는 게 의미가 있을까?

내가 내린 결론은,

Converter 목적상으로는 사용의 의미가 없다. 해당 map 을 copy 해서 사용할 이유도 없고 외부에 open 할 이유도 없다. 단순히 Converter class 내에서 matching table 역할만 하기 때문에 동작중에 내용이 변경되지 않는다고 가정할 수 있다.(100%???) matching table 의 크기도 크지 않기 때문에 속도나 메모리의 잇점도 크지 않다. 따라서 반드시 사용할 이유는 없어 보인다. Collections.unmodifiableXXX() 만으로도 충분하다. 

게다가 Guava 사용시에 proguard 사용하지 않으면, method 갯수 limit 도 신경써야 한다.(이 부분은 guava 에서는 android에서는 proguard 사용을 당연히 가정하기 때문에 문제 안되는다고 명시되어 있다. proguard 를 잘 적용하면 문제 안되겠지...)

Immutable Object

http://www.ibm.com/developerworks/java/library/j-ft4/index.html

Immutable object 를 어떻게 만드는지 설명하고 있다. Immutability 는 functional programming 에서는 가장 강조하는 개념(?)이다. multi-thread 환경에 가장 강점을 발휘한다. java 에서 immutable object 를 만들기 위해서는 아래와 같이 한다.

- 모든 member 를 final 로 지정하고,
- class 도 final 로 지정한다.
- 최소 1개의 constructor 를 제공
- no-argument constructor 는 제공하지 않는다.
- setter 를 제공하지 않는다.
- you need to make sure you defensively copy any object references you return from getXXX methods

< Immutable Address class >

public final class Address {
    private final String name;
    private final List<String> streets;
    private final String city;
    private final String state;
    private final String zip;

    public Address(String name, List<String> streets, 
                   String city, String state, String zip) {
        this.name = name;
        this.streets = streets;
        this.city = city;
        this.state = state;
        this.zip = zip;
    }

    public String getName() {
        return name;
    }

    public List<String> getStreets() {
        return Collections.unmodifiableList(streets);
    }

    public String getCity() {
        return city;
    }

    public String getState() {
        return state;
    }

    public String getZip() {
        return zip;
    }
}

장점

- Immutable classes make a host of typically worrisome things in Java go away.

- Immutable objects are also automatically thread-safe and have no synchronization issues.

- one of the best features of immutable classes is how well they fit into the composition abstraction.

from wikipedia(https://en.wikipedia.org/wiki/Immutable_object#Java)

final MyObject m = new MyObject(); //m is of reference type
m.data = 100; // OK. We can change state of object m (m is mutable and final doesn't change this fact)
m = new MyObject(); // does not compile. m is final so can't be reassigned

Google AutoValue

https://github.com/google/auto/tree/master/value

Generated immutable value classes for Java 1.6+ Kevin Bourrillion, Éamonn McManus Google, Inc.

원본 code :
https://github.com/google/auto/blob/master/value/userguide/builders.md

generated code :
https://github.com/google/auto/blob/master/value/userguide/generated-builder-example.md

최종 결론

Immutable 은 좋은 것이여!

Converter 에서도 쓰고, 모든 곳에서 사용하자. 

극단으로 사용해서 습관화하자.(??)

덧붙임.
Immutable class 를 많이 사용하면 GC 가 많이 돌수도 있다는 우려도 있다.
객관적인 자료는 없지만, 엄청나게 큰 시스템이 아니면 지금과 같은 h/w 사양에서 크게 문제가 되지는 않을 것 같다.
언어적으로는 memoization이 이런 문제에 대한 해결책 같은 걸까? 아니면 다른 개념인가...

[WebApp] google fit imitation 만들어 보기 - 4

개요

Google fit api 를 활용한 hybrid app 개발

목적

- web app 구조를 학습한다.
- hybrid app 의 구조를 학습
- html/javascript 기본 학습

Source :

https://github.com/tigerbalm/my-google-fit2

Component diagram

PNG |  SVG |  TXT |  Edit

 

Screen flow

 

HTML page structure

webapp 에서는 하나의 html 내에서 여러 page 를 처리한다.
resource loading 문제등의 이유로 하나의 html 내에서 처리하기를 권장하는 사람도 있다.
html 내에 여러 page 가 있기 때문에 html 자체가 매우 복잡해지고 가독성도 많이 떨어진다. boiler code 가 많기 때문에 html 당 하나의 page 는 효율이 떨어진다.
적절하게 html수와 page 수를 조절하는 게 필요하다.

 

Android mock

처음 작업할때는 android studio에서 작업해서 phone 이나 emulator 에 띄워서 html/javascript test 했다. 한번 build 해서 올리고 logcat 으로 확인하고 debugging 하는 게 생각보다 시간도 걸리고 귀찮은 작업이다. 어차피 html/javascript 이니 PC 상에서 작업하고, PC browser 에서 바로 확인하는 방법을 아래와 같이 사용했다. UI 작업은 많이 편해지고, chrome/firefox 의 개발자모드에서 바로 log 등을 확인할 수 있는 장점도 있다.
<< index.html / detail.html header  >>


<< androidmock.js >>

<< index.html >>

javascript <-> java code call

<index.html>

PNG |  SVG |  TXT |  Edit

<index.html>

PNG |  SVG |  TXT |  Edit

JSON data

Today's total data

[
    {
    "value" : 300,
    "color" : "#F7464A"
    "highlight" : "#FF5A5E"
    "label" : "Walking"
    }, 
    {
    :
    }
]

Workout List

[
    { "date" : "3/8", "steps" : 450 },
    { "date" : "3/7", "steps" : 450 },
    { "date" : "3/6", "steps" : 450 },
    :
] 

Workout daily detail
[
    { "time": 6, "steps": 456, "calories": 62,  "distance": 0.1 },
    { "time": 7, "steps": 56, "calories": 12,  "distance": 0.01 },
    { "time": 8, "steps": 106, "calories": 30,  "distance": 0.02 },
    :
]

사용한 library

Chart.js(http://www.chartjs.org/)
Timber
RxFit(X)

결론

- javascript의 기본 문법은 쉽다. -> debugging 은 어려움
- html/javascript/css/webview framework 자체에 대한 학습 시간이 필요
- UI 부분은 재사용이 가능할 수 있을 것 같다.
- 하지만, 단순한 UI 인 경우에는 native 로 platform 별로 각각 만드는 거나 html 사용하는 거나 차이가 있을까.
- hybrid 방식으로 구현된 open source app 을 찾기 어렵다. -> 많이 사용하지 않는 방식??
- hybrid 방식이 아닌 순수한 webapp 의 경우에는 차이가 있을 수도 있으니, 순수 webapp 구조를 생각해보는 것도 방법

[WebApp] google fit imitation 만들어 보기 - 3

Java native 코드와 JavaScript 코드사이의 interface 가 필요하다.
java script 의 argument 는 json 으로 받을 수 있으니 native 와 script 간의 data 는 json 형식으로 한다.

https://github.com/tigerbalm/my-google-fit2

PNG |  SVG |  TXT |  Edit