블로그 이미지
생각처럼

카테고리

전체보기 (209)
TOOL (1)
다이어리 (1)
Bit (200)
android (8)
C&C++ (3)
C# (26)
VB.Net (4)
MFC (0)
Win Ce (5)
아키텍쳐 (4)
WPF (9)
Rom (0)
읽어보기 (25)
Linux (24)
Java (0)
HELP? (0)
Total
Today
Yesterday

달력

« » 2025.1
일 월 화 수 목 금 토
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31

공지사항

태그목록

최근에 올라온 글

xubuntu 설치시 키모음 잠금 메세지 출력안되게하는 방법

Bit/읽어보기 / 2012. 12. 18. 20:56

xubuntu 의 경우 크롬 브라우져 사용시 키모음 메세지가 항상 출력되어 불편했다

하여 키모음 잠금 메세지 출력이 되지 않게 하기위해  seahorse (암호화 및 키 ) 를 설치후

(sudo apt-get install seahorse 를 사용하여 seahorse를 설치하면 됨)

기본 암호 설정의 암호를 공백으로 변경하여 설정하여주면 더이상 키모음 잠금 메세지가 출력되지 않는다.

Posted by 생각처럼
, |

당신의 조직은 개발자를 올바르게 관리하고 있는가?

Bit/읽어보기 / 2012. 2. 3. 17:45
http://www.zdnet.co.kr/ArticleView.asp?artice_id=00000039162121
Posted by 생각처럼
, |

SW 개발자의 길, 아니다 싶으면 포기하라!

Bit/읽어보기 / 2012. 2. 3. 17:36
[明, SW 개발자여 전문인으로 거듭나자!]
ZDNet Korea의 컬럼니스트 중 한명인 류한석 소장은 얼마 전 자신의 컬럼에 ‘한국에서 SW 개발자가 성공하지 못하는 세가지 이유’를 통해 어려운 사회적 현실을 이야기 했다. 그러한 이유가 아니더라도, SW 개발자로 성공한다는 것 자체는 다른 어떠한 직업과 견주어도 결코 쉬운 것만은 아닐 것이다. 

한국 자바 개발자의 1세대라 할 수 있는 김명호 박사 역시 개발자 출신으로 성공의 길을 걷고 있다고 할 수 있지만 “이 길이 아니다 싶으면 차라리 다른 일을 하라”는 말을 서슴지 않고 내던지고 있다. 요즘 시대에 개발자는 한국이라는 좁은 시장에서가 아니라 전세계적으로 통할 수 있는 전문성을 가져야 하는데, 이를 달성하는 것은 결코 쉬운 일이 아니기 때문이다. 

SW 개발자로 성공하려면, 단기간 학원 교육을 통해, 누구나 습득할 수 있는 주류 기술 몇 가지만 배워서는 안 된다. 코딩, 테스트, 디버깅, 이식, 성능, 설계, 스타일 등 다양한 소양을 갖춘 전문인이 진정한 개발자라고 할 수 있다. 단순히 코딩만을 할 줄 안다고 해서 전문인으로써의 ‘정신과 혼’을 담지 않고 있다면 ‘하급 노동자’에 지나지 않는다는 것이다. 

개발자와 아키텍트는 다르다
한국의 개발자들은 마치 개발자가 아키텍트로 가는 중간 단계로, 한번쯤 거쳐야 할 과정쯤으로 여기는 경향이 있다. 그러나 아키텍트와 개발자는 엄연히 다른 직업이다. 아키텍트가 되기 위해 개발자 경험이 있는 것은 좋지만, 막연하게 개발자를 거쳐 아키텍트가 된다고 생각하는 것은 옳지 않다는 것이 김박사의 설명이다. 

그는 “아키텍트가 될 자질을 갖추는 것은 개인의 소양에 따라 다르다. 이를 건설에 비유하자면, 개발자는 건설현장에서 일하는 인부고 아키텍트는 건축설계사라고 볼 수 있다. 미적, 공학적인 요소를 갖추었을 때 건축설계사가 되는 것처럼, 현장 인부가 자신의 경력을 통해서만 될 수는 없는 것이다”라며 “대신 그들은 미장이나 도색 전문가 혹은 작업반장이 될 수 있다. 즉, 해달 분야의 전문가로 훌륭히 성공할 수 있는 것이다”라고 말했다. 

그렇다고 벽돌을 나르는 수준의 초급 개발자가 10년 후 작업반장 수준의 상급 개발자가 되는 것은 아니다. 먹고 살기 위해서 개발을 한다면 행복해 질 수 없을 테고, 당연히 훌륭한 개발자가 될 수도 없다. 때문에 개발자들이 당면한 과제는 어떻게 하면 훌륭한 개발자가 될 수 있냐는 올바른 방법론이 필요하다.

이에 대해 김명호 박사는 몇 가지 지침을 가르쳐 준다. 

훌륭한 개발자가 되려면? 
1) 기본에 충실해야 한다. 
여기서 말하는 기본과 초급은 분명 다르다. 개발자라면 알고 있어야 할 프로그래밍의 기본 구조나 알고리즘 등의 기본에 충실하지 못하다면, 10년이 지나도 불행하기는 마찬가지일 것이다. 만약 개발자인 당신이 먹고 살기에 급급해서 수박 겉핥기로 몇몇 기술만 습득했다면 지금이라도 당장 시작하는 것이 중요하다. ‘언젠가는 적용해야 할 핵심기술’을 습득하는 것이 중요하다. 

2) 지식의 포트폴리오를 유지하라. 
재테크에서의 교훈에 따라 ‘달걀을 한 바구니에 담지 마라’는 것을 생각하자. 즉, 개발자는 어느 한 분야에 올인하지 말고 ‘남들도 다 아는’ 주류 기술과 ‘남들은 모르는’ 전문 기술로 분산 투자해야 한다는 것이다. 

3) 분야 전문가나 해박한 지식을 갖춰라. 
앞서 언급한 대로 건설현장에서 미장이나 도색 전문가, 작업반장이 될 수 있는 분야별 전문가가 된다면 어디서든 존중 받을 수 있다. 그러나 여기서 중요한 것은 과도한 욕심을 부려서는 안 된다는 것이다. 분야의 전문가인 동시에 해박한 지식을 갖추고 있다면 그야말로 ‘천재’라고 할 수 있지만, 이 둘 중 한가지만 갖춰도 충분하다는 것이다. 모든 분야에 대해 피상적인 지식만을 갖추고 있다거나, 사장된 기술에 매달린다거나, 자아도취에 빠져 자신만의 방법이 옳다고 여기는 오류를 범할 수 있기 때문이다. 

4) 학습을 두려워 마라. 
이것이 김박사가 가장 강조하는 부분으로, 충분한 기본지식을 갖추고 있다면 새로운 지식을 습득하는 것에 두려움이 없으며 새로운 기술을 습득하고 끊임없이 발전해 나가는 것이야 말로 행복한 개발자가 되는 최우선 요소다. 만약 새로운 기술을 습득하는데 더디다고 느낀다면 그것은 기본이 부족하기 때문이며, 지금이라도 기본을 습득해 나간다면 신기술 습득에 대한 두려움은 사라진다. 

이러한 개발자를 위한 성공 방법론이 제시됐음에도 불구하고, 개발자가 선택할 수 있는 최악의 길은 ‘다른 길을 찾아가는 것’이다. 개발자가 뭐 그리 대단한 것인가? SW 개발자가 아니더라도 얼마든지 다른 분야에서 전문인이 될 수는 있는 것이다. 자신이 택했지만 SW 개발자로의 미래가 안 보인다고 생각된다면, 과감히 다른 길을 선택하라. 

개발자야 말로 ‘파레토의 80대 20의 법칙’이 가장 확실하게 적용되는 분야다. 20%의 능력 있는 개발자만이 훌륭하게 80%의 개발을 수행할 수 있다. 

[暗, 과연 한국에서 SW 개발자가 성공할 수 있나?]
김명호 박사는 SW산업에서 이러한 파레토의 법칙이 중요하다고 말한다. 뛰어난 소수의 전문인력이 SW산업을 발전시킬 수 있고, 이러한 인재를 정책적인 지원 하에 키워내야 한다는 것이다. 

그러나 현실은 그다지 밝지 않아 보인다. 정부의 정책이라는 것이 ‘노동정책’에 가깝기 때문이다. 즉, 대학과 같은 전문교육기관에 의한 전문가를 양성한다기 보다 실업자를 줄이기 위해 하급 개발자를 배출해 내는데 급급하고 있다는 지적이다. 

막상 현재 대학의 교육 현실은 어떠한가? 학부제를 도입한 이후, 학생들은 어려운 과목은 제외하고 쉽거나 학점을 잘 받을 수 있는 과목을 수강할 수 있게 된 상태다. 숙명여대 전산관련 학과의 한 교수는 “요즘 학생들은 알고리즘과 같이 기본을 다질 수 있는 과목은 어렵다고 회피한다. 그저 취업을 위한 학점 챙기기나 가벼운 프로그래밍 기술에 몰린다”고 안타까워한다. 

이럴 바에는, 오히려 비전공자가 낫다는 의견도 있다. 기본에 충실하지 않은 전공자들보다 학원에서 5~6개월 집중적으로 배우고, 취직해서 급여를 받는 이들이 더욱 충실도가 높고 급여도 적게 든다는 것에 SI업체들이 매력을 느낄 수도 있다는 것이다. 

실패 거듭하는 ‘SW 정책’
실제 이렇게 부실한(기본에 충실하지 못하다는 의미로, 이들이 모두 부실하다는 것은 아니다) 개발자들을 고용한 SI업체를 통해 프로젝트가 실패한 경우, 그 책임소재의 표적은 SI가 아닌 HW로 돌리는 경향이 있기도 하다. 어떻게 보면 이것이 ‘SW 분리발주 정책’을 창출한 계기 중 하나이며, 개발자의 ‘표준공임단가’를 책정하게 된 이유가 될 것이다. 

특히 개발자에 대해 표준공임단가를 두어 금전적 보상에 제한을 두어서는 안 된다. 이는 능력 있는 전문가가 되고자 하는 이들의 의지를 꺾을 수 있기 때문이다. 핀란드의 한 대학에서 내놓은 조사자료에 의하면 ‘SW 개발생산성에 있어 훌륭한 개발자 1명의 개발생산성이 하급 개발자에 비해 20배 가량 높다’는 결과가 있다. 이는 급여 측면에서 볼 때에도 그 이상의 가치가 있는 것이다. 

현재 정부의 실업정책에 가까운 SW 정책은 이러한 측면에서 많이 부족하다는 지적이다. 즉, 표준공임단가에 묶여 있기 때문에 국내에서는 아무리 뛰어나다고 해도 인정받지 못하는 토양이 굳어져 가고 있으며, 이는 마찬가지로 기업 내부에서도 개발자에게 인색할 수 밖에 없다. 

또한 전문인을 양성하기 위해 수년의 기간이 필요하지만, 단기간 성과를 내야만 하는 국내의 프로젝트 특성도 개발자를 힘들게 하는 악순환에 한 몫 거들고 있다. 

소수의 전문인 중심 체계 필요
김명호 박사는 “정책적으로 획기적인 변화가 있어야 한다. 노동집약적 산업이 아닌 지식집약적 산업으로 바꾸기 위한 정책이 필요하다. 물론 교육도 마찬가지다. 전산 관련 대학 정원을 줄여서 의욕이 있는 전문가를 양성해 내고 이들을 대상으로 SW정책을 만들어 가야 할 것이다”라고 말했다. 

그는 또 “16만 명에 달하는 국내 개발자들 모두에게는 미안한 말이지만, 누구나 다 성공할 수는 없다. 끊임없이 노력할 수 있고 자기를 발전시킬 수 있는 소수 개발자들만이 성공할 수 있으며, SW 정책도 이들에게 마음 놓고 일할 수 있는 환경을 만들어 주는 산업으로 만들어야 정부차원의 ‘미래의 먹거리’ 산업으로 성장할 수 있을 것이다”라고 주장했다. @
Posted by 생각처럼
, |

지킬앤하이드 OST - 지금이순간 (조승우,류정한,김우형,

Bit/읽어보기 / 2012. 2. 3. 17:36

출처 한걸음씩 걷기 | 쩡
원문 http://blog.naver.com/23junlub/130025643666
지킬앤하이드 OST - 지금이순간

 

 

 

조승우

 

류정한

 

김우형

 

 

* 2008 지킬 홍광호 버전 추가

 

 

홍광호

 

지금이순간 
지금여기

간절히 바라고 원했던 이순간
나만의 꿈 나만의 소원 
이루어질지 몰라
여기바로 오늘

 

지금이순간
지금여기
말로는 뭐라 할수 없는 이순간

참아온 나날 힘겹던 날

다 사라져간다 연기처럼 멀리


지금이순간 마법처럼 
날묶어왔던 사슬을 벗어 던진다

지금 내겐 확신만 있을뿐
남은건 이제 승리뿐

 

그많았던 비난과 고난을 
떨치고 일어서 세상으로 부딪혀 맞설뿐

 

지금 이 순간
내모든걸 내육신마저 내영혼마저 다걸고

던지리라 바치리라 
애타게 찾던 절실한 소원을 위해

 

지금이순간 나만의 길
당신이 나를 버리고 저주하여도
내마음속 깊이 간직한 꿈

간절한 기도 절실한 기도

신이여 허락하소서

 

2006년도 지킬앤하이드에 캐스팅되었던 세 지킬의 '지금이순간'

개인적으로 노래만 놓고 봤을땐 김우형씨의 목소리가 젤 감동적이지만

무대를 직접 봐야만 평가할 수 있을것 같다

내년도를 기대하며...

Posted by 생각처럼
, |

지구온난화와 이산화탄소의 비밀

Bit/읽어보기 / 2012. 2. 3. 17:34

출처 어떻게 찾아오셨나요? | FANY
원문 http://blog.naver.com/chahwan3/100087528143
Posted by 생각처럼
, |

S/W 개발비용 산정

Bit/읽어보기 / 2012. 2. 3. 17:30

출처 탐구생활 | 크레파스
원문 http://blog.naver.com/sharon0a/110048932554

1. 소프트웨어 개발비용 산정 개요

 가. 개발비용 산정의 정의

  - 소프트웨어 규모파악(양적인 크기, 질적인 수준)을 통한 소요공수와 투입자원 및 소요기간을 파악하여 실행 가능한 계획을 수립하기 위해 비용을 산정

  - 발주자가 프로젝트 발주시 예정가격의 산정과 개발업자가 수주한 개발 용역에 대하여 적정한 대가를 산정할 수 있는 기준

  - 단위작업공수(비용)를 통한 총공수(총비용) 산정

 나. 규모산정의 의의

  - 소프트웨어 개발 프로젝트 계획 수립시의 소요 비용 및 기간의 산출

  - 아웃소싱 계약시의 계약 근거

 

2. 개발비용 산정시 고려요소

 가. 프로젝트 요소들

  - 문제의 복잡도(난이도, 유형)

  - 시스템크기(입출력 양식 수)

  - 시스템신뢰도(정확성, 견고성, 완전성, 일관성)

 나. 자원 요소들

  - 인적자원(관리자, 개발자, 지원체계)

  - 하드웨어자원(개발장비, 운영장비), 소프트웨어자원(개발지원 도구)

 다. 생산성 요소들

  - 개발자능력(경험, 전문지식 습득 정도)

  - 개발방법론(최신기법, 관리 방법론)

 

3. 소프트웨어 규모산정 방법

 가. 양적 규모산정 방식 - LOC(Line Of Code)근거

  1) LOC정의

   - 크기 중심 소프트웨어 측정기준으로 직접 소프트웨어 코드의 라인 수를 측정하는 방식

   - 라인수 혹은 개발별 M/M를 예측하여 이를 비용으로 변환시키는 방식

  2) 산정방법

   - 생산성 = KLOC/노력(M/M), 품질 = 오류의 수/KLOC

   - 비용 = 원/KLOC

   - 장점 : 측정하기 쉽고 이해하기 쉬움, 기존의 많은 프로젝트 측정모델들을 주요입력으로 LOC를 이용하고 있음,

              LOC를 중심으로 예측하는 자료들이 충분히 존재

   - 단점 : LOC측정은 프로그래밍 언어에 의존, LOC척도는 잘 설계된 그리고 짧은 프로그래밍일수록 불리,

             개발초기의 계획 및 분석단계에서 정확난 LOC를 측정하는것은 불가능

  3) 양적 규모산정 방식 종류

   - Doty Model : 통계를 바탕으로 규모가 대강 알려졌을 때 사용, 라인수가 상수 제곱

                        인터뷰와 문헌을 바탕으로 개발한 모델로 프로그램 규모가 알려졌다는 전제하에 총공수를 구하는 방법

                        총공수(MM): 상수*프로그램 규모(I) (규모(I) = 소스코드 라인수)

   - Putman Model(생명주기 예측 모델) : 가설을 젠제로 한 모델(대규모 연구개발 프로젝트에 적용된 모델을 기초)

   - COCOMO Model(COnstruction COst MOdel) : Boehm에 의해 63종류의 프로젝트 데이터에 기초하여 작성된 경험적인 소프트웨어 비용 견적모델

  ※ LOC기반 추정은 일단 소프트웨어를 모듈별로 분류하고 가중치를 이용하여 합리적인 LOC추정값을 얻음

 나. 양과 질을 고려한 규모산정 방식

  프로젝트 특성을 이용하여 간접적으로 규모와 복잡도를 산정하는 방식

  1) 기능점수(Function Point)

   - 정보 처리 규모와 기술의 복잡도 요인에 의하여 소프트웨어 규모 산정 방식

   - 소프트웨어의 양과 질을 동시에 고려한 방식

   - 최종 사용자 입장에서 소프트웨어 규모를 견적하는 방식

  2) Halstead의 소프트웨어 과학(Software Science)

   - 소프트웨어 규모와 난이도에 대한 척도를 이용하여 개발소요 공수 예측모형 제시 계산 공식

  3) McCabe의 회전 복잡도(Cyclomatic Complexity) 계산 공식

   - 회전복잡도 = 의사결정수 + 조건수 + 1

     의사결정수 : if then else, do while, do until 등의 의사결정 개수

     조건수 : and, or, not 등의 조건수

 

4. 소프트웨어 개발비용 산정방법의 종류

 가. 하향식 산정방법(to-down)

  일반적으로 가장 많이 사용하는 방법이며, 경험과 전문지식이 많은 개발자들이 참여한 회의에서 토론을 통하여 산정

  1) 전문가의 판단(expert judgment)

   - 소프트웨어 개발 기술에 관한 경험이 많은 전문가의 판단에 따라 비용을 산출하는 방법 - 2명 이상의 전문가에게 의뢰

   -  사소한 문제로 인한 결정이나 그룹 내의 한 사람에 의한 독단으로 가면 문제가 발생

  2) 델파이(Delphi)식 산정방법

   - 회의의 부작용을 방지하면서 전문가의 의견 일치를 얻기 위하여 1948년 랜드사(Rand Co.)에서 개발

   - 전문가의 판단 방법의 단점을 보완한 방법

   - 전문가들이 편견이나 분위기에 지배받지 않도록 조정자(coordinator)를 필요

 

 

 나. 상향식 산정방법(bottom-up)

  하향식 방법의 비과학성을 보완하기 위하여 개발할 시스템을 WBS로 정의하고, 각 구성요소에 대한 산정을 독립적으로 실시한 후 이를 합산하는 방식

  1) 원시코드 라인수 기법

   - WBS상에서 분해된 시스템의 기능들을 각각 필요한 원시코드 라인수로 산정

   - 가장 효율적인 방안은, 프로젝트 관리 목적으로 대두된 PERT(Project Evaluation and Review Technique)의 예측공식을 이용하는 것

   - 확률론에서 배타분포도에 근거하여 낙관치(optimistic estimate), 기대치(most likely estimate) 및 비관치(pessimistic estimate)의

      확률적 집합으로 예측치(expected value)와 이의 편방편차(variance)를 산출

  2)개발단계별 노력산정 기법

   - 시스템의 각 기능의 구현에 필요한 노력을 각 생명주기의 단계별로 산정하여 원시코드 라인수 기법보다 더 정확성ㅇ르 기하자는 것

   - 개발비 산정에 반영시키는 목적

 

5. 소프트웨어 개발비용 산정의 문제점 및 개선 방안

 가. 문제점

  - step수를 근간으로 한 산정이므로 산출이 어려움

  - 산정된 금액이 너무 높아서 실제 사용이 어려움

  - 정부의 최저 입찰제 구매 방식 때문에 제대로 적용되지 않음

 나. 개선방안

  - 정확하고 객관적, 일관성있는 소프트웨어 규모 산정을 위해 소프트웨어 규모 측정 표준화

  - 기능점수 모형은 기능수 계산을 대폭 축소하고 복잡도 계산의 객관성을 높여야 함

  - 정보시스템 컨설팅 및 제안서 작성에 대한 비용 산정 기준의 마련

Posted by 생각처럼
, |

Windows 98 blue screen of death

Bit/읽어보기 / 2012. 2. 3. 17:29

출처 사랑합니다 고맙습니다 | EAST
원문 http://blog.naver.com/ty3718/60098734917

죽음의 98 블스??

조수 : 새로운 드라이버들을 호환할 수 있습니다.

　　　자.. 이렇게하면... 웁스...

모니터 : (블루스크린이 갑자기 뜸)

관객 : (기쁨?,환호?,위로의 박수를 보냄)

조수 : 아... 이게 (빌과 동시에 말한다)

빌 : 우리가.(조수와 동시에 말한다)

빌 : 우리가 이것을 내놓으지 않는 이유입니다.

조수 : 옳은 말씀입니다.

 


Posted by 생각처럼
, |

[월드브리프]MS 사라진 세상은 어떨까

Bit/읽어보기 / 2012. 2. 3. 17:29

  google_protectAndRun("render_ads.js::google_render_ad", google_handleError, google_render_ad);

마이크로소프트(MS)가 없는 세상은 어떨까요?

MS는 시장 지배자적인 소프트웨어 업체이면서 기술을 독점하고 있다고 많은 지탄을 받고 있습니다. MS가 만들어낸 운영체계(OS), 클라이언트 및 서버 애플리케이션, 시스템 소프트웨어와 개발 툴, 여러 API까지 MS가 IT 업계와 기술 표준을 쥐락펴락하지요.

그렇다면 무료 오픈소스 소프트웨어가 확산돼 MS 윈도가 없어지면 기업들과 소프트웨어 개발자는 그들이 원하던 자유를 마침내 얻게 되고 아름다운 IT 세계가 펼쳐질까요? 미 IT 전문지 Infoworld(www.inforworld.com)에서는 ‘순진한 생각’이라고 하네요. 오히려 그 반대가 될 것이라고 합니다. 성경에서 말하는 종말론 이후의 세계가 될 것이라는 거죠.

 

   
Infoworld는 MS가 사라진 이후 기술 세계에 어떤 일이 벌어날지(Life after Windows: What happens to tech if Microsoft dies) 가상 시나리오를 소개합니다. Infoworld에 따르면 오늘날 MS가 장악하고 있는 애플리케이션과 디바이스 호환성 및 상호 운영성이 사라진다면 서부개척시대만큼 무법천지가 될 것이라고 합니다. MS-DOS 이전과 같이 말이죠.

 

구글이 있지 않냐고요? 윈도 이후 받게 될 충격을 웹이 다소나마 줄여줄 것으로 믿지 말라는군요. 구글은 웹 지향 패러다임으로 전통적인 컴퓨팅 모델을 대신하고 있습니다만, 구글 혹은 그 어떤 클라우드 컴퓨팅 플레이어라고 해도 시장 지배자 입장이 된다면 제2의 MS가 될 것이라는 게 Infoworld의 주장입니다.

그리고 ‘계란은 한 바구니에 담지 않는다’라는 말은 IT 분야에도 적용된다고 하네요. 선택이 구글밖에 없다면 기업에게는 MS 독점 시대와 다를 게 없다는 뜻이죠.

MS 사후의 가장 큰 혼란은 클라이언트 애플리케이션에서 일어날 것이라고 합니다. 더 이상 표준은 없다는 것이죠. 웹 기반 딜리버리 모델로 완전히 전환하면 되지 않냐구요? 각종 혁신 기술들이 범람하면서 이 각각을 어떻게 지원해야 하는가 문제로 골치 아플 것이라고 합니다. 풍부하고 다양한 UI 디자인, 웹 애플리케이션 구현을 일일이 맞춰야 한다는 것이죠.

또 개발자들은 자신만의 고유한 인터페이스를 더 선호할 것이고 개발자 임의의 결정이 혼란을 초래할 것이라고 합니다. 가장 단순한 작업, 즉 데이터를 활용하고 초기화하는 것과 같은 일들도 ‘구현’ 과정이 필요하다는 것이죠.

이기종 애플리케이션 통합도 어려워지고요. MS의 OLE/COM/VBA가 없어질테니까요. 서로 다른 애플리케이션들 간 데이터 연동 작업은 다양한 클라우드 호스팅 기반의 API, 리소스, 그리고 자바가 뒤죽박죽이 된 세계로 떨어질 것이라고 합니다. 이외에도 개발자 툴의 혼란, 웹 기반 신규 애플리케이션과의 통합 문제, 하드웨어 호환성과 인증 문제 등 모든 게 문제가 된다는 것이죠.

그런데 여기까지 읽고 보니 혼란스러워집니다. Infoworld는 MS가 지금과 같이 훌륭한 업계 표준을 쌓아올린 것을 인정해주자는 것일까요, 아니면 MS의 기술 독점을 비꼬는 것일까요? 직접 판단해보시기 바랍니다.

Posted by 생각처럼
, |

2010년 2월 19일 오후 2시 12분에 저장한 글입니다.

Bit/읽어보기 / 2012. 2. 3. 17:28

첫번째 자신의 전공에 대한 깊은 지식 뿐 아니라 주변에 대한 상식을 넓혀가는 일

 

두번째 타인에게 자신의 지식과 경험을 전달할 수 있는 커뮤니케이션 능력

 

세번째 어려움에 빠졌을 때 ‘내 탓’을 할 수 있는 긍정적 사고방식

 

네번째 지금 자신의 현실을 객관적으로 파악하고, 실수를 반복하지 않을 수 있는 마음가짐

 

마지막 으로 자신의 한계를 넓혀갈 수 있는 끊임없는 학습

 

“삶은 항상 불안전하며, 이를 인정하고 즐길 수 있어야만 행복하고 성공적인 삶도 가능할 것"

Posted by 생각처럼
, |

빌게이츠와 버핏의 이야기를 들어보실렵니까?

Bit/읽어보기 / 2012. 2. 3. 17:27

출처 이런 이야기 | 이동인
원문 http://blog.naver.com/tongins/80101973342
Posted by 생각처럼
, |

최근에 달린 댓글

최근에 받은 트랙백

글 보관함

티스토리툴바