서비의 다락방

'세계 유수의 온라인서비스 업체에서 웹서비스 개발에 이용하고 있는 언어는 무엇일가?' 에 관한 포스팅이 있어 소개한다.
Web Technology Stack [Analysis] (해당 사이트의 기고문의 신뢰도는 모르겠다. 처음 발견한 사이트라..)
facebook이 php로 구현된건 알고 있었지만 backend 는 java와 같은 다른 언어로 구성되었다니 몰랐던 사실이다. 표를 보면서 느낀점은 웹관련 스택은 참 많이도 쪼개져 있구나.. 역시 silver bullet은 없구나.. 스크립트 언어로 그들 정도 서비스를 유지하려면 서버가 얼마나 많이 필요할까.. 같은 잡 생각? ㅋ

Product	Front End	Back end	Database	Others
Twitter	Ruby on Rails (RoR), JavaScript, jQuery LabJS, Modernizr, JSON-P, oEmbed	Scala	Cassandra	Java, C, Python, Mustache templating language
Facebook	PHP, XHP, Hiphop for PHP, JavaScript	C, C++, Java	Cassandra, MySQL	Python, Erlang
LinkedIn	JSP, Apache Coyote Web Server	Spring MVC, Linkedin spring, grails,	Oracle and MySQL	ActiveMQ for JMS, Lucene as a foundation for search, DWR, Jetty, Eh-cache, Quartz, Spring remoting.
YahooMail	HTML, CSS, JavaScript (with YUI 3)	PHP	MySQL	Apache Traffic Server (formely known as Yahoo! Traffic Server).
Google +	Closure framework, including Closure’s JavaScript compiler and template system, HTML5 History API	Closure templates server-side, C++, Java, or Python	BigTable and Colossus/GFS	MapReduce
FourSquare	scala(lift framework)	scala Amazon S3 for hosting, /img/ folder which is served by nginx directly	MongoDB	load balancer(s): nginx/0.8.52 Lift- A web framework written in scala.
Youtube	Python	psyco, a dynamic python->C compiler	MySQL
Quora	Python and JavaScript	LiveNode/webnode2, Thrift (Communicate to backend) Amazon EC2 and S3 for hosting	MySQL + memcached	C++ Load Balancing: nginx in front of HAProxy
Viddler	PHP, Python	Rails 2.x, ffmpeg/mencoder/x264lib, Java 1.6 / Spring / Hibernate / ehcache, Erlang Amazon EC2 and S3 for hosting	Mysql 5.0	Hadoop HDFS (distributed video source storage) Nginx/Keepalived (Load balancers for all web traffic) Wowza (RTMP video recording server) Mediainfo(reporting video metadata) Yamdi (metadata injector for flash videos) Puppet(configuration management) Logcheck(log scanning) Duplicity(backup)
StackOverFlow	jQuery, ASP .NET	C#, Microsoft ASP.NET (version 4.0), ASP.NET MVC 3, Razor.	LINQ to SQL, some raw SQL Server	HAProxy (for load balancing), Bacula(for backup), Redis(caching layer)
Disqus	jQuery,EasyXDM, Sammy, Flot, Raphaël, JSHint	Python scripts, Django, Celery, South	PostgreSQL, memcached	HAProxy + heartbeat (Load balancing)

firefox 3.5 에서 iframe resize 스크립트가 작동하지 않는 문제로 골머릴 썩다 발견한 해결책.

원문 : http://overfloweb.com/zbxe/?mid=study&category=363&document_srl=741

test browser : ie6, ie7, firefox 3, safari 3, chrome, opera 9

...
<div id="content">
... contents ...
</div>
...
<script type="text/javascript">
function init(){
  var doc = document.getElementById('content');
  if(doc.offsetHeight == 0){
  } else {
  pageheight = doc.offsetHeight;
  parent.document.getElementById("contentFrame").height = pageheight+"px";
  }
}
window.onload = function(){
  init();
}
</script>
...

iframe 안의 소스에서 내용이 들어가는 전체를 <div id="content"></div> 로 감싸고,

onload 이벤트로 그 div 의 dom.offsetHeight 를 구해서 parent.iframe 의 height 를 바꿔주는 방식이다.
붉은색으로 표시된 height 가 크로스 브라우징의 핵심이다.
겨우 height 가 핵심이냐고? 모르는 소리다.

clientHeight, scrollheight,innerHeight, 등등 모두 크로스브라우징은 안된다. 하지만 그냥 height 는 된다.

브라우저 내에서 스크립트를 통하여 위치를 알아낼 수 있도록 하는 W3C의 API 스펙 제정과 더불어
모질라에서 최근 Built-in Geolocation support for Firefox3.5를 발표했습니다. 이는 앞서 발표한 오페라가
그들 브라우저의 위치 정보 지원을 발표한 것과 유사한 행보입니다.

W3C Draft로 제안된, 지리 API(Geolocation API)는 위치 정보를 얻어오기 위해 장치로부터 제공되는 위도,경도와
같은 정보를 활용할 수 있도록 고도로 추상화된 인터페이스를 제공합니다. 일반적인 지역정보의 소스는 GPS,
지역을 추측할 수 있는 IP 어드레스,  RFID, WiFi , 블루투스 MAC 어드레스, GSM/CDMA 등이 될 수 있습니다.
이처럼 다양한 지역정보의 소스를 API는 인지할 수 있습니다.

다음은 지역정보를 알아내는 개괄적 code 형태를 보여줍니다.
[code]
function showMap(position) {
// (position.coords.latitude, position.coords.longitude)를 지도의 중심에 위치하여 보여줍니다.
}
// 현재 위치를 조회 합니다.
navigator.geolocation.getCurrentPosition(showMap);
[/code]
Draft에는 물론, 프라이버시 보호와 관련한 내용도 명시하고 있습니다.

어떤 식으로 동작하나요?

지역 정보를 이용하도록 디자인된 웹사이트를 방문하면, firefox는 당신의 위치 정보를 공유할 것인지를 묻습니다.
동의하면, firefox는 근처의 무선 AP와 해당 컴퓨터의 ip 어드레스를 수집하고서, 지리정보 서비스 제공자인
google location service에 정보를 전송하여 당신의 위치를 알아냅니다. 그 후 위치 정보를 요청한 웹사이트와
해당 정보를 공유하게 됩니다.
위치 정보 공유에 동의하지 않는다면, firefox는 아무런 행위도 취하지 않습니다.

오페라 역시 그들 브라우저에 구현한 지리 기능에 대해 발표했습니다.

우리는 오페라에 geolocation 기능을 추가한 것을 기쁘게 생각합니다. 최근 W3C의
The geolocation Working Group에서 geolocation API 명세의 첫 번째 Working Draft를
발표하였고 우리는 그 API를 지원하는 첫번째 제품을 발표했습니다.
API는 웹페이지에서 자바스크립트를 통하여 위치하고 있는 곳의 위도와 경도를 알아내는
데 이용됩니다.

위에 예시한 location-aware 브라우저가 아니라면 구글 Gears의 Geolocation API를 이용할 수 있습니다.

Geolocation API는 다음과 같은 메소드를 이용할 수 있습니다.
getCurrentPosition 메소드를 통하여 현재의 위치를 알아냅니다.
watchPosition 메소드를 통하여 이용자의 시간의 경과에따른 위치 변화를 확인합니다.
lastPosition 프로퍼티를 통하여 이용자의 마지막 위치를 빠르게 조회할 수 있습니다.

Gears 0.5 에서는 좀 더 정확한 위치 판독을 위해 WiFi 안테나의 데이터도 이용할 수 있을거라는군요.

아래는 웹은 아니지만 구글 안드로이드에서 구현된, Layar라 불리는 모바일 Geolocation 어플리케이션의
구동 모습입니다. geolocation-aware 브라우저가 어떤일을 할 수 있을지를 가늠해 볼 만한 영상이라 소개
합니다. 현재는 네델란드 정보만 있지만 전세계로 확대할 예정이라고 합니다.

이미지출처 : http://www.flickr.com/photos/formforce/3409362834/sizes/o/

Information Architects에서 매년 작성하는 Web Trend Map의 2009년 판 final beta입니다.
지도에는 333개의 영향력 있는 도메인과 111명의 인물을 표기하고 있는데요.
도메인을 지하철 역에 비유한 아이디어가 무척 신선했습니다.

iA팀에서는 각 도메인과 인물들을 수입,트래픽,존속연수 등을 기준으로 토쿄 지하철
정거장에 배치해 놓았습니다.
지도의 상 하단에 범례가 있어 그 의미를 파악할 수 있습니다.
간단히 설명하면 도메인의 넓이는 안정성, 높이는 성공 도를 나타내며, 도메인이 두 개
이상 교차하면 해당 도메인은 두 개 이상의 분야에서 활동한다는 의미입니다.

잘 찾아보시면 국내 포털도 보입니다. ^^

출처 : http://informationarchitects.jp/web-trend-map-4-final-beta/

서블릿 API에 근간한 대부분의 자바 웹 어플리케이션 프레임웍은 web.xml파일에 하나 이상의 서블릿, 필터, 리스너 등 웹 어플리케이션에 관계한 설정을 기술해야만 합니다. 의존관계에 있는 WEB-INF/lib 디렉토리의 jar들도 포함해서 말이죠.
EE6의 한 부분을 구성하는 Servlet 3.0 스펙인 JSR-315은 이것을 바꿀 방법을 모색하고 있습니다. 서블릿 3.0 스펙은 현재 Public Review 상태이면 그 내용은 아래 링크에서 확인하실 수 있습니다.

JSR-000315 Java^TM Servlet 3.0 Specification

서블릿 3.0 스펙에는 무설정(Zero Configuration) 지향과 이식성(Plugability) 향상을 목표로 다음과 같은 새로운 기능이 추가됩니다.
    1. annotation의 추가 : 서블릿 3.0 스펙에는 서블릿의 url-mapping 정보를 제공하기위한 @Servlet과 같은 수 개의 새로운 어노테이션(@ServletFilter, @FilterMapping 등)이 추가됩니다.
    2. web.xml의 분할(fragments) 설정 지원 : 서블릿 정의, 필터 혹은 리스너 등을 각각 지정한 설정 파일을 web.xml에 merge하는 방식을 채택해 개개의 웹 프레임워크 jar 파일들의 각자 고유한 설정을 가질 수 있도록 하였습니다.
Flag(metadata-complete)는 annotation과 fragment 모두의 스캐닝을 제어하는데 이용됩니다.

위와 같은 사양 추가로 인해 원치않는 서블릿이나 필터들의 배포로 야기될 수 있는 보안 위협에 Expert Group내에서도 적지않은 논쟁을 펼치고 있습니다. 물론, 그런 보안 위협은 제거할 수 있을만큼 충분히 유연하다는 의견도 만만치 않구요.
이에 대한 Expert Group의 잠정적인 결론은 커뮤니티의 피드백을 받아보자는 쪽인것 같습니다.

Greg Wilkins는 Automatic Scanning 과 분할된 설정파일의 merge를 예로든 그의 글을 통해 <include>라는 옵셔널 엘리먼트를 추가하는 방식을 제안했습니다.

"Without a web.xml or with a 3.0 web.xml that does not list any inclusions,
the default would be to search all of WEB-INF for annotated servlets and filters,
TLD listeners and web.xml fragments as currently proposed. If however,
a web.xml contained <include> element, then the discovery process would be
modified as the following examples illustrate:
<include src="WEB-INF/lib/dwr.jar"/>
<include src="WEB-INF/lib/cometd.jar"/>
<include src="WEB-INF/classes"/>
This include would scan only the dwr.jar and cometd.jar for annotations,
TLD fragments and web.xml fragments, the WEB-INF/classes directory would be scanned for
annotated servlets. No other jars or classes would be scanned unless listed in their
own include elsewhere in the web.xml."

Specification 리더중의 한 명인 Rajiv Mordani는 위와 같은 방법에 놀랍긴 해도 수긍할 순 없다고 하네요.

"Greg Wilkins의 제안하는 방법은 의도하지 않은 서블릿과 필터들이 노출되는 것을 우려하는
곳에나 먹히는 매우 특별한 경우로 그것은 프레임워크 개발자의 문제이며 특정 컴포넌트를
노출하지 않기를 원하는 이용자의 문제는 아니라고 생각한다. 이런 경우라면 flag를 이용하여
jar의 집합으로부터 효율적으로 스캐닝을 컨트롤 할 수 있다."  

다른 두 가지 가능성에 대해 올해 Java One Conference에서 Expert Group 사이에서 논의가 있었습니다.
한 가지 방법은 web fragments와 annotations의 스캐닝 여부를 활성화(enable/disable)하는 두 번째 flag를
metadata-complete에 추가하는 방법이 있겠습니다.
Rajiv Mordani의 요지는 어노테이션 메카니즘은 이미 web.xml 파일의 설정을 상속받을 수 있도록 구현 되었기
때문에, 이런 방법을 통해서도 원하는 수준의 제어가 가능하다는 것입니다.

"When you use annotations to declare servlets and Filters then you must have a url-mapping
/ FilterMapping attribute on the corresponding servlet / Filter.
In this way there is no convention by which a servlet is exposed without having an explicit mapping.
Also, as with the rest of the Java EE platform, specifically technologies like EJB and Web Services,
the deployment descriptor is used to override information that is specified via annotations....
If you didn't want any of the annotations to be processed at all by the container and wanted to specify
all the configuration via the deployment descriptor, then, like with the rest of the Java EE 5 platform,
we have the metadata-complete element in the descriptor. If the element is present and set to "true" then
the container will not process any annotations and just use the configuration specified in the descriptor.
This provides a way [to] disable the auto-scanning for those that have concerns about performance,
and security.”

마지막 방법은 아래와 유사한 방식으로 서블릿과 필터를 무효화하는 메카니즘을 web.xml에 기술하자는것

<servlet>
      <servlet-name>FrameworkServlet</servlet-name>
      <enabled>false</enabled>    
</servlet>

등이 있습니다.

해당 이슈에 관심이 있거나 feedback을 원하는 분은 jsr-315-comments@jcp.org으로 의견을 보내실 수 있습니다.

** 본 포스팅은 2006년 12월 20일 네이버 블로그에 포스팅한 내용을 백업, 내용을 보강한 것입니다. **

자바 진영에서 웹어플리케이션(jsp,servlet,jsf,struts,webwork 등을 통틀어)을 구성하는데는 크게 두가지의 표준디렉토리 레이아웃이 존재한다.
( 모든 웹 프로젝트가 표준을 따르는것은 아니며 각각의 프로젝트마다 달라질 수있다. 여기서는 두 표준이 제시하는 디렉토리 레이아웃을
살펴보고자 할 따름이다.)

하나는 SUN에서 내 놓은 JAVA Blueprint, 나머지 하나는 자카르타 프로젝트이다.
두 레이아웃의 차이는 아래 다이어그램으로 표현 할 수 있다.

주황색으로 구분지어 놓은 부분이 두 구성간의 디렉토리 차이이다.

J2EE 환경을 구축하기 위해선 Java Blurprint 형식의 레이아웃이 더 알맞은 형식이라 생각한다.
netbeans 에서 웹 어플리케이션 프로젝트를 생성 하면 위의 두 형식의 표준을 모두 지원한다.
메뉴 -> File -> New Project... -> 프로젝트 카테고리에서 Web 선택 -> next 하면 아래와 같은 대화창이 뜬다.



붉은 색 박스 안과 같이 두 양식 중 하나를 선택 할 수 있으며 이 두 양식의 선택에 따라 아래와 같은 표준 레이아웃으로 프로젝트가 생성 된다.
(추가 : 현재의 넷빈즈는(버전 6.0이상) 위와 같은 옵션이 사라지고 Java BluePrints형식에 맞추어 디렉토리가 설정됩니다. )



맨 위 디렉토리 형식에 추가하여 nbproject 와 test 디렉토리가 추가로 생성 되는데 nbproject에는 해당 웹 프로젝트에 대한 메타 데이타와
build.xml에 기술 되어야 할 앤트 스크립트의 실제 내용이 배치되며, test 디렉토리에는 test용 클래스등을 구성 할 수 있는 디렉토리로 존재하게 된다.

* MANIFEST.MF ?
Executable JAR 파일을 생성 할 때 main 클래스를 지정 하게 되는데
이 내용을 기술 하는 텍스트 파일이다.

그 기술 내용은

Mainfest-Version: 1.0
Main-Class: [filename] (.class 없이)
Created-By: [생성자 정보] (필요한 내용을 자유롭게 기술...)

이며 
실행은 콘솔에서
java -jar jarfilename.jar [엔터]
혹은 jre 가 설치 되었다면  jar 파일을 더블클릭 하는것으로 실행이 가능하다.

현재 이용하고 있는 웹호스팅 서비스의 결재주기가 6개월인 이유로 매 6개월 발송되는 invoce를
잊지 않고 챙겨야 했습니다. invoce를 확인하고 paypal로 결재하고.. 이런거 신경 써서 챙기는 것도 은근히
피곤하더군요.

그래서 오늘 해당업체 세일즈팀에 요청하여 결재주기를 1년 단위로 변경하였습니다. 맘 같아선 한 3년 주기로 하고
싶었지만 그러면 아예 잊을 것 같기도 하고 결정적으로 한 번에 결재해야 하는 금액이 상당히 커 차마 그렇게까지는
못 했습니다. 뭐 간단히 카드번호를 기재 해 두고 자동 결재가 되도록 할 수도 있지만 그러기엔 사람의 심리란 게...

현재 호스팅 서비스에 가입할 때만 해도 계정 200Gbyte에 월 트래픽 2Tbyte의 서비스였는데
두어 달 전 업체에서 서비스를 업데이트 하더니 계정공간이  1,000Gbyte에 무제한트래픽이 되었습니다.
파일공유 사이트가 아닌 개인 사이트의 공간으로 평생 다 채울 수나 있을지 모르겠네요..
마음 맞는 주변 사람들에게 계정 분양을 심각하게 고려해 봐야 할 듯합니다그려...

아래는 버그많은 IE6의 버그들을 집중적으로 잡아낼수있는, IE6 용 CSS hack 들입니다

스타 핵 (* html 을 이용)
별표문자인 전체 선택자를 html 타입 선택자 앞에 오도록 해서 다른브라우져에서 적용되지 않지만 IE계열에서만 적용되는 스타일시트를 정의할 수 있습니다.


즉 위의 2줄을 적었을경우, IE계열에서는 border:2pxl 스타일이 적용됩니다.
이 스타핵은 IE7에서 적용되지 않습니다.
추가) IE7에서 적용되는 스타핵은 아래와 같습니다.


그렇다면, 모든 IE계열(7버전 포함)에서 동작하는 스타핵은 아래와 같이 하면 됩니다.



!important 핵
위의 스타핵은 IE6을 구분하기 위하여 2가지의 선언을 해야합니다. 그러나 한 규칙선언안에서 IE6 이하버전을 위한 선언과 다른 브라우저를 위한 선언을 하고 싶다면 !important 핵을 사용하면 됩니다.


IE6 버전에서는 한 규칙안에 여러개의 속성을 사용할 수 없으므로, 첫번째 선언을 무시하고 두번째 선언을 적용합니다.
나머지 브라우져에서는 important 키워드가 쓰여진 속성의 우선순위를 높게 인식하기때문에 첫번째 선언을 적용합니다.



언더바핵
가장 많이 알려진 CSS핵입니다.
iE6이하 버전에서는 속성정의자의 _ (언더바)를 무시하고, 인식하는 점을 응용한 핵입니다.


두번째 정의된 display 의 _ (언더바)가 없다면, 모든 브라우져에서 display:block 이 적용될 것이나 _ (언더바)가 있기때문에 두번째 속성정의자는 IE6 이하 브라우져를 제외하곤 잘못된 속성정의자로 인식합니다.
따라서 IE6에서만 _display 를 display 로 인식하기때문에 display:block 속성이 적용됩니다.