2020년 7월 15일
by aduris
0 comments

좋은 코딩을 위한 13 가지 간단한 규칙

나는 15년 이상의 경력을 가진 프로그래머이며 많은 여러 언어, 패러다임, 프레임워크를 사용해봤고 많은 삽질을 해봤다.

그리고 나는 좋은 코딩을 작성하기 위한 나만의 규칙들을 여러분에게 공유하고자 한다.

최적화 VS 가독성. 최적화보단 가독성

코드는 항상 읽기 쉽고 개발자들이 이해할 수 있게끔 작성하라. 읽기 어려운 코드를 읽는데 소모되는 시간과 비용은 최적화로부터 얻을 수 있는 것보다 더욱 크다. 최적화가 필요하다면, DI (의존성 주입)을 사용해 독립적인 모듈로 만들고, 100%의 테스트 커버리지를 유지하여 최소 1년간은 건들지 않아도 되도록 만들어라.

아키텍처 우선

나는 “우리는 빨리 개발을 해야하기 때문에 아키텍처를 설계할 시간이 없다”라고 말하는 사람을 많이 봐왔다. 그리고 그 중 99%가 이러한 생각 때문에 큰 문제를 겪었다.

아키텍처를 생각하지 않고 코드를 작성하는 것은 목표 달성을위한 계획없이 자신의 욕망을 꿈꾸는 것처럼 쓸모가 없다. 코드를 작성하기 전에 먼저 수행 할 작업, 사용 방법, 모듈화 방법, 서비스가 서로 어떻게 동작하는지, 구조가 무엇인지, 테스트 및 디버깅 방법, 업데이트 방법들을 먼저 생각하고 이해해야한다.

테스트 커버리지

테스트는 좋은 일이지만 항상 비용 효율적인건 아니며 프로젝트에 따라 다르다.

테스트가 필요한 경우:

최소 한 달간은 건들지 않아도 될 모듈이나 마이크로서비스를 개발하는 경우
오픈소스 코드를 작성하는 경우
핵심 코드 또는 금전적인 부분과 맞닿는 코드를 작성하는 경우
코드를 업데이트 하는 것과 동시에 테스트를 업데이트 할 수 있는 충분한 비용이 있는 경우

테스트가 필요하지 않는 경우:

스타트업인 경우
팀이 작고 코드가 빠르게 변하는 경우
출력값을 보고 간단하게 수동으로 테스트가 가능한 스크립트를 작성하는 경우

나쁜 테스트 코드와 함께 코드를 짜는 것은 테스트가 없는 코드보다 더 위험할 수 있음을 기억하라.

간단하고 단순하게

복잡한 코드를 작성하지 말라. 간단하게 작성하면 버그가 줄어들고 디버깅 시간도 줄어들 수 있다. 코드는 수많은 추상화 및 기타 객체지향적인 문제 (특히 Java 개발자와 관련이 있음) 없이 딱 필요한 일만을 수행해야하며, 추후에 간단한 방법으로 코드를 업데이트하기 위해 필요한 것의 20%를 수행해야한다.

주석

주석은 나쁜 코드를 보여준다. 좋은 코드는 주석 없이도 이해할 수 있어야한다. 그러면 새로운 개발자를 위해 시간을 절약하기 위해 해야 할 일은 무엇인가? — 메서드의 정의와 사용법을 설명하는 한 줄짜리 간단한 문서를 작성하라. 이는 이해를 위한 많은 시간을 절약해 줄 것이며 — 더 많은 사람들에게 메서드를 더 잘 구현할 수 있는 기회를 제공해준다. 또한 이는 글로벌 코드 문서화를 위한 좋은 시작점이 될 것이다.

강한 결합 VS 느슨한 결합

항상 마이크로서비스 아키텍처를 사용하도록 노력하라. 모놀리틱 소프트웨어는 마이크로서비스 소프트웨어보다 빠르지만, 단일 서버 환경에서만 그렇다. 마이크로서비스는 여러분의 소프트웨어를 여러 서버로의 분산뿐만 아니라 가끔은 하나의 머신에서의 분산처리 (프로세스 분산을 의미한다)도 할 수 있는 가능성을 제공해준다.

코드 리뷰

코드 리뷰는 좋을 수도 있고 나쁠 수도 있다.

여러분의 팀에 코드의 95%를 이해하고 있고 시간 낭비 없이 모든 업데이트 사항을 모니터링 할 수 있는 개발자가 있는 경우에만 코드 리뷰를 도입하도록 하라. 이 외의 경우에는 단지 시간 낭비가 될 수 있으며 모두가 이를 싫어하게 될 것이다. 이 부분은 많은 질문을 가져오기 때문에 이를 좀 더 깊게 살펴보자.

많은 사람들은 코드 리뷰가 새로운 사람이나 코드의 다른 부분을 작업하는 팀원을 가르치는 좋은 방법이라고 생각한다. 그러나 코드 리뷰의 주요 목표는 코드 품질을 유지하는 것이지 가르치는게 아니다. 여러분의 팀이 원자로 또는 우주 로켓 엔진 냉각 시스템을 제어하는 코드를 작성했다고 가정해보자. 그리고 여러분은 아주 어려운 로직에서 큰 실수를 저질렀고, 이를 새로운 사람에게 코드 리뷰를 위해 제공했다고 해보자. 이 경우 여러분은 사고 위험에 대해 어떻게 생각하는가? — 내 대답은 70% 이상이다.

좋은 팀은 각자가 자신의 역할을 가지고 있으며 일의 한 부분에 대해 완전한 책임감을 갖고 있는 팀이다. 만약 누가 코드의 다른 부분을 이해하고 싶으면 해당 부분을 담당하고 있는 사람에게 찾아가 질문을 하면된다. 모든걸 아는건 불가능하며 전체보다는 코드의 작은 부분을 (하지만 적어도 30%는) 완전히 이해하는것이 더 낫다.

리팩토링은 작동하지 않는다

나는 일하는 동안 “나중에 리팩토링 할거니까 걱정하지마라”라는 말을 많이 들었다. 그리고 나중에 이는 큰 기술적 부채로 돌아오거나 모든 코드를 다 삭제한 후 처음부터 다시 작성하게 되었다.

따라서 처음부터 여러번 소프트웨어 다시 개발할 수 있는 자금이 있는게 아니라면 부채를 만들지 말라.

피곤하거나 컨디션이 좋지 않을때 코딩하지 말라

개발자들이 피곤할 땐 평소보다 2-5배 더 많은 버그와 실수를 만들어낸다. 따라서 과업은 매우 나쁘다. 그렇기 때문에 하루의 업무시간을 약 6시간으로 고려하는 국가가 점점 더 많아지고 있으며, 일부 국가에서는 이미 실천하고있다. 정신적인 일은 육체적인 일을 다루는 것과 같지 않다.

모든걸 한꺼번에 작성하자 말라 – 반복적으로 개발하라

코드를 작성하기 전에 우선 여러분의 고객과 클라이언트가 정말로 필요로 하는걸 분석하고 예측하고, 짧은 기간동안 개발할 수 있는 MVF(Most Valuable Features)를 추려내라. 품질 업데이트를 배포하기 위해 이러한 반복을 사용하도록 하고 무리한 요구사항과 품질 희생에 시간과 자원을 낭비하지말라.

자동화 VS 수동

자동화는 장기적으로 100% 성공이다. 따라서 지금 당장 무언가를 자동화 할 수 있는것이 있다면 바로 하도록 하라. “5 분 밖에 걸리지 않는데, 왜 자동화 해야해?“라고 생각할 수도 있다. 하지만 한 번 계산해보자. 예를 들어 5명의 개발자로 이루어진 팀의 일상적인 작업을 들어보자. 5분 * 5명 * 21일 * 12개월 = 6,300분 = 105시간 = 13.125 일 ~ 5,250$. 직원이 40,000명일 경우엔 비용이 얼마나 커질까?

나가서 취미를 갖자

일의 차별화는 정신 능력을 향상시키며 새롭고 신선한 아이디어를 제공한다. 따라서 잠시 쉬고 신선한 공기를 마시거나 친구들과 이야기를 하거나 기타를 연주하는등의 취미를 가져라.

여유 시간에 새로운걸 배워라

학습을 중단하면 퇴화하기 시작한다.

좋은 코드 작성에 대한 아이디어와 관행에 대한 의견을 공유해준다면 매우 감사하겠다

13 Simple Rules for Good Coding (from my 15 years of experience)를 번역한 글입니다.

Categories: 개발 | Permalink

2014년 5월 30일
by aduris
0 comments

갈망의 아구니

김동건, 갈망의 아궁이 from devCAT Studio, NEXON

Categories: 개발 | Permalink

2014년 1월 27일
by aduris
0 comments

2014년 주요 웹디자인 트렌드 18선

2014년엔 어떤 웹디자인 트렌드를 보게 될 거라 생각하시는지? 필자는 다른 것들보다 좀더 심플하고, 깔끔하고, 작은 화면 사이즈에 특화된 게 유행할 거라 본다.

이 컬렉션은 전체적으로 관찰과 경험에 의한 추측, 그리고 지난 몇 달간 필자가 엮어 본 다른 많은 글들에 기반해 작성되었다. 그런 고로 다른 글들보다 좀더 정확할 것임!

놓친 트렌드가 있을 수 있으니, 여러분의 생각과 예상을 아래 댓글로 달아 주시길.

1. 플랫(입체감을 뺀) UI는 계속 성장세

산세리프 폰트의 팬인 나로서는 현재 장식적인 것보다 깔끔한 것이 트렌드란 걸 알릴 수 있어 기쁘다. 윈도우8은 이 점에 있어 매우 영향력이 컸고, 그 다음으로 애플이 iOS7을 런칭하며 스큐어모피즘을 버렸다. 플랫 디자인에는 여전히 많은 잠재력이 있다.

Windows 8

Apple iOS7

Skibuddy

2. 모바일 퍼스트(모바일부터 생각하기)

요 몇년간 스마트폰과 타블렛 사용의 급증으로 많은 웹사이트들에서 모바일 트래픽이 데스크탑 트래픽을 추월하고 있다. 2014년에도 늘어나는 모바일 점유율은 디자이너들이 더 작은 화면에서의 사용자 경험(UX)을 재고하게끔 할 것이다(물론 더 커진 화면도 고려해야 할 것이다). 모바일에서 이용 가능한 사용자 베이스에 적응할 필요성은 한 회사를 좀더 민첩하게, 조직내 혁신을 추동케끔 할 수 있다.

물론 실제로는 대다수의 회사에서 ’모바일 퍼스트’가 적용이 잘 안 되고 있다. 적어도 아직은 여전히 ‘모바일 세컨드’이지만, 반응형과 적응형웹을 수용한 곳에서는 투자수익률이 크게 오를 수 있다.

3. 여전히 긴 스크롤

2012년에 스크롤링 웹사이트를 탐구했을 적엔 아직 스크롤링 웹사이트가 유행의 초기 단계였지만 그 뒤로는 많이 보인다. 스크롤링이 매우 쉽기 때문이기도 하고, 디자이너들이 모바일과 타블렛 기기들을 고려하고 마음 속으로 스크롤(swipe)을 생각하기 때문이기도 하다.

패럴렉스 스크롤(Parallax Scrolling), 가로 스크롤, 컬럼-기반 스크롤, 무한 스크롤은 모두 2014년과 앞으로 계속 더 보게 될 것들이다. 다만 특히 무한 스크롤 관련해서 경계할 점이 몇 가지 있다.

4. HTML5 장점

HTML5가 주는 기쁨에 대해 내가 떠드는 걸 듣기보다 Codepen을 방문해 예제를 따라해 보며 뭐가 가능한지 보길 권한다. 아니면 HTML5에 CSS3와 jQuery를 잘 섞어 만든 창의력 있는 에이전시 사이트들을 보길 바란다.

5. HTML5 나쁜 점

이미 나는 웹디자인을 조악하게 만드는 것, 자제력 없는 이들이 사용자 경험에 반하는 범죄를 저지르는 것에 대해 상세히 불평한 바 있다. 할 수 있다는 것이 곧 해야 한다는 것을 의미하지는 않는다.

예를 들어 당신의 흥미로운 새 웹사이트에 들어가는 데에 1분이 걸린다면, ‘기다려 주세요’라는 로딩 아이콘이 아무리 번드르르해도 그건 잘못된 것이다. 기다리는 것은 언제나 짜증나는 일이다. 나는 브래드 프로스트의 “퍼포먼스는 디자인이다“에 동의한다.

깔끔한 사용자 경험을 제끼고 플래시 시절의 번지르르함으로 회귀하는 것은 어떤 식으로든 일어나지 않기를 바란다.

‘

6. 아주 소소한 UX

디테일에 주목해 웹사이트를 다른 것과 구별되게 만들 수 있다. 과하지 않게 감각을 만족시켜주는 메뉴, 트랜지션(transition) 효과, 마우스오버 효과 등 아주 소소한 UX(micro UX) 효과가 웹사이트에 활기를 불어넣어줄 수 있다. 예를 들어 데일리 비스트지의 사랑스러운 진행 표시기를 보시라.

7. 텍스트를 더 적게

웹에 텍스트를 잔뜩 쓰는 방식이 훨씬 줄어드는 듯 하다. 일부 앱들과 웹사이트들에서는 눈에 보이는 텍스트가 거의 없고 사용자에게 정보를 전달하기 위해 이미지와 아이콘에 의존하기도 한다.

일부 사례에서는 이 방식이 잘 작동했지만, 보통은 텍스트를 완전히 제거하는 것은 별로 도움이 안 되는 것 같다. 예를 들어 스냅챗(Snapchat) 홈페이지는 10개가 안 되는 단어를 사용하고 있는데 방문객들이 이게 뭔지 알 수 있으려면 비디오를 보도록 요구하고 있다.

의료 대쉬보드 컨셉

ELI – 이런 식의 배치는 포트폴리오 사이트처럼 보이게 한다.

Snapchat

8. 최소한의(미니멀한) 네비게이션(메뉴바)

기본만 남긴 네비게이션의 유행은 계속 퍼지는 듯 하다. 부분적으로는 모바일용으로 압축적인 네비게이션 디자인 수요에 영향 받아, 아이콘, 롤다운(rolldown), 페이지 스크롤을 내리면 줄어드는 네비게이션에 포커스를 둔 사이트를 많이 볼 수 있다.

미디엄Medium

스마트 홈

9. CSS가 이미지 대체

CSS를 쓸 수 있는데 왜 이미지를 쓰는가? 매력적인 CSS 체크박스 세트를 원치 않을 자가 누구란 말이뇨?

10. 비디오 / 움직이는 배경

이건 단연코 훨씬 더 많아질 거라 생각한다. 가디언지의 Firestorm이 그 좋은 예로, 2014년에는 (컨텐츠 사이트보다) 브랜드들이 더 많이 다이나믹한 배경을 활용할 거라 본다.

The House of Eyewear

11. 풍부한 컨텐츠 경험

Firestorm에서 계속 되는 것이다. 일부 언론 출판계는 텍스트, 이미지, 비디오, 인터랙티브한 기능들, 적절한 길이의 스크롤 등을 섞은 온라인 컨텐츠 경험 관련 쪽으로 이동해 가고 있다.

ESPN’s Grantland

12. 한 페이지를 최대한 사용

점점 많은 사이트들이 새로운 페이지를 로딩하는 것을 피하는 대신 현재 페이지에 내용을 추가적으로 보여주는 걸 선호하고 있다. 라이트박스, 오버레이, 확대/위치가 바뀌는 타일은 모두 평균적인 사용자의 탐색에서 클릭 수를 줄여줄 수 있다.

Stories by H&M

13. 다양해진 타이포그라피

웹폰트가 부상 중이고, 디자이너들은 전에 없이 큰 폰트를 좋아하며 여러 폰트를 섞어 매치하는 게 유행하고 있다. 덧붙여 반응형 타이포그라피는 반응형 웹디자인에서 큰 부분을 차지해야 한다.

14. 단색 디자인

2개 색상과 그 색조로 충분할 것에 왜 3 가지 색을 쓰는가? 최근 매력적인 단색조의 팔레트들을 좀 보았다.

Qatar Airways

15. 다양한 색들

다시, 무지개색을 다 쓸 수 있는데 왜 2가지 색을 쓰는가? 여러 색을 쓴다고 해서 꼭 현란하거나 집중을 방해하는 건 아니다. 다색 디자인은 특히 플랫 디자인과 잘 어울리는 듯 하다.

컬러풀한 웹사이트와 앱을 한 번 보시길.

Coloured Lines

16. 카드/타일

나중에 상술할 생각이지만 일단 왜 카드가 ‘웹의 미래’인지에 대한 개관을 보시길. 나는 카드가 과거이며 현재이기도 하다고 생각하게 됐다.

Etch

Pravda

Silktricky

17. 더 크고 더 좋은 이미지화

텍스쳐 패턴에 반대되는 커다란 사진과 배경 이미지가 점점 일반화되는 듯 한데, 확실히 레티나 디스플레이에서 좋아 보인다. Awwwards의 최신 ‘오늘의 사이트’ 갤러리를 보면 무슨 뜻인지 알 것이다.

언론 출판 쪽도 전례 없이 큰 이미지들을 쓰고 있다

Protest

18. 위치가 고정된 내용/네비게이션

스크롤을 내렸을 때 네비게이션(이나 다른 컨텐츠 박스)이 페이지에 고정되어 있는 경우를 말한다. 네비게이션의 높이가 짧아질 때도 있고 확대될 수 있는 작은 아이콘이 될 때도 있다. 새로 디자인되는 웹사이트들에서 흔히 보이데, 예를 들어 Awwwards를 계속 보자.

출처 : http://blog.jinbo.net/taiji0920/2778

Categories: 개발, 디자인 | Permalink

2014년 1월 21일
by aduris
0 comments

S/W 설계 변경전 따져봐야할 가치

Categories: 개발 | Permalink

2013년 12월 2일
by aduris
0 comments

2014년 주목할 만한 10대 전략 기술

시장조사전문업체 가트너가 2014년 주목할 만한 10대 전략 기술을 10월8일(현지기준) 올랜도에서 진행된 ‘가트너 심포지엄/IT엑스포 2013′ 행사에서 발표했다.

가트너는 매년 10월, 향후 기업들이 비즈니스를 하는데 있어 중요한 영향을 끼칠지 모르는 잠재력을 가진 ‘전략기술’ 10가지를 소개한다. 올해도 어김없이 향후 미래를 밝힐 기술에 대해 발표했다.

올해 가트너가 꼽은 2014년 전략기술은 ▲다양한 모바일 기기 관리 ▲모바일 앱과 애플리케이션 ▲만물인터넷 ▲하이브리드 클라우드와 서비스 브로커로서의 IT ▲클라우드/클라이언트 아키텍처 ▲퍼스널 클라우드의 시대 ▲소프트웨어 정의 ▲웹스케일 IT ▲스마트 머신 ▲3D 프린팅 등이다.

2011년부터 2014년까지 가트너가 선정한 10대 전략기술

	2011년	2012년	2013년	2014년
1.	클라우드 컴퓨팅	미디어 태블릿 그 이후	모바일 대전	다양한 모바일 기기 관리
2.	모바일 앱과 미디어 태블릿	모바일 중심 애플리케이션과 인터페이스	모바일 앱&HTML5	모바일 앱과 애플리케이션
3.	소셜 커뮤니케이션 및 협업	상황인식과 소셜이 결합된 사용자 경험	퍼스널 클라우드	만물인터넷
4.	비디오	사물인터넷	사물인터넷	하이브리드 클라우드와 서비스 브로커로서의 IT
5.	차세대 분석	앱스토어와 마켓 플레이스	하이브리드IT&클라우드 컴퓨팅	클라우드/클라이언트 아키텍쳐
6.	소셜 분석	차세대 분석	전략적 빅데이터	퍼스널 클라우드의 시대
7.	상황인식 컴퓨팅	빅데이터	실용분석	소프트웨어 정의
8.	스토리지급 메모리	인메모리 컴퓨팅	인메모리 컴퓨팅	웹스케일 IT
9.	유비쿼터스 컴퓨팅	저전력 서버	통합 생태계	스마트 머신
10.	패브릭 기반 컴퓨팅 및 인프라스트럭처	클라우드 컴퓨팅	엔터프라이즈 앱스토어	3D 프린팅

겉보기엔 모바일, 빅데이터, 클라우드를 강조했던 2013년과 크게 다르지 않아 보인다. 빅데이터 분야 내용이 빠지고 소프트웨어 정의와 3D 프린팅이 새로이 이름을 올렸다. 사물인터넷은 만물인터넷으로 ‘인터넷에 연결된 기기’에서 ‘인터넷에 연결된 플랫폼’으로 개념을 확장했다.

모바일과 클라우드는 2년 연속 주목해야 할 10대 전략기술로 선정됐다. 퍼스널 클라우드와 하이브리드 클라우드, 퍼블릭 클라우드, 모바일 다양성, 모바일 관리, 모바일 애플리케이션 등으로 개념을 구체화했다.

매년 특정 기술을 강조했던 지난해와 달리 올해 가트너는 소셜과 모바일, 클라우드, 정보의 통합을 모두 아우를 수 있는 ‘디지털 산업 경제’를 강조했다. 이번에 가트너가 선정한 2014년 10대 전략 기술은 디지털 산업 경제에 뿌리를 두고 있다.

데이비드 시어리 가트너 수석부사장은 “소셜과 모바일, 클라우드, 정보가 서로 융합돼 만들어지는 ’힘의 결합’을 주목할 필요가 있다”라며 “각 힘을 ‘모이는 힘’, ‘파생되는 충격’, ‘미래 혼란’으로 나눠 분류했다”라고 말했다.

데이비드 수석 부사장이 분류한 10대 전략 기술은 다음과 같다.

모이는 힘(Converging Forces)

1. 다양한 모바일 기기의 관리

가트너는 2018년이 되면 다양한 기기와 컴퓨팅 스타일, 사용자 환경이 등장할 것이라고 내다봤다. 이렇게 다양한 기기가 등장하면 ‘언제, 어디서나’ 서로 소통할 수 있는 시대가 열릴 것으로 전망했다. 이 과정서 자신의 기기로 업무를 보는 BYOD 사례도 늘어날 것으로 예측했다.

가트너는 직원 소유의 기기에 대해서도 회사가 관리할 수 있는 모바일 기기 관리 시스템을 준비할 필요가 있다고 강조했다. 사내 네트워크에 접속된 기기 정보를 파악하고 제어할 수 있어야 한다.

2. 모바일 앱과 애플리케이션

가트너는 2014년이 되면 자바스크립트 기반의 HTML5를 지원하는 애플리케이션이 늘어날 것으로 보고 있다. HTML5는 이전 HTML과 달리 사진이나 동영상 같은 콘텐츠를 지원하는 게 특징이다. 가트너는 개발자들이 이 점을 십분 살려 음성과 비디오 기능에 최적화된 다양한 앱을 선보일 것으로 예상한다. 좀 더 동적인 애플리케이션이 등장할 것으로 기대된다.

3. 만물인터넷

PC와 모바일 기기를 넘어 다양한 기기에 인터넷이 연결될 예정이다. 자동차나 TV와 같은 소비자 상품도 인터넷에 연결된다. 가트너는 대부분의 기업과 기술 공급업체가 만물인터넷 시대를 준비하고 있으며, 이 새로운 산업을 어떻게 발전시켜 수익을 얻을 것인지를 고민중이라고 지적했다.

모든 제품이 디지털화 되면 수집해서 분석할 수 있는 정보의 양도 많아진다. 창출된 정보를 바탕으로 또 다른 수익을 만들 수 있다.

4. 하이브리드 클라우드와 서비스 브로커로서의 IT

가트너는 최근 기업이 사내 정보를 보관하기 위한 프라이빗 클라우드와 함께 애플리케이션 운영을 위한 퍼블릭 클라우드를 동시에 이용하고 있다고 보았다. 이 과정에서 가트너가 눈여겨 본 점은 프라이빗 클라우드와 퍼블릭 클라우드 간 상호운용성이다. 가트너는 각 클라우드가 각자 따로 운영되는 게 아닌, 동일한 정책에 따라 관리하는 하이브리드 클라우드가 중요하다고 강조한다.

파생되는 충격(Derivative Impact)

5. 클라우드/클라이언트 아키텍처

클라우드와 클라이언트 시스템 환경이 변하고 있다. 과거 클라우드는 비교적 덜 중요한 애플리케이션을, 클라이언트가 중요한 애플리케이션을 운영하는 편이였다면 요즘은 다르다. 가트너는 클라우드에서도 클라이언트에서 운영되던 핵심 애플리케이션을 실행시키기 위해 서버와 스토리지 분야에서 다양한 기술이 사용되고 있다고 보았다.

6. 퍼스널 클라우드의 시대

개인용 클라우드 시대는 사용자가 언제든지 자신이 사용하는 기기를 손쉽게 바꿀 수 있다는 걸 의미한다. 특정 정보가 특정 기기에 종속되지 않기 때문이다. PC도 마찬가지다. 더 이상 PC 안에 정보를 저장하지 않고, 퍼스널 클라우드 스토리지에 저장하게 된다.

7. 소프트웨어 정의

소프트웨어 정의 네트워크(SDN), 소프웨어 정의 데이터센터(SDDC), 소프트웨어 정의 스토리지(SDS), 소프트웨어 정의 인프라(SDI) 등 클라우드 컴퓨팅이 등장하면서 소프트웨어로 기기 환경을 제어하는 움직임이 커지고 있다. 오픈스택이나 오픈플로우 같은 커뮤니티들이 이를 지원하고 있다. 소프트웨어 정의가 자리잡으면 다양한 자원을 프로그램을 통해 한꺼번에 관리할 수 있어 비용 절감 효과가 기대된다.

8. 웹 스케일 IT

웹 스케일 IT는 아마존, 구글, 페이스북, 등 대형 클라우드 서비스 제공업체들의 클라우드 운영 방식을 일컫는다. 이들은 자신들의 인터넷 서비스를 더 빠르고 신속하게 전달하기 위해 데이터센터를 짓고 클라우드를 운영한다. 이들이 만드는 웹지향 아키텍처는 개발자가 장애를 더 빠르게 복구하며, 유연하고 탄력적인 시스템을 구축할 수 있게 돕는다. 이들 회사는 웹 스케일 IT를 구현하기 위해 서버, 스토리지, 네트워크 등 각 구성 요소를 최적화해 운영한다.

미래 혼란(Future Disruption)

9. 스마트 머신

2020년이 되면 스마트 기기의 시대가 될 것으로 보인다. 시리와 같은 지능형 비서, 사람과 비슷하게 생각할 줄 아는 인공지능 ‘왓슨’과 같은 사례들이 더욱 풍부해질 것이다.

10. 3D 프린팅

2014년 3D 프린터의 출하량은 지금보다 75% 증가하고, 2015년이 되면 200% 성장할 것으로 보인다. 3D 프린터를 이용한 맞춤형 제조 시대가 열릴 것으로 보인다.

► 관련 기사

∙ 가트너가 꼽은 ’2013년 10대 전략기술’

Categories: 개발 | Permalink

2013년 10월 25일
by aduris
0 comments

Parallax Scrolling

1. Parallax Scrolling이란?

1940년대부터 전통적인 애니메이션이나 게임에서 사용됐던 기법으로 화면을 구성하는 배경이미지들과

기타 이미지들간의 움직임이나 동작 시간을 다르게 주어 스크롤이 될 수 있도록 하는 디자인 표현 기법입니다.

Parallax(시차 : 관측 위치에 따른 물체의 위치나 방향의 차이)의 뜻에서도 볼 수 있듯이 물체의 위치와 방향의 차이로

사용자에게 평면적인 웹사이트가 아니라 마치 살아 숨쉬는 듯한 느낌의 웹사이트를 제공할 수 있습니다.

2. 등장배경

원래는 애니메이션이나 게임에서 사용하던 기법으로 예전에 PC나 게임기에서 하던 마리오와 같은 게임을 예로 들 수 있습니다.

마리오 게임을 보면 배경과 배경 외 다른 오브젝트들(마리오, 장애물, 아이템상자 등)로 구성되어 있습니다.

마리오가 앞으로 진행 시 배경과 다른 오브젝트들의 동작 방향과 동작 시간의 차이를 두고 있습니다.

이 때문에 사용자는 연속성을 제공하여 캐릭터를 동작시키면 게임을 진행할 수 있습니다.

웹의 발전과 시각적으로 뛰어난 웹을 요구하는 사용자들이 증가함에 따라 웹사이트에서도 이러한 기법을 사용하려고 노력했습니다.

그러나 몇 년 전까지만 해도 HTML과 CSS만으로 한계에 봉착하였습니다.

그리하여 Adobe사의 Flash를 통해 Parallax Scrolling 기법을 사용하곤 하였습니다.

최근에는 다양한 모바일 기기의 발전과 여러 보안상의 문제점들로 인하여 ActiveX나 Flash와 같은 플러그인을 배제하려는 노력하고 있으며,

이와 함께 HTML5와 CSS3, Javascript, Javascript library 등의 발전하여 Flash를 대체하여 구현이 가능하게 되었습니다.

위와 같은 상황으로 기업이나 서비스 제공자가 제약적인 환경에서 벗어나 사용자나 소비자에게 좀

더 다이나믹하고 시각적으로 뛰어난 효과들, 다양한 디바이스에서의 지원, 여러가지 마케팅 효과 등을 얻기 위해

본격적으로 Parallax Scrolling 기법을 사용하게 되었습니다.

3. 사용유형

Parallax Scrolling 기법을 보면 사용자가 웹페이지에서 마우스의 스크롤 또는 키보드의 방향키를 통해 화면을 제어하도록 하고 있습니다.

이런 기능을 통해 기업이나 서비스 제공자가 사용자의 시선을 유도하거나 호기심 유발 등과 같은 효과를 줄 수 있습니다.

그렇기 때문에 다음과 같은 유형에 많이 사용하고 있습니다.

제품설명
기업 광고
스토리텔링
스토리를 가진 브랜드 광고
회사소개

4. 장/단점

Parallax Scrolling을 사용함으로 장/단점은 다음과 같습니다.

- 장점

페이지 컨텐츠를 소비하지 않음 -> 한 페이지로 구성 가능.
컨텐츠에 따라 사용자의 시선을 서비스 제공자가 원하는 방향으로 이끌수 있음.
단순히 마우스 스크롤 뿐만이 아니라 키보드의 방향키 등을 통해 다양하고 새로운 사용자 경험을 이끌어 낼 수 있음.
디스플레이 크기에 영향받지 않고 효과적으로 컨텐츠를 전달할 수 있음

- 단점

컨텐츠가 가로 또는 세로로 너무 길 때, 사용자가 지루함이나 불편함을 느낄 수 있음.
하나의 페이지로 구성 시 많은 리소스가 필요하기 때문에 초기 로딩속도가 느릴 수 있음.
컨텐츠의 양이 많을 경우 화면 구성이 복잡해질 수 있음.
모바일 등의 기기에서 처리 문제가 남아 있음.

5. 국내외 사례

- 국내

- 해외

6. 마치며…

Parallax Scrolling에 대해서 조사하면서 느낀 점은 아직까지는 국내보다는

해외에서 화려하면서 편리한 사용자 경험을 이끌어 내기 위한 노력을 많이 있다는 것을 느꼈습니다.

Parallax Scrolling과 같은 기법을 사용할 수 있는 유형이 거의 정해져 있지만

우리나라에서도 이런 기법이나 새로운 사용자 경험을 이끌어 낼 수 있는 노력이 필요할 것 같습니다.

또한 Parallax Scrolling 기법을 사용 시 초기로딩 속도 문제나 화면 전환시 끊김과 같은 성능 문제를 야기할 수 있습니다.

이런 성능 문제에 대해서는 Minify와 Gzip, Javascript Loader 나 화면 전화 시 Ajax를 통한 Append 등

여러 성능 개선 노력등을 통해 충분히 개선이 가능할 것이라고 판단합니다.

해당 기법만이 아닌 사용자에게 좀 더 편리하면서 시각적으로 뛰어난 디자인 기법에 대한

노력이 필요할 것 같습니다.

Parallax Scrolling에 대한 이론만 다루었습니다.

추후에 기회가 된다면 다양한 예제를 통해 다시 한번 다루도록 해보겠습니다.

감사합니다.

※ 참고 자료

[1] http://en.wikipedia.org/wiki/Parallax_scrolling

[2] http://designbyforest.tistory.com/entry/%ED%8C%A8%EB%9F%B4%EB%A0%89%EC%8A%A4-%EC%8A%A4%ED%81%AC%EB%A1%A4Parallax-Scrolling

[3] http://sir.co.kr/bbs/board.php?bo_table=pl_talk&wr_id=4187

[4] http://www.kirasung.co.kr/tc/entry/%EC%B5%9C%EC%8B%A0-%EC%9B%B9-%ED%8A%B8%EB%9E%9C%EB%93%9C-_-%ED%8C%A8%EB%9F%B4%EB%9E%99%EC%8A%A4-%EC%8A%A4%ED%81%AC%EB%A1%A4%EB%A7%81-%EC%9B%B9%EC%82%AC%EC%9D%B4%ED%8A%B8-Parallax-scrolling-Website

[5] http://skullacy.com/635

Categories: EDA STUDY, 개발 | Permalink

2013년 10월 11일
by 박성원
0 comments

웹접근성에 대하여 잘 설명해 놓은 동영상

Categories: EDA STUDY, 개발 | Permalink

2013년 7월 2일
by aduris
0 comments

vert.x는 무엇이 좋은가?

vert.x는 현재 가장 뜨겁게 부상하고 있는 서버 프레임워크입니다. 모든 서버 프레임워크가 그렇듯이 고성능과 다양한 프로토콜 지원을 장점으로 내세우고 있습니다. vert.x는 여기서 한 발 더 나아가 서버 네트워크 환경을 구축하고 운영하는 환경까지도 고려하고 있습니다. 즉, vert.x는 하나의 ‘서버 프로세스 데몬’을 제작하는 것뿐만 아니라, 클러스터링 환경에서 동작하는 여러 서버 프로세스 데몬을 제작하는 방법에 대한 고민까지 담고 있습니다.

그렇기 때문에 vert.x가 어떤 방식으로 고성능을 내고 있는지, 어떤 네트워크 환경을 고려하고 있는지 충분히 시간을 들여 알아볼 가치가 있다고 할 수 있습니다.

vert.x의 철학

vert.x는 Node.js로부터 영향을 받은 프로젝트다. vert.x는 Node.js처럼 Event-based 프로그래밍 모델을 제공하는 서버 프레임워크다. 그렇기 때문에 vert.x의 API는 Node.js와 매우 유사하다. 둘 모두 비동기 형태의 API를 제공한다.

Node.js는 JavaScript로 만들어졌지만, vert.x는 Java로 제작되었다. 하지만 vert.x를 Node.js의 Java 버전이라고 이해하기에는 무리가 있다. vert.x가 Node.js로부터 영향을 받은 것은 사실이지만, vert.x는 Node.js와 다른 고유한 철학을 가지고 있기 때문이다.

대표적인 vert.x의 설계 철학을 정리하면 다음과 같다.

Polyglot – 여러 언어 지원
vert.x 자체는 Java로 작성되었지만, vert.x를 사용하기 위해 반드시 Java를 사용할 필요는 없다. Java나 Groovy 같이 JVM 동작을 전제로 한 언어 뿐만 아니라 Ruby나 Python, 심지어 JavaScript로도 vert.x를 이용할 수 있다. JavaScript로 꼭 서버 애플리케이션을 만들어야 한다면, Node.js만이 유일한 대안이 아니게 되는 것이다. 향후 Scala와 Closure도 지원할 계획이다.
Super Simple Concurrency model
vert.x로 서버 애플리케이션을 작성할 때, 사용자는 싱글 스레드 애플리케이션을 작성하듯 코드를 작성해도 괜찮다. vert.x는 사용자가 작성한 코드가 동일한 스레드에서만 실행됨을 보장해서 더 이상 synchronized나 volatile 같은 동기화를 위한 locking 처리를 신경 쓰지 않아도 된다.
Node.js에서는 JavaScript 실행 엔진 자체가 멀티 스레드를 지원하지 않으므로 모든 CPU 코어를 활용하려면 같은 JavaScript 프로그램을 여러 개 실행해야 했다. 하지만 vert.x에서는 하나의 프로세스만 가동해도 CPU 코어 개수에 맞춰 멀티 스레드가 생성될 수 있다. 멀티 스레드와 관련된 작업은 vert.x가 하고, 사용자는 비즈니스 로직 구현에 집중할 수 있게 한 것이다.
Event Bus 제공
도입 부분에서 설명했듯이 vert.x의 목표는 ‘하나의 서버 프로세스 데몬’을 만드는 것에 그치지 않는다. vert.x로 만든 여러 서버 프로그램이 서로 원활하게 통신하게 하는 것까지도 목표에 두고 있다. 이를 위해 vert.x는 Event Bus를 제공한다. Point to Point나 Pub/Sub 같은 MQ 기능을 사용할 수 있다(Event Bus 기능을 제공하기 위해 vert.x는 Hazelcast라는 IMDG를 사용한다). 이런 Event Bus가 있기 때문에 서로 다른 언어로 작성된 서버 애플리케이션이 용이하게 통신할 수 있다.
Module System & Public Module Repository
vert.x에는 모듈 시스템이라는 것이 있다. 모듈 시스템은 일종의 컴포넌트로 이해할 수 있다. vert.x로 만든 서버 애플리케이션 프로젝트 자체를 모듈화한 것이다. 이런 방식으로 재사용성을 도모한다. 이렇게 만들어진 모듈은 Public Module Repository에 등록할 수 있다. Public Module Repository를 통해 모듈을 공유할 수 있는 것이다.

참고) Netty와 vert.x의 관계

vert.x의 성능을 논하기 전에 Netty와 vert.x의 관계를 정리할 필요가 있다. vert.x는 Netty를 사용한다. 즉, 다중 I/O 처리에 Netty를 사용한다. 그렇기 때문에 vert.x와 Netty의 성능 차이를 확인하는 것은 무의미하다.
vert.x는 Netty와는 다른 독자적인 API와 기능을 제공하는 다른 목적의 서버 프레임워크다. Netty는 로우레벨 수준의 I/O를 다룰 수 있는 프레임워크고, vert.x는 그보다는 하이레벨 영역을 다룬다.

Node.js와의 성능 비교

vert.x가 제공하는 기능이 Node.js와는 다르더라도 둘 사이의 성능을 비교하는 것은 충분히 의미 있는 일이다. 그림1과 그림2는 vert.x(Java, Ruby, Groovy)와 Node.js의 성능을 비교한 자료다(출처:http://vertxproject.wordpress.com/2012/05/09/vert-x-vs-node-js-simple-http-benchmarks/).

그림 1은 HTTP 서버를 만들고 200/OK 응답만을 주었을 때의 성능을 비교한 결과다. 그림 2는 72 바이트 크기의 정적 HTML 파일을 응답 결과로 제공하는 경우에 성능을 비교한 결과다. vert.x 제작자가 밝힌 성능이고 스스로도 엄격한 환경에서 실시한 테스트가 아니므로 상대적인 성능 격차에만 주목하는 것이 좋을 것으로 보인다.

그림 1 200/OK 응답만 주었을 때의 성능 비교

그림 2 72바이트 크기의 정적 파일 제공 성능 비교

주목할만한 점은 Node.js보다 vert.x-JavaScript의 성능이 좋다는 것이다. 이 성능 비교 결과가 신뢰성이 매우 높다고 하더라도, 단순히 Node.js에 비해 vert.x가 낫다고 말하기는 어려울 수 있다. Node.js는 Socket.io와 같은 훌륭한 모델을 제공하고 있을 뿐만 아니라, 많은 레퍼런스를 확보하고 있기 때문이다.

vert.x 용어들

vert.x는 vert.x만의 고유 용어를 정의하거나, 일반적인 용어를 vert.x에서 다시 정의해서 사용하기도 한다. vert.x를 잘 이해하려면 vert.x가 정의한 용어를 잘 이해해야 한다. vert.x에서 사용하는 대표적인 용어를 정리해 보았다.

Verticle

vert.x에서 배치(deploy)의 기본 단위다. Java의 경우라면 main 메서드가 있는 클래스가 된다. Verticle은 또한 main 메서드에서 참조되는 다른 스크립트를 포함할 수 있다. .jar 파일이나 리소스를 포함할 수 있다. 애플리케이션은 하나의 Verticle로 이루어질 수도 있고, event bus를 통해 서로 통신하는 여러 개의 Verticle로 이루어질 수도 있다. Java로 생각하면 독립적으로 실행 가능한 Class 또는 .jar 파일로 이해할 수 있겠다.

vert.x 인스턴스

Verticle은 vert.x 인스턴스 안에서 실행되고, vert.x 인스턴스는 자신의 JVM 인스턴스 안에서 실행된다. 단일 vert.x 인스턴스 안에서는 동시에 실행되는 많은 Verticle이 존재할 수 있다. 각각의 Verticle은 고유의 클래스 로더를 가질 수 있다. 이로 인해 Verticle 간에 스태틱 멤버, 글로벌 변수 등을 통한 직접적인 상호작용을 막을 수 있다. 네트워크상의 여러 호스트에서 동시에 많은 vert.x 인스턴스가 실행될 수 있고 event bus를 형성해서 vert.x 인스턴스 간에 클러스터링되도록 설정할 수 있다.

동시성(concurrency)

Verticle 인스턴스는 항상 동일한 스레드에서 실행됨이 보장된다. 모든 코드를 단일 스레드 동작 형태로 개발할 수 있기 때문에, vert.x를 사용하는 개발자에게 개발하기 편한 환경을 제공하는 것이라 할 수 있다. 게다가 레이스 컨디션이나 데드락이 발생하지 않게 할 수도 있다.

Event-based Programming Model

vert.x는 Node.js 프레임워크와 비슷하게 Event-based 프로그래밍 모델을 제공한다. vert.x로 서버 프로그래밍을 할 때 개발해야 하는 코드의 대부분은 이벤트 핸들러에 관한 것이다. 예를 들어, TCP 소켓으로부터 데이터를 수신하기 위해 핸들러를 설정하는 것이나 데이터가 도착할 때 호출될 핸들러를 제작하는 것이다. 이외에도 ‘Event bus에서 메시지를 수신할 때’, ‘HTTP 메시지를 수신할 때’, ‘커넥션이 종료되었을 때’, ‘타이머가 종료 되었을 때’ 알림을 받기 원한다면 핸들러를 작성하면 된다.

Event Loops

vert.x 인스턴스는 내부적으로 스레드 풀을 관리한다. vert.x는 가급적 스레드 풀의 개수를 CPU 코어 수와 일치할 수 있게 한다.

그리고 이 각각의 스레드에서는 Event Loop를 실행한다. Event Loop란 확인해야 할 이벤트를 루프(loop)를 돌면서 확인하는 것이다. 가령 소켓에 읽을 데이터가 있거나, 어떤 타이머에 이벤트가 발생했는지 확인하는 것과 같은 것들이다. 루프를 돌다가 처리해야 할 이벤트가 있다면, 해당 핸들러를 호출하는 방식으로 vert.x가 동작한다(물론 이때 핸들러 처리 시간이 길다거나 블로킹 I/O가 있다거나 할 때는 별도의 작업이 필요하다. 다음 게시글에서 소개할 예정이다.).

Message Passing

Verticle 간의 통신은 Event Bus를 이용한다. Verticle을 actor라고 생각하면, Message Passing은 Erlang 프로그래밍 언어에서 유명해진 actor 모델과 유사하다. vert.x 서버에서는 많은 Verticle 인스턴스 생성 및 이들 간의 message passing을 통해 Verticle 코드에 대한 멀티 스레드 실행이 없이도 사용 가능한 코어에 맞게 시스템 확장이 가능하다.

Shared data

Message passing이 매우 유용하긴 하지만 모든 종류의 애플리케이션 동시성 상황에서 최고의 접근 방법은 아니다. 캐시가 대표적인 예다. 어떤 캐시를 어느 하나의 Verticle만 가지고 있다면 매우 비효율적이 된다. 이 캐시가 다른 Verticle에도 필요한 내용이라면 Verticle이 각각 같은 내용의 캐시 데이터를 관리하여야 하기 때문이다.

그렇기 때문에 vert.x는 전역에서 접근할 수 있는 방법을 제공한다. 바로 Shared Map이다. 그리고 Verticle 사이에서는 오직 불변(immutable) 데이터만 공유되게 하고 있다.

vert.x Core

이름 그대로 vert.x의 핵심 기능이다. Verticle에서 직접적으로 호출될 수 있는 기능은 모두 이 Core에 담겨있다. 당연하게 이 Core는 vert.x가 지원하는 프로그래밍 언어 API에서 접근할 수 있다.

vert.x 아키텍처

vert.x의 대략적인 아키텍처는 다음 그림과 같다.

그림 3 vert.x 아키텍처(원본 출처: http://www.javacodegeeks.com/2012/07/osgi-case-study-modular-vertx.html)

vert.x의 기본 실행 단위는 Verticle이고 동시에 여러 Verticle이 하나의 vert.x 인스턴스에서 실행될 수 있다. Verticle은 Event-Loop 스레드에서 실행된다. 하나의 호스트는 물론 네트워크상의 다른 여러 호스트에서 여러 vert.x 인스턴스가 실행될 수 있는데, 이때 Verticle이나 Module 간에는 Event Bus를 통해 통신할 수 있다.

요약하면, vert.x 애플리케이션은 Verticle 또는 Module 의 조합으로 이루어지며 이들 간의 통신은 Event Bus를 사용한다.

vert.x 프로젝트 구조

다음 그림은 github의 vert.x 페이지에서 소스 코드를 복제(clone)해 Eclipse에서 본 vert.x 프로젝트 구조다.

그림 4 vert.x 소스 트리

전체적인 구성을 살펴보면 다음과 같다.

핵심 library인 vertx-core
배포 및 라이프사이클을 관리하는 vertx-platform
Core Java API를 다른 언어로 노출하는 vert-lang

프로젝트 빌드(build) 시스템으로는 Ant와 Maven의 장점을 갖췄다는 Gradle를 사용한다.

vert.x 설치 및 간단한 예제 실행

vert.x를 사용하려면 반드시 JDK7이 필요하다. vert.x는 JDK7에 있는 invokeDynamic을 사용하기 때문이다.

vert.x는 매우 간단하게 설치할 수 있다. https://github.com/purplefox/vert.x/downloads에서 압축된 설치 파일을 원하는 위치에 다운로드해 압축을 푼 다음, bin 디렉터리를 PATH 환경 변수에 추가하면 설치를 완료할 수 있다. 커맨드 창에서 vertx version을 실행해 버전 정보가 제대로 나오면 설치가 성공한 것이다.

이제는 “Hello World!”를 출력하는 간단한 웹 서버를 JavaScript로 작성하고 실행해 보자. 다음과 같이 코드를 작성한 후 server.js로 저장한다. Node.js 코드와 거의 흡사한 형식이다.

load('vertx.js');

vertx.createHttpServer().requestHandler(function(req) {

req.response.end("Hello World!");

}).listen(8080, 'localhost');

생성한 server.js 애플리케이션을 다음과 같이 vert.x 명령어로 실행한다.

1	`%> vertx run server.js`

브라우저를 열고 http://localhost:8080에 접속해 “Hello World!” 메시지를 볼 수 있으면 성공이다.

다른 언어로 작성 된 예제를 살펴보자. 다음은 Java로 작성한 예제다. 정적 파일을 읽어 HTTP 응답으로 제공하는 웹 서버를 작성해 본 것이다.

Vertx vertx = Vertx.newVertx();

vertx.createHttpServer().requestHandler(new Handler<httpserverrequest>() {

public void handle(HttpServerRequest req) {

String file = req.path.equals("/") ? "index.html" : req.path;

req.response.sendFile("webroot/" + file);

}

}).listen(8080);

</httpserverrequest>

다음은 Groovy로 작성한 코드로 앞의 Java로 작성한 예제와 같은 기능을 한다.

def vertx = Vertx.newVertx()

vertx.createHttpServer().requestHandler { req ->

def file = req.uri == "/" ? "index.html" : req.uri

req.response.sendFile "webroot/$file"

}.listen(8080)

NHN과 vert.x

NHN의 플랫폼 개발 부서에는 vert.x가 정식으로 릴리스되기 전부터 개발 과정을 지켜보고 있었다. vert.x의 가능성을 높이 샀기 때문이다. 그리고 2012년 6월부터 메인 개발자인 Tim Fox와 교류하여 vert.x를 발전시켜 나갈 수 있도록 논의를 진행하고 있다. 예를 들어, Socket.io는 Node.js에서만 사용할 수 있었는데, 이를 vert.x에서도 Java로 사용할 수 있게 포팅 작업을 진행했고 현재 개발이 완료된 상태다. 다음은 github의 vert.x 레파지토리에 있는 pull request 요청 링크다.

https://github.com/vert-x/vert.x/pull/320

산출물인 socket.io vert.x 모듈은 현재 개발 중인 RTCS 2.0 버전(vert.x + Socket.io)에 사용될 예정이다.

Node.js가 지금처럼 활성화된 것은 Socket.io 덕분이었는데, vert.x에서 Socket.io를 사용할 수 있다면 vert.x 또한 많은 사용 사례가 생길 것으로 예상한다. 또한 이 socket.io vertx 모듈을 임베디드 라이브러리 형태로 사용하면 Java 기반의 애플리케이션에서도 socket.io를 사용할 수 있게 된다는 점에서 의미가 있다 하겠다.

참고) RTCS 란?

RTCS(Real Time Communication System)는 NHN의 Real Time Web 개발 플랫폼으로, 브라우저와 서버 간에 실시간으로 메시지를 전달할 수 있게 도와주는 플랫폼이다. RTCS는 현재 야구9단, 미투데이 채팅, 밴드(BAND) 채팅에 적용되어 있다.

마치며

vert.x는 2012년 5월에 첫 버전이 나왔다. 2009년에 첫 버전이 나온 Node.js에 비하면 역사가 매우 짧다고 할 수 있다. 그렇기 때문에 아직 레퍼런스가 많지 않다. 하지만 vert.x는 VMware의 든든한 후원을 받고 있고 Cloud Foundry에서 구동할 수 있기 때문에, 앞으로 많은 레퍼런스가 확보될 것으로 보인다.

참고 자료

“Main Manual” http://vertx.io/manual.html
“Installation Guide” http://vertx.io/install.html
“The C10K problem” http://www.kegel.com/c10k.html
김성박, 송지훈 “자바 I/O & NIO 네트워크 프로그래밍”, 한빛미디어 2004

Categories: 개발 | Permalink

2013년 6월 10일
by aduris
0 comments

대한민국 커뮤니티데이

행 사 명:제 3 회 대한민국 커뮤니티 데이

주 제:2013 커뮤니티의 최신 트랜드 및 기술 이슈에 대한 Tech, Meetup, Workshop
일 시:2013년 6월 29일(토) 오전 10시 ~ 오후 6시
장 소:상암동 누리꿈스크웨어
주최 주관:Community Federation

“혼자 가면 빨리 갈수 있지만, 함께 가면 멀리 갈수 있다.” 자발적으로 모여서 서로의 고민거리를 찐하게 나누는 곳..
위대하진 않지만, 묵묵히 지식을 나누고, 공유하는 작은 영웅들이 있는 곳.. 바로 커뮤니티 입니다.
그리고 그러한 커뮤니티를 한꺼번에 다 만날 수 있는 곳. 「대한민국 커뮤니티 데이」입니다. 3회 대한민국 커뮤니티 데이는 역대 어느 행사보다 더 양적, 질적으로
성장했습니다.. 디자이너, 사용자등 다양한 성격의 커뮤니티들이 새롭게 합류했습니다.
(한국HCI연구회, LEED, 생활코딩, Drupal 서울 커뮤니티, 맥/iOS 개발자 커뮤니티, GNOME 한국커뮤니티, 안드로이드사이드 등)
기존 Tech Session 및 Meetup 외에도 Workshop 참여를 통해 커뮤니티 리더나 여러 전문가들과 함께 더 능동적으로 행사를 즐기실 수 있습니다.
대한민국 커뮤니티를 느껴보시기 바랍니다.

여러분들의 많은 관심과 적극적인 참여 바랍니다.

사전등록 – 22,000원(VAT포함)현장등록 – 55,000원(VAT포함)

EVA의 한 마리 기러기
NHN NEXT 교수 손영수

등록비

사전등록 – 22,000원(VAT포함)현장등록 – 55,000원(VAT포함)

시간	Track 1	Track 2	Track 3	Track 4
	Tech(대회의실)	Tech(중회의실)	Meetup(국제회의실)	Workshop
	Tech(대회의실)	Tech(중회의실)	Meetup(국제회의실)	중회의실	소회의실
9:30~10:30	Registration
10:30~10:40	개회사 및 축사
10:40~12:00	Keynote : OSSI 프로젝트(오픈소스 인공위성 프로젝트) 강연 : 송호준(미디어 아티스트)
12:00~13:00	Lunch (행사 참가 선착순 300명에게 식사 제공)
13:00~13:40	OSS 개발자포럼	드루팔 8의 중요한 변화 홍영택(Drupal 커뮤니티)	모바일의 미래 그리고 앞으로의 전망	테스트 사례공유 - MockMVC 기본설정 및 테스트 - embeded tomcat을 이용한 컨트롤러 테스트 - 테스트 커버리지를 올리기까지의 솔루션 개발시 테스트 경험 공유 (한국스프링사용자그룹)	UI 디자이너 되어보기: 일정관리 모바일 앱의 UI 디자인 - 사용자 중심적인 UI디자인 프로세스 체험 - 리서치, 설계, 평가, 수정 (한국HCI연구회) (4시까지)
13:40~13:50	Break
13:50~14:30	클라우드 서비스 브로커(CSB)가 가져올 클라우드 세상 장선진(소프트웨어인라이프)	JavaScript 성능향상과 Sencha 김태원(한국센차유저그룹)
14:30~14:40	Break
14:40~15:20	WWDC2013 애플의 미래 김정(맥/iOS 개발자 커뮤니티)	Front-End 개발 기술 (자바카페)	오픈소스 커미터 과연 개발자의 미래인가?
15:20~15:30	Break			Break
15:30~16:20	오픈스택과 자동화 구축 방안 안재석(오픈스택 한국 커뮤니티)	위대한 벤처의 탄생(창업) 양준철(온오프믹스대표)		초보개발자들과 함께하는 리팩토링 실습 - Sample 프로그램 제공 - 프로그램 분석 - 코드 리팩토링 (자바카페)	TDD로 하는 iOS 앱 개발 코딩도장 (OSXDev)
16:20~16:30	Break
16:30~17:10	우분투와 찰떡궁합 Hardware & Software 소개 최우영(우분투 한국 커뮤니티)	업무 및 커뮤니케이션에 활용 가능한 UX 아이디어 스케치 이재희(LEED)	아키텍트에 길을 묻다.
17:10~17:20	Break
17:20~18:00	생활코딩 활동의 처음 그리고 현재까지 이고잉(생활코딩커뮤니티)	전투기의 메세지 처리로 보는 패턴 이야기(Fault Tolerance Pattern) (EVA)
18:00~18:10	경품추첨 및 마무리