삽질 중: 7월 2017

2017년 7월 22일 토요일

Tech-HR Conference 참석 후기

Tech-HR Conference에 다녀옴.
처음 페북에 광고가 많이 뜨길래 뭔가 낚는 행사인가 했었다. 좀 찾아보니 okjsp에서 준비한 행사 같더라.

내용에 개발자와 HR에 대해 다루고 있어 기존 개발자 행사와는 좀 차이가 있어 보였고 개발자의 진로?에 대해서도 다루고 있어 흥미를 느끼게 되었다.

토요일 오전임에도 불구하고 많은 사람이 참석해서 좀 놀랐고 대부분 세션이 꽤 나에게는 유익했었고 전체적으로 보기에 주니어 개발자나 갓 시니어 개발자 급이된 사람들에게 유익했을 것으로 생각한다.

나는 두 번째 "주니어 개발자와 시니어 개발자의 차이" 세션이 꽤 유익했었고 나이만 먹은 나에게는 반성의 기회와 아직 시니어로 지칭 되기에는 부족한 점이 많은 것을 깨닫는 기회를 제공해 주었다.
또한 첫 번째 세션인 "성공하는 개발자"에서 개발자의 qualificatiom의 항목들을 제시한 것과 각 개발자이 이 항목들에 대해 어느 수준인지 지속적인 확인이 필요하다는 부분도 인상 깊었었다.

다음은 듣다가 괜찮은 부분들을 대충 정리한 내용이니 자세한 것은 나중에 공개될 동영상을 확인하자.

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ《Successful Software Developer / 성공하는 개발자》박종천

인사 시스템
- attract : 매력으로끌어모임
- develop : 회사에 맞춰 교육
- engage : 투입
- 이런 과정이 일련의 절차로 이어 진다.

Hiring
. Why this compamy?
. Why you?
. What you can do?

. Smart. Diligent. Good will

. Team interview시 싫어하는 사람이 있으면 채용 불가. 하지만 좋아하는 사람도 있어야 채용이 될 것임.

☆☆☆Performance review
. Productivity
. Professionalism - reliability
. Teamwork - communication
. Knowledge (domain, generic)
. Functionality - no defect
. Implementation -good code
. Design & architecture

자신에 대해서 평가해보고 다른 사람 중 잘하는 사람들을 분석하고 자신을 개발하라.

One on One
. Performance
. Growth (공부하는것보다 시장의 기대치가 올라간다.)
. Happiness

Short term goal - 1/3/5 years

Potentials vs capacity
: 잠재 능력에 다가가기 위해 capacity를 높여야한다.
실패를 통해서도 늘릴 수 있다.

쉬운일을 선택하면 끝이 없다.
어려운일을 선택해야 나중에 선택지가 있다.

하고 있는 일 외 밖의 새로운 것들을 공부하고
하기 싫은 분야도 찾아서 공부하라.
어렵고 힘든일들이 사람을 성공 시킨다.

Happiness
. What you like
. What you are good at
. What do you want to do.

STEM 에 관심을 기울여야
: Science
: Technology
: Engineering
: Mathematics

기초를 다져라
. Critical thinking을 하는 습관을 가지자.
답을 말하되 왜 질문을 할까? 다음에는 어떤 질문은? 등의 고민을 하여 생각을 넖혀라

Talent Practice Chance
능력과 재능을 기반하여 노력을 해야 기회가 올 때 대비할 수 있다.

어떤일을 함에 있어 끈기가 필요하다.

개발자가 갖추어야할 9가지 기술
https://youtu.be/fHyTA-UIcqs

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
11:00《주니어 개발자와 시니어 개발자의 차이》김범준

Senior 개발자는 누구인가?
!=. 대부분 나이.연차를 말하는데 연차만 많은 것은 아님
!=. 1년의 경험을 반복한 개발자도 아님
. 10년동안 다양한 경험을 통해 성장한 개발자

1만 시간의 법칙 => 단 의도적인 수련(deliberate pratice) 필요.

의도적 수련은
1. 학습을 하기위한 목적
2. 적절한 피드백

업무 처리는 학습을 위한 수행을 하는 것이 아니라 빨리 업무를 해결하기 위한 방법일 수 있음

루틴한일을 그냥 해내는 것 보다
뭔가 개선을 위한 일들을 찾아서 하는 거나
자신에게 패널티를 줘서 단련을 하는 것도 방법

Senior 실력이 뛰어난 개발자 = 실력이란 일을 되게끔 하는 사람

Junior. Senior
일 단위. Task. Projects
결과물. 코드.문서. 실질적 성과
관리. 일정. 일정 risk

우아한 형제들 기술 조직
> 코드 덩어리가 아닌 가치를 만들고
스스로의 가치를 높이며 일한다.

긍정적인 사람은 한계가 없고
부정적인 사람은 한 게 없다.

Senior
일 잘하는 사람 > 시니어의 일 = 팀의 일과 성과

시니어의 성장은
테크니컬 성장으로만 국한되는 것이 아니다.

시니어는 누구를 이끌어주는 역할이다.

Senior
. 자신의 경험을 나눠줄 수 있고
. 그를 통해 동료들을 변화시킬 수 있으며
. 변화가 회사의 성과로 이어지게끔 하는 사람

덕목
. 의도적 수련을 통한 발전에 익숙하고
. 코드가 아닌 가치를 만드어 낼 수 있으며
. 동료를 변화시키고 성과로 이어지게하는 것이 필요.

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
《스타트업에서의 HR과 스타트업 조직문화》안민호

직급호칭 > 수평 문화 > 빠른 의사 결과의 문제
: 영어 호칭이 의사 소통 측면에서는 편하다.

스타트업 팀원들의 오너쉽
: 실제로 오너가 되어야 한다. 지분? 돈
: 스타트업에서는 안식 휴가 제도? 스톡옵션? 도 방법이 되겠지만 실제 회사의 가치. 환경. 복지를 잘 갖추는게 방법임.

채용은 신중히 해야한다.
뽑고 나면 퇴직이 어려울 수 있음.
해외는 이미 다단계 면접을 흐고 있고 국내 몇몇 업체도 진행 중이다.

빠르게 망하는 조직이 성공한다.
다양한 일을 해보고 변화에 유연해지는 것이 필요.

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
《왜 우리는 개발자에 집중하지 않는가?》이민석

https://www.slideshare.net/mobile/MinsukLee/ss-78137490?from_m_app=ios

소프트웨어 = 업을위한 도구가 아닌 가치로 바뀜

미국의 경우에서
1. 개발자에게 중요한 것은
. 새로운 기술 습득, 새로운 것 만들기, 제품의 결정권, 회사의 방향성 등등

2. 이직 시 고려할 때 중요한 것은
. 연봉, 일과 균형, 기업문화, 회사 동료, 유연근무

3. 미국에서의 주당 업무외 토딩 시간
70%가 1ㅡ10시간임.
0시간은 15% 밖에 안됨. 뭐라도 다들 하고 있음

4. 구직 활동을 원하는 사람은 75%

현재 HR은 기존 대기업 출신의 HR인 경우가 많고 기존 방식의 인력관리를 하고 있는게 문제다.

줄세우기 보다는 상호평가가 적절하다.
HR은 개발자들이 힘들고 어련운 상황에서 일을 할 때 도와줄 수 있어야 한다.

HR의 필요 인력.기준은 계속 변화하고 있음.
기존 94년에는 65명 기준에서 15년 10-15명 기준까지로 변화하였음

사장은 일을 선택하기 보다 누군가를 실망시키는 일을 하는 것임.
CTO는 개발자들이 어느 영역에 집중할지를 결정해야한다.
개발자는 개발에 집증해야 한다
집중은 개빌자에게 해야한다.

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
15:30《개발자 공부론》김창준

http://mindscale.kr/course/how-to-learn-prg?utm_source=bl&utm_medium=post&utm_campaign=htlp&utm_content=1

1. 실력을 키우고 싶으면 작정하고 해야한다.

근무 연차만 공개된 두 의사에게서 수술을 받아야 한다면
5년차 15년차 중 누구를 선택할 것인가?
> 통계상 년차가 높을 수록 사망율이 높아진다.

> 개인의 발전이 업계의 발전을 앞서지 못한다.
예전에 받은 교육을 가진 의사는 그때의 지식을 가지고 수술하게 되고 학습을 하더라도 업계의 발전을 이기지 못한다.

2. 공부하면 실력이 느는가? 어떤 방법이 효과적인가.

누구나 공부에 대한 강박감이 있고 의무감으로 공부하곤 한다.
공부하면 실력이 느는가? 아니다.

주된 공부방법
1. 키워드 수집 > 책, 온라인과정, 자격증 취득
2. 스터디 모임

과연 효과적인가?
교육 방법들 마다 차이가 크다.
원격 교육이나 숙제 같은 경우 안하는 것 보다 못하다.

학교 교육은 순차적이다.
개발자들의 교육은?

학교 교육은 학습교재나 범위가 정해져 있다.
개발자들은 주로 책을 정한다.

학교 학습은 수료나 자격증 취득 같은 목표가 있다.
개발자 들은 주로 책을 떼는게 목표다.

학교 학습은 시험이란 구체적인 평가 방법이 있다.
개발자도 나름의 규칙이 있다.

학교 학습은 개별적이다.
게빌지 스터디들도 개별적이다.

즉 학교를 떠나 회사에서도 학교에서의 방법을 그대로 사용하고 있다.

이런 학교적 공부는 불확실하지 않은 영역에서 효과적이다.

책을 학습하는 것과 뭔가 학습하는 것은 다르다
즉, 파이선 책을 학습하는 것과 파이선 학습은 다른 것이다.

또한 책읽기가 공부를 위한 한가지 방법 일뿐 유일하고 주된 방법이 아니다.

야생학습
. 비순서적이다.
. 자료의 한정이 없다.
. 목표가 불분명하고 바뀌기도 한다.
. 명확한 평가 방법이 없다.
. 협력적이다.

새로운 기기를 샀을 때를 생각해보자. 처음부터 매뉴얼을 1장부터 읽고 시작하지 않을 것이다. 먼저 동작 시켜보고 필요한 부분을 매뉴얼에서 찾거나 검색하여 알아갈 것이다. 이게 야생학습이다.

학교 학습은 분절화가 문제가 된다.
파편화하여 공부릉 하지만 실생활에서는 엮어서 사용해야 한다. 파편화적으로 공부하면 파편화된 것을 다루는데는 능하지만 실생활에서는 적절하지 않다.

3. 야생학습을 하기 위해서는 어떻게 해야하나?

책에 얽매이지 말라. 책응 잘 설계되지 않았다.
이미 만들어진 프로그램을 수정하는 것도 방법임.
실무와 비슷한 환경을 구축하는 것도 방법임.

실수를 많이 하는 아이들이 실무에 적응을 잘하더라.
실수를 통해 많이 배워라.

QnA
본인이 주체가 되어
배울 topic 관련되어 향후 무엇을 할 것인가를 고민하고 그것에 맞춰 커리큘럼을 작성하라.

Accelerate C++
대부분 책들이 c를 설명하고 C++를 설명한다.
학교학습과 유사하게 순차적으로 배우도록 되어 있다.
그에 반해 이 책은 첫 챕터부터 멀쩡이 동작되는 괜찮은 프로그램이 나오게 되고 이후 챕터들을 통해서 발전되는 순서로 되어 있음.

피드백이 증요하다
하지만 무슨 피드백을 받을 지를 고민해야 한다

긍정적인 피드백을 준 사람들이 오히려 강의 내용응 사용하지 않는다. 오히려 부정적인 피드백을 준 사람들이 오히려 많이 사용한다.
컨텐트가 만족도를 결정하지 않고 강사의 태도나 호감이 만족도에 영향을 미친다.

2017년 7월 11일 화요일

고성능 .NET 프로그래밍 책을 읽고 필요한 것만 대충 정리

책을 읽다가 좀 정리함.
책의 내용은 좋은데... 이해가...

http://www.yes24.com/24/goods/24020688

성능에 대한 부분에 대해서 고민을 하고 있거나

C#, .NET 프로그래밍 시 이유나 원인을 잘 모르고 있던 것들에 대해서 설명을 잘해주고 있다.

게다가 어셈블리까지 직접 보여주며 설명하고 있는 센스 :) (난 이해 못함)

내용이 어렵거나 번역상 몇 번을 읽어도 이해되지 않는 부분이나

다소 불필요할 정도로 자세한 내용도 있는 듯하다.

보고 대체로 나에게 필요한 부분만 정리함.

자세하고 중요한 내용은 다 책에 있으니 나중에 계속 읽어 보련다.



비동기 프로그래밍

멀티 스레드를 사용하는 3가지 근본적인 이유
- UI main thread를 차단?하지 않기 위해
- I/O를 완료할 때까지 기다리지 않고 다른 작업을 함께 처리
- 처리하는 작업에 모든 프로세스를 동원

Thead context switching 비용을 위해서 .NET에서는 각 관리되는 프로세스에 대한 스레드 풀을 관리함.



Task 사용

.NET 4.0에서는 TPL(Task Paralle Library)라는 스레드의 추상화를 소개함.
내부적으로 TPL은 .NET thread pool을 사용하지만 해당 thread를 pool에 다시 반환하기 전에 동일한 thread에서 순차적으로 여러 tasks를 실행하므로 더 효율적으로 수행한다. 


- 연속 Task가 빠르고 짧은 코드 부분이면 task들이 동일 스레드에서 실행되도록 지정하는 것도 방법
 : context switching, queue에서 대기 시간을 줄일 수 있음.
 : https://msdn.microsoft.com/ko-kr/library/dd321576(v=vs.110).aspx

public Task ContinueWith(
 Action<Task> continuationAction,
 TaskContinuationOptions continuationOptions
)

public class TaskCounter
{
   private volatile int _count;

   public void Track(Task t)
   {
      if (t == null) throw new ArgumentNullException("t");
      Interlocked.Increment(ref _count);
      t.ContinueWith(ct => Interlocked.Decrement(ref _count), TaskContinuationOptions.ExecuteSynchronously);
   }

   public int NumberOfActiveTasks { get { return _count; } }
}

: 단 I/O thread와 관련되어 있다면 확인 필요.

- 오랫동안 동작하는 Task의 경우 TaskCreationOptions.LongRunning flag를 사용
 : https://msdn.microsoft.com/ko-kr/library/system.threading.tasks.taskcreationoptions(v=vs.110).aspx

- Task 다중 연속
 : ContinueWith()를 사용해서 연속해서 사용할 수도 있음.
 : https://msdn.microsoft.com/ko-kr/library/dd270696(v=vs.110).aspx

task.ContinueWith(OnTaskEnd1);
task.ContinueWith(OnTaskEnd2);
=> OnTaskEnd1, OnTaskEnd2 가 독립적이고 병렬적으로 실행됨.

task.ContinueWith(OnTaskEnd1).ContinueWith(OnTaskEnd2);
=> OnTaskEnd1이 실행되고 OnTaskEnd2가 실행됨.

 : Task 종료 조건에 따라 실행되게 할 수도 있음.
  . https://msdn.microsoft.com/ko-kr/library/dd321576(v=vs.110).aspx
  . https://msdn.microsoft.com/ko-kr/library/system.threading.tasks.taskcontinuationoptions(v=vs.110).aspx
 : 다중 Task handling을 위해서는 Task.Factory.ContinueWhenAll, Task.Factory.ContinueWhenAny

- Task를 강제로 취소하는 것 보다 Task 내에서 취소 여부를 확인해서 종료하는 방법 추천

- Task.Wait()을 사용하는 것은 Task를 강제로 기다리게 하므로 비추임.
 : 해당 thread가 대기 상태로 차단되고 언제 다시 시작할 지 몰라서 다른 스레드를 실행 시킴. 
 : 스레드에서 신호를 기다리면서 몇 밀리초 동안 회전하는 동기화 개체를 적중 시킴. 실패 시 차단되고 기다림.





Async와 Await

.NET 4.5에서 async, awit가 소개됨. TPL 코드를 쉬운 선형 동기화 코드로 전환 시킴.
: https://docs.microsoft.com/ko-kr/dotnet/csharp/async

private readonly HttpClient _httpClient = new HttpClient();

downloadButton.Clicked += async (o, e) =>
{
    // This line will yield control to the UI as the request
    // from the web service is happening.
    //
    // The UI thread is now free to perform other work.
    var stringData = await _httpClient.GetStringAsync(URL);
    DoSomethingWithData(stringData);
};




올바른 Timer 사용

- 과도하게 많은 Timer 를 만들지 않도록 하자.
 : 모든 Timer는 스레드 풀의 단일 스레드에서 제공됨. 
 : 너무 많은 Timer 는 Timer Callback 실행에 지연을 일으킨다.
- 운영 체제의 tick counter(15밀리초)보다 정밀할 수 없음.




스레드를 중단하지 않는다.



스레드 우선순위를 변경하지 않는다.



스레드 동기화와 잠금

- 스레드들 간 동기화/잠금은 CPU를 낭비하며 context switching 시간을 높힌다. 
- 다음 기본 원칙들을 고려하자.
 : 잠금이 필요한가? 
  . 스레드 동기화에 대한 필요성을 완전히 제거할 수 있다면 성능향상에 있어 궁극적인 방법임.
  . 단지 변수를 읽기만하거나 불변일 경우 동기화는 필요하지 않다. 
  . 쓰기를 할 경우 임시사본을 사용해서 쓴 다음 한번에 동기화하여 쓰는 것도 방법이다.
 : 동기화 우선 순위
  . 동기화에도 여러 수준이 있으므로 판단해서 사용
    성능에 미치는 순서 : 동기화 안함 < Interlocked method < lock/moitor class < 비동기 잠금 < 기타
 : 메모리 모델
  . 메모리 모델 : 시스템(HW/SW)에서 규칙의 집합으로 컴파일러나 프로세서에서 다중 스레드에 다시 순서를 매기는 읽기와 쓰기 작업이 얼마나 되는지를 통제한다.
                  순서 재정렬에서 컴파일러와 하드웨어가 많은 최적화를 수행하지 못하게 하는 절대적인 제약 사항이 있는 경우 strong 모델로 기술한다.
                  weak 모델에서는 컴파일러와 프로세서가 더 많은 자유를 허용 받으므로 잠재적으로 더 나은 성능을 얻기 위해 읽기와 쓰기 명령들의 순서를 바꿀 수 있다.
  . x86/x64은 strong 모델이며 ARM은 weak 모델을 가진다.
    => 즉 CLR의 호환성을 위해 해당 코드가 약한 메모리 모델이 맞는지 보장하는 것이 좋은 방법이다.
       스레드 간의 공유되는 상태에서 volatile을 올바로 사용하여 JIT 컴파일러로 하여금 문제를 정리하도록 하는 것도 방법임.
       공유 상태의 적절한 순서를 보장하는 다른 방법은 Interlocked를 사용해서 잠금 내에서 모든 액세스를 유지하는 것도 방법임.

  * 나머지는 책에서 자세히 다루고 있음 꼭 책을 구입해서 보세요!!!



일반 코딩 및 클래스 설계

- 클래스의 인스턴스는 항상 힙에 할당,일부 개체는 고정 오버헤드를 가짐 (32bit - 8bytes, 64bit - 16bytes)

- 구조체는 전혀 오버헤드를 가지지 않음. (메모리 사용 = 구조체의 모든 필드의 크기 합)
 : 구조체가 메서드의 지역변수로 선언 => 스택 할당
 : 구조체가 한 클래스의 일부분이면 => 힙에 존재

- 구조체 배열에서는 데이터의 동일한 크기가 메모리 양을 작게 차지한다. (오버헤드 없음)

- 구조체 배열은 순차적으로 메모리에 존재하므로 CPU 캐시에 존재 시 더 빠른 순서로 참조 될 수 있음.

- 메서드를 가상화 하는 것은 JIT 컴파일러가 메서드를 인라인 시키는 특정 최적화를 막는다.
 : 파생 클래스가 없다면 sealed를 표시하라.

- foreach보다 for가 빠르다. (당연하겠지만..)
 : IEnumerable<int>보다 단순 배열이 더 많은 비용이 소요된다. (당연하겠지만..)

- 캐스팅도 비용이다.
 : if (a is foo) 
   {
     Foo f = (Foo)a; 
   }

  => 
   Foo f = a as Foo; 
   if (f != null) 
   {
   }

- 예외가 발생된 메서드는 단순 빈 메서드보다 수천 배 느리다





.NET 프레임워크 사용

- Generic Collection은 boxing이나 변환 비용을 발생시키지 않고 더 좋은 메모리 집약성을 가짐.
 : https://docs.microsoft.com/ko-kr/dotnet/csharp/programming-guide/generics/
 : Dictionary => hash table로 구현되고 O(1) 삽입, 조회 시간을 가짐
 : SortedDictionary => binary search tree로 구현되고 O(log n) 삽입과 조회 시간을 가짐
 : SortedList => 정렬된 배열로 구현 O(log n) 조회시간, worst case로 O(n) 삽입 시간을 가짐, 단 최소 메모리 사용.
 : HashSet => hast table을 사용, O(1) 삽입 및 제거 시간 가짐
 : SortedSet => binary search tree를 사용하고 O(long n) 삽입, 제거 시간을 가짐 

- 문자열 비교 시 option에 따라서 속도 차이 고려 필요
 : String.Compare(a,b, option), StringComparison.OrdinalIgnoreCase < StringComparison.Ordinal < StringComparison.CurrentCulture
 : https://docs.microsoft.com/ko-kr/dotnet/csharp/programming-guide/strings/how-to-compare-strings

- ToLower, ToUppper는 왠만하면 피하라.

- String 생성 시 단순 '+' 연산자나 String.Concat 메서드를 사용하라. 
 : StringBuilder를 사용하는 것 보다 효과적이고 StringBuilder는 문자열이 아주 가변적이고 크기가 클 때 고려하라.

- 문자열 서식 (String.Format()) 메서드는 비용이 크므로 간단한 문자열이면 단순 연결 '+'을 사용하라.

- 정상적인 상황에서 예외 발생 API를 회피하라.

- 느슨한 초기화를 사용하자 (Lazy<T>)

- 정규 표현식은 빠르지 않고 어셈블리 생성, JIT 비용, 평가 시간을 위한 비용 및 시간이 필요하다.
 : Regex 성능 개선을 위해서는 Regex 인스턴스 변수 생성, RegexOptions.Compiled 플래그 사용, 반복 생성하지 않고 재사용 하는 것이 방법

- LINQ는 편리하고 성능 기준에 만족하지만 코드 숨김의 가능성이 있어 조심해서 사용하라.

2017년 7월 9일 일요일

MVVM, Xamarin.Forms

Xamarin을 사용하게 되면서 MVVM에 대한 개념은 그래도 이해가 되긴 했지만
실제 코드에 적용하기에는 어려움이 있었던 관계로
링크와 함께 간단하게 대충 정리함....

보통 MVVM 검색하면 아래 그림과 link가 나와서 이것을 위주로 정리함.

: https://msdn.microsoft.com/en-us/library/hh848246.aspx

그외 볼만한 link들

안드로이드의 MVC, MVP, MVVM 종합 안내서, Eric Maxwell
: https://news.realm.io/kr/news/eric-maxwell-mvc-mvp-and-mvvm-on-android/

우선 Xamarin 홈페이지에서도 XAML, Binding, MVVM에 대해서 자세히 설명하고 있다.
https://developer.xamarin.com/guides/xamarin-forms/xaml/xaml-basics/data_binding_basics/
https://developer.xamarin.com/guides/xamarin-forms/xaml/xaml-basics/data_bindings_to_mvvm/

The MVVM Pattern

https://msdn.microsoft.com/en-us/library/hh848246.aspx

(이건 사실 Xamarin보다는 WPF, Silverlight 관련된 article이라 method나 xaml tag가 다른 부분도 있음.)

MVVM의 가장 큰 이유는 separation of concerns
Tightly couple될 수 밖에 없는 GUI와 logic을 분리하기 위함이다.

View와 Model은 View Model을 중간에 두고 서로 분리되어 있고
View는 View Mode간에서는 data binding과 notification을 사용해서 연동된다.

MVVM pattern은 명칭에서 알 수 있듯이 Model, View, View Model로 구성되어 있다.

View

View는 Screen에서 사용자들이 보는 GUI 부분이며 XAML과 code-behind 파일(.cs)로 구성된다. (물론 cs 파일로 구성될 수 도 있을 것이고..)
View는 각각 View Model을 가지고 View Model에게서 binding을 통해 data를 가져오거나 method를 호출한다.
run-time중 UI control이 변경되면 binding된 View Model의 property가 변경되어 View Model에서 적절한 처리를 할 수 있다.

View 파일 (XAML)
- Title, Label, Image, HtmlLabel, button이 binding 되어 있음.
https://github.com/hallower/WhooingNewsReader/blob/master/WhooingNewsReader/WhooingNewsReader/Views/ItemDetailPage.xaml

View code-behind 파일 (.cs)
- ItemDetailPage 두번째 constrctor에서
ViewModel을 인자로 받아 BindingContext로 지정하고 있음.
https://github.com/hallower/WhooingNewsReader/blob/master/WhooingNewsReader/WhooingNewsReader/Views/ItemDetailPage.xaml.cs

Model

Model은 application의 domain model의 구현체로서 data model, business, validation logic을 포함한다.

View Model

View Mode은 View와 Model 중간 매개자 역할을 하며 View logic을 처리한다.
View Model은 Model의 method를 호출하여 model과 연동하고 전달 받은 data를 View에 맞게 가공한 뒤 View로 전달한다.
View Model은 UI의 event에 따른 action을 처리하기 위한 command를 제공한다.

View Model이 View와 two-way data binding을 하고자 할 경우 PropertyChanged event를 발생 시켜야 한다. 이를 위해서 View Model은 INotifyPropertyChanged inteface를 구현해야하고 실제 binding된 property가 변경 되었을 때 PropertyChanged를 호출하여 변경을 알려야 한다.

View Model 파일
- View에서 binding된 property들이 public으로 존재하는 것을 볼 수 있음.
- GetDetail에서 OnPropertyChanged()를 호출하여 View를 업데이트 하는 것을 볼 수 있음.
https://github.com/hallower/WhooingNewsReader/blob/master/WhooingNewsReader/WhooingNewsReader/ViewModels/ItemDetailViewModel.cs

Connecting View Models to Views

동작, 이벤트 처리를 위해 MVVM의 data binding을 사용하여 View와 View Model을 연결해야 한다. View Model이 연결되므로 view의 code-behind에는 business logic이 있을 필요가 없다.

Code-behind
View의 Code-behind file의 생성자에서 View Model을 DataContext(Xamarin에서는 BindingContext)로 View Model을 지정한다.

View
View Model가 default constructor 만 가지고 있을 경우 View에서 DataContext(Xamarin에서는 BindingContext)로 View Model을 연결 할 수 있다. 일반적으로 View Model Locator를 사용하는데 이는 각 view가 binding할 View Model을 제공하는 것으로 application이 여러 View들을 하나의 View Model로 연결하여 관리할 수 있다.

그리고 개발을 하다 보니

- View, View Model은 되도록이면 한 쌍으로 구성하는 것을 권장
: 하나의 View Model이 여러 View를 관리할 경우 비대해질 경우가 있음.

- 단, 여러 View에서 동일한 Context가 공유 될 경우 View Model을 Singleton이나 만들어 사용 하는 것도 방법이다.

- View Model이 List로 구성되거나 중첩된 control/view로 구성된다면 View Model간 연동이 고민인데
: View Model간 notification을 줄 수 있는 interface를 구현하거나
: Xamarin의 Messaging Service를 사용하는 것도 방법이다. (편리하지만 남용은 금물이다.)

- View Model은 View의 초기화 시점에 새로운 instance로 만들어 진다.
: 같은 View가 여러 번 보여지더라도 생성되는 View Model은 각기 다른 instance임.

- View Model의 Property들은 당연히 public 접근자를 가져야 함.

- OnPropertyChanged 구현 시 Property name의 default 값을 CallerMemberName으로 지정하는 것이 바람직함.
: Property 이름 오타로 인한 notification 누락을 방지할 수 있음.

protected void OnPropertyChanged([CallerMemberName]string propertyName = "")
{
var changed = PropertyChanged;
if (changed == null)
return;

changed.Invoke(this, new PropertyChangedEventArgs(propertyName));
}

- Property 값을 private 변수로 만들어 두고 Property setter에 OnPropertyChanged를 호출하게 하는 것도 방법임.

private string displayText;
public string DisplayText
{
get
{
return displayText;
}
protected set
{
if (displayText != value)
{
displayText = value;
OnPropertyChanged();
}
}
}

- Two-way binding 시 View에서 Property 변경 시 다른 작업을 수행하려면
BindablableObject의 PropertyChangedEventHandler를 사용하면 된다.

2017년 7월 2일 일요일

Google I/O 2017 Extended in Seoul

Google I/O 2017 Extended in Seoul에 다녀옴.

거의 자발적으로 행사를 진행하는 것 같아 이런 행사가 매년 있음에 감사하다.
비록 외부 시스템으로 인한 등록 이슈, 애매한 시간 공지가 있긴했지만
전반적인 진행과 내용도 다 괜찮았던 것 같다. ~~발표자에 따라서 좀 차이는 있지만..~~

행사 주소
https://io-extended-seoul-17.firebaseapp.com/

발표 세션들
https://io-extended-seoul-17.firebaseapp.com/schedule/

Google I/O 주요 내용이야 기사를 통해서 알 수 있겠지만
이런 행사를 통해서 한번에 직접 들으면서 정리를 하는게
게으른 나에게는 큰 도움이 되고 있다.

대충 적어두고 아 그렇구나 하고 말겠지만
아무것도 몰라서 사용하지 못하는 것보다
대충은 알고 있다가 필요할 때 바로 가져다 쓸 수 있는것도 유익하다.

주로 관심이 많았던 Track A를 듣다가 내게 필요한 부분만 대충 정리함.
아래 사이트에 동영상이 올라와 있어 이를 보는게 좋겠음.
https://www.youtube.com/playlist?list=PLF_OUznA3RTRSTDdjnlzyC-rKVq6nq4S7

[Architecture Components, 김상일]

Google IO 2017에서 첨 소개됨.
함께 아키텍처 가이드가 제공되고 있음
https://developer.android.com/topic/libraries/architecture/index.html

4가지로 구분
. Handling life cycle
. Live data
. ViewModel
. Room

추후 support library로 나올 예정

=Handling life cycle
. Lifecycle, Lifecycle owner, Lifecycle observer로 구성
. Observer 구현하고 등록 삭제하여 사용하면 됨.
. Custom Activity를 사용하려면 owner를 직접 구현하면 된다.

=Live data
Live Data = Observeable data holder
Live data 상속 시 onActive(active onserver가 있을 때). OnInactive(active onserver가 없어질 때)를 구현해야 함.
: https://developer.android.com/topic/libraries/architecture/livedata.html 설명이 명확하지 않았는데 구글 문서를 봐도 명확하지 않음.

=Viewmodel
. View가 변경되어도 configuration을 유지할 수 있음.
. Androidviewmodel은 Viewmodel과 달리 application instance를 인자로 받으므로 필요하면 선택해서 사용하면 된다.
. ViewModel은 뷰와 생명주기가 다르므로 메모리릭 등을 유의해야 함.
: View, Activity context, Resources를 참조하면 안 됨

=Room

Sqlite ORM이며 아래 클래스로 구성
. Entity
. DAO
. Database

Entity 선언 시 어노테이션 필요
: class내 pojo class들을 의해 embedded 어노테이션 제공
: typeconverter 제공

. DAO interface는 쿼리 작성을 할 수있음.
: Insert, delete, update는 기본 쿼리로 제공
. Database =sqlite open helper

Data insert는 main thread에서 불가. 런타임 에러 발생

.RXjava vs lifecycle
: Lifecycle은 rxjava를 잘 사용하고 있다면 굳이 변경할 필요 없고 간단하게 적용해보고자 할 경우

.Room vs greenDAO vs realm
: Realm이 가장 성능도 좋고 지원하는 feature가 많음(relation지원 강력).
: Room은 아직 초반이고 feature도 부실한 상황임.

[Kotlin: Make Android Great Again, 김태호]

2011년부터 시작하여 2016년 1.0 공개 2017년에 공식 안드로이드 언어로 추가됨.

Java 1.8은 jack toolchain을 사용하면 가능
https://developer.android.com/guide/platform/j8-jack.html?hl=ko
Retro lamda를 사용하는 것도 방법

안드로이드 기기도 바뀌고
IDE도 바뀐 상태에서
언어는 java 그대로임.

Kotlin에서는
. 람다 지원, it으로 single argument생락 가능
. No getter.setter > property 지원
. Builtin nullable check > ?
. ?. 지원
. 타입 선언 필요 없음.
. Kotlin android extension응 사용하면 findviewby... 사용할 필요없음.
. Intent도 Anko을 사용하면 간편함
: https://blog.jetbrains.com/kotlin/2015/05/advanced-features-of-anko/
. Pair > to 사용
. Data class에는 getter setter equal 등을 자동 생성
. 자바코드를 코틀린 코드로 변환해주는 플러그인 있음.

[주의]
. 새로운 코틀링 문법이 최적이 아님
. 자바에서 넘기는 객체는 주의해서 보자.
. 메서드 카운트가 늘어나 multi dex 사용 시 주의

[장점]
. 코드 안정성
. LOC 감소
. Swift. scala 같은 새로운 언어에 적응 가능

[Application 용량줄이기 플레이윙즈 실적용을 중심으로, 신호석]

. Download size < Installed size
. 평균적잉 앱 사이즈큰 23M (Android 12M iOS 34M)
. 플레이윙즈 광고.. 성공적

어플 용량 분석 툴은 Android Studio의 Analyze APK를 사용하면 됨.
: 용량 분석. Manifest 분석. Apk 비교 분석
. Android Studio 3.0에서는 프로가드 난독화 확인 가능

줄이는 방법
1. Proguard
. 코드 난독화
. 코드 최적화
: dead code elimination
: resource shrinking

2. Vector drawables
. 해상도별 이미지 말고 하나의 벡터 이미지로 모든 해상도 대응
. support library 사용 필요. App:srcCompat 사용 필요.
. sketch를 사용하여 벡터 이미지 제작하는 것을 추천
. 안되면 png 용량을 줄여라.
. Android Studio 3.0에서는 WebP변환 기능을 제공한다. (단 API 16.18제약)

3. Exclude space translation
. 번역 중 비어있는 문자열들을 찾아서 주언어를 기준으로 압축함.

4. Set specific circumstance
. 지원하는 해상도로만 추릴 수 있음.

5. Use downloadable fonts
. font family에서 downloable google font들을 사용.
. 구글 downloadble fonts sample앱이 있음.
. 단 아직은 잘 안되더라...

시간 대비 효과적인 방법을 찾아보는 것이 필요함.

. 시간 대비 Proguard 적용 효과 있음.
. Exclude space translation도 해볼 만 함.
. Vector drawable 효과 좋음

. 벡터 이미지로 변환 시 해상도 제약이 있으니 확인 필요.
. 일러 사용으로 svg 추출 시 문제가 생겨 스케치를 사용함.
. 5.0에서 벡터 이미지 사용 시 메모리 릭이 있었으나 현재 테스트 중에서는 아직 발견되지는 않았음.
. Downloadable fonts 테스트 시 Play service v11 이상이어함.

[아주 주관적인 안드로이드 O 살펴보기, 양찬석]

주요기능은 좀 찾아보면 나올 거고..

. 현재 DP3. API 종료.
. Q3에 정식 릴리즈

http://d.android.com/preview

. 안드로이드 업데이트가 좀 자주 있긴 하지만
더 좋은 안드로이드를 만들기 위해
안드로이드 플랫폼 및 하위 layer들도 함께 업데이트하기 위함임

플랫폼에서 향상된 기능들

.런타임 업데이트
: dex파일 layer 최적화
: Forground 앱에대한 concurrent compaction, read barrier based GC
> 적은 메모리. 빠른 메모리 할당. 부드러운 앱
: project treble
. 안드로이드.업데이트가 느린 것을 위한 프로젝트
. 안드로이드 3단 분리(앱.프레임워크>앱.벤더인터페이스.프레임워크)
. VTS (vender Test Suite)응 통과하면 안정성 보장됨
. 안드로이드 O부터 시작

사용자에게 더 좋은 경험
.구글 플래이 프로텍트
: Android O, 최신 플레이스토어 설치 시 사용 가능
.PIP지원
: resizable activity를 지원했었어야 했지만...이젠 상관 없는듯?
. Autofill framework 지원
. Alert window
: 다른 앱위에 경고창을 띄울 수 있음
: type_application_overlay 윈도우 타입 추가
. 시스템 layout 아래에서만 표시됨
. 상단 notification창에 어떤 앱이 띄우는지 확인 가능함.

알림
. 알림 종류에 따른 배치 (중요한 알림 순으로)
. 알림 채널 (개별 알림별 설정>채널별 설정)
. 알림 표시 점(dot)
: 채널별. 롤프래스로 알림 확인

개발자를 위해
.Android Studio 3.0
.Emulator
: google play 탑재 바이너리 추가, 단 루팅 불가
.Kotlin
.Instant app
.architecitre component
.android support library 26
.폰트 리소스
.폰트 다운로드 by font provider

우리 모두를 위해
. Android vitals (d.android.com/vitals)
: 플레이스토어에 메뉴가 추가 되어 있음.
: anr, crash rate
: 느린 렌더링, 프레임 멈춤
: stuck wake lock
: wakeup

[파이어베이스 무엇 달라지나, 남상균]

듣기는 했으나...