어제부터 MS의 최대 개발자 컨퍼런스인 Build가 개최 중인데 엄청나게 큰 정보가 나왔습니다.
Windows에서 리눅스 프로그램을 실행 파일 그대로 실행할 수 있게 되었습니다.

현재까지는 Windows에서 리눅스 프로그램을 실행하려면 가상화 방식을 사용해야 하는데 이제 네이티브로 실행할 수 있게 되었습니다.

 

관련 정보를 정리한 것이 있어서 번역 해 보았습니다.

 

 

 

 

 

 

 

 

 

 

저작자 표시
신고
by 흥배 2016.04.01 08:44

며칠 전 MS에 인수된 Xamarin 이 앞으로 완전 무료가 될지 모르겠지만 현재 DreamSpark 가입자라면 무료로 사용할 수 있다.

 

https://xamarin.com/student 로 이동

 

1.MicrosoftDreamSpark에 가입한 사람이라면 1의 링크에서 준비된 Xamarin 이용권을 취득

사용할 수 있는 Xamarin Business는 라이선스와 마찬가지로Visual Studio에서 이용할 수 있다.

 

2.DreamSpark에 가입되지 않은 사람은 2의 링크에서 폼을 채워서 보낸다

사용할 수 있는 Xamarin(아마도)Mac에서 Xamarin Studio를 이용할 수 있는 Indie 라이선스와 같은 것이다.

 

3.선생님, 교수 또는 수업 등 교육 기관에서 사용하는 경우는 3의 링크에서 폼을 채워서 보낸다

아마 무료가 아니라 1라이센스 $100 정도. 30명의 반에서 iOS/Android 개발을 하는 경우 $6,000정도가 될 듯

 

 

 

출처: http://ytabuchi.hatenablog.com/entry/2016/02/24/141529

저작자 표시
신고
by 흥배 2016.02.29 09:00

Go 1.6

2 17(미국 시간)에 프로그래밍 언어 "Go"의 버전 1.6 이 나왔음.

 

이전 버전 1.5의 발매부터 약 반년 후의 업데이트.

 

주된 기능으로는 우선 net/http 패키지에서 HTTP/2 대응. HTTPS 채용 서버와 클라이언트 쌍방에서 HTTP/2(Hypertext Transfer Protocol Version 2)이 기본적으로 유효하게 되었다.

HTTP/2 2015년 공식 RFC 7540로서 표준화된 통신 프로토콜이다. RFC에 따르면 네트워크 자원의 보다 효율적 이용과 레이턴시 감소.

 

template 패키지가 개선되어 버전 1.5에서 시험적으로 도입된 vendor 디렉토리가 기본적으로 유효하게 되었다. 이 밖에 cgo에서는 Go C의 코드들 사이에서 포인터 교환 규칙이 변경되었다.

변경 내용은 문서에서 확인할 수 있다.

 

 

 

저작자 표시
신고
by 흥배 2016.02.24 08:00

MicrosoftASP.NET에 대해서 몇 가지를 설명 하였다.

최근의 스케줄 변경과 ASP.NET 5에서 ASP.NET Core 1.0으로 명칭을 변경한 것에 대한 것이다.

 

RC2 RTM 시기는 미정으로 되었다.

 

DNX에서 CLI로 변경에 대해서 피드백을 받고 있다.

"굉장한 변경이지만 왜 이렇게 늦게?"

옳은 질문이다.이 변경이 스케줄 변경의 주요 이유이다. 너무 빠르게 진행해서 돌아보는 시간을 갖지 않은 것은 분명하다.

 

 

ASP.NET 팀은 변경에 대해서 자세히 설명 하고 있다. 쉽게 말하면 이 변경은 크며 ASP.NET의 기초가 된다는 것이다. 이런 종류의 큰 프로젝트에서는 변경을 정확하게 잡기 어렵다. 또 팀은 품질과 뛰어난 제품을 출하하기 위해 균형을 유지하고 있다. 기존의 애플리케이션은 ASP.NET Core로 이행하기 위해서 개발이 필요하므로 시간은 중요한 문제이다.

 

새 출시 날짜에 대해서 Jeffrey씨는 다음과 같이 말한다.

새로운 ASP.NET .NET Core 도구를 정비하고, ASP.NET에 대한 로드맵을 갱신하려고 한다. 그리고. NET 팀이 NET Core의 로드맵을 갱신할 것이다.”

 

 

또 이름 변경에 따른 다른 의문도 나온다. 새로운 버전의 MVC Web API는 어떨까? InfoQ의 기사에서 용어를 정리한 대로, 장래 MVC Web API의 다른 버전은 없다. 현 시점에서도 ASP.NET에 포함되어 있으며 버전도 공통된다.

 

ASP.NET 5에서 ASP.NET Core로 명칭 변경은 아직 혼란을 낳고 있다. ASP.NET 관련의 웹 사이트에 아직도 낡은 이름이 오르고 있기 때문이다. 명칭 변경은 현재도 실시 중이며 ASP.NET Core의 다음 릴리스에는 수정을 완료할 예정.

 

자세한 정보는 ASP.NET 팀의 동영상에서 확인할 수 있다. GitHub의 저장소에서도 발표 내용을 확인할 수 있다.

 

 

출처: http://www.infoq.com/news/2016/02/aspnet-core-schedule-changes

 

 

 

저작자 표시
신고
by 흥배 2016.02.22 08:36

Cassandra 사용 사례

- 애플은 지난해 iCloud 등에 저장된 10 페타바이트의 데이터를 7 5000 노드로 구성된 Cassandra에서 운용하고 있다고 발표했다.

- Netflix에서도 2500 노드에서 420 테라바이트의 데이터를 운용하고 있다고 발표 발표했다

(위 사례는 Apache Cassandra Web 사이트 메인 화면에서 소개되고 있다).

- 또 세계적으로 금융 사업을 전개하는 ING 그룹도 온라인 결제 시스템에 Cassandra를 채용하고 있다.

 

 

Cassandra의 최신 버전인 "Cassandra 3.0"이 출시되었다.

Cassandra 3.0에서는 스토리지 엔진 코드가 리팩토링 되어 CQL에 최적화되어 효율이 좋아졌고, 새로운 materialized views 기능이 탑재되었다.

v3.0은 성능과 최적화 측면에서 이 데이터베이스의 혁신의 새로운 이정표가 되었다. 데이터 일관성의 조작을 개선하고 평균 데이터 보존영역을 50% 삭감, 새로운 materialized views 등의 기능은 애플리케이션 개발을 아주 쉽게 해줄 것이다.

 

뷰는 실 테이블에서 작성되는 가상적인 테이블. materialized views는 가상 테이블에 데이터를 cache로 가지므로 실제 테이블에 액세스 할 필요가 없으므로 고속으로 값을 얻을 수 있다.

Cassandra 3.0materialized views에서는 실 테이블의 데이터에 변경이 있는 경우 결과 정합성을 유지하면서 그 변경을 서버 측에서 가상 테이블(materialized views)에 반영한다.

예를 들어 게임의 하이 스코어를 저장할 테이블을 materialized views로 작성한 경우, 애플리케이션에서 그 뷰를 참조하면 언제나 최신의 하이 스코어를 얻을 수 있다.

 

그 외 Cassandra 3.0에서는 사용자 정의 함수, Windows에서의 시험 등도 포함된다.

 

자세한 것은 The Apache Software Foundation announces Apache™ Cassandra™ v3.0

(https://blogs.apache.org/foundation/entry/the_apache_software_foundation_announces82)

 

 

 

출처: http://www.publickey1.jp/blog/15/nosqlcassandra_30.html

저작자 표시
신고
by 흥배 2015.11.16 08:00

3.22015년 말에 나올 예정이다.

 

 

도큐먼트 검증

도큐먼트 내용에 검증(키 이름과 값 체크)을 걸 수 있다.

예를 들면

{age: {$gte:0,$lte:150}}

age 0~15사이의 값인지 체크.

 

 

부분적 인덱스

문서 속의 한 값에 따라 인덱스에 포함시킬지를 나눌 수 있다.

예를 들어 사용자 도큐먼트 속에 활성화, 비 활성화 플래그가 있어서 적극적인 사용자만 검색하는 요건인면 비 활성 플래그의 데이터는 인덱스에 포함시키지 않을 수 있다. 이것에 의해 메모리를 효율적으로 이용할 수 있다.

 

 

스토리지 엔진의 추가

지금까지는 MMAP WiredTiger뿐이었지만 새로 인 메모리스토리지 엔진과 암호화할 수 있는 스토리지가 추가된다.

단 암호화 스토리지는 유상 Enterprise 판에만 있는 것 같다.

 

 

BI 툴과 커넥터

BI 툴과 커넥터가 붙을 것 같다. 예상으로는 Tableau 일듯.

 

 

config 서버가 레플리카 셋에

지금까지는 config 서버는 mongod 3대에서 2 PC에서 경신했지만 앞으로는 비 권장되고 대신에 레플리카 셋에서 config를 구축한다.

 

 

Javascript의 엔진이 또 Spidermonkey

지금은 Javascript 엔진은 V8이지만 Spidermonkey이 된다.

분명히 2.4에서 Spidermonkey에서 V8로 바뀌었는데 다시 돌아온 것이 된다.

 

 

mongodump mongorestore가 압축&스트림 전송 대응

mongodump mongorestore가 압축에 대응한다. 또한 원격의 mongod에 대해서 dump한 데이터를 스트림으로 전송 하고 restore 할 수 있게 된다.

 

 

aggregation framework 개량

aggregation framework에 많은 오퍼레이터가 추가되었다. 너무 많아서 생략.

 

 

전문 검색의 개선

전문 검색이 영어 이외에 대응했다! 하지만 유감스럽게도 일본어는 대응하고 있지 않는다.

추가된 언어는 아라비아어, 페르시아어, 우르두어 중국어이다.

외에도 몇 가지 개선이 있는 것 같다.

 

 

새로운 CRUD API

지금까지 CRUD는 한번의 쿼리로 갱신되는 문서 수가 하나이거나 복수여서 알기 어려웠는데 새로운 API가 추가되었다.

예를 들어 update()의 경우 하나를 경신하는 updateOne()이나 복수를 경신하는 updateMany()를 대용할 수 있다.

외에도 findAndModify()도 알기 어려웠으므 갱신으로 치환과 삭제 3개의 대용 API가 생겼다.

 

 

Ops Manager( MMS)개선

파일 시스템의 백업, 쿼리 프로파일링, 인덱스의 시사, 그리고 레플리카 전체의 인덱스를 롤링 업데이트할 수 있게 되었다.

 

 

 

출처: http://qiita.com/fetaro/items/907f4a8791ffb24df9bb

 

저작자 표시
신고
by 흥배 2015.11.06 08:00

이름 해석(name resolution)에서 DNS 서버의 응답이 512 바이트를 넘을 경우 DNS 서버는 DNS 메시지를 512 바이트 이하로 줄이다. 그 때 압축이 발생했음을 표시하는 "TC 비트"set 한 응답을 돌려준다. TC 비트가 set된 응답을 받으면 송신원은 같은 문의를 TCP로 다시 보낸다. 이 일련의 교환을 "TCP 폴 백"이라고 부른다. 이것으로 65535 바이트까지 DNS 메시지 수신이 가능하다.

 

DNS에서는 TCP 사용에 의해서 발생하는 비용과 지연을 피하기 위해 갑자기 TCP로 문의하지 않고 UDP 에서 시행한 후에 TCP를 이용해야 한다고 규정되어 있다(RFC 5966에서 정의)

  

출처: http://www.atmarkit.co.jp/ait/articles/1510/28/news014.html

 

 

 

DNS의 문의에 대한 답변이 512byte를 넘는 경우에 UDP 프로토콜이 아니라 TCP 프로토콜에 의해서 응답하는 것을 말한다.

 

udp/53에 문의한 것에 왜 TCP 프로토콜로 응답하는가?

- MTU의 최소치인 576byte DNS 응답 패킷으로서는 512 byte(현재는 576 byte라는 경로는 거의 없고 1980년 당초의 사정을 사용하고 있다)를 넘어 버리면 경로에 따라서는 패킷이 분할된다. 1 패킷으로 처리될 수 있도록 RFC 1035에서 512 byte 이하의 응답 패킷으로 제한한다고 규정한다. 그래서 512 byte를 넘는 경우에는 TCP 프로토콜으로 응답한다.

 

비고

DNS 클라이언트(resolver) udp 프로토콜의 임의의 포트를 바인드 해서 문의하고 있으며 응답이 있을 때까지 바인드 한다. DNS 서버는 송신원 포트를 송신지 포트로 하고 송신원 포트를 53번 포트로 응답하는 것으로 도중의(내 통신을 제한하는) F/W를 통과할 수 있도록 설정되어 있고(라는 것이 일반적이다), resolver는 응답을 받을 수 있다. TCP 폴 백 할 경우 UDP 응답 패킷에서 TCP 프로토콜에 의해서 다시 접속 확립이 이뤄지고 TCP 프로토콜에 의해서 응답한다

  

출처: http://blog.development-network.net/ung/2011/07/tcp.html

 

저작자 표시
신고
by 흥배 2015.11.04 08:00

미국 오라클은 오픈 소스로 개발된 데이터베이스 "MySQL"의 최신 버전인 "MySQL 5.7"의 정식 공개를 발표했다(2015. 10. 19).

 

MySQL 5.7의 주요 특징은 다음과 같다.

 

실행 속도 향상

SysBench SysBench Read-only Point-Selects의 결과 1024 연결에서 MySQL 5.7 MySQL 5.6 3배가 되는 160만 쿼리/(QPS)의 값을 나타냈다.

 

InnoDB의 새로운 기능 등

성능 향상이나 병렬도 향상과 온라인 상태에서의 조작 향상, Spatial Index, 네이티브 파티셔닝 등의 새로운 기능이 추가.

 

리플리케이션 강화

멀티 소스 리플리케, 글로벌 트랜잭션 아이덴티화이어(GTIDs) 확장, 멀티 쓰레드화 된 종속에 의한 확장성과 가용성 향상 등.

 

새로운 네이티브 JSON 데이터형과 JSON Function

스키마레스 데이터를 효과적이고 유연하게 보존, 검색, 조작이 가능하고 새로운 내부 바이너리 포맷으로 SQL과의 통합이 쉽다.

 

 

이런 새 기능과 함께 MySQL 5.7에서는 약 1년마다 패스워드를 변경하는 것이 기본 설정된다.

 



출처: http://www.publickey1.jp/blog/15/mysql_573.html

 


저작자 표시
신고
by 흥배 2015.10.28 08:00
C++

WLW(Wonderlns Wars. 4vs4 전략 액션 게임 http://wonder.sega.jp/player/game.html ) 개발에 대한 경험담. 원문 자체가 번역하기 까다로워서 번역 상태가 좀 이상함 ;;;

 

 

 

최근 아케이드 게임 개발에 사용하는 기반은(Nu). Windows Embedded 8

 

stl은 표준, Boost, Zlib etc.. 원하는대로 아케이드 개발

 

프레임 레이트 30fps. CRI 미들웨어의 ADX2. 그래픽은 Acroarts 데이터 드리븐으로 사내 툴 사용.

 

C++ 툴계

C# 매칭 & 게임 서버는 C++.

DB Java & SQL.

STL은 컨테이너 조작으로 다양하게 사용

VS 2012 사용에 의해 일부 C++11 객체 지향 MVC 설계

 

병사 객체가 많이 나오는 거동은 기본

 

C++ 편리 기능

람다식. STL 알고리즘과 상성이 좋아서, 지금까지 콜백 함수 정의 부분과 사용 부분이 떨어져 있던 것이 한군데로 합쳐져서 상쾌. boost::bind투성이가 조금 좋아졌다.

std::function을 사용하여 식을 함수에서 반환 하는 것도 가능.

단 식이 너무 커지면 결국 보기 어렵게 되므로 적당히.

 

auto & decltype 를 컴파일러에 맡겨서 코딩이 상쾌. 쓸데없는 typedef를 없앨 수 있어서 편리.

auto &&(참조의 참조)에는 주의가 필요. →(정정)reference collapsing의 예로서 "&&에 대해서&가 우선한다"라는 것.

쓰는 법에 따라서 Reference Collapsing이 동작하거나 동작하지 않았는데 이를 몰라서 잠시 헤맸던 기억이...

 

range-based for로 반복. 함수가 필요 없다

 

std::tuple

구조체를 정의하는 것은 귀찮다. std::tuple를 사용하면 std::pair는 필요 없음. tuple의 구조가 달라졌을 때 주의

 

std::array

이터레이터를 사용할 수 있고, 범위 외 접근 체크도 쉬움. 예상 외로 전체 요소 비교가 편하다.

 

Scoped Enumeration통신 동기 · std::atomic

 

std::future & std::promise

어떤 처리 완료 결과를 비동기 얻을 때 편리하다. 다만 이것이 나중 문제로

 

static_assert

컴파일 시 에러 체크. 버그의 싹을 빨리 쌓아서 정말로 추천.

 

사용해본 C++편리 기능

final & override 수식자. 승계시의 관계가 알기 쉽고 승계 실수에 대한 오류를 뱉어 준다.

Boost.Property_tree. XML 형식의 파라미터 해석에 이용. 트리 구조의 범용 속성 관리에서 편리하다.

Boost.Preprocecor. 편리한 프리 프로세서 매크로 모음

 

고속화 하는 객체 수가 많아지면 컨테이너에 대한 접근 비용이 병목으로. std(list std::vector로 바꾼다.

상한이 정해진 것은 reserve 또는 std::array를 사용하도록 push**** emplace*로 치환.

원 알고리즘을 재검토한다.

컨테이너에 대한 액세스 범위 비를 한정하거나 처리

 

메모리 릭

std::thread, std::future, std::promise를 사용하면 메모리릭 발생. 아무래도 VS2012의 버그.

대응: boost가 제공하는 동종의 것으로 대체

 

 


출처: http://shinriyo.hateblo.jp/entry/2015/09/20/Event_for_Diverse_Game_Engineers

 

저작자 표시
신고
by 흥배 2015.10.26 08:00

데이터 분석에 대해서

LINE에게 데이터 분석이란 무엇인가

- Collecting: 데이터를 집약하다

- Reporting: 서비스 상황을 정확하게 보고하다

- Analyzing: 서비스 문제점과 개선점을 분석할 수 있다

 

3가지를 실현하도록 기술이나 환경을 제공한다.

 

 

중요하다고 생각하는 것

Collecting

- 합리적인 데이터의 집약

- 대량의 데이터를 유지하는 것

Reporting

- 유연한 데이터 집계

- 알기 쉬운 차트로 가시화

Analyzing

- 간편하고 고속인 데이터 추출

 

 

다른 요구

데이터의 이용자에 따라 요구하는 것이 다르다.

엔지니어의 목소리

UI 따위는 아무래도 좋으니까, (row) 데이터를 1군데에 모으고 자신들이 접근하기 쉽도록 해 달라.

플래너의 목소리

KPI을 낼려고 한다. 데이터는 예쁜 그래프로 가시화 되어 있는 것이 바람직하다. 그리고 Excel로 다운로드 할 수 있는 것이 매우 중요하다.

 

플래너는 엔지니어보다 데이터 가공을 요망하는 경우가 많다. 이들을 근거로 어떤 분석 환경이 필요할까?

 

 

for 엔지니어

엔지니어에 대해서는 특별한 것을 할 필요는 없다고 생각했다. SQL 등의 쿼리를 유연하게 발행할 수 있도록 한다.(엔지니어가 자유롭게 실행한다)API에 의한 일괄 처리와 연계할 수 있도록 한다.

다음과 같은 툴을 이용하고 있다.

- Fluentd: 유연한 로그를 수집 가능하게 하는 프레임워크

- Norikra: 실시간 집계 처리 시스템. 스트리밍 데이터 처리로 SQL를 이용할 수 있다

- Shibu/Shibu UI: Web기반 쿼리 도구와 작업 스케줄. Hadoop에 집약된 데이터를 다룬다.

 

데이터를 Hadoop에 집약하고, 쿼리를 입력하는 인터페이스로 사용한다. 실시간 처리에는 Norikra를 사용하고 있다.

 

For 플래너

가시화, 다운로드, No SQL(SQL을 안 써도 어떻게든 할 수 있도록 한다)이 포인트.

 

다음과 같은 툴을 이용하고 있다.

- Hadoop: 대규모 분산 데이터 처리 환경. 구성은 HDFS, MapReduce, YARN

- Hive: 대규모 데이터에 대한 DWH

- Presto: 분산 데이터 처리 엔진. Hive보다 고속 처리가 가능하므로 BI 툴의 백엔드에 이용

- Prestogres: BI Presto를 잇는 커넥터

- InfiniDB: MySQL 기반의 칼럼형 분산 DB. BI 툴과 클라이언트 툴에서 이용하는 데이터를 저장

- IBM Cognos: Web 베이스의 리포트 오서링 툴. 순위 변동의 히프 맵 등 복잡하고 수작업으로 만들면 힘든 그래프나 표를 적절한 비용으로 작성할 수 있으므로 이용하고 있다.

- Pentaho: OLAP(Online Analytical Processing)형의 다차원 분석용 시스템

 

엔지니어용으로 집계한 Hadoop 클러스터의 데이터를 플래너 용으로 유포하고 Presto를 경유하여 확인하도록 했다.

 

 

솔루션

이처럼 서두에서 언급한 과제를 해결하고 있다.

Collecting

- 합리적인 데이터의 집약 → fluentd

- 대량의 데이터를 유지하는 것 → Hadoop

Reporting

- 유연한 데이터의 집계 → Hive/Shibu/Norikra

- 알기 쉬운 차트의 가시화 → IBM Cognos, Pentaho

Analyzing

- 간편하고 고속 데이터의 추출 → Presto, InfiniDB, Pentaho

 

 

중요시하고 있는 것

위의 데이터 분석 기반을 구축, 운영하는 데 다음의 내용을 중요시하고 있다.

- API 연동 할 수 있도록 함

- OSS 채용. 부족한 것은 스스로 만들기

- 데이터를 가급적 은폐하기. 인증을 제대로 한 후 사용자 정보를 보여준다

- 사용자 추적은 하지 않는 것. LINE 사용자들은 매우 많아 한 사용자를 추적해도 서비스 개선으로 이어지지 않는다고 생각한다. 고생이 많지만 득은 없으니 일체 하지 않았다

 

 

 

 

분석 플랫폼 구성

글로벌화에 따른 다음과 같은 과제가 보였다.

서비스의 변화

글로벌화, 다양화와 함께 장수화(서비스의 연명)

사람의 변화

플래너의 증가

 

위 변화에 의해서 어떤 일이 일어나는가 하면 KPI가 서비스×메이저×차원으로 폭발적으로 증가한다.

 

국가별, 분류 별 등은 물론이고 서비스 운용 중에 역사적 배경으로 플래그가 존재하거나 사람이 늘면서 여러 요청이 있거나 하는 것으로 KPI가 증가한다.

KPI가 늘어나면 바빠지고, 아무도 KPI을 자세히 보지 못한다. 그리고 서비스 운영으로서 무얼 하면 좋을지, 점점 모르게 된다.

 

 

KPI의 변화를 사람이 아니라 기계가 본다

위의 대책으로서 팀에서의 생각은 KPI를 인간이 보지 않고 KPI의 변화를 전달할 것. 예를 들어 수 십 개국 수 만개의 스탬프의 KPI을 인력으로 보면 힘들기 때문에 자동화하고, KPI에 특징적인 변화가 일어났을 때, 플래너나 엔지니어에 통보하는 구조를 만든다.

 

KPI 모니터링 시스템 개발

KPI 모니터링 시스템을 절찬을 개발 중이고, 조금 있으면 운용을 시작하려고 한다.

- 모든 KPI 트렌드 분석을 자동화

- 시계열로 트렌드를 학습하고 예측 값을 산출

- 산출된 예측 치에 검출된 값이 비정상인가 여부를 보자.(긍정적 혹은 부정적이라도)

- 메일이나 채팅으로 경고를 전달

 

플래너용 시스템과 별도로 KPI 트렌드 분석 시스템을 설치한다. 여기에는 KafkaSpark를 이용한다. KPI을 시간 순으로 나열하고 Kafka로 전망치를 산출한다. 실제 값을 보고 통보해야 할지 아닌지를 판정하고 처리를 한다.

- Timseries Producer: 차원 별로 나누어 Kafka

- Timseries Monitor: 트렌드를 학습하고 모델을 구축하고 Kafka에 저장

- Notification Monitor: 전망치보다 사실 값이 크게 다른 경우 통지한다

 

 

 

정리

데이터 분석 환경은 Hadoop을 바탕으로 구축

- OSS 베이스로 부족한 부분이나 요망에 맞지 않는 부분은 스스로 추가한다

- 인증을 넣는다(누가 어떤 쿼리를 던지거나 감사 로그를 받는 등 데이터를 보수적으로 다룬다)

- 사용자 정보(사용자 ID)는 중요하지 않으므로 가급적 은폐하다

 

KPI 모니터링을 강화

- 늘어나는 KPI를 자동적으로 처리하는 구조를 만든다.

 


 

출처: http://dev.classmethod.jp/event/linedevday2015-b5/

 

저작자 표시
신고
by 흥배 2015.10.19 08:00
| 1 2 3 4 5 ··· 43 |