오픈소스 개발 플랫폼 램프「닷넷·자바 입지 위협」
http://zdnet.co.kr/news/enterprise/dev/0,39028947,39137316,00.htm
기업용 소프트웨어 개발 세계는 수년동안 MS 닷넷과 자바가 크게 양분하고 있었다. 이 시장에 또 하나의 경쟁자가 뛰어들 채비를 갖추고 있다.램프(LAMP)라 불리는 오픈소스 소프트웨어 스택이 지금 기업용 컴퓨팅의 주류로 성장하고 있다. 여기에는 리눅스 운영체제, 아파치 웹서버, MySQL 데이터베이스, 스크립트 언어인 PHP와 펄, 파이썬 등이 포함돼 있다.
...
...핀치는 “자바는 구식 언어다. 난 자바에 감동하지 않는다. IBM 웹스피어나 BEA 시스템의 웹로직을 쓸 때 드는 돈이 얼만지 봐라. 개발비가 끊임없이 들어간다”고 말했다.
...
...
약간의 오버는 있지만, 충분히 공감이 가는 이야기 인 것 같습니다.
LAMP ( Linux + Apache + MySQL + PHP ) 를 말하는 것인데,그 중심에는 오픈소스의 마스코트 아파치가 있습니다.
MySQL 은 PostgreSQL 과 교체가 가능하고, PHP 는 perl, python , ruby 등과 교체 가능하겠네요.(LAPP , LAPR .. )
아직 모자란듯 하지만, 엄청난 개발속도 단축에 의해 많은 사용자를 확보하고 있는 듯 합니다.
앞으로도 이런 구조가 더욱 탄탄해 질 것 같고, 더욱 자바,닷넷 진영을 압박할 듯 합니다.
ruby, python 등을 들여다 보면, 거의 환상이죠. ^^
MySQL, PostgreSQL 도 이제 "Oracle 을 넘볼까?" 하는 수준(아직은..)까지 근접한것 같구요.
아파치는 두말하면 잔소리구요.
여기서 위험한 화두 하나!!
대형프로젝트에는 꼭 닷넷,자바 진영을 사용해야 하는가?
단순히 제안서에 쓸만한 레퍼런스(?)가 부족하기 때문인가!!
라고 생각해 봅니다.
그냥 단순히 웹시장에서 경쟁력을 말하는 것이라면 뭐 LAMP 충분하겠습니
그냥 단순히 웹시장에서 경쟁력을 말하는 것이라면 뭐 LAMP 충분하겠습니다만
기술적으로 따진다면 전 .NET을 한참 위에다 놓고싶네요 그냥 제의견 ^^;
Re: 오픈소스 개발 플랫폼 램프「닷넷·자바 입지 위협」
국내 자바쪽에서 활동하고 계시는 박용우님의 공개 프로젝트의 문서에 보면 이런 내용이 있었던 것으로 기억합니다.
(url: http://okjsp.pe.kr/slf/
또는 5회 자바 컨퍼런스 문서를 참조하세요.
이곳(위 주소)안에 있는 게시판에 있습니다.)
대략적인 요지는 다음과 같았던 것으로 기억합니다.
"mysql 등등의 오픈소스 제품을 사용 하고 싶지만 개발 단가가 안나온다.이유는 업체들에게 안먹혀 들기 때문이다. 선입견 때문이기도하며 오픈소스로도 충분히 구현가능하지만 개발비가 모자르게 된다."
이런 내용이었던 것으로 기억합니다.
봄들판에서다
Re: 오픈소스 개발 플랫폼 램프「닷넷·자바 입지 위협」
"인건비를 솔루션비로 대체한다"의 조금 완곡한 표현이군요. 그러고보면 돈이 남아돌아 어쩔줄 모르는 곳은 참 많은 것 같습니다.
Re: 오픈소스 개발 플랫폼 램프「닷넷·자바 입지 위협」
결국에는 현재의 인식의 문제 라는 것이군요.
그런데, 그 인식이 전환(?)될 가능성은 어떻게 보시는지요?
가능하다고 해도 오랜시간이 필요하려나?
닭잡는데 소잡는 칼을 쓸 필요는 없습니다.자바라고 해도... 굳이
닭잡는데 소잡는 칼을 쓸 필요는 없습니다.
자바라고 해도... 굳이 필요없는 곳에 J2EE/EJB를 쓸 필요는 없습니다.
물론 닷넷도 마찬가지겠지요.
Linux - Tomcat/Apache - MySQL - Servlet/JSP
Windows - IIS - MSSQL - ASP.NET
이런 조합도 LAMP와 크게 차이가 없다고 봅니다.
DB는 (일반적으로) 언제든지 교체가능한 것이구요...
(오히려 PHP의 DB 바인딩은 약간은 구시대적인 느낌입니다.
물론 Pear가 있지만 Pear를 쓴 코드를 별로 못본거 같네요.)
다만, 그 닭이 점점 커져서 타조만해지면 LAMP의 한계가 보일지도 모르죠.
MySQL은 기존의 대형 RDB못지않은 기능/성능을 보여주고 있습니다만...
PHP가 오히려 발목을 잡을지도 모르겠습니다.
제가 PHP를 잘 몰라서 하는 헛소리일지도...
----
the smile has left your eyes...
[quote="iolo"]닭잡는데 소잡는 칼을 쓸 필요는 없습니다.
LAMP 를 PHP 에 한정해서 보면, 한계가 많이 드러나긴 합니다.
PHP 자체가 특수상황(?)에 맞게 만들어지다 보니 그런것 같습니다.
위의 LAMP 를 Perl , Python, Ruby 등으로 확장해서 생각해 주시기 바랍니다.
근데 사실 자바가 소 잡는 칼이라고 하기엔 요즘 너무 자바로 개발하기가
근데 사실 자바가 소 잡는 칼이라고 하기엔 요즘 너무 자바로 개발하기가 쉬워졌죠. 개발 생산성에서 PHP에 결코 뒤지지 않습니다. PHP로 하루 만에 뚝딱 만들 수 있는 페이지라면 자바로도 하루 만에 만들 수 있습니다. 다만, PHP로 한 시간에 만들 수 있는 건 자바로 여러 시간 걸릴 수 있죠. 현재 PHP와 자바의 생산성 차이는 딱 그 정도인 듯 합니다. 물론, 양쪽 모두 자신의 언어에 충분히 익숙한 상태라면 말입니다. 자바가 learning curve는 훨씬 더 크니까 그 점은 또 별도의 고려 대상이 되겠죠.
그리고 사실 Linux, MySQL은 자바에서도 많이 씁니다. 아직은 Unix 계열과 오라클의 조합이 압도적으로 많지만 포탈 같은데는 서버 단가상 다 리눅스죠.
글보다가 갑자기 궁금해진건데Fortran.NET Ruby.NET Py
글보다가 갑자기 궁금해진건데
Fortran.NET Ruby.NET Python.NET 등등등은 도데체 언제쯤 나올까요 흠;;
그리고 만약 나온다면.... VS.NET에도 포함될 수 있으려나??
[quote="creativeidler"]근데 사실 자바가 소 잡는 칼이
jsp만 놓고 보면 닭잡는 칼지만, jsp는 분명 java의 모든 기능을 포용하고 있습니다. 사실 jsp와 서블릿을 구분하는 것이 이상한데, jsp는 말하자면 닭잡는 용도로 변장한 java라는 거죠.
php는 애초에 닭 잡는 용도로 만들어졌기 때문에, 말씀하신 것처럼 닭잡을 때는 최고의 효율을 보입니다(닭잡는 용도로 임시변통한 jsp와 비교해도 당연히 더 높은 효율을 보이죠). 그러나 그걸로 소를 잡으려고 하면, 정말 닭질을 해야하는 거죠. 종종 c같은 드라이버나 펜치가 필요할 때도 있죠 .
php.net에서는 php를 소잡는 용도에도 사용할 수 있도록 무던히 노력하고 있으나, 그다지 성과는 없어 보입니다. 그 부분에 대해서는 php 개발자들에게도 책임이 있어 보입니다. php의 향상된 기능들을 쓰지 않는 다는거죠. 물론 불필요하게 고급기능을 남발할 필요는 없습니다만, 있으면 더 편한데도 불구하고 기존의 방법을 답습하는 경우를 많이 보게 됩니다. Pear가 대표적인 예가 될 수 있겠죠. 말하자면 아직도 많은 php개발자들은 "PHP: Hypertext Preprocessor"가 아닌 "Personal Home Page"를 쓰고 있다는 거죠.
firefox님께서 말씀하신 것처럼 LAMP의 P가 python, perl, ruby(루비는 p가 없군요 ^^;)라고 보면 충분히 소잡는 용도로도 쓸 수 있을 것 같습니다.
----
the smile has left your eyes...
제 경험에 의하면 반드시 기술적으로 옳은 것이 고객을 만족시키지는 못하더
제 경험에 의하면 반드시 기술적으로 옳은 것이 고객을 만족시키지는 못하더군요.
단적인 나쁜 사례로 고객 자체가 특정 업체나 제품을 선호한다던가 해버리면 다른 말이 끼어들 여지가 없어집니다. 그냥 "네 알겠습니다." 라는 답변 외에는요...
예를 들면 이런식입니다. 어떤 프로젝트가 있는데 데이터베이스를 구매해야합니다. 그래서 비용적으로 적당하고 그럭저럭 쓸만한 MS SQL 을 제안한다고 가정해보겠습니다. 상대가 대기업쪽이라면 일단 MySQL 은 말도 꺼내기 어려운 것이 최근까지의 풍토였으니까요. 암튼 MS SQL 이 좋은지 나쁜지는 일단 제껴놓도록 하고 얘기를 계속하죠.
기능적으로 크게 뛰어난 기능도 별로 필요없고 데이터양도 그리 많지 않습니다. 그래서 상대적으로 저렴한 MS SQL 을 제안하고 한참동안 회의를 진행하면서 장점이나 단점등을 설명해줍니다. 그런데 회의가 끝날때쯤 고객이 이렇게 말합니다.
"그냥 오라클로 넣어주세요."
그럼 저희는 할 말이 없습니다.
"넵!"
그리고 끝입니다. 나중에 물어보니 이런 이유라는군요. 그 고객, 즉 클라이언트쪽 담당자는 결국 프로젝트가 종료되면 관리까지 하게 될 입장입니다. 그런데 나중에 퇴사를 하게 된다거나 기타 이력서를 쓸때가 되면 문제가 된다는 겁니다. 오라클 5 년 DBA 라고 한 줄 들어가는 것과 MS SQL 5 년 DBA 라고 한 줄 들어가는 것은 이력서 한 줄이긴 하지만 차원이 다르다는 거죠. 정말로 그런지는 모르겠습니다만, 제가 말씀드리고 싶은 것은 기술적인 선이 미시적인 관점에서의 내 고객에게 항상 이롭다고는 장담하기 힘들다는 것입니다. 더군다나 그 고객이 의사 결정을 하는 사람인 경우에는요.
또 다른 사례로는 이런 경우도 있었죠. 굳이 COM+ 가 들어갈 필요가 없는 프로젝트인데도 담당자는 계속해서 COM+ 를 강요합니다. 당시 프로젝트 구성원 중 한 명을 제외하고는 COM+ 를 해본적도 없는 사람들이 다였는데도 말입니다. 그 이유는 간단했습니다. 담당자가 MS 광팬이었거든요. 그리고 그 담당자 입장에서는 이런 내용이 들어가는 보고서를 쓸 필요가 있었던 것입니다.
"... 저는 XXX 사업부 시스템에서는 최초로 마이크로소프트의 신 기술인 COM+ 를 도입하여 성공적으로 프로젝트를 마무리 했으며..."
이 지경이 되어버리면 을이나 병인 저희들 입장에서는 대책이 없는 거죠.
저도 ZDNet 을 자주 들어가는 편입니다만, ZDNet 의 기사중 상당수가 외국, 그중에서도 미국의 관점에서 씌여진다고 알고 있습니다. 필진 자체가 그러하니까요. 현재 SI 업계에 몸담고 있는 저로서는 최소한 대기업 대상 프로젝트에서 아직까지 저러한 움직임을 느껴본 적이 전혀 없습니다.
개인적으로 파이선에 상당히 매력을 느끼고 있지만 도무지 SI 쪽에서는 도입될 기미가 보이질 안네요...
[quote="kkb110"]글보다가 갑자기 궁금해진건데Fortran
FORTRAN, ruby는 잘 모르겠지만 python이라면 ironpython이 있습니다.
http://www.gotdotnet.com/workspaces/workspace.aspx?id=ad7acff7-ab1e-4bcb-99c0-57ac5a3a9742
기업용 Java, .net의 어플리케이션 서비스 중에 사용자에게 보이지
기업용 Java, .net의 어플리케이션 서비스 중에 사용자에게 보이지 않는 영역, 가령 메세징 등을 위해서는 LA는 사용이 되지만 아직 MP로 붙이기에는 역부족입니다.
그리고, 저 위에 인용된 부분 중에 "개발비가 끊임없이 들어간다"고 했지만, 사실은 운영비가 계속 들어가는 거죠. 예를 들어, IBM의 Websphere MQ를 사용하면, cpu당 클라이언트 비용과 message broker 비용 만해도 일년에 수천만원 씩 들어갑니다. 그래도 현재로는 신뢰할만한 대안이 없으니 울며 격자먹기로 사용을 하던가, 조금 싼 MS의 Biztalk으로 가던가, 그 위에 돌아가는 어플리케이션 개발/운영은 인도로 용역을 주던가 해서 외부적인 것에서 대안을 찾아쓰는 형편이죠.
예전에 옆 부서의 매니저가 윈도우즈/탐캣에 돌아가는 jsp/servlet 어플에 ssl을 적용을 위해 apache2용으로 openssl을 컴파일 하는데, 결국은 직접 개발자와 접촉을 해서 해결을 하는 수 밖에 없었다고 매번 이래야 된다면 어떻게 운영을 할 수가 있냐는 생각에 결국은 JRun 서버를 도입을 했다는 이야기를 한 적이 있습니다.(일년에 몇백불은 내지만 타 서버에 비해서는 저렴하고 그래도 서비스를 받을 수 있다는 이유에서 였죠.) 3년전 쯤 된 이야기이지만 제 주위의 사람들은 아직 이런 비슷한 생각을 가지고 LAMP 즉, open source가 기업에 도입이 될 수 있을까를 현재에서도 관망하는 것이 분위기인 듯 합니다.
----
I paint objects as I think them, not as I see them.
atie's minipage
[quote="kkb110"]글보다가 갑자기 궁금해진건데Fortran
python.net은 이미 ironpython이라고 있습니ㅏㄷ
ms의 공식지원 받는 거라거 ms에서 다운가능..
vs.net에 포함될겁니다.
http://www.dotnetpowered.com/languages.aspx
보면
이미 fortran
ruby등 다 있습니다.
즐린
원문이 php니까 php에 대해서 딴지를 걸어보자면,자바가 구식이라는
원문이 php니까 php에 대해서 딴지를 걸어보자면,
자바가 구식이라는건 자바에 대해서 잘 알지도 못하고 쓰는것 같군요. 악플을 달자면, RMS빠? 라고 하고 싶습니다.
j2se 1.4, 1.5에서 변경된 부분만 보더라도 구식이라 할 수 있을지 궁금합니다. 자바는 버전이 올라가면서 기존 체계를 더욱 확고히 굳히고 있지만 php는 5.0에 와서야 클래스를 완전하게 지원하는 등 아직도 언어의 정체성이 명확하지 않죠. C와 C++과 java 사이에 어설프게 걸쳐서 존재하는것처럼 보입니다. -덕분에 C나 C++이나 java를 어설프게나마 다룰줄 알면 php는 쉽게 다룰 수 있는 장점이 있습니다만..-
php 보안버그때문에 새 버전으로 업그레이드 할때마다 공식 배포파일에서 뭔가 하나씩 안맞아서 5~6시간씩 삽질하면서 cvs에서 파일 찾아서 받고 컴파일한 경험이 세번이나 있는지라 php를 옹호하지 못하겠군요. php그룹은 솔라리스에서 컴파일 테스트 한번 안하나 봅니다. 메일링 리스트에도 몇번 올라와 있더군요. 솔라리스가 무슨 죄가 있다고..
저는 업무는 자바로 하고 있지만 취미로 php를 사용합니다. 한때는 php로 업무를 한적도 있었구요. 둘 다 다뤄본 경험상 php가 더 불편하고 불합리하다고 느낍니다. 이젠 더이상은 php로 업무하지 않으므로 트랜드에 뒤떨어져서 그렇게 느낄지도 모릅니다만..
php는 어느 레벨까지는 개발 효율이 굉장히 좋습니다. perl, rubi, 파이썬, 자바 등과는 비교가 안되게 빠르죠. 하지만 규모가 점점 커지다보면 확장성 및 유지보수에 한계가 옵니다. MVC모델을 적용하고 html에서 php코드를 제거하고 아무리 고치고 고쳐서 발악을 해도 한계는 찾아오더군요. (perl, rubi, 파이썬, java 등 독립언어도 하다보면 한계에 오긴 합니다만 php만큼 빨리 찾아오지도 않고 예상보다 손쉽게 벗어날 수 있었습니다.)
한계 상황에서 자바로 이전한다고 나아지냐 하면 항상 그런것만은 아닙니다만.. 자바 진영이 다른 언어에 비해 대체로 쓸만한 프레임웍 구성이 많고 당장은 복잡하고 효율도 안나오지만 잘 따라주기만 하면 나중에 편한건 사실이죠. (뭐, jsp에 소스코드 덕지덕지 바르고 프레임웍따윈 안중에도 없다면 차라리 php를 쓰는게 금액이나 개발속도에 이익이겠지만요.)
대형 프로젝트엔..
대형 프로젝트엔 자바 나 닷넷을 써야합니다.
다시 PHP나 Perl과 같은 스크립트형과 Java와 C류의 컴파일류의 언어 , 더구나 객체지향언어를 비교하는건 의미없을듯 하구요..
대형 프로젝트에서 '유지, 보수'가 얼마나 큰 일인지 모르시는 분은 LAMP에 열광할겁니다. 그 빠름에 감탄을 하지않을 수 없죠..
제가 좋아하는 단어들..
재사용성, 설계, 패턴, 프로세스
이런것들.. 대형 프로젝트에선 필수입니다. 이런거 다 싫다.. 로직자체만 난 집중할래.. 하시는 분들은 PHP로도 충분합니다.
Re: 대형 프로젝트엔..
Python , Ruby 를 생각하면 꼭 그렇지도 않은 듯 합니다.
사용자가 바꾸어 나가자!!
= about me =
http://wiki.kldp.org/wiki.php/offree , DeVlog , google talk : offree at gmail.com
엔터프라이즈 프로젝트에서 지금 파이썬이나 루비 썼다가 해당 인원이 나가버
엔터프라이즈 프로젝트에서 지금 파이썬이나 루비 썼다가 해당 인원이 나가버리고 난 뒤의 경우...
전 생각하고 싶지도 않군요. 덜덜덜... 인재 풀 관점에서 볼때 완전 꽝입니다.
[quote="Anonymous"]엔터프라이즈 프로젝트에서 지금 파이썬이
루비는 몰라도 파이썬은 의외로 사용자가 많더군요.
덜덜덜 할 정도는 아닙니다. ^^
[quote="ssggkim"][quote="kkb110"]글보다가 갑자
자료감사합니다 ^^
생각보다 .NET 지원 언어가 더 많고 진척도 많이되어있는것같네요!
저게 정말 한프로젝트에 언어차원에서 서로 다 동시호환이 된단말이면... 정말 기대되는데요?
과연 PHP와 MySQL은 대형환경에서 쓰이지 못할정도로 부적합할까
네이버, 야후, 세이클럽등 대형포탈들이 PHP를 적극적으로 사용하고 있는것을 보면
대형환경에서도 PHP는 최소한 보조적인 환경에서, 또는 다른 JSP를 대체할수 있는 환경이 된다고 생각하는데요.
Apache2.0이 안정화되면서, 스레드 지원으로 인해서 많은 접속자를 동시에 처리하는 능력이 상당히 향상되었고
PHP5.0이 나오면서 그동안의 약점이었던 객체지향등을 크게 강화 시켰습니다.
MySQL 4.1은 많은 개발자들의 요구사항이었던 서브쿼리를 지원하기도 하구요.
5.0버전에서는 트리거를 지원합니다. 이정도면 완벽히 오라클을 대체할수는 없어도 기본적인 RDBMS의 기능을 갖추고 있다고 생각합니다.
거기에 PHP Zend Cache같은것을 사용하면, 많은 접속자가 요구되는 환경에서도 처리속도는 JSP와 동등하거나 더 빠르기도 합니다.
만약에 소스코드 유출이 문제라면 Zend Encoder를 사용하면 되구요.
PHP의 언어 자체가 거의 10년이 되어가는지금 모든 기능들이 안정화되어서
충분히 대형 환경에서도 활용가능할수 있을것 같은데요....
솔직히 파견사원으로 이곳저곳 다니면서, 외형은 대단하지만 (JSP + ORACLE)
그에비해 인터페이스나 기능은 조잡한것들을 많이 보아와서 말이죠.
꼭 상용 어플리케이션을 썼다고 해서 프로젝트가 성공적일것이다라고 생각하는것은 좀...
재사용성, 설계, 패턴, 프로세스... 이런것들이 정녕 LAMP환경에서는 불가능한 일인지...
저도 PHP 으로 작업하고 있습니다만.. 전 오히려 PHP가 분발해
저도 PHP 으로 작업하고 있습니다만..
전 오히려 PHP가 분발해야하는 부분이 있다고 생각되는데요...
우선 unicode에 대한 부분도 그렇구요.. PHP에서 Thread가 지원안된다는 점. 그리고 기본적으로 바이트코드을 만들수 없어서 페이지가 리로드될때마다 재컴파일해야한다는 점들...
물론 갈수록 Thread구조에 대한 문제점(프로그램의 복잡도..같은걸까요?)을 나타나고 있다고는 합니디만..;(전 자세히 모릅니다. T_T)
Python이나 Java처럼 Non-Blocking IO같은 부분도..(아..이부분은 있겠군요... PEAR나 PECL을 함 찾아봐야겠습니다.;)
사실 자바나 닷넷보다 파이썬이나 루비 같은 언어가 더 괜찮지 않을까 하는 생각이 들기도 합니다.
문제는 벤더의 지원 같은 부분에서.. (특히 자바는 프레임워크와 아키텍처의 천국이고 닷넷은 마소라는 엄청난? 지원?이 있으니까요..) 좀 미흡해서 그런 부분을 LAMP에서 더 잘 된다면 엔터프라이즈 환경에서 더욱더 발전하지 않을까.생각됩니다.
ps.전 자바보다 파이썬이 좋고.. 닷넷보다 루비가 좋습니다.-_-;
아이언파이썬은 CPython보다도 빠르다는 루머에 시달려야 했습니다.-_
아이언파이썬은 CPython보다도 빠르다는 루머에 시달려야 했습니다.-_-
PHP.NET도 그런 루머가 있지요..
GC같은 부분을 최적화 한다면 그냥 네이티브보다 빠를수도 있나 봅니다.+_+
모노에서는 아니더군요.T_T 아직 최적화가 안되었는듯.
php 에서 바이트코드를 만들지 못하는것은Zend Encoder 의
php 에서 바이트코드를 만들지 못하는것은
Zend Encoder 의 판매을 위함이겠지요...
php 에 프레임웍이 부족하여 대형 프로젝트의 체계를 잡기 힘든게 있는데,
프레임웍이 아주 없는것도 아니고,
java 개발자를 위한 php 프레임웍도 있는것 같더군요.
php 에서 unicode 지원을 분발할것은 없어보이네요.
윈도, 솔라리스에는 glibc-2 의 iconv 가 아니고,
구버전인 libiconv 를 사용하기 때문에 iconv 의 기능이 많이 부족하긴 합니다.
그러나 그건 php 의 문제라고 할 수는 없고요.
GNU 에서 지원하지 않는것이니까요.
리눅스 glibc-2.3 iconv 는 환상적입니다.
중국어 간번체 변환 테이블까지 들어있어요. (gbbig.c)
아, iconv_strlen() 같은 함수는 어느정도 문자열이 길어야 동작하던것 같네요.
저는 보통 UTF-8 로 사용하고 문자열을 다룰때는
pcre 로 /u modifier 를 이용하기 때문에 쓰지도 않지만...
http://phpschool.com 의 팁만 봐도 pear 나 자작클래스 등으로 만들어 활용하는 분이 많습니다.
php 의 db 함수를 그냥 이용하는 것을 자주 보신 이유가,
php 전문(?) 개발자가 아닌 타 언어 개발자가 익숙해 지지 않은 채로 작성한 코드라서 라는 생각이 드네요.
non-blocking 은 stream_set_blocking(STDIN, FALSE); 해주면 됩니다.
php://stdin 은 non-blocking 모드가 됩니다.
소켓용은 socket_set_blocking 이고요.
http://kr.php.net/manual/en/function.stream-select.php
http://kr.php.net/manual/en/function.socket-select.php
이거 쓰레드 개념 아닌가요? select() poll() 같은걸로 쓰레드 구현하는거 맞죠?
아...fork 가 있네요.http://kr.php.net/manual/en/function.pcntl-fork.php
https://xenosi.de/
MS, 오픈소스 플랫폼「램프에 물 뿌리기」http://zdnet.co
MS, 오픈소스 플랫폼「램프에 물 뿌리기」
http://zdnet.co.kr/news/enterprise/dev/0,39028947,39137336,00.htm
php가 사실 상당히 유연한 언어임에는 분명합니다.거의 모든 C로 작
php가 사실 상당히 유연한 언어임에는 분명합니다.
거의 모든 C로 작성된 라이브러리 함수를
wrapper형태로 구현이 가능하기 때문이죠.
따라서, posix에 관련된 거의 모든 함수가 구현이 가능합니다.
다만, 이에 대한 보장이 플레폼에 종속적이라는 것이
때로는 아주 약간 아쉬울 때가 있습니다.
(사실은 플레폼에 너무 잘 유연하게 적응해서 생기는 문제에 가깝습니다.)
주로 부족한 라이브러리나 미약한 posix지원의 한계를 가진
m$플레폼으로 다른 플레폼에서 작성된 php코드를 포팅할 때
짜증나는 경우가 종종 있습니다.
또한 가지는 binary상태로 컴파일하는 부분인데,
이부분은 zendoptimizer등의 cacher로 어느 정도는 극복이 가능합니다.
젠드옵티마이저말고도 오픈소스기반의 php캐셔가 있는데,
상당히 유연하게 캐쉬를 하기 때문에 잘 설계하면 상당한 이득을
볼 수도 있습니다.
추가로,
zendencoder는 바이너리로 컴파일하는 기능이라기 보다는
암호화하는 것에 더 가깝다고 알고 있습니다.
즉, php코드를 오픈소스 기반이 아닌 closed된 코드형태로
배포가 가능하게 해주는 목적입니다.
따라서, zenddecoder는 공짜입니다.
(zendoptimizer에 빌트인되어 있는 걸로 압니다.)
물론 코드가 최적화되기 때문에 다소 성능향상은 있지만,
아주 미미한 것으로 알고 있습니다.
php unicode 문제는 ....
php unicode 문제는 뉴스그룹에서 읽은 기억에 의하면,
5.1버젼에서 해결 될 것 같습니다.
op code caching 은 5.0 대 버젼에 오면서 좀 불만입니다.
오픈 소스 버젼이 있기는 하지만 예전만 못한 것 같더군요.
물론 돈 주고 사면 해결됩니다.
LAMP 플랫폼 성능은 이미 증명된 것 같습니다.
Google도 MySQL을 쓰는 이유는 Oracle보다 나은 점을
경영자에게 엔지니어가 증명했기 때문입니다.
Yahoo 같은 포탈이 PHP를 선택한 것도 ....
일반 유저들도 그렇고 효과적으로 설명하지 못한다면 보통
안 바꾸죠.
제 경험상(꽤 좁지만) 확실히 웹 어플리케이션 개발에 있어서
생산성은 최고 수준인 것 같습니다. 애초에 웹을 위해서 개발된
언어이니 당연한 결과겠지만요.
참고로 제가 말하는 높은 생산성은 타이핑을 적게 하면서 알기
쉬운 코드로 원하는 구현을 합리적인 시간 안에 끝내도록 해
주는 것을 뜻합니다.
[quote="kkb110"]그냥 단순히 웹시장에서 경쟁력을 말하는 것이
개인적으로는 .net은 좀 아니라고 봅니다.
asp.net을 경험할 수록 웹 콘트롤은 이게 아니라는 생각이 듭니다. 표준에도 어긋나고 틀에 박혀 커스터마이징이 힘들어 유연성이 떨어지며 생산성도 생각보다 떨어지더군요.
asp.net는 웹 콘트롤이라는 환상에 지나치게 사로 잡혀서 구멍난 추상화가 된 예라고 생각하고 있습니다.
- 죠커's blog / HanIRC:#CN
Re: php unicode 문제는 ....
google은 mysql을 어디에 쓴다고 하나요?
----
http://nohmad.tumblr.com/
[quote="송효진"]php 에서 바이트코드를 만들지 못하는것은Ze
바이트코드 컴파일이 소스코드 보호 외에 성능상의 큰 이점은 없다고 알고 있는데.. 실제로 있나요? 성능이 문제라면 캐싱 프레임웍으로도 충분할 것 같습니다. PHP 충분히 빠르거든요. ;-)
자작 클래스는 더 안 좋은 케이스입니다. 이런 걸 개발자들이 직접 만들어 쓴다는 것은 상당한 문제가 있다는 얘깁니다. 자바의 JDBC나 펄의 DBI, DBD는 모두 인터페이스와 구현을 분리해서, 나름대로 벤더 독립성을 실현하고 있습니다. 왜 아직도 mysql_* 이런 류의 함수들만 매뉴얼에 있고, PEAR는 떨어뜨려 놨는지 이해할 수 없습니다. 사용자들이 잘 모르고 쓰는 걸 탓할 수는 없습니다. 이 경우는 확실히 PHP 주도자들이 그렇게 만들었기 때문입니다.
----
http://nohmad.tumblr.com/
[quote="송효진"][quote="iolo"]오히려 PHP의 DB 바
자작 클래스는 더 안 좋은 케이스입니다. 이런 걸 개발자들이 직접 만들어 쓴다는 것은 상당한 문제가 있다는 얘깁니다. 자바의 JDBC나 펄의 DBI, DBD는 모두 인터페이스와 구현을 분리해서, 나름대로 벤더 독립성을 실현하고 있습니다. 왜 아직도 mysql_* 이런 류의 함수들만 매뉴얼에 있고, PEAR는 떨어뜨려 놨는지 이해할 수 없습니다. 사용자들이 잘 모르고 쓰는 걸 탓할 수는 없습니다. 이 경우는 확실히 PHP 주도자들이 그렇게 만들었기 때문입니다.
PDO로 가고 있습니다.
인용이 이상하게 되었네요.PDO로 가고 있습니다.근데 지금
인용이 이상하게 되었네요.
PDO로 가고 있습니다.
근데 지금 까지 그렇게 된 것이 별 필요성을 못 느끼거나 밴더
독립적으로 구현하는 것이 그렇게 어렵지 않기 때문이 아닐까
생각합니다. 지금까진 어쨌든, Pear와 ADODB가 있었습니다.
[quote]google은 mysql을 어디에 쓴다고 하나요?[/quot
Google CEO가 한 인터뷰에 봤었는데, 구체적으론 아마 언급이
안 됐던 기억이.... 그 분 말이 자기가 Oracle쓰자고 하니까 엔지니어가 그러드랍니다.
제가 인력 채용 부분을 잠깐 보니,
Billing Application, Workflow Application 에는 확실히 쓰는 것
같네요. Oracle도 물론 쓰고 있군요.