뭐 여러가지 방법이 있겠지만
그 안의 절차를 살펴보죠


import java.io.*;

public class Foo {
  public static void main(String[] args) {

    if (args.length == 0) {                   // args.length 는 옵션 개수
      System.err.println("Input Filename...");
      System.exit(1);                         // 읽을 파일명을 주지 않았을 때는 종료
    }

    String outFilename = args[0] + ".uni";    // 출력 파일명 만들기, uni 라는 확장자를 붙여서


    try {
      ////////////////////////////////////////////////////////////////
      BufferedReader in = new BufferedReader(
                                             new InputStreamReader(
                                                                   new FileInputStream(args[0]),
                                                                   "MS949"
                                                                   )
                                             );

      BufferedWriter out = new BufferedWriter(
                                              new OutputStreamWriter(
                                                                     new FileOutputStream(outFilename),
                                                                     "UTF-8"
                                                                     )
                                              );


      String s;

      while ((s = in.readLine()) != null) {
        out.write(s); out.newLine();
      }

      in.close(); out.close();
      ////////////////////////////////////////////////////////////////
    } catch (IOException e) {
        System.err.println(e); // 에러가 있다면 메시지 출력
        System.exit(1);
    }

  }
}
BOM (봄; Byte Order Mark)은 '바이트 순서 표시'입니다.

유니코드가, little-endian 인지 big-endian 인지 아니면 UTF-8 인지 쉽게 알 수 있도록, 유니코드 파일이 시작되는 첫부분에 보이지 않게, 2~3바이트의 문자열을 추가하는데 이것을 BOM이라고 합니다. 텍스트 에디터 화면에서는 보이지 않고, 헥사 에디터(Hex Editor)*로 열었을 때만 보입니다.



little-endian 의 BOM:
FF FE

big-endian 의 BOM:
FE FF

UTF-8 의 BOM:
EF BB BF



UTF-8에는 BOM이 없는 것이 보통인데, 오래된 프로그램은 BOM이 있는 UTF-8 파일에 오작동할 수 있습니다.

그렇지만 한국어 편집에서는 BOM이 있는 UTF-8이 더 좋습니다. 만약 'BOM이 없는 UTF-8 파일'에 영문과 숫자만 있고 한글이 없다면, 편집기가 그 파일을 유니코드가 아닌 일반 아스키 파일로 오인하기 때문입니다.

그런데 인터넷에 올릴 HTML/CSS/XML 파일을 UTF-8로 작성할 때에는 BOM이 있으면 문제가 생길 수 있습니다.


* 울트라에디트의 헥사 모드(Ctrl+H)로 UTF-8 파일을 보면, 16비트 유니코드처럼 보이고 BOM이 있든 없든 항상 FF FE 라는 엉뚱한 BOM이 나타납니다. 이것은 울트라에디터가 유니코드를 편집할 때, 내부적으로 '16비트 little-endian 유니코드 (UTF-16LE)'로 변환하여 편집하기 때문입니다. 진짜 헥사 에디터로 보아야만 UTF-8의 BOM인 EF BB BF 가 제대로 보이게 됩니다. 물론 BOM이 없는 UTF-8이라면 BOM이 없는 것으로 나옵니다.

BOM 사용시 문제가 생기는 이유는 프로그램이 BOM을 처리하지 않기 때문입니다. 이는 프로그램이 유니코드를 지원하지 않거나, 지원하더라도 제대로 구현되지 않았다는 뜻입니다.
특히 웹에서 이러한 일이 많이 생기는 이유는 웹 프로그램들이 텍스트 파일을 로드해 붙여쓰는 경우가 많은데, 이 때, 파일의 처음에 BOM이 있을 수 있다는 가능성을 무시하고 제작된 프로그램이 많습니다. 그래서 붙여진 텍스트에는 텍스트 중간에 BOM이 존재할 수 있고, BOM의 특성상 제어문자로 오인되는 경우가 많아 처리과정에서 오류가 생겨 비정상으로 작동합니다.

정리하면:
BOM을 제대로 처리하지 못하면 유니코드를 제대로 지원하지 못하는 것입니다. 이상적으로는 제대로 된 프로그램만 사용하는 것이 가장 좋겠으나, 현실적으로는 그러기 힘들고 최대 호환성을 위해 BOM을 제거하는 것이죠.

이번달 교양도서로 "그들이 말하지 않는 23가지" 라는 책을 읽었습니다.
저자는 장하준, 특이하게 한국인이 쓴 책인데 역자가 있습니다.
(영어로 출판하고 한국사람이 다시 번역했다는 이야기죠)

장하준이 누구인지는 모르시더라도 아마 "나쁜 사마리아인들" 이라는 책은 들어보셨을것 같네요
(예전 국방부에서 금서로 지정해서 화제가 되었던 것으로 기억합니다.)

저자에 대해서 좀 알아봤더니 레알 명문가출신의 화려한 경력을 가진 분입니다.
(아래는 네이버 검색결과입니다.)
출생 1963년 10월 7일
소속 캠브리지대학교 (교수)
학력 캠브리지대학교대학원 경제학 박사 수상
경력
2005년 레온티에프상 (최연소 수상)
2004년 유럽진보정치경제학회 뮈르달상
2005 대통령 자문 정책기획위원회 위원

음.. 그냥 저도 모르게 멋있다는 생각이 드네요. 뭐 아무튼 일반인은 아닌수준이죠

읽으면서 여러가지 많은 생각들을 해보게 되었지만,
그 중 제가 느낀점은 두가지 입니다

1. 진짜 잘아는 사람들은 내용을 어렵게 쓰지 않는다.
- 경제학이라는 분야가 일반인이 이해하기가 어렵다는 통념을 깨고, 저자가 하는 이야기의 대부분이 이해되었습니다.
  저는 제가 똑똑하다기보다는 저자가 글을 참 쉽게 썼기 때문이라고 생각합니다.
  진짜 고수는 어려운것을 쉽게 이야가할 수 있는 사람이겠죠 ^^

2. 파생금융상품은 위험한 것이니 정부가 좀 더 잘 관리해야만 한다.
- 이 책을 읽으면서 2008년 서브프라임 모기지사태를 다시 검색해 보게 되었고,
   파생금융상품이란것이 금융세계대란의 원인이었다는것도 알게되었습니다.
   파생금융상품이란 신용이 낮은 사람에게도 부동산담보대출을 해주고, 이 대출채권을 담보로 또 다시 파생상품을 만들고
   그리고 이 파생상품을 서로 금융회사끼리 사고파는 것을 의미합니다.(손실이 원금을 초과)


책안의 자세한 내용은 아래의 PT자료를 참고하시면 도움이 되실것 같습니다.
(회사 독서발표회에 사용한 자료입니다)

그들이말하지않는23가지(장하준)
View more presentations from Hyeongchae Kim.


Cross Browser(User-agent) 서비스 개발

Contents

    * 1 User-agent 필터링을 하는 이유
    * 2 브라우저 분기에 Media Queries를 사용하지 않는 이유
    * 3 브라우저 / 단말별 User-agent
    * 4 Meta Tag, CSS
          o 4.1 Safari
          o 4.2 Android
          o 4.3 Opera9.5 Mobile
    * 5 알려진 문제점
          o 5.1 공통
          o 5.2 Safari
          o 5.3 Android
          o 5.4 IE와 동일한 User-agent를 제공하는 모바일 브라우저
    * 6 User-agent 체크 모듈 샘플(PHP)


User-agent 필터링을 하는 이유

국내 포털에서 제공하는 모바일용 페이지는 아래와 같은 이유로 User-agent를 필터링하여 기본적으로 1개의 HTML 페이지에 여러개의 CSS 및 메타태그를 적용하여 서비스를 제공하고 있음.


    * 다양한 단말을 지원해야 함
    * 구축/운영의 편의/신속성
    * 단말별로 해상도/화면크기 및 DPI(Dots per Inch)가 상이하여 1개의 CSS로 모든 기기 지원 불가능

동일 CSS를 사용하는 Device이나 서로 렌더링이 상이할 경우 Device의 판매량, Telco 전략 단말 여부에 따라 우선 순위를 지정하여 순위가 높은 Device에 최적화 함.

따라서 썸네일, 서버 자동생성 이미지(증권 차트 등)을 제외한 타이틀, 버튼은 <img src="" />요소를 사용하지 않고 IR기법으로 CSS의 background 속성을 이용하여 사용하며 또한 이미지 깨짐 현상을 우회하기 위하여 최대한 이미지가 아닌 텍스트를 활용 하는 것을 권장함




브라우저 분기에 Media Queries를 사용하지 않는 이유

Media Queries는 해상도를 기준으로 CSS를 분기하는데 실제 페이지들은 어플리케이션 링크 또는 브라우저 자체의 HTML/CSS/JS 구현 정도에 따라 특화되어 만들어지므로 해상도를 기준으로 분기하는 것보다 User-agent를 통해 플랫폼 또는 단말별로 명확하게 분기하는 것이 더 정확한 방법임




브라우저 / 단말별 User-agent

    * Apple Safari
          o iPhone : Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_0 like Mac OS X; en-us) AppleWebKit/532.9 (KHTML, like Gecko) Version/4.0.5 Mobile/8A293 Safari/6531.22.7
          o iPod Touch : Mozilla/5.0 (iPod; U; CPU iPhone OS 4_0 like Mac OS X; en-us) AppleWebKit/532.9 (KHTML, like Gecko) Version/4.0.5 Mobile/8A293 Safari/6531.22.7
          o iPad : Mozilla/5.0 (iPad; U; CPU OS 3_2 like Mac OS X; en-us) AppleWebKit/531.21.10 (KHTML, like Gecko) Version/4.0.4 Mobile/7B334b Safari/531.21.10


    * Android
          o Galaxy-S : Mozilla/5.0 (Linux; U; Android 2.1; ko-kr; SHW-M110S Build/ECLAIR) AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Mobile Safari/530.17
          o Moto-Qwerty : Mozilla/5.0 (Linux; U; Android 2.1-update1; ko-kr; A853 Build/SUSKT_U1_00.10.0) AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Mobile Safari/530.17
          o Optimus-one : Mozilla/5.0 (Linux; U; Android 2.2; ko-kr; LG-KU3700 Build/FRF91) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1


    * Opera Mobile9 (설정에서 2가지중 선택 가능, 기본값은 데스크탑 컴퓨터)
          o M490(옴니아) 휴대용 기기 모드 : 기기명/(null)IC4 (compatible;MSIE 6.0; Windows CE; PPC) Opera 9.5
          o M490(옴니아) 데스크탑 컴퓨터 모드 : Opera/9.5 (Windows NT 5.1; SKT; U; en)


    * Infraware Polaris6
          o LH2300(아르고) 초기 : Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0); lgtelecom
          o LH2300(아르고) : Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; 800*480;POLARIS 6.0;em1.0;lgtelecom;EB10-20080520-702676908;LG-LH2300;0);
          o SPH-W6050(햅틱온) : Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; 800*480;POLARIS 6.0;em1.0;lgtelecom;EB10-200090512-709515955;SPH-W6050;0);
          o SCH-W740(햅틱8M) : Mozilla/4.0 (compatible; MSIE 6.0; WIPI 2.0);800*480;NATEBrowser 5.0;em1.0


    * uZard WebSurfing (Webviewer)
          o LH2300(아르고) : Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; 800*480;WV01.00.01;;lgtelecom;EB10-20080520-702676908;LG-LH2300;0)
          o SPH-W6050(햅틱온) : Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; 800*480;WV01.00.01;;lgtelecom;EB10-20090512-709515955;SPH-W6050;0);
          o SCH-W740(햅틱8M) : Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; WOW64; Trident/4.0)
          o canU801Ex : Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2;480*752;WV01.00.06;;lgtelecom;EB10-20080000-200900001;canU801Ex;)
          o M490(옴니아), SONY X1 : Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2); WOW64; Trident/4.0
          o M4800(미라지) : Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; WOW64; SV1); uZard; KTF




Meta Tag, CSS

DPI 이슈의 우회와 브라우저가 제공하는 기능의 제어를 위하여 사용



Safari

    * viewport 속성을 사용하여 화면 비율을 100%로 고정하고 사용자의 임의 확대축소를 불가능하게 함
    * format-detection 속성을 사용하여 연속된 숫자의 자동 링크(전화걸기) 기능을 제한함

    * 브라우저가 폰트 사이즈를 강제로 조정하는 것을 방지함



Android

    * viewport 속성을 사용하여 화면 비율을 100%로 고정하고 사용자의 임의 확대축소를 불가능하게 함



Opera9.5 Mobile

    * viewport 속성을 사용하여 화면 비율을 100%로 고정하고 사용자의 임의 확대축소를 불가능하게 함




알려진 문제점

공통

    * 유선과 다르게 무선은 네트웍 속도가 느리고, 단말 자체의 처리 속도가 느려서 CSS를 외부 파일로 제공하거나 다량의 속성을 인터널로 삽입하면 CSS가 로드되지 않은 HTML페이지가 뿌려졌다가 CSS가 입혀지는 과정을 사용자가 보게 됨
    * 단말에 탑재된 폰트의 경우 대부분 볼드와 볼드가 아닌 서체가 크게 다르지 않아 기획/디자인상에서 강조하려는 부분은 폰트사이즈 및 컬러를 이용하는 것이 권장됨



Safari

    * CSS속성 overflow:scroll을 이용한 페이지 내부 스크롤바 생성이 불가능함 (스크롤바 자체를 표시하지 않음)
          o 투핑거 드래그로 제어는 가능하나 대부분의 유저들이 해당 기능을 인지하고 있지 않음

Android

    * CSS속성 overflow:scroll을 이용한 페이지 내부 스크롤바 생성이 불가능함 (스크롤바 자체를 표시하지 않음)


IE와 동일한 User-agent를 제공하는 모바일 브라우저

    * 초기에 배포된 Webviewer, WebSurfing의 경우 일반PC에 탑재된 IE6또는 7과 동일한 User-agent를 제공하거나, 단말의 모델 정보나 해상도 정보등을 추가하지 않은 경우가 있어 필터링이 불가능한 경우가 있음
    * 따라서 현재 Webviewer, WebSurfing가 탑재된 단말 중 800px보다 큰 해상도의 단말은 출시가 안되었으므로 User-agent필터링에 실패할 경우 기본으로 가로를 800px으로 제한하는 웹뷰어용 CSS를 제공함
    * 일반PC인지 모바일인지 완벽하게 분리가 불가능하므로 이전의 WAP이나 PDA 전용 페이지를 PC에서 접근시 별도의 소개 페이지로 자동 이동시키는 것과 같은 플로우는 불가능함

프로젝트에서 스마트폰기기에서 동영상 콘텐츠의 배포와 관련해서 작업해야 하는 일이 있었다.
딱히 내가 신경쓰지않아도 될만한 프로젝트라 그냥 멀리서 지켜보기만 했는데
우왕자왕하느라 시간만 소비하고, 원하는 결과는 쉽게 만들어지지 않는 모습을 보니 속이 답답~

우선 프로젝트가 해결해야 하는 상황을 보면
갤S, iphone3GS. iphone4G 등의 주요 스마트폰 환경에서 10분정도 분량의 동영상을 제공해야 한다.
(소스파일은 flash에서 생성해낸 swf 타입으로 존재함)

스마트폰용 동영상으로 변환할 수 있는 프로그램을 여러가지 설치하고, 변환을 테스트 했다.


인코딩프로그램으로 생성시킨 파일의 크기를 보면 20~30메가 사이.
스트리밍이 되느냐 아니냐부분은 일단 고려하지 않아도 될것이라 판단했다

콘텐츠의 제공방법으로 우선 두가지정도의 방법이 떠올랐다.

1) 해당 동영상 파일의 링크를 누르면, 파일이 직접링크되고 각 기기별 재생방법에 의존하는 방법

우선 각 기기별 동영상에 대한 지원여부를 확인했다.

spec

안드로이드 2.1 Spec

iPhone 3Gs Spec

iPhone 4 Spec

Display

- 4” super AMOLED capacitive touchscreen, 16M colors

-480x800pixels

3.5-inch 480 x 320, no IPS

TFT capacitive touchscreen,16M colors

3.5-inch IPS 960 x 640(326dpi)

Retina IPS LCD 패널

지원오디오 형식

mp3/AAC/AAC+/eAAC+/OGG/WMA/AMR-NB/AMR-WB/WAV/MID/AC3/IMY/FLAC/XMF

AAC (8 ~ 320Kbps), 복사 방지된 AAC, HE-AAC, MP3 (8 ~ 320Kbps), MP3 VBR, Audible (포맷 2, 3, 4, Audible Enhanced Audio, AAX, AAX+), Apple Lossless, AIFF, WAV

AAC,HE-AAC,MP3(8~320kbps),MP3 VBR,Audible(포멧2,3,4,Audible Enhanced Audio,AAX,AAX+),Apple Lossless,AIFF,WAV

동영상

■지원동영상형식:HD Video Player & Recorder(1280X720) 30ps

■코덱:Divx,XviD,MPEG4,H.263,H.264,WMV,VC-1

■파일형태:3gp(mp4),AVI(divx),MKV,FLV,H.263Sorenson

■지원 동영상 형식: H. 264 비디오, 최대 1.5Mbps, 640 x 480 픽셀, 초당 30 프레임, H.264 Baseline Profile의 Low-Complexity 버전, AAC-LC 오디오 최대 160Kbps, 48kHZ, .m4v, .mp4, .mov 파일 형식의 스테레오 오디오. H. 264 비디오, 최대 2.5Mbps, 640 x 480 픽셀, 초당 30 프레임, Baseline Profile 최대 Level 3.0 AAC-LC 오디오 최대 160Kbps, 48kHz, .m4v, .mp4, .mov 파일 형식의 스테레오 오디오. MPEG-4 비디오, 최대 2.5Mbps, 640 x 480 픽셀, 초당 30 프레임, Simple Profile AAC-LC 오디오 최대 160Kbps, 48kHz, .m4v, .mp4, .mov 파일 형식의 스테레오 오디오

 

■지원동영상 형식:H.264 비디오, 최대 720p, 초당 30 프레임, Main Profile level 3.1, AAC-LC 오디오 최대 160Kbps, 48kHz, .m4v, .mp4, .mov 파일 형태의 스테레오 오디오. MPEG-4 video, 최대 2.5Mbps, 640 x 480 픽셀, 초당 30 프레임, Simple Profile, AAC-LC 오디오 채널 당 최대 160Kbps, 48kHz, .m4v, .mp4, .mov 파일 형태의 스테레오 오디오. Motion JPEG (M-JPEG) 최대 35Mbps, 1280 x 720 픽셀, 초당 30 프레임, ulaw 오디오, .avi 파일 포맷으로 된 PCM 스테레오 오디오


3가지 기종의 공통분모를 찾아보니 영상코덱으로 H.264, 음성코덱으로 AAC를 사용하면 콘텐츠 제공에 이상이 없다는 결론이 나왔다.

제작을 마친 후, 스마트폰으로 접속해서 확인해 보았다.
ㅡ.ㅡ;;
H.264와 AAC 코덱으로 변환한 파일을 갤S에서 재생할수 없는 동영상이라고 나온다.(iphone3Gs, iphone4G는 이상없음)

갤S로 링크파일 다운로드 받아서 재생을 시켜보니 정상적으로 나온다.
(iphone은 power downloader 라는 app을 추가로 설치해야 브라우저에서 링크파일을 다운로드 받을 수 있다고 한다)

이건 무슨 현상일까요, 갤S에서 브라우저가 다운로드 받아서 재생가능한 영상이란, 뭔가 다른것이 있다는 이야긴데...
이 부분에 대해서는 아직 적당한 해결책을 찾지 못했다.

그래서 현재는 자바스크립트로 브라우저와 해상도를 탐지해서,
해당 환경에 맞는 동영상콘텐츠로 이동시키는 방법으로 구현되어 있다.


2) html5의 video 태그를 사용해서 페이지에서 바로 재생시키는 방법

HTML5의 video 태그를 사용할 경우, ogg theora 코덱과 H.264코덱을 같이 제공해야 크롬,파폭,사파리 등에서 재생가능하다.


다양한 변환프로그램들이 존재하지만
테스트를 아직 해보지 못한 상태이다.

참고 URL
Making HTML5 Video work on Android phones
HTML5 Video Tag
"Raw Data Now"

웹(www)의 창시자 팀버너스리가 다음세대의 웹을 위한 이야기를 합니다. (2009년 5월자료)

예전의 20년간 웹이 가지고 온 혁명이 문서였다면, 앞으로 필요한것은 데이터입니다.
데이터는 서로 연결되어 놀라운 힘을 발휘하게 됩니다.

우리에게 예전에 문서를 웹에 공개했다면,
이제는 데이터를 웹에 공유하는것이 필요합니다.

- 발표 내용 중

왜 웹이 앞으로 시맨틱해져야 하는지에 대한 답변이 되겠네요.~

(발표내용 중 위키피디아를 데이터로 만든 http://dbpedia.org/ 의 예)




우리나라에서 SW관련 종사자 중에 아래한글을 안써보신 분은 없겠죠.
아마도 아래한글을 어둠의경로로 사용하는 분들이 엄청나게 있을거라고 생각되네요.

저는 아래한글하면 군대의 행정병PC가 떠오르네요
그때는 세로줄그리는 부분에서 스페이스바로 밀어서 이리저리 맞추던 기억이.. ㅎㅎ

한컴이 우여곡절을 겪으면서 올해 20주년이 되었다네요
최근에는 소프트포럼에 인수되었다고 알고있는데 앞으로도 행보가 기대됩니다.

20살을 맞아서 한컴에서 재미있는 이벤트를 하는 중이니
보다 자세한 정보는
아래 주소를 방문해서 확인하세요.

이벤트 상세정보
http://www.hancom.co.kr/event/anniversary.jsp?rurl=rHancom0000049



이벤트 상세정보
http://www.hancom.co.kr/event/anniversary.jsp?rurl=rHancom0000049



zdnet 기사를 보면 지메일 전화를 내놓자 마자 24시간만에 100만 통화를 돌파했다고 합니다.
http://www.zdnet.com/blog/btl/google-more-than-1-million-calls-through-gmail-in-24-hours/38500


지메일 전화란 무엇일까요?

통신방식의 변화를 그림으로 먼저 보시죠.
지메일 소개 영상에서 캡쳐한 이미지입니다.
건너편 동굴에 돌을 던져서 통신하는걸 설명하고 있네요










유선 전화로 통신하는 장면입니다









구글 토크를 이용한 통신장면 입니다.










지메일 전화를 설명합니다.
PC 사용자가 스마트폰 사용자에게 전화를 걸고 서로 통신하는 모습입니다.
PC에는 전화를 송수신하기위한 프로그램을 설치하고 스마트폰에 전화를 거시면 통화가 되는거죠.









브라우저로 gmail.com/call 로 접속하시면 아래 그림과 같은 화면이 나옵니다.
버튼을 누르시고 음성통화를 위한 프로그램을 설치합니다.





지메일 전화 소개 영상


앞으로 몇가지 과제(gmail 계정을 유선번호로 전환하는 등)를 해결한다면 구글이 통신시장의 비용구조를 모두 바꾸어 버릴지도 모릅니다. 아래 사진처럼 공중전화에서 gmail에 전화를 걸 수 있을지도 모르죠 ㅎㅎ


어찌되었는 흥미로운 행보임에는 틀림없습니다.
아이폰의 facetime과 구글의 구글전화를 지켜봐야 겠습니다.

MS, 코딩 필요없는 SW개발툴 '라이트스위치' 공개

http://www.zdnet.co.kr/Contents/2010/08/05/zdnet20100805102517.htm

지디넷 MS 전문 블로거 마리 조 폴리는
"라이트스위치는 비전문 개발자가 더 쉽게 애플리케이션을 개발할 수 있도록 미리 만들어진 템플릿에 의존할 수 있는 툴" 이라고 말했다.


공식사이트 : http://www.microsoft.com/visualstudio/en-us/lightswitch


제공되는 Tutorial 순서대로 진행해보니 간단하게 이런것이 나오네요.




'웹개발 간편해진다', MS 무료SW '웹매트릭스' 배포


http://www.zdnet.co.kr/ArticleView.asp?artice_id=20100707092407

무료로 제공되는 웹매트릭스는 MS ASP닷넷 웹 플랫폼에 기반해 애플리케이션을 만드는 개발자들을 겨냥했다. IIS 익스프레스로 불리는 웹서버, SQL서버 컴팩트 에디션 최신 버전, 레이저로 불리는 ASP닷넷용 뷰엔진 옵션도 포함하고 있다. 레이저는 개발자들이 HTML안에 비주얼 베이직이나 C샵 프로그래밍 언어를 내장시킬 수 있게 해준다.


공식사이트 : http://www.microsoft.com/web/webmatrix/download/


마우스를 클릭하면서 만들수 있다고 해서 좋은 SW를 개발하기가 쉽다것은 아니지만, 좋은 도구를 계속 만들고 있는 MS의 노력은 분명 본받을 점이 있는것 같습니다.

그런데, MS가 만일 자사가 제공하는 한가지 플랫폼을 통해서 개발자에게 쉬운 개발을 하도록 하는것이 원하는 것이라면,
그게 과연 비지니스에서 원하는 것일지 잠깐 생각해봅니다.
요즘처럼 복합적인 여러기술을 사용해야 하는 비지니스 환경에서, MS의 독자적 기술만으로 비지니스의 성공을 이끌겠다는 생각이 왠지 좀 오만하게 느껴지는건 제 생각 일까요?

 


관련 링크






저는 평생 한두곳의 회사만 다니고 싶어요.
그렇게 오랫동안 일할 수 있게 해주는 회사가 있다면 저는 그 회사를 위해서 최선을 다해서 일할 것 입니다.
그런데 그런회사는 어떤 회사일까요?
우선 저는 근무 시간중에 일정 시간동안 자기가 원하는 일을 하도록 해주는 구글이 마음에 들어요. 직장 내에서 혁신을 조장하는 정말로 멋진 방법이죠. 그러기 위해서는 분명 조건이 있어야 할 겁니다. 제가 골랐고 열정적으로 느끼는 일반적인 일 외에도 뭔가에 몰두할 수 있는 능력이 있어야 하겠죠. 원격 통신 능력이 있으면 아주 좋을 겁니다. 아무도 하루종일 흰색 벽 속에 갇혀있고 싶어하지 않을 테니까요. 그렇게 일하는 건 신체적으로나 감정적으로 너무 힘들죠. 근로 시간을 유연하게 조정해서 일하는 것도 좋겠지요. 그렇지만 제가 집에서 일항 경우 그런게 별로 의미는 없겠죠. 스톡옵션은 좋아요. 저와 제 아들까지 수혜 대상이 되는 복지 혜택도 있으면 좋구요. 출장 기회도 많고, 제가 제 분야에서 발전할 수 있는 훈련도 받을 수 있다면 금상첨화겠죠. 어디서나 데이터 연결이 가능하고, 연간 비품 비용을 청구할 수 있고, 마사지까지 받으면 더 좋구요.


그러나 그 어느 것보다 제가 일을 구할 때 가장 중시하는 건 그 일이 '도전적'인지 여부입니다. 저는 보고서나 작성하고, 육체노동이나 하고, 머리를 쓸 필요가 없는 일을 하면서 제 시간을 보내고 싶지는 않아요. 저는 직장 내에서 제가 가치를 인정받는다는 느낌을 받고 싶은데, 그런 느낌은 도전적인 일을 해결할 때 느낄 수 있죠. 예를 들어 "우리는 저 직원은 힘든 일도 잘 처리할 수 있다고 생각합니다. 재능이 있는 친구입니다."라는 말을 듣고 싶은 거죠. 그러면 저는 제능력을 증명해 보이고 싶을 것이고, 제가 그렇게 하면 저를 고용한 회사의 고용주들 에게도 좋은 일이겠죠. 그러면 모든 사람이 승리하는 거구요.  - 디지털 네이티브(돈 탭스콧 저)

좋은 품질을 원할때 팀원에게 해주어야 하는 노력들..
책에서 발췌도 했고, 제생각도 적었고, 물어보기도 했습니다. ㅎㅎ
(추가해주시면 생각해보겠습니다. )


  • 충분한 개인 개발 공간
  • 책, 파일, 노트, 코드목록, 컴퓨터장치를 동시에 놓을 수 있는 책상공간
  • 전화로 인한 방해를 멈출수 있는 수단(전화 대신 편지사용)
  • 사람으로 인한 방해를 멈출수 있는 수단
  • 원하지 않는 소음을 차단할 수 있는 수단(문이 있는 개인사무실)
  • 적절한 서가공간
  • 외부 창문이 있는 사무실
  • 넓은 화이트보드 공간
  • 넓은 게시판 공간
  • 다른 팀원에 대한 편리한 접근 수단
  • 고속 프린터
  • 자동문서 공급장치가 붙은 복사기
  • 회의실에 대한 편리한 접근수단
  • 펜, 연필, 형광펜, 종이클립, 고무줄, 스탬플, 테이프, 메모장, 노트, 3공바인더, 공디스켓  등의 사무용품
  • 적절한 온도유지
  • 청결한 환경
  • 일하기 좋은 성능의 PC
  • 업무에 구애받지 않는 SW

주의사항 : 개발자 우대에 대한 다른 조직원의 불만을 주의해야 함.


+ Recent posts