자, 자바커들아, 게이물 시작하지. Porject Jigsaw 통과.

지난 6월 27일, 내 예상과는 달리 직쏘가 통과되어, JDK 9에 당당히 포함할 수 있게 되었다.
직쏘 반대하느라 A4용지 30여페이지를 날린 레드헷만 끝가지 반대 입장을 고수했고, 나머지는 오라클 영업력에 뻑이 갔는지 모두 찬성했다고 한다.

자바 개발자들에게 여태까지 버텨왔던 하위 호환성. 이제 개나 주게 생겼다.
하지만 그건 문제가 아니다. 왠만한 언어 스펙도 이런 고통을 안고 업그레이드 했다.
가장 대표적인 게 Python인데, 유니코드 지원이 강화한 대신 유용(?)한 API를 삭제했다고 원성을 높여
아직도 2.7을 쓰는 프로젝트와 제품이 즐비한 상황이다.
자바도 뭐 이미 그꼴 날 건 뻔할 뻔자지만, 당분간 자바개발자들은 임베디드나 모바일 계통이 아닌 이상은
계속 Java 8을 보고 있을 것으로 보인다.

직쏘를.araboja

정식 명칭으로 “자바 플랫폼 모듈 제계(Java Platform Modulule System)”라는 이름을 가지게 되었으며, JSR-277 번호를 가지고
2011년 프로젝트를 시작하여 원래 자바 7에 추가할 예정이었다. 하지만 구조적 문제가 해결되지 않아 자바 8에서도 보류하는 아픔을 겪었다.
직쏘에 기대를 거는 이유는 하나다. 여태까지 고질적인 자바의 문제를 해결할 핵심 기능을 가지고 있었기 때문이었다.
자바의 고질적인 원흉인 캡슐화 문제는 뭐 이미 옛날부터 제기해왔지만, 당시 닫혀 있었던 구조상 해결할 수 없어 그저 수용만 했던 개발자들이 대부분이었다.
하지만 자바의 오픈 이후 이를 개선할 수 있는 움직임이 생겼으며, 이 중 하나가 바로 직쏘다.

대부분의 자바 개발자는 이런 반응을 보일 것이다.

  • 크로스 플랫폼으로 잘만 돌아가고 있는데 왜?
  • 메모리 문제? 그저 사양만 늘려주면 빠르고 깔끔하잖아?
  • 경량화? 경량화 할 디바이스가 어딨다고…

근데, 리조트 프로젝트 했었는데, POS를 자바로 개발하려는 시도가 있었다. 하지만 낮은 사양에 높은 처리능력을 요구하기에 자바는 맞지 않았고 닷넷으로 갔다.
관련 프로젝트를 해본 사람이라면 안다. 왜 자바를 POS에 접목시키는 게 쉽지 않았는지. 웹 말고.
하지만 모듈 시스템을 탑재하면 더 가벼워진 이미지로 적은 메모리로도 POS 시스템을 돌릴 수 있다고 생각해보자.
속 시원하지 않겠는가?

이 중 큰 원인이 바로 자바의 상속 시스템인데. rt.jar 파일 아는가? 자바에 모든 API가 있는 라이브러리다.
그만큼 무겁다. 더럽게 무겁다. 모든 자바 프로그램은 절대 이 라이브러리를 거역할 수가 없다.
닷넷의 경우 얘기가 틀린데, 닷넷은 GAC이라는 레지스트리급 쓰레기가 있지만, 대신 모듈이 분리되어 필요한 것만 갖다가 쓸 수 있다.
그래서 시작 속도 뿐 만 아니라 성능 면에서도 유리하다. 예를 들어,
자바는 웹을 아예 안 써도 웹 API를 가지고 가야 한다. 하지만 닷넷은 안쓰면 안가져가도 된다. 이 차이인 것이다.
그러나 직쏘와 함께하면 자바도 웹 안쓰면 웹 안들고 가도 동작하도록 할 수 있다. 말 다했다.

한마디로 자바의 입지를 한 층을 넘어 더 다양한 분야에 뛰어들게 해주는 샘물같은 존재다. 그걸 모르는 자바 개발자들은 지금에도 만족하며 잘 개발하고 있겠지만.
게다가 이런 현상을 유지하는 데 한몫한 업체가 바로 의외에 있었는데, 구글이다. 그렇다. 안드로이드다.
하지만 안드로이드는 개발 시 자바를 언어로 쓸 뿐, 오라클의 JVM을 쓰지 않고 아예 독립적으로 개발한 JVM으로 돌리고 있다.
게다가 딸려나오는 라이브러리도 많다. 그리고 이들 모두를 상속받아야 안드앱 개발이 가능하다.
따라서 모듈 시스템에 수혜를 받기엔 가상머신부터 틀려서 일단 패스하고.

이클립스 실행하는 데 느리다고 생각하는 사람 많을 거다. 더럽게 무겁기도 유명한 비주얼 스튜디오보다도 느리다. 인텔리제이도 시작 속도 예외는 없다.
그걸 빠르게 해 주겠다는데. 왜?

직쏘가 어떻게 구현되고 돌아가는지는 얘기가 너무 길어지니 직접 검색해서 보도록 하자. 한글 블로그에도 많이 소개되어 있다.

직쏘의.problem

이렇게 자바에게 날개를 달아주는 녀석이지만, 많은 자바 개발자들이 우려하고 있는 점이 있다면 바로 하위 호환성을 꼭 빼놓을 수 없다.
자바 1.5부터 추가된 제네릭의 경우는 객체 소멸(Type Erasure)을 통해 컴파일 때에만 제네릭을 검사하고 런타임 상는 제네릭 없이 돌아가도록 구현하였다.
그래서 닷넷과는 달리 Map 클래스와 Map<Key, Value> 클래스. 제네릭이 있던 없던 같은 클래스로 취급하는 것이다. 닷넷은 다른 클래스로 취급한다.
결국 1.4 때 제네릭 없었던 클래스처럼 써도 무방할 정도인 것이고, 성능상 이점이 없으며, 그저 자바의 방향인 Strong Typed에 부합될 뿐이었다.
그리고 자바 1.8부터 도입된 람다식의 경우 이미 익명 클래스로 충분히 소화해낼 수 있기 때문에 간소화된 것만 빼면 하위 호환성에 큰 지장은 없다는 것이다.
하지만 직쏘는 그 이전 버전에 대체할 수 있는 환경이 아예 없다. 하위 호환성을 유지하려면 직쏘를 아예 쓰지 말아야 할 정도이다.
여태까지 하위 호환성을 최대한 생각했기에 개발자 입장에서는 큰 난관이 아닐 수 없다.
만약 버전을 올리고 개발했을 때, 문제가 생기면 해당 버전에 맞게 개발하고 컴파일 하면 됐다. 하지만 직쏘는 그게 안된다. 다 버려야 한다는 것이다.
그래서 자바 API를 닷넷에 쓰게 해주는 IKVM.NET 개발자는 모듈 시스템의 복잡도 때문에 더 이상 새 자바에 대응하지 않겠다는 공식 입장을 피력할 정도.
그리고 이 불안은 현재진행형이며, 정식 버전이 나오면 1.9를 바라볼 사람이 얼마나 될 지 의문이다.

자, 자바 개발자들이여, 이제 게임을 시작하지. 직쏘.

composite / 2017년 7월 5일 / Piss Development / 0 Comments

프로젝트 직쏘는 희망이 없다?

자바 9가 올해 7월 말 즈음 출시될 가운데 안타까운 소식이 들어왔다.

바로 JCP(Java Commnity Program) 총괄 리뷰에서 프로젝트 직쏘가 많은 반대에 부딪혀 빛을 못볼 위기에 처해 있다는 것이다.
DZone – Java Zone – EC Rejects Jigsaw

직쏘 프로젝트 참여자들은 30일 내에 보완 후 다시 리뷰를 진행해야 하는데,
다음 리뷰에서 실패하면 직쏘는 자바 9에서도 볼 수 없는 시스템이 될 것이다.

프로젝트 직쏘는 익히 알다시피 하여 짤막하게 소개한다. SI/SM 개발자들은 관심없이 1.6 이하 버전이나 쳐 만지겠지만.
현재 자바는 JVM 내에 돌아가는데, JVM이 자바에 있는 핵심 라이브러리 외에도 사용자가 추가한 라이브러리 모두 안고 가기 때문에
성능 문제는 여러 방면에서 제기된 문제가 있었으며, 이로 인해 특히 임베디드 장비에서 자바를 꺼려하는 이유이기도 하다.
그래서 안드로이드 자바는 아예 달빅 등으로 자바를 재구성 해서 안드로이드 전용 자바 환경을 만들었던 이유이기도 하다.
물론 안드도 성능 이슈는 피할 수 없긴 매한가지지만.

어쨌든, 이걸 해결하고자 모듈 시스템으로 필요한 라이브러만 쓰고, 쓰는 곳으로만 최적화하고, 이식 가능(Portable)한 프로그램을 만들기 위해
꾸려진 프로젝트가 JSR 376q번 프로젝트 직쏘다.

하지만 프로젝트 직쏘는 당연하겠지만 많은 반대에 부딪혔다. 특히 이번 반대의 가장 주역이 바로 상업용 리눅스로 유명한 대기업 “레드햇”인데,
프로젝트 직쏘에 대한 문제점을 34페이지를 썼다.

DZone에서 언급한 주요 내용은 아래와 같다.

The patterns introduced within Jigsaw are (in some cases) going to be extremely difficult to fix even in a later release, and will create backwards- and forwards-compatibility problems that will be very difficult to unwind

직쏘에서 제시한 패턴은 이후 자바 출시를 할 때 여러 면에서 거대한 장벽을 유발한다. 그리고 상위, 하위 호환성 측면에서도 난관이 많을 것으로 보인다.

Due to lack of one to one mapping of use cases (or sufficient interoperability capabilities) and other restrictions, we are concerned that there will likely be two worlds of Java software development: the Jigsaw world, and the “everything else” world (Java SE Classloaders, OSGi, JBoss Modules, Java EE, etc)

일대일 연계에 대한 문제와 여러 제한 사항으로 인해 우린 자바 개발자들이 직쏘 세계와 현재 자바 세계(Java SE Classloaders, OSGi, JBoss Modules, Java EE, etc)를 두가지로 나눠 개발하는 광경을 볼 지도 모른다.

그렇다. 레드햇은 자바의 기본적인 목표인 “하나의 코드를 여러 플랫폼으로”에서 거리가 먼 직쏘에 거리를 둔 것이다.
이외 IBM, SAP 등 여러 거대 개발기업도 반대 의사를 표시했으며, 세계에서 가장 큰 자바 커뮤니티인 런던 자바 커뮤니티는 강한 반대 의사를 표시했다고 한다.
우리가 많이 쓰는 개발 툴 제작사 이클립스 재단도 반대 의사를 표시했다.

물론 찬성도 있다. 자바를 주도하는 오라클, V2COM, 후지쯔 등인데,
후찌즈는 “EC 회원들이 직쏘에 많은 집중을 하는 만큼 다음 투표에서 해결되길 바란다.” 라며 찬성 의사를 표시했다. 그렇다. 실질적인 반대 의사인 것인데 찬성한 것이다.
SouJava 라는 업체는 처음에 찬성을 하다 반대 의사를 표시했는데. 역시 사용자 접근성 결여를 이유로 반대 표시를 한 것이다.

결국 접근성 문제와 여러 제한 사항, 호환성 문제를 이유로 많은 커뮤니티와 업체에서 반발한 것이다.
우려한 대로 말이다.

닷넷 진영에서는 프로젝트 직쏘 때문에 다 갈아엎어야 하는 iKVM.NET 개발을 포기하기로 했고, 자바를 기반으로 한 스칼라나 코틀린에서는 대응이 안되어 있는 상황.
이렇게 준비가 되어 있지 않은데 우린 대체 무슨 희망으로 직쏘를 지지했던 것인가를 다시한 번 생각하게 한다.

내가 보건데 자바 9에서도 직쏘는 보기 힘들 것으로 보인다.
별 거 아닌 것처럼 보여도. 자바 2.0이면 모를까 자바 1.x 에 직쏘를 넣는다는 건 엄청난 변화이고, 기존 자바 개발자들이 한국 SI/SM 개발자처럼 정체된 자바 환경을 접해야 할 지도 모르기 때문이다.
직쏘를 적용하는 순간부터 하위 호환성을 포기해야 하고, 상위 호환성을 걱정해야 하며, 그리고 자바 직쏘에 대한 또다른 지식과 구조를 개발자들이 알아야 하니, 기존 개발자들에게는 큰 난관이 아니 예상할 수 있겠는가.

composite / 2017년 5월 18일 / Piss Development, Waldo Translation / 0 Comments

자바 개발시 Hot Swapping 종류

Java Server Hotspot

  • JDK 설치하면 기본적으로 제공
  • 메소드 내용을 수정한 뒤 재시작 없이 반영
  • 그게 다임. 내용 수정 외의 수정은 모두 재시작해야 함.

jRebel

  • 상용으로 유료 솔루션
  • 자바 코드 어떻게 수정해도 재시작 없이 반영
  • Spring 플러그인에 한해 XML 설정도 재시작 없이 반영
  • 왠만한 WAS 및 환경에서 사용가능 (국내한정 JEUS는 되긴 하지만 공식 미지원)
  • 적은 코드 변경에는 아주 빠른 Reload
  • 변경 코드가 많을수록 Overhead 심각 (이건 어느 솔루션도 못피함. 이건 무조건 재시작삘.)

Spring loaded

  • 무료이며 오픈소스
  • 스프링만 적용 가능 (전자정부는 되겠지 뭐)
  • 스프링 자바 및 XML, properties 변경 시 적용
  • 스프링 외 플러그인 설정파일 변경 지원 안함.
  • 현재 톰캣만 지원. 나머지 WAS 보증불가
  • 몇몇 사용자에서 재시작이 안되는 문제가 보고되고 있음

Spring boot devtools

  • 무료이며 오픈소스
  • Spring boot만 적용 가능 (상속 때문에 일반 spring 적용 불가)
  • spring boot 및 상속 가능한 모든 자바 및 설정 파일 변경 시 적용
  • spring boot 돌아가는 어떤 WAS 상관 없이 지원 (JEUS는 모름)

닷넷커: ㅋㅋ ASP.NET (MVC 포함)은 기본 전체 홧스왑 수준인데 고생한다.
자바커: MS 종속적이고 비싸기만 하며 오픈소스 없는 놈이 말이 많어.
닷넷커: 이제 크로스플랫폼 지원하고 소스는 이미 오픈된지 오래임.
자바커: 그러던가. 어자피 한국에서는 영원히 잊혀질 기술임 ㅗ.

composite / 2016년 5월 12일 / Piss Development / 0 Comments

또다른 오픈소스 IDE: Consulo IDE

흐음… 한국에 자바 IDE 쌍벽은 아무래도 Eclipse 와 IntelliJ 일 것이다.
Netbeans 도 있긴 하지만 쓰는 사람이 드물어서…

어쨌든 간에, JetBrains 에서 .NET IDE 만든다고 한 지 2주.
근데 댓글에서 심상치 않은 IDE를 발견했다.

이름하여 Consulo IDE 이다.

Consulo는 IntelliJ IDEA Community Edition의 쉘 전신인 IDEA IDE 베이스로 만들어진 오픈소스 IDE이다.
현재 안드 공식 개발 툴인 IntelliJ IDEA 기반의 쉘 UI 프레임워크가 오픈했다라…
엉? IntelliJ에 썼던 UI가 오픈소스라고?

정말 있다. 오픈소스로. IntelliJ Community Edition

그렇다. 커뮤니티 에디션에 한해서 오픈소스로 공개하긴 했다.
게다가 Apache 2.0 라이선스다. 상업적으로 써도 문제는 물론 없다.
아니었으면 상업적으로 안드로이드 개발은 물건너 갔을테니.

어쨌든, 다시 Consulo로 돌아가자.

Consulo는 현재 C#, Javascript, Java 등을 지원하며, 모든 언어를 지원하는 하나의 IDE로 통일하겠다는 목표를 가지고 있다.
안타깝게도 안정된 버전이 아니라서 실무에 쓰기는 조금 어렵지만,
유니티 개발자들이 이 IDE를 주목하고 있다.
왜냐?
모노IDE가 좆같거든.

인텔리 기반이라 인텔리 플러그인을 지원 하기는 한다. 조금 손을 봐줘야 한다고 한다.
마이그레이션 과정을 거치는데, 아무래도 라이선스 이슈 때문이다.
불편하더라도 인텔리제이와는 분리해야 써야 하는 이유이기도 하다.

Add a plugin

JetBrains 에서 Project Rider 로 C# IDE를 꾀하고 있고.
아마 유니티 개발에서 하나의 변수로 떠오를 가능성이 큰 상황이다.
어자피 모노와 닷넷은 API가 틀리지 언어 구조와 스펙까지 틀린 건 아니니
지켜봐야 할 내용이고,

거기에 오픈소스로 강공을 펼칠 Consulo IDE에도 주목할 필요가 있다.

IDE 전쟁이 시작되는 것이다. 우오.

composite / 2016년 1월 28일 / Piss Development / 0 Comments

Javascript 파이프라인

어찌보면 나도 간과한 일일 수도 있다.
Javascript 로 열심히 삽질하다 보면 역시 콜백 늪에 안빠져본 자스 개발자는 없을 것이다.
이런 콜백 지옥을 빠져나가기 위해 여러 패턴이 도입되었고, 그 중 대표적인 게 Promise 패턴, Generator, 그리고 async/await 이다.

마침 Play.node() 라는 컨퍼런스가 이미 진행했었고, 공개된 발표자료 중 바로 한눈에 들어온 세션이 있었는데,
그게 바로 Session 3. Pipe: 콜백지옥의 또 다른 거짓 선지자 였다.

그리고 콜백 지옥을 빠져나갈 수 있다는 여러 선지자들, 그리고 세션 발표자가 이를 개선하기 위해 만든 또다른 선지자를 소개하는 시간이었다.
필자는 여기에 참여하지 못해 이 세션의 처음과 끝이 어땠는지는 잘 모르겠지만, 자스 개발자들은 뭔가 너무 차별화된 형식으로 접근하려는 시각이 눈에 띄었다.

그렇다. 너무 차별화되어 다르게 보일 수 있지만 결국 똑같은 패턴.

그게 바로 작업 흐름 관리이다. 영어로 Task flow management.
이를 관리하기 위해 보통 제공되어 사용하는 패턴이 바로 Pipeline pattern 이다.
작업 단위 간 통신을 위해 꼬리를 물고 무는 패턴.

자바스크립트는 싱글 쓰레드다. 그렇기 때문에 얻을 수 있는 이점이 있지만 이를 위해 잃은 많은 것들이 있다.
얻을 수 있는 이점이 바로 비동기 이다. 자스는 비동기에 능하다. 어떤 작업 흐름을 미꾸라지처럼 빠져 나가는 재주를 지녔다.

다른 언어에서도 이런 미꾸라지같이 작업 흐름을 마칠 수 있는 이점을 수용하려 하고 있었고, 이렇게 생겨난 것이
자바의 Future<T> 와 닷넷의 Task<T> 이다. 그리고 닷넷 4.5 에는 asyncawait 문법으로 비동기 작업 흐름 관리에 종지부를 찍을 것 같았다.
자스에서도 이런 종지부를 받아들여 ES7에 들어올 예정이긴 하지만… 언제 들어올지는 아직 모른다. 그렇기에 기대에 부응하지 못하고 오늘도 자스는 작업 흐름을 관리하고 있다.

동시성과 비동시성을 합쳐서 여러 케이스로 작업 흐름을 관리하는 업무는 의외로 많다.
하지만 많은 개발자들은 이를 동기적으로 처리하려고 한다. 왜냐, 그게 편하고 순서있고 보기도 편하기 때문에.

하지만 위 소개된 세션을 통해 이런 자스의 고충을 이해할 수밖에 없는 이유가 있다. 아니. 이해해야 할 수밖에 없다.
바로 자스는 아까 말했듯 싱글 스레드이다. 아까 말했듯이 자스는 어찌보면 너무 많은 것을 잃은 것만 같다.
쓰레드를 여러 개 사용할 수 있는 자바나 닷넷 등이 아니다 보니 쓰레드 단위로 Pipeline 을 갖는다는 것은 매우 어려운 일이다.
그래서 위 세션처럼 비동기 방식의 장점을 살려 바로 이벤트를 통해 작업 흐름을 관리하는 파이프라인을 구현한 것이다.
여기서 가장 핵심 공통점은 바로 작업 간 데이터를 주고받아야 한다. 그리고 이 때문에 구현한 것이다.
자스는 작업 흐름 관리를 위해 콜백 간에 데이터를 주고받아야 하는 일이 많다. 그렇다 보니 전통적인 방법으로는 콜백 지옥이 발생하는 것이다.

그렇다. 자스도 결국 파이프라인 패턴 써야 한다. 작업끼리 물고 물고 늘어진다. 이건 어느 언어나 업무 흐름에 피할 수 없는 숙명인 것이다.
자스는 작업을 관리하는 방식이 다를 뿐, 결국 작업은 파이프라인인 것이다. 어쩌면 동시에 해야 할 수 있고, 그리고 동시에 모두 끝나야 대기탔던 작업 해야 하고.

WE ARE THE HELLO WORLD.

참고자료

Play.node() 발표자료 http://d2.naver.com/news/2602887
자바 : 파이프 스트림과 쓰레드간 데이터 교환 http://javacan.tistory.com/entry/72
닷넷 : C# 쓰레드 이야기: 11. 이벤트(Event) http://www.hanbit.co.kr/network/view.html?bi_id=360

콜백지옥의 또 다른 거짓 선지자 관련 또다른 참고자료

Node.js Flow (part 1) – Callback Hell vs. Async vs. Highland http://blog.vullum.io/javascript-flow-callback-hell-vs-async-vs-highland/
Node.js Flow (part 2) – Fibers and Generators http://blog.vullum.io/nodejs-javascript-flow-fibers-generators/
yortus/asyncawait – Callback heaven for Node.js with async/await https://github.com/yortus/asyncawait

composite / 2016년 1월 6일 / Piss Development / 0 Comments

Cloud IDE를 통해 우리가 얻을 수 있는 프로젝트 이점들

Eclipse. 국내 자바 개발자들의 국민 IDE 도구이다.
현재 릴리즈는 MARS 이며, 나온 지 얼마 안됐다. Luna 를 쓴지 얼마 안됐는데…
하지만 아직도 꽤 프로젝트들이 Indigo 및 심지어 Galileo 버전을 쓰기도 한다. ㄷㄷㄷ
그리고 어떤 이들은 디스크 오버헤드가 큰 개발환경에 질려 유료 IDE인 IntelliJ IDEA 를 통해 모던 웹 개발을 꾀하기도 했다.
게다가 구글은 자사 안드로이드 개발에 Eclipse 를 떠나보내고 IntelliJ 를 수용하여 많은 국내 안드개발자들의 공분(?)을 얻었다.

그런 말도 탈도 많은 Eclipse에서 며칠 전 Che 버전이 오픈됐다.
몇년 전부터 웹 기반 Eclipse 개발을 발표했고, 그리고 꾸준히 개발해왔다.
그리고 이제 “쓸 수 있는” 웹 기반 Eclipse IDE가 생겼고, 이 버전 코드명칭을 Che 로 칭했다.
근데 Che가 뭔지 아직 모르겠다. 좀 더 자료를 수집해야겠다.

어쨌든, 이녀석은 웹 기반의 IDE이다.
Atom같은 쉘을 통하여 자체 브라우저를 통해 응용 프로그램 행세하는 에디터는 아니고 그저 브라우저에 돌아가는 녀석이다.
이녀석은 서버로 운영되며, 서버 내 개발자들에게 같은 개발 환경을 제공한다.

그리고 또하나 흥미로운 기능이 있다면 바로 Workspace 서버이다.
이클립스는 Workspace를 잡고 여기에 설정을 관리하고 개발 환경을 만든다.
이런 Workspace가 이제는 서버에서 관리되어 개발자들의 용량 부담을 최소화 했다.

Eclipse Che

요렇게 생겼다. 뭔가 인텔리제이같이 생겼다고? 디자인만 그럴 뿐 순전히 Eclipse 환경이다.
그리고 이 같은 개발환경을 여러 개발자에게 워크스페이스와 같이 제공한다.

그렇다면, 이런 개발 환경에서 얻을 수 있는 개발 이점은 무엇이 있을까?
가장 많이 쓰이는 자바 개발 환경 기준으로 설명하겠다.

1. 개발환경을 매우 쉽게 세팅할 수 있다.

한국의 SI 스러운 개발환경. 솔직히 말해 A부터 Z까지 표준을 맞춘다는 건 마음에 안들고 너무 꽉막힌 생각이다.
한국의 개발환경은 그리고 A-Z 모두 맞춰줘야 한다. 심지어 경로까지… 워워…
아무렴 어떤가. 클라우드 개발환경은 개발자들의 쓸데없는 개발환경 세팅 시간을 줄여준다.
관리자가 그저 개발자 계정과 워크스페이스 권한만 주면 개발자는 브라우저를 통해 접속만 하면 개발환경 세팅 끝이다.
물론 DB의 경우는 얘기가 틀리겠지만 Tadpole DB Hub를 통해 개별 관리하거나 하면 시간은 더 줄어들겠지만 그럴 일은 없어보이고…

2. 익숙한 개발환경을 그저 클라우드로 즐길 뿐이다.

Eclipse Che 는 Eclipse 기반이다. 당연히 자바로 만들었고, 자바로 돌아간다. 자바 개발환경이 모범을 보여줘야지.
자바 개발자들에겐 당연히 Eclipse 는 친숙함 그 자체이다. 이 친숙함 그대로 클라우드로 즐기면 된다. 뭐가 문제인가?
개인 프로젝트 개발해야 하는데? 그러면 별도 IDE를 쓰면 되잖나. 개발환경 분리되는게 일상인 프리랜서가 뭔 걱정인가?

3. 보안과 통합이 매우 쉽다.

워크스페이스를 서버가 관리한다는 게 무슨 뜻이겠는가? 개발 소스를 자기들이 관리하겠다는 거 아닌가?
그렇게 되면 개발자들이 개별로 소스와 구조를 가질 필요가 없어지고, 그리고 이로 인한 소스 코드 유출 피해를 줄일 수 있지 않겠는가?
아직 소스 구조를 다운로드 받기 기능과 이에 대한 권한에 대해서는 확인이 필요하지만, 만약 있다면 개발 보안도 한층 업그레이드 될 것이다.
그리고 개발자가 이제 철수한다면 철수할 개발자에게 권한을 빼면 끝이다. 뭐 삭제
또한, 통합을 하고자 한다면 그저 관리자가 Eclipse Che 서버만 관리하면 된다. 모든 개발자가 다 적용된다.
물론 각 개발자별 플러그인이 필요할 것이고, 이를 관리자가 맞춰줄 수 있다. 그렇지 않다면 분명 불편할 개발자도 있을 테니.
SVN? Git? 다 된다. 버전 관리는 공통으로 한번 세팅하거나, 사용자별 세팅하면 땡이다. 그다음 지속적 배포 환경 고민을 하면 된다.

4. 개별적 개발상 이슈를 최소화할 수 잇다.

개발하다보면 예상치 못한 문제에 직면한다. 갑자기 개발자 컴퓨터가 맛이 가버리거나, 팅기거나 등등…
여태까지 작업한 것들이 날아가는 모습을 본 개발자에게는 허망함과 부담감이 가득할 것이다.
또한, 개발 환경이 반드시 100% 맞춤형이 아니다 보니, 어떤 컴퓨터에서 잘 안돌아가기도 한다.
그래서 어떤 프로젝트는 심지어 OS와 브라우저 등 아주 원초적인 환경까지 통일해야 하는 표준을 규정하여 개발시키기도 한다.
피곤하다.
웹 환경은 그딴거 없다. 웹만 되면 된다. 구버전 브라우저만 아니라면 개발할 수 있는 모든 게 다 된다.
Eclipse Che는 그렇게 만들어졌고, 그게 목표이기 때문이다.
웹 브라우저 외에 어느 환경도 구애받지 않는 개발 환경이라면 피곤할 필요도 없지 않겠는가?
게다가 관리자가 허락만 한다면 재택 근무도 가능하고. 물론 그럴 가능성을 염두해 둘 리는 없겠지만.

이제 개발환경도 새바람이 불고 있다.
여태까지 나온 임대 기반 개발환경이 싫다면 언제든 개발환경을 구축하여 제공할 수 있다.
서버 기반의 개발환경으로도 데스크탑 못지 않은 개발환경을 구축할 수 있는 시대도 도래했다.
이를 친숙한 Eclipse 에서 Che 버전을 통해 제공할 것이다.

이제 자바 개발자들에게 고민해야 할 것은 무엇인가?
바로 인식의 전환이다.
다른거 다 필요없다.

composite / 2015년 12월 28일 / Dog's bullshit / 6 Comments

Symbol 프로그래밍?

https://en.wikipedia.org/wiki/Symbol_(programming)

심볼. 굳이 우리말을 쓰자면 기호. 기호 개발. (뭔가 어색하다?)

오늘 페북에서 ECMAScript 6 표준에 Symbol이 정의되어 누군가가 MDN에 번역해 주었다.
Symbol – Javascript | MDN
심볼. 아마 자바, 닷넷, 자스 개발자 등에게 어찌보면 생소한 개념일 수 있다.
하지만 루비 개발자나 Object-C 개발자는 이미 있기 때문에 알고 있을 것이다.
이 심볼 개발방법은 여러 스크립트 언어 등에서 채택한 개발론이다.

간단하게 설명하자면, “가장 유일한 식별자”다.
뭐?
루비(Ruby)의 심볼이란?

정의는 한 번. 더 이상 변경할 수 없는 값이다.
여기까진 상수와 비슷한 개념이다.
그렇다면 값 비교 시 “A” 와 “A”가 같다? 심볼은 그딴거 없다.
그렇다. 심볼의 값은 일종의 사람만이 식별하기 위해 존재하는 값일 뿐.
문자열 값은 리터럴을 정의할 때마다 메모리가 늘어난다. 설령 변수를 지정하던 상수를 쓰던.
간단하게 생각해보자.
“A” “BC” “DEF”… 이들은 언제 바뀌지 못하기 때문에 불명확한 메모리를 할당받으며 서 있다.
당연히 그런 만큼 메모리를 잡아먹는다.
하지만 심볼은 딱 정해진 메모리만큼만 먹는다. 바뀔 일도 없기 때문에. 확장할 일도 없고.
그러니 메모리 애끼는 효과가 있다.

그렇다면 어따가 쓰냐고?
가장 쓰임새가 많이 쓰이는 곳이 바로 “해시 값”을 다루는 데에 쓰인다.

JS에 새로 정의된 Symbol을 통해 예제 하나 뿌리겠다.
ES6 Symbol Test 예제

var obj = {};
var a = Symbol("a")

obj[a] = "a";
obj[Symbol.for("b")] = "b";
obj["c"] = "c";
obj.d = "d";

for (var i in obj) {
   console.log(i); // logs "c" and "d"
}

console.log(obj[a]); //logs "a"

심볼 “a” 란 해시 키에 “a” 값을 넣었다.
근데… 반복문에는 나타나지 않는다.
그렇다. 주소 값이니 나오지 않을 수밖에.
대신에 명시적으로 해시 키를 정의하면 가져올 수 있다.
이런 이득이 있다는 것이다.
그렇다면 이런 특징으로 얻을 수 있는 이득이 뭐가 있을까?

간단하다. hidden 키와 값을 넣을 수 있는 그런 개발이라면 모두 가능하다.
일종의 private identifier 인 셈이다.

자. 이제. 자바와 닷넷도 이런 개념이 존재하냐고 물어보는 사람이 있을 것이다.
당연히 없다. 근데 자바와 닷넷은 문자열에 한해 인터닝(Intern) 이라는 개념이 있다.

자바의 String.intern() String.intern()은 메모리를 아낄 수 있다?

  • String pool에 있는 각종 문자열에 equals해서 같은게 있다면 그 놈을 반환하고,
  • 같은게 없다면 String pool에 String object를 추가하고, 추가한 놈을 반환한다.

즉, String 객체를 리터럴로 관리하여 메모리 절약을 꽤하는 개념이다.
그렇다 보니 아래와 같은 단점이 존재한다.

  • 우선 String 객체를 하나 만들어야 한다.
  • String의 equals 메소드를 이용해서 String pool에 있는 놈을 찾아서 비교해야 한다. ( 시간이 걸림 )
  • String pool에 들어 갔으므로, 더 이상 GC(가비지컬렉션)의 대상이 될 수 없다. ( 메모리 관리 불가 )

그렇기 때문에 적재적소에 잘 관리해야 한다는 점이 있다. 그래도 같은 문자열을 객체로 정의하여 메모리 쳐묵보단 낫다.

참고로 닷넷도 아주 동일한 개념이다. String.Intern() 메소드 쓰는 건 매한가지이며 동일하기 때문에 별도의 설명은 생략하겠다.

자. 자바와 닷넷이 문자열을 관리하는 방법이 여기서 나온다. 리터럴은 자바나 닷넷이나 내부 풀을 따로 운영하여 저장한다. GC에 걸리는 걱정 없이.
(물론 new String 처럼 객체로 만들었다면 걸릴 각오는 해야 하지만.)

뭔가 삼천포로 빠진 것 같다.
하지만 메모리를 아껴서 빠르고 유연한 개발을 꾀하는 개발자는 있다.
이럴 때 필요한 것이 뭐고, 뭘 알아야 하는지는 개발자의 사명인 것이다.
그러기 위해 이 포스트를 올렸다.
그럼 이제…

끗.

composite / 2015년 11월 17일 / Piss Development / 0 Comments

2015년 6월 29일자 NoSQL 오픈소스 임베디드 DB 리스트

이번엔 약속대로 자바 기반의 임베디드 NoSQL DB를 소개한다.
Java 1.6에 내장된 Apache Derby DB(Java DB)는 소개에서 제외한다. SI/SM 개발자들 이거 자바 내장인거 알기나 하는지 내 알바 아니지만.
사족으로 역시 자바가 정말 다양한 방식의 NoSQL DB가 있다. 닷넷에서 아쉬우면 IKVM 써서 쓰는 방법이 있긴 하지만…

1. MapDB

MapDB is embedded database engine. It provides java collections backed by disk or memory database store. MapDB has excellent performance comparable to java.util.HashMap and other collections, but is not limited by GC. It is also very flexible engine with many storage backend, cache algorithms, and so on. And finally MapDB is pure-java single 400K JAR and only depends on JRE 6+ or Android 2.1+.

순수 자바로 만들어진 컬렉션 기반의 키값 DB. 메모리 및 파일 가능.
400kb의 가벼움과 안드로이드 지원으로 특히 안드로이드 개발자에게 사랑받고 있는 DB인 데다가
Apache License 2.0 이라 기업에서도 부담없이 사용 가능.

2. OrientDB

OrientDB is a 2nd Generation Distributed Graph Database with the flexibility of Documents in one product with an Open Source commercial friendly license (Apache 2 license). First generation Graph Databases lack the features that Big Data demands: multi-master replication, sharding and more flexibility for modern complex use cases.

순수 자바로 만들어진 Graph/Document DB. 서버/임베디드 모두 가능. NoSQL 계의 MySQL 같은 존재임.
Graph DB는 NoSQL 중에 Relational Schema를 지원하기 때문에 기존 SQL DB와 유사하게 사용 가능한 장점이 있다.
리플리케이션 및 셰딩이 지원되기 때문에 스케일링이 가능하면서도 Apache License 2.0으로 기업에서도 무료로 사용 가능.
자바를 사용하는 유명 기업에서 채용되기도 하였으며, 유료인 Enterprise Edition은 엔터프라이즈에 필요한 기능을 사용 가능. (개발/테스트 목적으로 무료로 사용가능)

3. Neo4j

Neo4j is used by thousands of organizations, including 50+ of the Global 2000, in mission-critical production applications. Developed by the inventors of the modern graph database, Neo4j is the only graph database on…

순수 자바로 만들어진 Graph DB로 OrientDB와 쌍벽을 이루고 있으나 우세. eBay나 National Geographic 등 세계 유명 기업에서 사랑받는 DB.
Graph DB는 NoSQL 중에 Relational Schema를 지원하기 때문에 기존 SQL DB와 유사하게 사용 가능한 장점이 있다.
리플리케이션 및 셰딩이 지원되기 때문에 스케일링이 가능한데 라이선스가 GPLv3 라 기업의 경우 내부시스템은 무료로 쓸 수 있으나 재배포 판매 시 소스 공개하던가 사던가 해야 함.
유료인 Enterprise Edition은 엔터프라이즈에 필요한 기능을 사용 가능. (30일 체험 사용 가능)

4. Titan

Titan is a scalable graph database optimized for storing and querying graphs containing hundreds of billions of vertices and edges distributed across a multi-machine cluster. Titan is a transactional database that can support thousands of concurrent users executing complex graph traversals in real time.

빅데이터를 위해 태어난 자바 기반의 Graph DB. 다른 NoSQL DB와 연동하는 기능이 특징.
Graph DB는 NoSQL 중에 Relational Schema를 지원하기 때문에 기존 SQL DB와 유사하게 사용 가능한 장점이 있다.
빅데이터 위주의 스케일링에서 강점이 있으며, Apache License 2.0이기 때문에 기업에서도 부담없이 사용 가능.

5. iBoxDB

iBoxDB is a fast transactional table style document NoSQL Application Database, easily store, process objects and documents, traditional table with unstructured data, zero configuration, pure JAVA and .NET engines, no dependencies.

iBoxDB has a well designed interface with great performance and capability for agile development, you can focus on the applications. It can embed into an application and deploy on mobiles, desktops, servers, then help designers to persist objects and documents thread-safely with transaction support.

.NET 과 Java 둘 다 품은 (그것도 IKVM도 아니고 독립적으로 각각 엔진 개발) 특이한 키값 기반 NoSQL DB.
.NET은 2 이상, Java는 6 이상이면 가능. 라이선스는 걍 무료. 오픈소스는 아님 (자바는 오픈되었으나 닷넷만 클로즈드)

6. JasDB

JasDB was designed with easy of use and minimal configuration in mind. JasDB can be installed and configured in almost no time at all. Use JasDB as an embedded DB inside your JVM or you can use it to store your unstructured data in JSON format. If you want to scale JasDB, simply run and use it through the REST webservice.

순수 자바로 만들어진 Document DB. REST 내장으로 서버로도 사용 가능. JSON 형식으로 저장하는 것이 특징.
안드로이드도 지원하며, MIT X11 License로 기업에서도 부담없이 사용 가능

… 자바로 만든 NoSQL DB 드럽게 많아서 더이상 나열 못하겠다.
NoSQL DB를 전문적으로 모은 사이트가 있으니 어느 언어 개발하던 상관없이 부족함을 채우고 싶다면 여기로 가서
http://nosql-database.org/
Key-Value, Document, Graph, Column 등 다양한 DB 종류 구분이 가능하다. 하지만 지원되는 언어는 나도 모르니 해당 공식 사이트 가서 확인하라.

composite / 2015년 6월 29일 / Piss Development / 0 Comments

[.NET vs JAVA] 쓰레드 동기화

고급 언어의 가장 알다가도 모를 이슈가 바로 쓰레드 동기화이다.
둘 다 Thread unsafe 의 경우는 반드시 발생을 하며, 특히 대량 처리로 인해 꼬이는 경우에 대해서는 유용하게 사용한다.
그럼 이 둘이 사용하는 동기화의 차이는 무엇일까?

결론부터 말하자면 차이점 없다. 기능 똑같다. 단지 구문만 틀릴 뿐.
자바의 경우 메소드에 synchronized 키워드를 붙일 수 있다.

public synchronized void doSomething(){
    //...
}

하지만 그래봤자 메소드 내용을 아래와 같이 처리하는 꼴이 된다.

public void doSomething(){
    synchronized(this){
        //...
    }
}

닷넷은 메소드에 동기화 키워드를 제공하지 않으며 구문으로만 제공한다.

public void DoSomething()
{
    lock(this)
    {
        //...
    }
}

그리고 임의의 private 객체 하나 지정해서 이를 사용해서 부분적인 동기화 작업을 수행하는 케이스가 대부분이다.
문제는 자바의 경우 메소드 동기화는 클래스 동기화나 다름없는데도 이를 이용하는 경우가 많다는 것이다.
물론 클래스 모두 동기화를 걸어서 일관적으로 수행하는 작업이라면 오히려 편리하지만,
그런 경우가 흔치 않기 때문에 오히려 동기화 방식은 구문 방법을 추천하고 싶다.
그 이유는 간단하다. 유연하고, 명확하며, 동기화가 필요한 부분에만 적용되어 더 빠른 처리를 제공할 수 있다.
특히 닷넷과 자바를 오가는 등의 폴리글랏 개발자라면 메소드 동기화보다 동기화 구문을 사용하자.
마이그레이션하기 존나 편할 것이다.

composite / 2015년 5월 7일 / Piss Development / 0 Comments

자바 개발자들은 왜 비동기를 싫어하는 걸까?

지금 닷넷 하고 있지만 얼마 지나지 않은 자바 개발 시절 얘기다.
나는 자바스크립트의 비동기 패턴에 익숙했다.
그래서 가끔씩 이벤트 패턴을 사용하기도 한다. 웹인데도.
하지만 공통팀 개발자로부터 태클이 들어왔다.
Anonymous Class 사용을 하지 말라는 거다. 유지관리가 어렵다는 이유에서였다.
나는 어이가 없어서 따졌고, 프로그램도 문제없이 돌아가는데 대체 왜냐고 물어봤다.
결국 최종적인 답변은 듣지 못했으나, 한가지 단서를 발견했다.
원래 자바는 익명 클래스를 만들면 해당 클래스에 $숫자 가 추가된 파일을 생성한다.
아마 그가 걸고 넘어지려는게 그 파일이 아닌가 생각했다.
왜냐면 그 달러 파일 안넘기면 당연히 런타임 오류가 나서 프로그램이 동작하지 않으니까.
개발환경에서 멀쩡히 돌아가는게 가운영서버에서 안돌아가는 케이스 되시겠다.
Jenkins 쓰지만 운영 배포는 따로 관리를 통해 수동으로 배포하고 운영한다.
결국 얼마 지나지 않아 나는 익명 클래스 빼고 길고 긴 Procedural style 로 코딩할 수밖에 없었다.
야근했다. 그날. ㅅㅂ.

자바 SI 하면서 정말 힘들었다. 튀는 개발은 받아주지 않는다. 당연하겠지만.
게다가 정부부터 전자정부 강제로 쓰게 만드는데 뭐 그건 좋다 이거야.
하지만 확장성이 부족하고 (어려움) 틀 안에서만 개발해야 한다.
이래놓고서 대량 트랜잭션을 바란다. 미치겠다.
물론 불가능한 건 아니다. 단지 빡셀 뿐이다.

자바는 원체 동기와 비동기 유연하게 돌릴 수 있다. Quartz를 통한 스케줄링을 사용할 수 있다.
특히 웹에서 그 진가를 발휘하지만 역시 GC와 메모리 문제로 따로 돌리는 경우가 대부분이다.
닷넷의 경우 이벤트 지원이 확실하기 때문에 비동기 프로세스를 자바보다 더 간결하게 구성할 수 있다.
그러나 ASP.NET의 경우에도 웹 앱에 스케줄링 걸면 뻑나가기 때문에 따로 빼거나 COM+ 돌린다.
여기서 웹상에서는 자바가 ASP.NET 보다는 스케줄링 작업이 잘 되긴 하지만 둘다 결과적으로 메모리 관리는 쉣이다.
둘 다 웹에서 비동기 스케줄링 걸 수는 있지만 메모리 관리 측면에서는 올바르지 않은 방법이다.
하지만 비동기만 쓴다면 나쁜 선택도 아니다. 사실 관점지향개발(AOP)도 비동기의 한 부류이기 때문이다.
이벤트 돌리니까 말이지. 하지만 그렇게 생각 안하나보다. 게다가 AOP조차도 잘 안쓴다.
비동기 개발에 능한 자바 개발자는 이벤트를 효율적으로 운영하는 방법을 찾는 데에 열중했고,
그 과정에서 발견한 프레임워크가 바로 Akka 이다.

하지만 SI 출신 개발자들은 이런 방식의 코딩을 능멸하는 것 같다.
여전히 많은 개발자는 Procedural style 의 코딩을 즐긴다. 객체지향? 그건 클래스에나 통하는 거고.

당연히 전통적 방식에 익숙한 자바 개발자들이 아는 범위 내에서 문제 없이 코딩해야겠는데 어쩌겠는가.
절차지향이 아무래도 보기에는 좋으니까. 무조건 순서대로 처리하니까 말이다.
게다가 가능하면 절차대로 수행하는 게 프로젝트 면에서 안전빵이라 생각하고 있을 것이다.

하지만 요즘은 달라졌다. 코어 수는 늘어났고, 더 많은 작업을 더 짧은 시간에 해내기를 요구한다.
게다가 코어 수가 늘어난 것도 엄청 오래됐다. 전통적인 싱글 코어에 맞춘 프레임워크는 멀티코어를 자동으로 해결해주지 않는다.
그 어떤 언어라도 마찬가지다. 더 많은 작업을 더 빨리 작업하려면 개발자가 생각하고 잡아주고 코딩해야 한다.
그런 측면에서 Procedural style 코딩은 이에 한계가 있다.
자바와 닷넷이 아무리 멀티코어를 지원한다 해도, Procedural style 코딩은 결국 하나의 쓰레드만 쓰는 꼴이니까.
프레임워크가 알아서 필요하면 쓰레드 잡고 간다고 편안하게 생각한다면 그건 개발자의 자질이 글러먹었다.

그런 측면에서 병렬 처리는 많은 작업을 짧게 해내는 데 유용한 기능을 제공한다.
자바 닷넷 둘 다 제공하거나, 부족할 경우 채워주기도 한다.
하지만 아무리 커다란 프로젝트라도 여전히 이를 만족하는 개발은 없다. 본적도 없고.
공공데이터 시스템 빼고는. (이는 병렬처리 안하면 뻑나가는 구조임)
특히 금융권 개발은 이를 잘 반영 안하고 있다. 대부분 DB 프로시저에 익숙한 탓이기도 하다.
그리고 이를 개선할 생각도 없고 개선하려 해봤자 눈먼 돈만 나가고 결국 실패하고.

이 병렬 처리를 하려면 개발자가 갖춰야 할 기본 자세가 바로 비동기이다.
왜냐면, 병렬 처리는 동시에 이루어지기 때문에,
Procedural style 로는 동시에 누가 먼저, 나중에 시작 후 끝나는지 캐치할 방법이 없기 때문인 데다가,
Procedural style 은 싱글 프로세스이기 때문에 애초부터 접근할 방법이 없다.

비동기의 장점은 꽤 많다. 물론 비동기도 Procedural style 에 비해 단점도 있다.
특히 비동기는 작업 중간중간을 캐치할 수 있다는 크나큰 장점이 있다.
예를 들면, 1분 이상 걸리는 무거운 쿼리를 요청한다고 가정해보자.
Procedural style 로 하려면 이 쿼리를 마냥 기다려야 다음 작업을 진행할 수 있다. 과정보다는 결과가 우선시되는 작업이다.
하지만 비동기로 하면 이 무거운 쿼리가 성능에 어떤 영향을 미치는지, 이에 실패하면 어떨지 등 여러 경우를 캐치할 수 있다.
이는 결과와 과정을 둘 다 캐치해낼 수 있는 작업인 것이다.
그걸 잘 반영한 자바 프레임워크가 바로 Akka 이다.
하지만 그거 쓰는 자바 개발자들이 얼마나 있을까. 특히 SI 말이다.

Akka 가 이젠 닷넷 개발자도 배려해 주었다. 이런 비즈니스 요구를 잘 반영한 Akka를 말이다.
아. 생각해 보다 닷넷 개발자도 자바 개발자와 다를 거 없다. 둘 다 절차적 스타일에 따른다.

나는 이 글을 쓰는데 비동기를 강조하고 Procedural style 을 까내리려 하는 것은 절대 아니다.
Procedural style 은 당연히 피할 수 없는 코딩 구조이다.
하지만 나는 필요시 비동기 스타일을 권유하고자 글을 쓰는 것이다.
굳이 대안을 작성하자면, 비동기 개발 좀 하라고. 끝.

SI가 정말 한국 개발의 발전을 저해시키고 동결시키긴 했다. 나도 이런 답답한 개발에 지겨우긴 했다.
하지만 그렇다고 나를 받아주는 곳도 없다. SI에서는 튀고, 그렇다고 선진개발자에게 SI경력은 Procedural style 중점의 개발자로 낙인찍히니.
나는 이렇게 본의아니게 어정쩡한 개발자가 되버렸다.
뭐. 아무렴 어때. 이제부터 중요한 것은, 내가 직접 보여주는 수밖에.

어떤 패턴을 쓰던 나는 존중한다. 하지만 그 패턴만 고집하는 행위는 옳지 않다.
그런 사고방식이 전에 자바 개발했을 때 개발자의 사기를 떨어뜨렸다.
그래서 나는 어떻게 개발하던 존중해달라고 하고 싶어서
이런 뻘글 썼다.

아. 한가지 첨언하자면 Akka는 스칼라로 만들어졌지만 자바로 개발 가능하니 스칼라 태클 걸지 않도록.
자세한 소개는 Akka 로 한국어 웹 검색만 해도 좌르륵 나온다.

composite / 2015년 4월 10일 / Piss Development / 0 Comments