Use constructor injection for this field

why? http://olivergierke.de/2013/11/why-field-injection-is-evil/

Or Inject -> Autowired ( Autowired 와 Inject 차이 - http://dev-eido.tistory.com/entry/Autowired-Resource-Inject%EC%9D%98-%EC%B0%A8%EC%9D%B4 )

QA.

1. Partial VS Curry 차이

2. 함수 VS 메소드 차이

3. 트레잇 VS 추상 클래스

4. Function compose VS andThen

- 순서의 차이 

compose A(B())

andThen B(A()) 

5. 클로저란?

함수 내부 컨텍스트를 가지고 있는 ..

6. 자바 switch문과 scala의 패턴 매칭의 차이점은?

용어

REPL(read eval print loop. 입력을 받아 값을 계산하고 결과를 출력하는 루프)

참고

https://github.com/alexandru/scala-best-practices

https://twitter.github.io/scala_school/ko/basics2.html

http://tryhelloworld.co.kr/courses/30%EB%B6%84-scala

Spring for scala

https://slipp.net/wiki/pages/viewpage.action?pageId=24641784

준비물

- 서버

1. 개발 서버 ( Heroku, etc.. )

2. optional - Stage 서버 1대

3. Production 서버 1대

4. 배포 서버 ( circle ci, jenkins.. etc )

5. 로드밸런싱 서버 ( aws ELB, ngnix ) 

- 소스 저장소 : git

- 배포 : 젠킨스

- 로드밸런싱 : AWS ELB or ngnix

- Deployment CMS

bolt2 ? 

https://deploybot.com/guides/deploy-craft-cms-to-digitalocean - 적지 않은 비용.

https://jekyllrb.com/docs/deployment-methods/ 

-- 배포 시, 젠킨스로 deploy or deployment cms를 통해 배포 진행 or 콘솔 접속 배포 프로세스 진행.

- Log Management : graylog

- Monitoring : grafana - https://grafana.com/cloud/grafana

ex) production 서버 구축하기

서버 구성도

https://www.draw.io/?lightbox=1&highlight=0000ff&edit=_blank&layers=1&nav=1#G0B8XAh1SciE-9V3AzUG1BWEFPLWM

Step 1

1. git repository 등록.

2. github시 circle ci 이용, 그외의 경우 별도로 jenkins 서버 설치.

3. production 서버 설치 

4. ngnix, AWS ELB 구축

- production 서버 attach

Step 2

1. jenkins 도커를 이용한 clone, build and test, bake images

그외 기타 구축.

- Message Queue : rabbitmq

- API Framework : swagger-ui

- DB 테이블 관리 : flyway db

- Software Component Management : Nexus ( maven Repository와 같이 라이브러리 임포트 시 )

optional  - 도커를 이용한 배포 이미지 구축

P.S 점으로 된 책

http://www.yes24.com/24/goods/19591495?scode=032&OzSrank=1

https://andromedarabbit.net/ssh-%EC%A0%91%EC%86%8D%EC%9D%B4-%EC%9E%90%EA%BE%B8-%EB%81%8A%EA%B2%A8%EC%84%9C-%EC%A7%9C%EC%A6%9D%EB%82%A0-%EB%95%8C/

참조 : http://stackoverflow.com/questions/15774475/how-to-send-a-getforobject-request-with-parameters-spring-mvc

RestTemplate 객체를 사용하여 url 주소를 호출과 동시에 파라미터를 전달 해줄 경우 Uri 객체에 파라미터를 넣어 코드를 작성하여야한다.

Uri targetUrl= UriComponentsBuilder.fromUriString(BASE_URL)
    .path("/android/played.json")
    .queryParam("name", nome)
    .build()
    .toUri();
return restTemplate.getForObject(targetUrl, Name.class);

Reverse Ajax, Ajax Push, Two-Way-Web, HTTP server PUSH 등등으로 불리던 말이 이제 Comet 이라는 용어로 통일되어 가는 거 같다.

Comet 이란 웹 클라이언트(보통 웹 브라우저)의 명시적인 요청이 없어도 서버에서 클라이언트로 데이타를 밀어넣는(Push) 방식으로 동작하는 웹 프로그래밍 모델을 일컫는 말이다.

1. Polling 

2. Long Polling

3. Streaming

이중 Long Polling 과 Streaming 을 Comet 기능으로 주로 사용함.

Spring Framework 에선 WebSocket을 이용한 Comet 기능 구현이 있다. 

페이스북과 같이 댓글이 실시간으로 바로 나오기 위해서 사용하게 된다.

다만 주의할 점은 톰캣 8 이상에서 테스팅이 원활하게 진행이 된다.

만일 톰캣 버젼이 낮을 경우에는 

 org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [org.springframework.web.socket.server.support.DefaultHandshakeHandler]: Constructor threw exception; nested exception is java.lang.IllegalStateException: No suitable default RequestUpgradeStrategy found

라는 에러가 뜨게 될 것이다. 이것저것 시도해보았지만 톰캣 서버 버젼을 높이는 경우 밖에 없는 듯 하다.

어떤 라이브러리 개발을 하고 서비스를 하게 될 경우, Upgrade는 부담이 가게 되어있다.

서비스의 안정성으로 인한 문제인데, 해결책으론 버저닝 (Versioning)의 규칙 쉽게 하는 방법이 있다.

예로들면, Semantic Versioning이 있겠다.

                     X (major)  Y(minor)  Z(patch)

다만 패치를 했을 경우, 몇 개의 부분을 수정했는지 크기를 알 수 없어

1개 수정하든 3개를 수정하든 패치 버전 업은 한번 일어나는 경우가 생기게 된다.

| 파일 | 버전 | 상세 내용 | 메소드 | … 이런식으로 각각의 수정 사항에 대해 상세화 시켜줌으로 해결할 수가 있다한다.

라이브러리를 개발하기 위해선 변화에 대응하기 위해 테스팅을 많이 해야한다.

테스트도 두가지 경우가 있다. 자동화 테스트, 사람 테스트

자동화 테스트 도구론 JsTestDriver 와

이벤트 시점에서 테스트 할 수 있는 Testem, Karma (Core – 테스트) 가 있다.

사람 테스트는 수치화 안되어 있는 것 (파일 업로드 등등 .. )인데 밀도 있게 하면? 된다한다.

Ex) 컴포넌트 별 기능 별로 테스트

결론, 라이브러리 개발은 단위 테스트 – 도구 활용, 사람 테스트 – 밀도 있게끔 하고

추가적으로 최소한의 의존관계, 발전 방향 쉽게 구성

Ex) Cross browsing (Polyfill)을 Syntactic sugar(Core)에 까는 식

이렇게 할 시에는 Polyfill은 외부 개발자에게 지원 받을 수 있음.

http://blog.naver.com/kildongs - 소스 보기

안드로이드 개발 중 대부분의 버그들은 Data Transfer에서 발생한다.

( Intent, Uri 잘 다루는 것이 중요하다 )

또한 안드로이드를 개발할 때, 액티비티의 static도 안정하지 않아, Application 객체에다 저장하는 게 낫다. Application 객체만 잘 설계해도 좋은 어플리케이션을 만들 수 있다.

Application 객체를 사용하기 위해선 AppContext 라는 클래스를 만들어 Application 관련 처리를 편리하게 사용할 수 있게 구성을 해야한다.

앱 개발시, 코드를 간결 하는 것도 중요하다.

Inheritance, Reflection, Generics, Annotation, XML 를 이용하면 간결하게 할 수 있다.

findViewById 메소드는 복잡성 증가 시켜 어노테이션, 리플렉션을 이용하여

@DeclareView를 통해 해당 뷰를 받게끔 구성. 할 수도 있다.

XML 부분 UI 컴포넌트 나누는 작업도 어느정도 해줘야한다.

예로는 Resource Id Mapping 간략화, Preference Xml 생성하여 변하지 않은 것은 넣기가 있다.

@BundleField 어노테이션 사용으로  DataTransfer의 코드를 줄일 수 있다.

과정은 다음과 같다.

Uri 스킴?을 매핑 객체 만든후, 클래스 멤버로 참조하여 사용하는 방법을 주로 한다.

인텐드 사용할 때도, Intent를 Serialize가 되면 데이터양이 많은 것들은 전송이 힘들 경우가 있다.

따라서 AppContext.putValue 처럼 AppContext 클래스를 적극 활용하는 것도 하나의 방안이다.

Table, Cursor 단순화는 @DataField ( Cursor Reader, Content Values Mapper ) 객체 활용하면 된다.

하지만 나와있는 API들이 존재하므로 Jackson, XStream (API – Data Object Model)

를 사용해도 무방하다.

다만 API는 안드로이드 최적화가 되어있지 않아 한번 더 Convert 해야한다는 점이 불편하긴 하다.

간격하고 효율적인 안드 세미나를 들으면서, 어노테이션에 대해 다시 돌이켜보는 기회가 되었다.

어렵지도 않으면서, 어느정도 융통성 있게 어노테이션과, 리플렉션을 사용하면 코드의 양과 간결함을 유지할 수 있다고 한다.

그 말에 대해 어느정도 공감이 되는 부분이었고, 해외에서도 여러 어노테이션을 사용하는 API?가 존재한다. (AndroidAnnotations, GoogleGuice 등등..)

이런 API를 적극 활용하여 다음번에는 개발을 해봐야겠다.

Docker의 핵심적인 내용은 각각의 리눅스 서버의 세팅에 대한 설정 관리를 Docker가 대신해 준다는 것.

해당 리눅스 이미지를 저장하여 버전에 따라 다시 불러오는 기능을 할 수가 있다.

도커에 대해 들어보긴 했어도 어떠한 기능을 하는지 감을 잡을 수가 없어서 듣게 되었는 데, 아직까지는 도커를 쓰고 경험하기에는 거리가 먼 일들이라는 것을 깨닫게 되었다.

기능 자체가 개발적인 부분도 일부 포함되어 있지만, 환경이 변하지 않고 그 상태에서만 지속된다면 도커의 효과를 맛보기란 어렵기 때문이다.

보안이란 것은 시간을 버는 관점으로 봐야한다는 것이 핵심.

절대로 완벽한 보안은 없다.

마지막 세션에서 안드로이드 APK를 디컴파일하여 소스를 분석한다음, 악성코드를 심는 과정까지 간단하게 설명을 해주었다.

해킹툴만 가지고 있고 어느정도의 소스 분석 지식만 있다면 누구나 해킹을 할 수 있다한다.

데이터를 보내는 것들 또한 암호화 시키고 해커가 디컴파일해서 소스분석해도 잘 모르게끔 하는 것이 중요.

* 워드에다 쓰고 티스토리에다 쓰니깐 깔끔해지는 듯?

  
<server xmlns="urn:jboss:domain:1.5">
    <extensions>
        <extension module="org.jboss.as.clustering.infinispan"/>
        <extension module="org.jboss.as.connector"/>
        <extension module="org.jboss.as.deployment-scanner"/>
        <extension module="org.jboss.as.ee"/>
        <extension module="org.jboss.as.ejb3"/>
        <extension module="org.jboss.as.jaxrs"/>
        <extension module="org.jboss.as.jdr"/>
        <extension module="org.jboss.as.jmx"/>
        <extension module="org.jboss.as.jpa"/>
        <extension module="org.jboss.as.jsf"/>
        <extension module="org.jboss.as.logging"/>
        <extension module="org.jboss.as.mail"/>
        <extension module="org.jboss.as.naming"/>
        <extension module="org.jboss.as.pojo"/>
        <extension module="org.jboss.as.remoting"/>
        <extension module="org.jboss.as.sar"/>
        <extension module="org.jboss.as.security"/>
        <extension module="org.jboss.as.threads"/>
        <extension module="org.jboss.as.transactions"/>
        <extension module="org.jboss.as.web"/>
        <extension module="org.jboss.as.webservices"/>
        <extension module="org.jboss.as.weld"/>
    </extensions>

 <system-properties>
        <property name="org.apache.catalina.connector.URI_ENCODING" value="UTF-8"/>
        <property name="org.apache.catalina.connector.USE_BODY_ENCODING_FOR_QUERY_STRING" value="true"/>
    </system-properties>

.....

</server>

추가 해주면 서버 utf-8 설정 끝!

user.html, user.json, user.xml .... 확장자에 따라서 보여주는 페이지를 바꿀 수 있고,

ResponseBody

반환하는 형태를 명시를 해서 반환 하는 형태이다.

the default charset of @ResponseBody is iso-8859-1, how to change to utf8.

@RequestMapping(value = "/path", produces="text/plain;charset=UTF-8")

public @ResponseBody String handlePath() {

    .....

}

produces="text/plain;charset=UTF-8"를 사용하여 응답 페이지에 대한 UTF-8 인코딩이 가능하여 한글 깨짐을 방지 할 수 있음.