2018년 1월 27일 토요일

앱 서명 키 관리 Google Play App Signing

앱 signing 인증서를 잃어 버려 동일한 앱을 다시 출시 했던 경험이 있어서
이후 부터는 인증서를 위험하더라도 cloud 서비스에 저장하고 있다.

얼마전 Google Play App Signing가 생긴것을 알게 되어
기존앱의 signing private인증서와 업로드를 위한 인증서를 등록함.



앱 서명 인증서와 앱 업로드를 위한 인증서가 분리되었고
사용자는 업로드를 위한 인증서만을 사용하여 Google Play에 업로드하고
Google Play에서는 업로드 인증서로 업로드된 앱을
다시 앱 서명용 인증서로 서명하여 배포하는 것으로 보인다.



그래서 사용자가 서명용 인증서를 잃어버릴 가능성도 없고
업로드를 위해 사용하는 인증서를 잃어 버려도 
다시 업로드용 인증서를 재등록하여 앱배포에는 문제가 없게 되었음.

진작에 이렇게 하지...

2018년 1월 18일 목요일

C# API Design #3, Implementing

새해 강의를 찾다가 아래 강의를 듣게 됨.
https://www.udemy.com/api-in-csharp/learn/v4/overview

API design에 대한 책은 많지만 C#에 대해서 특화된 내용이 없어서 좀 아쉽던 차에
이런 강의를 보게 됨. 하지만 강의 내용은 평범하다.

보다가 기억에 남는 것을 간단히 정리함.
하지만 강의를 들어야 모든 내용을 이해할 수 있으니 필요하면 구입해서 듣는 것도 방법임.


[Designing and Implementing Types and their Members]


. struct, class
struct와 class의 차이에 대해서 설명을 하는데
struct는 value type, class는 reference type이라는 것,
struct를 property, readonly, 일반 변수로 사용할 때 조심해야 할 것은
property의 getter나 readonly는 변수를 복사(value type)해서 전달하므로 변수를 변경해도 실제 변수에 영향을 미치지는 않는다고함.
그래서 struct를 사용하려는 객체는 불변값을 가지는

컴파일러는 property(get)에 대해 대충 아래처럼 코드를 생성함

private Mutable ☆ ☆ ☆; // private backing field
              // 컴파일러에서 생성, 코드에서 접근 불가

public Mutable get_PropertyMutable()   // get; 컴파일러 생성
{
return ☆ ☆ ☆;
}

get_PropertyMutable은 풀어서 보면 대략 이런 느낌?

private Mutable ☆ ☆ ☆; 
public Mutable get_PropertyMutable()
{
Mutable temp = ☆ ☆ ☆;
return temp;
}


. Abstract class는 default 구현을 두고 필요한 구현만 상속 class에 맡김
Interface는 상속 class의 형태(prototype)를 강제하고 모든 구현을 맡김
 : Interface는 API client 입장에서 보면 API 사용 시 유연하고
API developer 입장에서 보면 API 구현 시 융통성이 없음.
 : Abstract class는 API client 입장에서 보면 API 사용 시 융통성이 없고
API developer 입장에서 보면 API 구현이 유연함.


. Abstract class에는 constructor를 protect로 만들어라. 실제로 Instance 생성이 불가한 abstract class에 public constructor는 말이 안됨.
https://docs.microsoft.com/ko-kr/dotnet/standard/design-guidelines/abstract-class


. Constructor에서 virtual method를 호출하지 마라.
실제 상속된 class의 virtual method에서 내부의 변수를 참조할 경우 부모의 constructor가 수행되는 중에는 자식의 constructor가 호출되지 않는 상태라 변수가 초기화가 안되어 있을 수 있다.


. Optional parameter 사용하는 API를 만들 시 아래 article을 꼭 참조하라.
: https://haacked.com/archive/2010/08/10/versioning-issues-with-optional-arguments.aspx
http://codebetter.com/2011/01/11/c-in-depth-optional-parameters-and-named-arguments-2/

. Optional parameters는 빌드 된 IL이 default value를 포함하게 함
 : library에서 default value를 사용하는 API 사용 시 library와 API client 코드가 모두 재 빌드 되어야 default value가 변경 됨. ㅜㅜ

. Overload 된 methods들을 선택할 때
optional parameter가 없는 함수 중 동일한 parameter 개수의 함수를 선택.
없다면 optional parameter를 가진 함수 중에서 일치하는 함수를 선택한다.
이 때 API들의 parameter 중 default value를 가지고 있지 않는 개수가 동일한 경우 같은 함수로 취급된다.


.Constructor의 경우 간략한 작업을 하도록 하고
 생성 시 parameter 부족이나 초기화에 문제가 발생한다면 exception을 발생 시키는 것도 방법임. 하지만 static constructors에서 exception을 발생시키면 노답.


. Finalize를 구현하면
Finalize될 object들을 관리하는 overhead 발생하고
Finalize 시점을 예측할 수 없어 과연 resource 해제여부도 불투명함.
그래서 unmanaged resource에 대해
IDisposable을 사용하고 IDisposable 사용 시 class 상속을 허용하지 않는 것이 좋지 않을까?
https://msdn.microsoft.com/ko-kr/library/system.idisposable(v=vs.110).aspx

2018년 1월 15일 월요일

C# API Design #2, Naming

새해 강의를 찾다가 아래 강의를 듣게 됨.

API design에 대한 책은 많지만 C#에 대해서 특화된 내용이 없어서 좀 아쉽던 차에
이런 강의를 보게 됨. 하지만 강의 내용은 평범하다.

보다가 기억에 남는 것을 간단히 정리함.
하지만 강의를 들어야 모든 내용을 이해할 수 있으니 필요하면 구입해서 듣는 것도 방법임.

[Naming]

사실 아래 Coding convention을 참고해도 됨
http://www.dofactory.com/reference/csharp-coding-standards

올바른? naming을 사용하는 것은 code readability나 maintenance를 위해 꼭 필요하다.

. 영어 단어를 사용하되 의미가 맞고 적절한 어순으로 사용하라.
. 아재들이 사용하는 헝가리안 표기법(Hungarian notation)은 사용하지 말라.
. C coding style 도 별로임. “i_cnt”, “str_name”.
. 변수, 함수 사용 시 짝을 맞춰 사용하라. (locked/unlocked, first/last 같이)
. private/protected field, parameters들은 Camel casing, 그외는 Pascal casing
. 약어는 2글자 이하는 모두 대문자로 3글자 이상은 casing을 따른다.
  하지만 예외는 있음 : BitFlag(bitFlag), Email(email), Id(id), Ok(ok), Pi(pi), Metadata(metadata)
. 상속 받는 class들의 suffix를 따른다.
. 하나씩만 사용하는 enumeration은 단수형 이름으로 복수개를 한번에 사용할 수 있는 것은 복수형 이름으로...

무엇보다 code는 readable 하게 작성되어야 함.

2018년 1월 9일 화요일

C# API Design #1

새해 강의를 찾다가 아래 강의를 듣게 됨.
https://www.udemy.com/api-in-csharp/learn/v4/overview

API design에 대한 책은 많지만 C#에 대해서 특화된 내용이 없어서 좀 아쉽던 차에
이런 강의를 보게 됨. 하지만 강의 내용은 평범하다.

보다가 기억에 남는 것을 간단히 정리함.
하지만 강의를 들어야 모든 내용을 이해할 수 있으니 필요하면 구입해서 듣는 것도 방법임.

. API는 functionality의 모음으로 볼 수 있다.
. Nice APIs, nasty APIs는 있지만 prefect, definitely APIs는 없다.
. Private API는 잘 관리되는 동물원과 같고 Public API는 정글과 같다.

괜찮은 API의 특성에 대해서 말하고 있음
. Simplicity, Expressiveness(표현력) and Compromises(타협), Extensibility, Open-Closed Principle (OCP), Consistency

. API의 Simplicity는 API 기능과 반비례함.
. Simplicity를 측정하는 방법은 없지만 동료에게 사용하게 해보고 API를 사용하는데 얼마의 시간이 걸리는지 확인해 보는 것도 방법
. API를 만들기 위한 resource들은 제한적이므로 적정한 선에서 API를 제공할 수 밖에 없음.
. Universal APIs 따위 만들 수 없음.

API design 방법을 말하고 있는데 몇개 추려보면
. API는 최대한 간단하게 만들어라.
. API를 간단히 배워 사용할 수 있게 하라.
. 간단한 constructor들을 제공하되 필요한 parameter들에 대해 기본값을 제공하는 것도 방법
. Exception을 발생 시킬 때는 뭘 고쳐야 할지 알려줘라.
. API 자체가 어떻게 사용할 수 있는지 알 수 있도록 만들어라.
. Decent documentation