4월 3주차 소식들..

보안

오라클의 4월 정기패치 릴리즈 소식.. 49개 제품에 139개의 결함에 대한 패치가 릴리즈 되었다고.. 링크

Git 2.7.4 이하 버전에서 원격 코드 실행 공격과 관련한 결함이 발견 되었는데 맥의 커맨드라인 툴의 최신버전에 Git이 2.6.4가 포함되어 있어 문제가 된다는 소식.. 개인적으론 Homebrew를 통해 최신 버전을 사용중인.. 링크


소프트웨어

Windows 10 패스트링에 1주년 기념 버전 기능을 포함한 레드스톤 빌드 14328이 배포됨.. 이번 빌드에서 드라이버 모델에 뭔가 변화가 있었는지 일단 AMD의 최근 디스플레이 드라이버는 화면을 제대로 드로잉하지 못하는 문제가 있고 앞전 버전부터 사운드 컨트롤쪽 문제는 여전하고.. 메인 장비가 맥북 프로라서 롤백 안하고 디스플레이 드라이버는 마소 베이직 드라이버를 쓰고 있는데 이번 버전은 드라이버 쪽에 이슈가 좀 많은 느낌이.. 링크

리눅스 커널 스케줄러의 멀티코어 환경에서 성능문제에 대한 논문을 기반으로 패치가 적용되는 배포판이 나오기 시작 했다는 소식.. 링크 링크

Reactive Java 참고 자료들..

6월에 Spring Framework 5가 나올 예정인데 Reactor 프로젝트의 스프링 적용 버전인 Spring Reactive가 포함되어 나올 예정임. Spring Framework 4.3 부터 선행 적용하기로 되서 미리 사용이 가능한데 간략히 설명하면 기존의 멀티쓰레드 방식 코드에 이벤트 루프 방식이 추가되는 형태라고 볼 수 있는.. 단적으로 Node.js의 경우는 싱글쓰레드 이벤트 루프 방식임.

Spring MVC에서 서비스 클래스 영역까지는 비동기 코드 작성에 대한 패턴들이 나와 있었는데 이제 컨트롤러까지 확장되는 추세이고 데이터소스 영역도 이미 NoSQL 데이터베이스 같은 경우 Non-block I/O를 지원하는 JDBC 드라이버들이 제작되고 있는 상황.

기존에 Java의 비동기 코드가 .NET에 비해 깔끔하지 못하다는 해외 커뮤니티의 평가가 많았는데 여기에서 모티브를 얻은 RxJava가 인기를 끌면서 RxJava의 Spring 버전인 Spring Reactive가 메인스트림에 합류하는 분위기.

선행 학습을 위해 참고한 자료들의 링크를 남깁니다.

메인 동영상은 기존의 레거시 코드를 Java 8으로 마이그레이션 하는 방법에 대한 내용을 다루는데 주로 Stream을 이용한 람다코드와 Consumer를 이용한 리소스 관리에 대한 이야기를 하고 있다. 강연 내용중에 기억에 남는 글귀가 있는데 "A good code is like a story not like a puzzle." 이라는 말이.. Spring Reactive에 대한 자료는 이곳 을 참고할 수 있고 관련자료의 슬라이드 링크를 포함하고 있다. 슬라이드 중 Reactive Web Applications에 대한 강연 영상은 이곳 에서 확인할 수 있고 서블릿에서 비동기 서블릿의 진화 과정에 대한 간략한 내용과 Reactive Stream에 대한 이야기를 담고 있다. Spring Boot와 RxJava를 이용해 RESTful API를 만드는 방법에 대한 내용은 이곳 에서 확인할 수 있고 Observable을 이용한 데이터 핸들링과 컨트롤러의 비동기 응답과 테스팅에 대한 힌트를 주고 있다. Spring Reactive의 REST 컨트롤러 구성에 대한 코드 예제는 이곳 에서 확인 가능하다.

닌텐도NX와 관련한 루머..

사실 닌텐도의 차세대 기종에 대한 관심이 큰건 아니지만 AMD 방향성에 대해 문득 이런 저런 생각이 들어서 글을 남긴다.

원문은 링크의 글인데 GPU로 사용되는 칩이 차세대 아키텍쳐인 폴라리스가 탑제될 가능성이 커 보인다는 소식인데 그 이유로 Primitive Discard Accelerator(이하PDA)를 들고 있다. 우리나라식 표현으로 하면 폴리곤(Primitive) 제거 가속기 정도나 될려나.. 3D 그래픽은 평면에 보여지지만 우리가 보지 못하는 영역까지 처리 하는 부분이 존재 하는데 PDA는 이러한 부분의 불필요한 연산을 줄이는 역할을 한다고 하며 실재로 게임 개발자 컨퍼런스(GDC)에서 EA의 다이스팀이 프로스트바이트 엔진에 소프트웨어 기반의 Triangle Culling방법을 적용해서 테스트를 했을 때 75%를 넘는 폴리곤을 지오메트리 엔진으로 보내기 전에 쳐낼 수 있었고 최대 20%에 육박하는 성능 향상을 얻을 수 있었다고. 비슷한 소프트웨어 솔루션으로 AMD의 GPUOpen의 GeometryFX도 존재한다고 한다.

PDA의 경우 이렇게 소프트웨어적으로 구현되던 것을 하드웨어 블럭으로 구현한 것이며 닌텐도에서 이기능이 포함되기 원했다고 하는데 현존 28nm 아키텍쳐에 백포트 하기엔 R&D 비용이 부담이고 아무래도 AMD의 절망적인 현재 재정 상황 때문에 14nm 기반의 폴라리스 기반 커스텀 칩을 닌텐도의 부담을 줄이기 위해 일정 기간 수율과 상관없이 고정된 가격으로 공급하는 형태의 딜을 할 가능성이 있어보인다는 이야기가..

여하튼 최근 화제인 AMD의 비동기 컴퓨트의 경우 예전에 디버깅 하느라 페이스북의 비동기 통신용 프로토콜인 Thrift 소스를 뜯어본 기억을 더듬어 보면 결과적으론 잡의 싱크를 맞춰줄 큐가 존재한다던가 하는데에서 비동기 프로그래밍 기법에서 사용되는 개념들이 하드웨어적으로 구현되어 있는 느낌이라고 해야하나.. 아마도 GPU 자체가 거대한 멀티코어 연산장치의 클러스터 형태이다 보니 암달의 법칙을 극복하고 구스타프슨의 법칙을 적용할려고 노력한 결과물이지 않나 싶은..

VR시대에 접어들어 AMD의 목표는 2020년까지 한쪽눈당 16K해상도에 144Hz 이상의 리프레시율을 갖는 영상을 제공하는 것이다 보니 응답성을 높이고 좀더 높은 해상도를 표현할 수 있는 근본적인 문제를 해결할 수 있는 기술들을 계속해서 추가해 나가지 않을까 싶고.. 아마도 올해 초였던 것 같은데 백악관에 가서 지구온난화와 관련해 기후협약 문서에 서명했다는 기사를 봤던 기억이 나는데 앞으로 제품은 저전력 저발열을 추구하는 형태로 나오지 않을까 싶은.. NVIDIA의 경우는 해외에선 GimpWorks라고 욕먹고있는 GameWorks 강화에 주력하지 않을까 생각이들고.. 개인적으론 고자웍스라고 부르고 있음;;

CPU부문의 경우는Zen 아키텍쳐부터 SMT 방식으로 다시 회귀하기로 되었는데 최근 CMT 기반 아키텍쳐의 최적화된 퍼포먼스 관련해 간간히 나오는 소식을 보면 아무래도 불도저가 10년은 이른 아키텍쳐가 아니었나 싶기도... 아마도 HSA를 이용한 이기종 컴퓨팅이 활성화 되는걸 너무 빨리 올거라고 예측하고 FPU성능을 낮추는 형태를 택한게 아닌가 싶은데 개인적으론 올해가 이기종 컴퓨팅의 원년이 되지 싶은.. 한 5년쯤 뒤엔 다시 CMT 방식으로 회귀하는게 아닌가 하는 생각도 문득 해봅니다..

4월 2주차 소식들..

기타

넷플릭스가 마르코폴로의 첫시즌부터 HDR 4K영상을 제공하기 시작 했다는 소식.. HDR10과 Dolby Vision을 지원하는 장비에서 시청 가능하다고. 링크


소프트웨어

Atom 에디터의 MS 버전인 Code가 1.0버전이 나왔다는 소식..  링크


하드웨어

OpenPOWER 플렛폼의 CAPI 인터페이스에 대응하는 FPGA 가속기에 대한 소식.. 구글이 OpenPOWER 플렛폼을 채택하면서 FPGA 엔지니어 수요가 증가하지 싶은데.. 지금은 소프트웨어를 하고 있지만 학부때 Xilinx의 VHDL을 이용해서 SoC 프로그래밍을 했었고 하드웨어쪽으로 취업한 사람들도 S모 전자 가서 전혀 다른 일을 하고 있는걸 보면 다양성이라는게 참 중요한 것 같다는 생각이.. 링크


보안

URL 줄이기 기능의 보안 취약점이 발견 되었다는 소식.. 웹상의 공개된 링크에대해 사용하는 것은 괜찮지만 개인적인 자료의 공유에는 권장되지 않는 다고. 랜덤하게 값을 대입해서 공개되지 않은 URL정보를 알아낼 수 있을 만큼(Brute-force attack) 짧은게 문제인데 사실 요즘은 GPU를 이용한 Brute-force 툴도 있어서 암호화 규격도 최신 버전이 권장되는 시대이기도.. 클라우드 드라이브의 경우 일부 쓰기 권한이 있는 공유 폴더가 노출되게 되면 멀웨어가 자동으로 싱크 되면서 사용자의 PC에 다운로드 될 수 있는 문제가 있고 구글맵 같은경우 개인적인 정보들이 노출될 수 있다고. 구글은 현재 URL 줄이기 기능의 문자수를 2배로 늘인 상태라는 소식.. 링크

JBoss WAS를 대상으로 한 랜섬웨어 공격 가능성에 대한 소식.. Destiny라는 학교에서 사용하는 도서관 관리 소프트가 설치된 서버에 원격에서 접속 가능한 웹쉘을 통해 서버의 권한을 탈취할 수 있는 문제가 발견 되었다는데 탈취된 서버의 경우 웹쉘이 1개 이상 떠있을 거라고.. 국내에도 사용하는 곳이 있는지는 모르겠으나 서버도 이제 랜섬웨어의 타겟이 될수 있다는 소식.. 링크

더이상 업데이트가 지원되지 않는 윈도용 애플 퀵타임 플레이어에 보안 결함이 발견 되었으나 애플에서는 아무런 공지가 없는 상태라 언인스톨을 권장하고 널리 알려 달라는 소식이.. 링크

리눅스 재단의 프로젝트 중 하나인 웹사이트의 무료 인증 발급 시스템인 Let's Encrypt의 베타서비스가 종료되고 정식서비스로 전환 되었다는 소식.. 링크

4월 1주차 소식들..

하드웨어

IBM의 OpenPOWER 플렛폼이 구글의 데이터 센터에 채용될 예정이라는 소식.. 탈 x86을 선언한 구글의 선택은 IBM으로 결론이.. 연산 가속을 위한 Open CAPI/NVLink 인터페이스 채용이 특징인데 Open CAPI의 경우 범용 연산 가속기인 GPU 대신 FPGA 칩과 연결되는 인터페이스이다. 인텔의 경우 인수한 알테라의 FPGA칩을 통합한 커스텀 Xeon칩을 생산하고 있는 걸로 보이는데 아무래도 가격 하락의 압박을 받게 되지 싶고 AMD의 경우 Zen 프로세서부터 HyperTransport 대체 인터페이스가 나올 예정인데 IBM과 비슷한 형태로 가지 않을까 예상이.. 링크

소프트웨어

Windows 10에 네이티브로 동작하는 Ubuntu 리눅스의 사용자 모드와 Bash 쉘에 대한 소식.. 아마도 올해 가장 놀라운 뉴스 중 하나가 되지 않을까 생각이.. 서버 개발자 같은 경우는 더이상 맥을 고집할 필요가 없어져서 WWDC에서 애플도 뭔가 대응책을 내놓을 것 같긴 한데 과연.. 패스트링의 Build 14316 버전에 포함되어 배포됨.. 링크 링크

MS가 인수한 안드로이드와 iOS에서 C#과 .NET 구동을 위한 Xarmarin 프로젝트가 비주얼 스튜디오의 플러그인 제공과 함께 SDK를 오픈소스로 공개 할 것이라는 소식.. 링크


보안

Facebook의 WhatsApp 메신저가 End-to-End 암호화 기능을 기본으로 제공하게 되었다는 소식.. 링크

브라우저가 아닌 PHP, Python, Go 언어의 API에서 SSL/TLS 인증과 관련한 연구 결과 취소된 인증(Revoked Certification)에 대한 검사를 전혀 하지 않는 문제가 있어 관련 코드를 직접 작성해야 된다는 소식.. 링크

Node.js의 패키지 관리자인 NPM의 보안 취약점을 이용해 NPM 생태계 내부에 악성코드를 전파시킬 수 있는 문제가 발견 되었다는 소식..

관련된 몇가지 문제는 다음과 같다 npm install 명령어를 실행 해서 패키지를 설치 할 때 라이프사이클 스크립트가 같이 실행 되는데 명령어를 실행한 사용자의 권한에 따라 root로 실행될 수 있다는 점. NPM이 사용하는 SemVer 버전 관리 시스템 상에서는 패키지를 원하는 특정 버전으로 고정하는 것이 매우 힘들다는 점(내부 참조 패키지들 버전이 범위로 지정될 수 있기에..). NPM Author 계정의 자동 로그아웃 기능이 없기 때문에 패키지가 언제든 퍼블리싱 되어 악성코드를 포함한 패키지가 전파될 수 있다는 점. NPM은 리소스에 대한 검증이나 커뮤니티의 리뷰 절차 같은 것이 없다는 점들이 언급 되었다..

임시방편으로 라이프사이클 스크립트를 제한하는 방법은 다음과 같다.
### Install package without running scripts
npm install [pkgname] --ignore-scripts
### Disable scripts execution globally
npm config set ignore-scripts true

링크

3월 4주차 소식들..

보안

Java의 버전업과 함께 과거에 패치 되었던 결함이 다시 문제가 되었던 것에 대한 긴급패치가 릴리즈 되었다는 소식.. 특이한점은 이번 패치에서 이 문제를 전혀 새로운 버그로 규정했다는게(?).. 링크

무선키 해킹을 통해 차량 문을 열고 시동을 걸 수있는 24종의 차량에 대한 소식.. 링크


미분류

인텔을 CPU를 만드는 회사로 만든 주역이었던 앤디 그로브의 별세 소식.. 링크


소프트웨어

윈도10 레드스톤 빌드 14295가 PC와 모바일 버전 모두 패스트링에 배포됨.. 링크

경험 많은 자바 개발자와 아키텍트가 조심해야할 10가지 함정

원문 : http://zeroturnaround.com/rebellabs/watch-out-for-these-10-common-pitfalls-of-experienced-java-developers-architects/

좀 오래된 글이긴 하지만 아직도 유효한 글인듯 싶어서 정리해 봅니다. 코드 예제는 원문의 링크에..

#10 Dependency Injection(이하 DI)의 잘못된 사용 혹은 잘못된 이해
DI를 이용하여 미리 정의된 객체를 삽입 하는 것 까진 좋지만 다른 객체의 초기화를 위해 의존성이 삽입 된 객체에 트레인 코드(. 연산자를 이용한 기차 처럼 길게 연결된 코드)를 사용하는 것과 같은 형태는 좋지 않다. 그냥 DI만 쓰시오..

#9 Java를 Perl을 사용하듯 쓰는경우
시스템이 커질수록 런타임 보다 컴파일 타임에 문제를 발견할 수 있는 것이 중요하다. 팩토리 형태의 코드의 매게변수로 스트링을 사용하게 되면 잘못된 스펠링의 변수가 전달되면 런타임에 문제가 발생하는 경우가 있다. 자바는 타입 언어이기 때문에 enum과 같은 타입을 이용하여 문제를 방지할 수 있다.

#8 OOP를 이해하지 못해 C를 사용하듯 자바를 쓰는경우
if-else와 instanceof를 통해 객체를 구분하여 캐스팅을 통해 이용하기 보다는 인터페이스나 추상 클래스의 상속과 메소드 오버라이딩을 이용하는 편이 코드가 간결하고 유지보수가 쉬워진다.

#7 객체의 라이프사이클을 이해하지 못해 과도하게 Lazy loading을 사용하는 경우
Lazy loading을 사용하지 전에 체크할 요소.
1. 정말 고비용의 객체인건가?(그것에 대해 어떻게 정의 할 것인가?)
2. 객체가 사용되지 않는 경우가 있어 생성되어 있을 필요가 없는가?

Lazy loading을 사용할 경우 해당 객체의 정확한 로딩 시점을 알아야 하기 때문에 디버깅을 힘들게 할 수 있어 디플로이 시점에 모두 로딩되게 하면 관련 이슈를 사전에 발견할 수 있다. 개인적으론 개발과 배포 시점의 구성을 다르게 가져가는 방법도 고민해 볼만하지 싶은.. 

#6 'Gang Of Four'(GOF) 책을 종교와 같은 수준으로 의존 하는 경우
책의 적절한 사용법은 서문에 나와있으니 참고하시오... 이미 안티패턴이 된 #5의 싱글턴과 같은 패턴도 있음..

#5 안티패턴이 된 싱글턴을 사용하는 경우
최근의 DI 프레임웍에선 더이상 사용할 필요가 없어짐.. (사실 Spring 프레임웍의 경우 빈 생성시 기본 조건이 싱글턴인..)

#4 메소드의 가시성을 무시하는 경우
public 메소드의 경우 가능한 작고 간결해야 하며 재사용 가능한 라이브러리를 작성하는 경우 이러한 점이 더 중요해진다. private 메소드로 지정 되어야 할 메소드가 단위 테스트를 위해 public으로 지정되는 케이스가 종종 있는데 이런 경우는 지양되어야 한다.

#3 NIH(Not Invented Here) 증후군이나 프로젝트에 특화된 StringUtils와 같은 것으로 고통받는 경우
충분히 테스트 된 현존 솔루션들을 활용하라. 예를 들면 Apache Commons, Guava, joda Date와 같은 것들이 있다. 특히나 익숙하지 않은 영역의 작업을 하게 될 경우 이런 점에 대한 사전 조사를 충분히 하자.

#2 환경에 의존적인 빌드
환경에 의존적인지 체크할 수 있는 시나리오..
1. 어느날 회사에 새 개발자인 톰이 왔다.
2. 톰에게 기본적인 설명을 하였고 설명을 들은 그는 자신이 좋아하는 개발 환경으로 세팅 했다
3. 톰은 소스 저장소로부터 소스를 체크아웃 한다.
4. 톰은 어떤 빌드 시스템을 이용하는지 파악 하는데 5분을 소모했다.
5. 톰은 단하나의 커맨드로 어플리케이션 빌드를 실행하고 그것은 성공했다.

조건을 만족하지 못한다면 문서화와 빌드시스템에 대해 다시 생각해볼 필요가 있다.

#1 리플렉션/인트로스펙션을 사용하는 경우
리플렉션은 이슈가 발생할 경우 이해하기 어렵게 하고 디버그가 힘들어지며 고치기 어렵게 만든다. 리플렉션을 사용하는 것은 시한 폭탄을 심는 것과 같다. 리플렉션을 사용하지 않더라도 잘 설계된 객체의 계층적 구조를 이용해 좀더 깔끔하게 해결할 수도 있다.

보너스 : 정말로 병목을 유발하는 요소가 어디인지 아는 경우에만 최적화를 시도하라
추측하지 말고 측정하라!
1. 현재 시스템을 유효한 측정 방법을 이용해서 벤치마크 하라
2. 변경을 가한다.
3. 다시 벤치마크 한다.
4. 가해진 노력과 퍼포먼스 향상 비율에 대해 평가한다