'개발'에 관한 글 7건

  1. 2011.08.22 CloudFoundry, Getting Started
  2. 2008.04.26 책: 애자일 프랙티스 (Practices of an Agile Developer)
  3. 2007.05.25 "The top 10 dead (or dying) computer skills"
  4. 2007.05.21 "The Power of Code Review"
  5. 2007.05.18 우리들 만의 문제가 아닌 세계적인 "나무 프로젝트"
  6. 2007.05.15 소프트웨어 개발, 철학의 부재
  7. 2007.05.08 patch for udp socket reuse for rtp multicast.

CloudFoundry, Getting Started

Clip to Evernote

블로그가 이사를 갔어요!

죄송합니다! 대부분의 글을 유지하고는 있으나 일부는 유지하지 못했습니다!
10초 이내에 새로 옮겨진 페이지로 이동할 겁니다.
원하시는 글이 아니면 전체 목록을 확인해주세요!
소용환의 생각저장소 / 아카이브

CloudFoundry 맛보기. 이 정도로 사실, 맛을 볼 수는 없겠으나 일단 시간과 능력의 부족으로 Getting Started Guide를 따라해보는 수준으로 정리, 간만에 신세계 구경도 하고 짧게 나마 포스팅도 한다.

먼저, http://www.cloudfoundry.com 에서 계정 신청을 해야하는데, 몇일 전에 CloudFoundry와 Ubuntu와의 뭔가 끈끈한 관계에 대한 글을 읽고 자극을 받아서 한 번 신청해봤는데, 오늘 메일함을 보니 계정 생성 메일이 와있었다. (초대형식으로 가입된다는 이야기)

1. 준비하기

특이한 점이, 웹 인터페이스가 없는 것 같다. 비슷한 서비스인 heroku(http://www.keroku.com) 의 경우에는 기본적인 정보 열람 등이 가능한 웹 인터페이스가 있는데, CloudFoundry는 그게 없다. 아마도 현재는 Beta 상태이므로 상용 서비스가 시작되는 시점에는 뭔가 포털이 생기지 않을까? 아무튼, command line 모드 클라이언트인 vmc를 설치해야 한다.

vmc는 ruby gem 형태로 배포되는데, 다음과 같이 설치가 가능하다. (물론 리눅스 이야기, 그리고 ruby 설치 등은 생략)

sio4@silver:~$ gem install --user-install --no-rdoc --no-ri vmc
Successfully installed json_pure-1.5.3
Successfully installed rubyzip2-2.0.1
Successfully installed highline-1.6.2
Successfully installed terminal-table-1.4.2
Successfully installed vmc-0.3.12
5 gems installed
sio4@silver:~$


2. 시작하기

이제 CloudFoundry에 로그인을 해야한다. 그런데 특이한 점은 CloudFoundry의 독특한 성격. 즉, 배포와 사용이 가능한 "Open PaaS"라는 점 때문에 어디로 로그인할 것인지 "target"을 정하는 과정이 있다는 점이 특이하다.

sio4@silver:~$ vmc target api.cloudfoundry.com
Succesfully targeted to [http://api.cloudfoundry.com]

sio4@silver:~$ vmc login
Email: xxxxxxxx@xxxxxxxx.com
Password: ****************
Successfully logged into [http://api.cloudfoundry.com]

sio4@silver:~$ vmc passwd
Changing password for 'xxxxxxxx@xxxxxxxx.com'
New Password: *********
Verify Password: *********

Successfully changed password

sio4@silver:~$

첫번째 로그인이라서 암호도 바꿔줬다. (가입 완료 메일에 임시 비번이 딸려온다.)


3. 개발하기

이제 간단하게 어플리케이션을 하나 개발(?)해볼 차례.

sio4@silver:~$ mkdir app_name
sio4@silver:~$ cd app_name/
sio4@silver:~/app_name$ cat > app_name.rb << EOF
> require 'sinatra'
> get '/' do
>   "Placeholder"
> end
> EOF
sio4@silver:~/app_name$ vmc push
Would you like to deploy from the current directory? [Yn]:
Application Name: app_name
Application Deployed URL: 'app_name.cloudfoundry.com'?
Detected a Sinatra Application, is this correct? [Yn]:
Memory Reservation [Default:128M] (64M, 128M, 256M, 512M, 1G or 2G)
Creating Application: OK
Would you like to bind any services to 'app_name'? [yN]:
Uploading Application:
  Checking for available resources: OK
  Packing application: OK
  Uploading (0K): OK
Push Status: OK
Staging Application: OK
Starting Application: OK

sio4@silver:~/app_name$

크핫! 이제 http://app_name.cloudfoundry.com 에 접속해보면, 짜잔~ 한 줄 뜬다. :-( 어쨌든 정상 작동!


이야~~~ 멋지지 않아? "준비하시고~", "시~", "작!" 하면 딱 뜨는데... 왜 클라우드를 안써? 아니, 왜 가상화만 생각해? 이게 궁극의 클라우드 아닌감? 게다가 CloudFoundry의 멋진 "Open PaaS" 정책은 (자세히 살펴보지는 않았지만) 데이터 유출의 걱정도 없이 Private PaaS의 구축을 쉽게 해줄 것 같은 느낌. 이거 좀 파봐야겠는데...

아하... 이럴 땐 여건에게 핑계를!!


참고로, 정보 보기

sio4@silver:~$ vmc info

VMware's Cloud Application Platform
For support visit http://support.cloudfoundry.com

Target:   http://api.cloudfoundry.com (v0.999)
Client:   v0.3.12

User:     xxxxxxxx@xxxxxxxx.com
Usage:    Memory   (128.0M of 2.0G total)
          Services (0 of 16 total)
          Apps     (1 of 20 total)

sio4@silver:~$

앱 스무개라... 음... 좋네~ ㅋ

트랙백 0 댓글 0

댓글을 달아 주세요

책: 애자일 프랙티스 (Practices of an Agile Developer)

Clip to Evernote

블로그가 이사를 갔어요!

죄송합니다! 대부분의 글을 유지하고는 있으나 일부는 유지하지 못했습니다!
10초 이내에 새로 옮겨진 페이지로 이동할 겁니다.
원하시는 글이 아니면 전체 목록을 확인해주세요!
소용환의 생각저장소 / 아카이브

애자일 프랙티스 : 빠르고 유연한, 개발자의 실천 가이드

인사이트; 벤캣 수브라마니암, 앤디 헌트 지음; 신승환, 정태중 옮김

사용자 삽입 이미지

요즘 읽고 있는 책이다. 3주 전부터 읽기 시작했는데 아직이다. 워낙 책 읽는 속도가 느리기도 하고, 또 출퇴근 버스 안에서 주로 읽다 보니 통 진도가 나가지 않는다. 편안히 앉아서 책을 읽을 수 있는 환경이... 간절하다.

실은, 오늘 남은 1/4 정도를 다 읽어야 한다. 회사 도서관에서 빌린 책인데, 기본 2주에 1주 연장한 기한이 오늘이다. 3/4를 이미 읽은 상태인데, 이제 반납 시간이 다가오다보니 별 희한한 생각이 다 든다. 뭐냐면, "살까?" 이런거. 말이 좀 길었는데... 결국 하려던 말은 괜찮은 책이라는 얘기.

먼저, 가벼운 책이다. 복잡한 기술적 설명과 이해가 필요한 책도 아니고 실습이 필요한 책도 아니다. 읽으면서 공감하고, 느끼고, 생각을 배우는 그런 책이다. (요즘 우리 분야에서 이런 책들이 유난히 많이 보이는 것 같다. 나 역시 이런게 목마른 중이라... 이런 책 대환영이다.)

45개의 작은 주제를 악마의 속사귐, 본문, 천사의 충고, 정리/균형잡기의 네 단계로 짤막 짤막하게 이어가고 있어서 나의 경우처럼 토막시간을 이용하여 읽기에 매우 적당하다. 마치, 직장 동료나 선배와 커피 한 잔 마시면서 짧은 대화를 나누는, 그런 느낌으로 읽을 수 있었다는 점이 물리적으로 편안했다.

개념적인 부분부터 세부적인 행동에 이르기까지, 애자일 개발 방법론을 실제로 실무에 적용하기 위한 다양한 실천적 방법들을 설명하고 있다. 간략히 목차를 보면,

 1장 애자일 소프트웨어 개발

 2장 애자일 시작하기

 3장 애자일 기르기

 4장 사용자가 원하는 내용을 제공하기

 5장 애자일 피드백

 6장 애자일 코딩

 7장 애자일 디버깅

 8장 애자일 협력

 9장 에필로그: 애자일로 이동하기

1~3장은 "애자일"의 본질, 개념에 가까운 내용으로 구성되어 있고 4~8장은 주로 그것을 행동에 옮기는 방법에 대하여 다루고 있다. 행동에 대한 부분은 굳이 애자일이라는 용어로 설명하지 않더라도 유용한 부분이며 이미 많은 사람들이 실천하고 있거나 최소한 적용을 위한 노력을 기울이고 있는 내용들이긴 하다. 하지만 이렇게 "애자일 방법론"이라는 주제 안에서 바라보니 왠지 새로운 느낌을 준다.

음... 특히 변화를 꿈꾸는 팀에게 권하고 싶다. 확실히 또는 막연히 느끼고는 있으나 뭘 어떻게 해야 할지 갈팡질팡 헤메고 있는 팀이 있다면, 이렇게 부담스럽지 않은 분량의 짧은 주제를 한 주에 한 두 개씩 함께 읽고, 토의하고, 적용해 나가는 방식으로 변화의 흐름을 타 보는 것도 좋을 것 같다.


트랙백 0 댓글 0

댓글을 달아 주세요

"The top 10 dead (or dying) computer skills"

Clip to Evernote

블로그가 이사를 갔어요!

죄송합니다! 대부분의 글을 유지하고는 있으나 일부는 유지하지 못했습니다!
10초 이내에 새로 옮겨진 페이지로 이동할 겁니다.
원하시는 글이 아니면 전체 목록을 확인해주세요!
소용환의 생각저장소 / 아카이브
전산 환경에 대한 재미있는 글이 나왔다.

The top 10 dead (or dying) computer skills
Those in search of eternal life need look no further than the computer industry. Here, last gasps are rarely taken, as aging systems crank away in back rooms across the U.S., not unlike 1970s reruns on Nickelodeon's TV Land. So while it may not be exactly easy for Novell NetWare engineers and OS/2 administrators to find employers who require their services, it's very difficult to declare these skills -- or any computer skill, really -- dead.

1. Cobol
2. Nonrelational DBMS
3. Non-IP networks
4. cc:Mail
5. ColdFusion
6. C programming
7. PowerBuilder
8. Certified NetWare Engineers
9. PC network administrators
10. OS/2

그 중에서 6. C Programming
As the Web takes over, C languages are also becoming less relevant, according to Padveen. "C++ and C Sharp are still alive and kicking, but try to find a basic C-only programmer today, and you'll likely find a guy that's unemployed and/or training for a new skill," he says. (see also: "Hot Skills, Cold Skills ")
에궁... 놀라라...
트랙백 0 댓글 0

댓글을 달아 주세요

"The Power of Code Review"

Clip to Evernote

블로그가 이사를 갔어요!

죄송합니다! 대부분의 글을 유지하고는 있으나 일부는 유지하지 못했습니다!
10초 이내에 새로 옮겨진 페이지로 이동할 겁니다.
원하시는 글이 아니면 전체 목록을 확인해주세요!
소용환의 생각저장소 / 아카이브

코드리뷰에 대한 좋은 글이 있어서 인용한다. 그런데, 한 문장도 빼놓기가 아까운게... 잔뜩 인용해버렸다. :-)

BSBlog » Blog Archive » The Power of Code Review

For the most part, reviewers are not responsible for ensuring correct code function: unit tests are much better suited to that task. What reviewers are responsible for is much more “social”, and typically does not require a detailed line-by-line analysis of the code to perform a review. In many cases, important parts of the review process should happen before a coder starts working on a patch, or after APIs are designed but before implementation.

There are some important side effects of the review process that are also beneficial:
  • More than one person knows every piece of code. Many Mozilla modules have grown a buddy system where two people know the code intimately. This is very helpful because it means that a single person going on vacation doesn’t imperil a release or schedule.
  • Reviewing is mentoring. New hackers who are not familiar with a project can be guided and improved through code review. Initiall, this requires additional effort and patience from the reviewer. Code from inexperienced hackers deserves a much more detailed review.
  • A public review log is a great historical resource for new and experienced hackers alike. Following CVS blame and log back to bug numbers can give lots of valuable historical information.
There can’t really be general guidelines on how much time to spend reviewing. Some experienced hackers may spend up to 50% of their time doing reviews (I typically spend two days a week doing design and code reviews and various planning tasks). This can be hard, because coding feels much more productive than reviewing.

나의 지론, 휴가 가고싶으면 잘 하란 말이다.


트랙백 0 댓글 0

댓글을 달아 주세요

우리들 만의 문제가 아닌 세계적인 "나무 프로젝트"

Clip to Evernote

블로그가 이사를 갔어요!

죄송합니다! 대부분의 글을 유지하고는 있으나 일부는 유지하지 못했습니다!
10초 이내에 새로 옮겨진 페이지로 이동할 겁니다.
원하시는 글이 아니면 전체 목록을 확인해주세요!
소용환의 생각저장소 / 아카이브

재밌네. 누군가 번역하여 둔 것을 먼저 봤으나, 원본의 것을 붙인다. 역시 우리만의 문제는 아닌게다.

사용자 삽입 이미지

원본은 : (project.jpg 그림, JPEGx800 픽셀)


트랙백 0 댓글 0

댓글을 달아 주세요

소프트웨어 개발, 철학의 부재

Clip to Evernote

블로그가 이사를 갔어요!

죄송합니다! 대부분의 글을 유지하고는 있으나 일부는 유지하지 못했습니다!
10초 이내에 새로 옮겨진 페이지로 이동할 겁니다.
원하시는 글이 아니면 전체 목록을 확인해주세요!
소용환의 생각저장소 / 아카이브

"생각이 없음"

(제목을 바꾸고 내용의 일부분, 이 위치에 있던 인용부분, 을 지웠다. 인용했던 글을 다시 읽어보니 스크랩 금지란다. 뭐, 나와는 다르더라도 그렇게 생각하신다면... :-)

뭐, 컴퓨터나 두들기는 쟁이가 "철학" 운운하면 좀 우스운가? 그런데, 철학이라는게 (한자어로 표현해서 그런지) 말은 좀 거창하지만 그 뜻은, "'생각' 하며 살자" 보다 더 크지 않은 듯.

개발자에게는 적어도 두 줄기의 철학이 필요하다. 그 중 첫번째는 물론, "사용자에 대한 배려"이다. 내가 만든 이 프로그램이, 이 기계가, 이 서비스가 사용자에게 어떤 행복을 줄 수 있을까? 또는 사용자의 행복을 빼앗게 되지는 않을까 하는 고민이 필요하다. 이것이 엔지니어와 취미생활의 차이가 아닐까?

다른 한 줄기는 "(주변과) 어울림"이다. 내가 만든 것이 어디에서 움직이는지를 생각하고 그 곳에 어울리도록 모양을 잡고 속을 채워야 한다. 사람의 삶이 그렇듯이, 기술, 도구 역시 어울림 속에서 그 빛을 발할 수 있고 기쁨을 만들어 낼 수 있다.


예전에, 한 10년도 더 전에, 나에게 많은 실망을 줬던 프로그램이 하나 있었는데, 그것은 다름아닌 당시의 "국민 프로그램", "아래한글" 의 첫 윈도 버전이었다.

윈도95 시대에 들어오면서 윈도가 비로소 DOS에서 벗어나 나름의 철학을 가지고 움직이기 시작했다. 예를 들면 윈도 3.1 시절의 .ini 라는 파일 기반의 설정 방식에서 벗어나 중앙의 규격화된 인터페이스의 레지스트리 방식으로 전환했다든지, 또는 C:\DOS 라는 자기 집만 챙기던 방식에서 나름의 계층화된 저장 구조를 이용하게 되었다든지...

그런데 문제의 "아래한글"은 그 철학을 전혀 존중해주지 않았으며(디렉토리에 대하여 아직도 독자적인 노선을 걷고 있고...) 심지어는 그래픽 툴킷까지도 독자적인 것을 사용하는 "만행(?)"을 저지르고 있었다. (게다가 더 향상되거나 편리해진 것도 아니었다. 단지 자신들의 기존 방식을 유지한 정도랄까?)

그들의 철학을 지키기 위해서 그랬다면, 듣자하니 별 것도 아닌데 무슨 상관이냐고? 그 무렵의 나는 이런 저런 이유로 윈도 기반 중앙 집중 관리식 전산실을 구성하여 관리하고 있었는데, 이 부분에 있어서는 윈도의 방식과 어울리지 않는 부분을 헤쳐나가기 위하여 이런 저런 꽁수와 삽질을 하지 않을 수 없었다. 그래서? 별로 행복하지 않았다는거지. 따지고 보면 극히 소수에게만 느껴지는, 그래서 무시할 수 있다고 생각하는(이것도 철학인데) 부분이라면? 뭐, 그냥 그렇다는 거다. 철학의 문제이니. :-)


요즘도 철학을 무시하는 경우를 가끔, 심심치 않게 볼 수 있다. 리눅스/유닉스의 세상은 비교적 잘 정리된, 뿌리가 있는, 그리고 오랜 기간 동안 다듬어진 철학을 가지고 있다. 반면, 근래의 리눅스 기반 프로그래머 중 일부는 리눅스/유닉스 세상에 대한 이해로부터 출발하여 "철학이 있는 개발"을 하기 보다는 돈이 되는 것 같아서 "아는 범위에서 일"을 하는 것 같다. 그러나 그 뿌리를 다른 곳에 두고 있고 그 범위 안에서 일을 하게 되므로 결과적으로 주변과 어울리지 않는 것을 만들어내는 것이다.

심각하다. 최근에는 프로그램의 임시 파일을 /usr/local/XXX/log 아래에 남기는 프로그램을 본 적도 있는데, 일반 사용자가 그 곳에 파일을 쓸 수 있을까? 혹시나 쓸 수 있도록 설정한다고 하여도 그것이 근본 철학과 맞는 것일까? 항상 root 계정으로 리눅스 PC를 사용하는, 마치 Administrator가 윈도의 기본 사용자이듯, 비전향 리눅스 개발자의 작품이겠지.

/home 아래에 MySQL, Apache, PHP 등의 패키지를 설치하여 사용하는 모습도 보인다. 엉뚱한 위치에 설치된 것은 물론이고 왜 공식적으로 배포되는 다듬어진 것을 사용하지 않고 직접 일을 만들어가며 하는 것이지?

이런 "철학의 부재"는 어디서 나타난걸까? 어떻게 하면 치료될까?

트랙백 0 댓글 0

댓글을 달아 주세요

patch for udp socket reuse for rtp multicast.

Clip to Evernote

블로그가 이사를 갔어요!

죄송합니다! 대부분의 글을 유지하고는 있으나 일부는 유지하지 못했습니다!
10초 이내에 새로 옮겨진 페이지로 이동할 겁니다.
원하시는 글이 아니면 전체 목록을 확인해주세요!
소용환의 생각저장소 / 아카이브
조금 된 패치인데, 기록을 위하여.

http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2007-March/049970.html

리눅스 세상에서 아마도 가장 인기있는 미디어 재생기이며 동시에, 더군다나, 가장 인기있는 소프트웨어 중의 하나가 MPlayer이다. 꽤 오래전부터 이 프로그램을 사용해왔는데, 기능도 다양하고 본래의 재생기로써의 부분 외에 인코더 기능도 있어서(별도의 바이너리) 이 녀석 하나면 거의 대부분의 멀티미디어 관련 작업을 할 수 있다. MP3 듣기, 영화보기, 영화 다시 인코딩하기 등...

이 오랜 친구를 이번에는 업무에 연관하여 사용해봤다. HD급의 라이브 방송에 대한 재전송 시스템의 한 부분으로 삽입된 RTP 프로토콜 게이트웨이 프로그램을 작성했는데, 이 시스템의 간이 사용자 인터페이스(XUL 기반)의 미리보기 기능을 이 녀석을 이용하여 구현한 것.

그런데, 문제 발견. MPlayer가 RTP 프로토콜을 지원하기는 하는데 배타적으로 지원한다는 것. 다시 말해서 (MPlayer를 이용하여) 미리보기를 하는 스트림은 재전송을 위하여 다시 열릴 수 없다는 것을 알게 되었다. 그리고 약간의 수정, 메일링리스트를 통한 보고, 그리고 몇 통의 메일 끝에 결과가 반영되었다.

패치를 첨부한다. (최종적으로는 좀 더 향상된 형태로 반영되었다.)

'오픈소스' 카테고리의 다른 글

오픈소스, 사람들  (0) 2007.05.09
patch for udp socket reuse for rtp multicast.  (0) 2007.05.08
"Comcast picks Zimbra for online e-mail"  (0) 2007.05.07
Adobe to Open Source Flex  (0) 2007.04.27
트랙백 0 댓글 0

댓글을 달아 주세요