Consensus algorithm

http://www.google.co.kr/url?sa=t&rct=j&q=paxos%20commit%20%20ppt&source=web&cd=6&ved=0CFoQFjAF&url=http%3A%2F%2Fwww.cs.sun.ac.za%2Frw334%2F2012%2FSlides%2FRW334_18.ppt&ei=xBsPUWrGmYgH3qyA8A4&usg=AFQjCNHqvN-8eQ_SXqXXkDccC9ZuXN--kw&bvm=bv.41867550,d.aGc&cad=rjt

 

Chubby

http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/ko//archive/chubby-osdi06.pdf

http://www.slideshare.net/ioanna_tsalouchidou/the-chubby-lock-service-for-loosely-coupled-distributed-systems


Zookeeper

http://static.usenix.org/events/atc10/tech/full_papers/Hunt.pdf

http://zookeeper.apache.org/doc/current/zookeeperInternals

http://zookeeper.apache.org/doc/r3.3.1/recipes.pdf


Zab

http://kisalay.com/2011/04/25/zab/

http://www.tcs.hut.fi/Studies/T-79.5001/reports/2012-deSouzaMedeiros.pdf

http://research.yahoo.com/node/3274

http://research.yahoo.com/node/3514

http://link.springer.com/chapter/10.1007%2F978-3-642-04355-0_39?LI=true


Paxos 

http://www.read.seas.harvard.edu/~kohler/class/08w-dsi/chandra07paxos.pdf

http://www.slideshare.net/paolos84/the-paxos-commit-algorithm

http://www.slideshare.net/savemanos/lock-service-with-paxos-in-erlang

http://www.slideshare.net/kuenishi/genpaxos-1679212 (https://github.com/gburd/gen_paxos)



 

Nosql 좋은 설명- paxos 관련 내용

http://highlyscalable.wordpress.com/2012/09/18/distributed-algorithms-in-nosql-databases/

 

Chubby (한글 정리)

http://blog.naver.com/PostView.nhn?blogId=smiler82&logNo=30042144407

 

paxos and zookeeper 의 zab 정리

http://home.ustc.edu.cn/~daidong/blog/paxos.html

Posted by '김용환'
,

인문학이 경영을 바꾼다.

http://www.seri.org/db/dbReptV.html?menu=db12&pubkey=db20110825001


좋은 내용 발췌


최근
- 스티브 잡스는 '애플의 창의적인 IT 제품은 애플이 기술과 인문학의 교차점에 서 있기 때문에 가능'
- 구글은 신규 채용자 6000명중 5000명이 인문학 전공자
   인터뷰할 때 ' 측정할 수 있는 것이 아니면 믿지 않는다'는 기술 공학 중심의 문화에서 '당신은 세상을 어떻게 바꿀 수 있는가'를 질문을 통해 인문학적 상상력을 평가
- 존슨앤드존슨은 다양성 대학을 운영, 조직 내에서 역량과 개성을 발휘할 수 있도록 지원
- IB의 다양성 위원회는 표창을 통해 다양한 배경을 지닌 임직원 간의 차이점을 존중하고 격려
- 픽사는 사내 교육기관 픽사 대학을 설립하고 글쓰기, 문학, 철학, 즉흥연극 등의 과정을 개설.
  지원에게 1주당 4시간의 자유로운 교육 시간 보장


이어령
- 최근 기업이 인문학에 관심을 갖게된 것은 ' 지식에 의한 생산'에서 '지혜에 기반한 경영'으로 패러다임이 반영
- 공급자 중심의 기술 경쟁하의 '산출물'만을 중시하시만, 소비자가 어디에서 재미와 편의를 느끼는지 이해기 위해서는 '창조 과정'에 주목하는 인문학적 통찰력 필요
- 인문학은 '관계'와 '사이'를 연구하는 학문으로 인간과 인간, 인간과 자연, 인간과 기계간의 관계를 바꾸는 인터페이스 혁명은 인문학적 상상력의 결과



시사점
- 경영과 인문학의 접목은 지식의 접목이 아니라 관점의 접목
- 조직내 다양성 배양관점에서 인문학을 포용
- 경영과 인문학의 접목을 위한 매개자는 필수

Posted by '김용환'
,

제가 시스템 운영하면서 가장 귀찮았던 것 중의 하나가 하드 디스크 폴트로 인해서 서비스 재설치하는 것입니다..서비스 개발자는 매번 이런 귀찮은 작업이 우리들의 업무들의 일부를 갂아먹고 있는 것 같습니다.  

Failure Trends in a large disk drive population 이라고, 구글도 고민한 글(논문이랄까요?)이 있더라구요..

http://static.googleusercontent.com/external_content/untrusted_dlcp/labs.google.com/ko//papers/disk_failures.pdf

 

구글의 bigtable을 관리하면서 이 자료가 만들어졌습니다. 구글에서는 SMART(drive’s self monitoring facility, http://en.wikipedia.org/wiki/S.M.A.R.T.) 라는 툴을 통해서 어떻게 하면 좋을까 하는 고민을 하면서 내놓은 글입니다..



2년지나면, 하드디스크에 문제가 확 나타나기 시작한데,.. 이거 완젼 우리와 똑같은 이슈가 있습니다. Dell장비는 2년만 지나면, 여기저기 하드디스크 깨지기 시작하고, 반복적인 일을 하게 됩니다. 처음엔 우리만 그런 줄 알았더니. 구글도 똑같은 이슈를 겪나 보네요..

 

이 논문의 결론을 말씀드리면,

다양한 신호를 통해서, 하드디스크 깨지는 요소들을 확인하였습니다.

 

중요 key는 다음과 같습니다.

1) 기존에 리포트된 것과 달리, 온도와 이용률(?, activity levels)과 failure rates는 거의 연관관계가 없다.

2) 중요 SMART 정보 (scan errors, reallocation counts, offline reallocation counts, and probational counts)가 중요하게 영향을 줄 수 있다.

3) SMART 만으로는 완벽하게 하드디스크 폴트를 예측할 수 없다고 합니다.

  * SMART의 여러 파라미터중, 모든 파라미터로 확인하면 64%까지 하드디스크 깨지는 것을 확인할 수 있다고 합니다.


<comment>
구글도. 운영을 잘할려구 하는 듯~~
 

Posted by '김용환'
,

rsync: connection unexpectedly closed (24 bytes read so far)
rsync error: error in rsync protocol data stream (code 12) at io.c(342)

 

이런 에러가 나면. 대부분..

다음의 이유가 있다.

 

  • The destination disk is full (remember that you need at least the size of the largest file that needs to be updated available in free disk space for the transfer to succeed).
  • An idle connection caused a router or remote-shell server to close the connection.
  • A network error caused the connection to be dropped.
  • The remote rsync executable wasn't found.
  • Your remote-shell setup isn't working right or isn't "clean" (i.e. it is sending spurious text to rsync)
  •  

    그리고, /var/log/messages 파일을 보고. 로그를 확인한다.

     

    remote 디렉토리가 없어도 위의 에러가 생기니. 디렉토리도 제대로 있는지 확인한다.

    Posted by '김용환'
    ,

    Bash Shell and Beyond

    By William Park

    Series Introduction

    In this monthly series, I will try to expose the power of the Bash shell. In particular, the readers will be introduced to Bash.Diff which is a collection of my patches incorporating many ideas from Ksh, Zsh, Awk, Python, and other languages.

    Each article will focus on one theme or feature, which is not normally thought of in shell context. I will also make liberal use of shell functions, standard builtins, dynamically loadable builtins, and advanced features patched into Bash, in a format that can be easily sourced and maintained.

    string.sh

    In C, <string.h> defines strcat(3), strcpy(3), strlen(3), and strcmp(3) for string concatenation, copy, size, and test operations respectively. Such basic operations are needed constantly when programming in any language, and shell scripting is no exception.

    strcat() and strcpy()

    For string copy and concatenation, you would do something like
        a=abc
        a=${a}'123'			# a=abc123
    
    in shell. This is simple variable assignment. However, you can't have variable reference on the left-hand side (LHS) of '='. You have to either type the LHS variable name explicitly as above, or use eval, as in
        x=a
        eval "$x=abc"
        eval "$x=\${$x}'123'"
    
    to parse the "..." expressions twice. It quickly becomes painful to call eval all the time, especially when the variable names are parsed from a file or a string.

    What is needed is a shell version of C functions strcat(3) and strcpy(3) which can be called with equal ease and simplicity. So, here they are:

        strcat ()		# var+=string
        {
    	local _VAR=$1 _STRING=$2 _a _b
    
    	case $#.$3 in
    	    2.) ;;
    	    3.*:*) _a=${3%:*} _b=${3#*:}
    		set -- `python_to_shell_range "$_a" "$_b" ${#_STRING}`
    		_STRING=${_STRING:$1:$2}
    		;;
    	    *)  echo "Usage: strcat var string [a:b]"
    		return 2
    		;;
    	esac
    	eval "$_VAR=\${$_VAR}\$_STRING"
        }
    
        strcpy ()		# var=string
        {
    	local _VAR=$1 _STRING=$2 _a _b
    
    	case $#.$3 in
    	    2.) ;;
    	    3.*:*) _a=${3%:*} _b=${3#*:}
    		set -- `python_to_shell_range "$_a" "$_b" ${#_STRING}`
    		_STRING=${_STRING:$1:$2}
    		;;
    	    *)  echo "Usage: strcpy var string [a:b]"
    		return 2
    		;;
    	esac
    	eval "$_VAR=\$_STRING"
        }
    
    where 'var' is the name of variable you want to use to store the result. The above example, then, becomes
        x=a
        strcpy $x abc		# a=abc
        strcat $x 123		# a+=123
    

    strlen()

    In C, strlen(3) gives you the size of a string. In the shell, you would use parameter expansion (i.e., ${#var}):

        a=abc123
        echo ${#a}			# 6
    
    Here is a shell version of C function strlen(3):
        strlen ()		# echo ${#string} ...
        {
    	for i in "$@"; do
    	    echo ${#i}
    	done
        }
    
    which has the additional ability of accepting multiple strings, e.g.
        strlen abc123 0123456789		# 6 10
    

    strcmp()

    To compare two strings for equality, you use strcmp(3) in C. In shell, you would do something like

        [ $a = abc123 ]
    
    Here is a shell version of C function strcmp(3):
        strcmp ()		# string == string
        {
    	local _STRING1=$1 _STRING2=$2 _a _b
          
    	case $#.$3 in
    	    2.) ;;
    	    3.*:*) _a=${3%:*} _b=${3#*:}
    		set -- `python_to_shell_range "$_a" "$_b" ${#_STRING1}`
    		_STRING1=${_STRING1:$1:$2}
    		set -- `python_to_shell_range "$_a" "$_b" ${#_STRING2}`
    		_STRING2=${_STRING2:$1:$2}
    		;;
    	    *)  echo "Usage: strcmp string1 string2 [a:b]"
    		return 2
    		;;
    	esac
    	[ "$_STRING1" == "$_STRING2" ]
        }
    
    so that the above example becomes
        strcmp $a abc123
    

    Python-style [a:b] substring

    Extracting substrings is another common operation. In the shell, you would use parameter expansion (i.e., ${var:a:n}), where 'a' is starting index and 'n' is the number of characters to extract. So,

        b=0123456789
        echo ${b:0:3} ${b: -3} ${b:1:${#b}-2}
    
    will print the first 3 chars, the last 3 chars, and all chars except the first and the last, respectively.

    The main problem with this syntax is that 'n' is a relative number starting at index 'a'. Usually, absolute index is more convenient, not only because it's more natural, but also because that's the way it is in C. Python has syntax var[a:b], where 'a' and 'b' are indexes which can be positive, negative, or omitted. Although it's roughly equivalent to ${var:a:b-a} in shell, missing 'a' and 'b' means the beginning and the end of string, and negative index means offset from the end of string.

    The above shell functions strcat(), strcpy(), and strcmp() already support Python-style [a:b] format, provided you source an internal function.

        # string[a:b] --> ${string:a:n}
        #
        # Convert Python-style string[a:b] range into Shell-style ${string:a:n} range,
        # where
        #	0 <= a <= b <= size  and  a + n = b
        #
        python_to_shell_range ()
        {
    	local -i size=$3
    	local -i b=${2:-$size}
    	local -i a=${1:-0}
    
    	if [ $# -ne 3 ]; then
    	    echo "Usage: python_to_shell_range a b size"
    	    return 2
    	fi
    
    	[[ a -lt 0 ]] && a=$((a+size))
    	[[ a -lt 0 ]] && a=0
    	[[ a -gt size ]] && a=$size
    
    	[[ b -lt 0 ]] && b=$((b+size))
    	[[ b -lt 0 ]] && b=0
    	[[ b -gt size ]] && b=$size
    	[[ b -lt a ]] && b=$a
    
    	echo $a $((b-a))
        }
    
    to convert Python range to shell range. It's not user-serviceable, but you can try it out:
        python_to_shell_range '' 3 10		# 0 3
        python_to_shell_range -3 '' 10		# 7 3
        python_to_shell_range 1 -1 10		# 1 8
    
    Now, you can specify a substring for strcat(), strcpy(), and strcmp() using Python-style [a:b] range as the third parameter, like this:
        b=0123456789
        strcpy x $b :3		# x=012
        strcpy y $b -3:		# y=789
        strcpy z $b 1:-1		# z=12345678
        echo $x $y $z
    

    Chaining of tests

    strcmp() tests two strings for equality. When there is a chain of 2 or more binary tests, like 'a < c > b' or '1 -lt 3 -gt 2', you have to break it up and test each pair:

        [[ a < c ]] && [[ c > b ]]
        [ 1 -lt 3 ] && [ 3 -gt 2 ]
    
    This breaks up the flow of your code, not to mention being error-prone. Here is a shell function which enables you to simply write down the chains on command-line:
        testchain ()		# string OP string OP string ...
        {
    	if [ $# -lt 3 ]; then
    	    echo "Usage: testchain string OP string [OP string ...]"
    	    return 2
    	fi
    	while [ $# -ge 3 ]; do
    	    test "$1" "$2" "$3" || return 1
    	    shift 2
    	done
        }
    
    where 'OP' is any binary operator accepted by test command. You use it much like test command:
        testchain a '<' c '>' b
        testchain 1 -lt 3 -gt 2
    

    Summary

    The source code for the 6 shell functions listed in this article is also available from string.sh. To use it, just source it,
        . string.sh
    
    In the next article, we'll see how strcat(), strcpy(), strlen(), and strcmp() shell functions can be written in C and compiled as builtin commands. And that will be the first introduction to my patched Bash shell. :-)

     

    Posted by '김용환'
    ,

    bash shell

    paper and essay 2008. 1. 18. 08:20

    Bash Shell and Beyond

    By William Park

    Series Introduction

    In this monthly series, I will try to expose the power of the Bash shell. In particular, the readers will be introduced to Bash.Diff which is a collection of my patches incorporating many ideas from Ksh, Zsh, Awk, Python, and other languages.

    Each article will focus on one theme or feature, which is not normally thought of in shell context. I will also make liberal use of shell functions, standard builtins, dynamically loadable builtins, and advanced features patched into Bash, in a format that can be easily sourced and maintained.

    string.sh

    In C, <string.h> defines strcat(3), strcpy(3), strlen(3), and strcmp(3) for string concatenation, copy, size, and test operations respectively. Such basic operations are needed constantly when programming in any language, and shell scripting is no exception.

    strcat() and strcpy()

    For string copy and concatenation, you would do something like
        a=abc
        a=${a}'123'			# a=abc123
    
    in shell. This is simple variable assignment. However, you can't have variable reference on the left-hand side (LHS) of '='. You have to either type the LHS variable name explicitly as above, or use eval, as in
        x=a
        eval "$x=abc"
        eval "$x=\${$x}'123'"
    
    to parse the "..." expressions twice. It quickly becomes painful to call eval all the time, especially when the variable names are parsed from a file or a string.

    What is needed is a shell version of C functions strcat(3) and strcpy(3) which can be called with equal ease and simplicity. So, here they are:

        strcat ()		# var+=string
        {
    	local _VAR=$1 _STRING=$2 _a _b
    
    	case $#.$3 in
    	    2.) ;;
    	    3.*:*) _a=${3%:*} _b=${3#*:}
    		set -- `python_to_shell_range "$_a" "$_b" ${#_STRING}`
    		_STRING=${_STRING:$1:$2}
    		;;
    	    *)  echo "Usage: strcat var string [a:b]"
    		return 2
    		;;
    	esac
    	eval "$_VAR=\${$_VAR}\$_STRING"
        }
    
        strcpy ()		# var=string
        {
    	local _VAR=$1 _STRING=$2 _a _b
    
    	case $#.$3 in
    	    2.) ;;
    	    3.*:*) _a=${3%:*} _b=${3#*:}
    		set -- `python_to_shell_range "$_a" "$_b" ${#_STRING}`
    		_STRING=${_STRING:$1:$2}
    		;;
    	    *)  echo "Usage: strcpy var string [a:b]"
    		return 2
    		;;
    	esac
    	eval "$_VAR=\$_STRING"
        }
    
    where 'var' is the name of variable you want to use to store the result. The above example, then, becomes
        x=a
        strcpy $x abc		# a=abc
        strcat $x 123		# a+=123
    

    strlen()

    In C, strlen(3) gives you the size of a string. In the shell, you would use parameter expansion (i.e., ${#var}):

        a=abc123
        echo ${#a}			# 6
    
    Here is a shell version of C function strlen(3):
        strlen ()		# echo ${#string} ...
        {
    	for i in "$@"; do
    	    echo ${#i}
    	done
        }
    
    which has the additional ability of accepting multiple strings, e.g.
        strlen abc123 0123456789		# 6 10
    

    strcmp()

    To compare two strings for equality, you use strcmp(3) in C. In shell, you would do something like

        [ $a = abc123 ]
    
    Here is a shell version of C function strcmp(3):
        strcmp ()		# string == string
        {
    	local _STRING1=$1 _STRING2=$2 _a _b
          
    	case $#.$3 in
    	    2.) ;;
    	    3.*:*) _a=${3%:*} _b=${3#*:}
    		set -- `python_to_shell_range "$_a" "$_b" ${#_STRING1}`
    		_STRING1=${_STRING1:$1:$2}
    		set -- `python_to_shell_range "$_a" "$_b" ${#_STRING2}`
    		_STRING2=${_STRING2:$1:$2}
    		;;
    	    *)  echo "Usage: strcmp string1 string2 [a:b]"
    		return 2
    		;;
    	esac
    	[ "$_STRING1" == "$_STRING2" ]
        }
    
    so that the above example becomes
        strcmp $a abc123
    

    Python-style [a:b] substring

    Extracting substrings is another common operation. In the shell, you would use parameter expansion (i.e., ${var:a:n}), where 'a' is starting index and 'n' is the number of characters to extract. So,

        b=0123456789
        echo ${b:0:3} ${b: -3} ${b:1:${#b}-2}
    
    will print the first 3 chars, the last 3 chars, and all chars except the first and the last, respectively.

    The main problem with this syntax is that 'n' is a relative number starting at index 'a'. Usually, absolute index is more convenient, not only because it's more natural, but also because that's the way it is in C. Python has syntax var[a:b], where 'a' and 'b' are indexes which can be positive, negative, or omitted. Although it's roughly equivalent to ${var:a:b-a} in shell, missing 'a' and 'b' means the beginning and the end of string, and negative index means offset from the end of string.

    The above shell functions strcat(), strcpy(), and strcmp() already support Python-style [a:b] format, provided you source an internal function.

        # string[a:b] --> ${string:a:n}
        #
        # Convert Python-style string[a:b] range into Shell-style ${string:a:n} range,
        # where
        #	0 <= a <= b <= size  and  a + n = b
        #
        python_to_shell_range ()
        {
    	local -i size=$3
    	local -i b=${2:-$size}
    	local -i a=${1:-0}
    
    	if [ $# -ne 3 ]; then
    	    echo "Usage: python_to_shell_range a b size"
    	    return 2
    	fi
    
    	[[ a -lt 0 ]] && a=$((a+size))
    	[[ a -lt 0 ]] && a=0
    	[[ a -gt size ]] && a=$size
    
    	[[ b -lt 0 ]] && b=$((b+size))
    	[[ b -lt 0 ]] && b=0
    	[[ b -gt size ]] && b=$size
    	[[ b -lt a ]] && b=$a
    
    	echo $a $((b-a))
        }
    
    to convert Python range to shell range. It's not user-serviceable, but you can try it out:
        python_to_shell_range '' 3 10		# 0 3
        python_to_shell_range -3 '' 10		# 7 3
        python_to_shell_range 1 -1 10		# 1 8
    
    Now, you can specify a substring for strcat(), strcpy(), and strcmp() using Python-style [a:b] range as the third parameter, like this:
        b=0123456789
        strcpy x $b :3		# x=012
        strcpy y $b -3:		# y=789
        strcpy z $b 1:-1		# z=12345678
        echo $x $y $z
    

    Chaining of tests

    strcmp() tests two strings for equality. When there is a chain of 2 or more binary tests, like 'a < c > b' or '1 -lt 3 -gt 2', you have to break it up and test each pair:

        [[ a < c ]] && [[ c > b ]]
        [ 1 -lt 3 ] && [ 3 -gt 2 ]
    
    This breaks up the flow of your code, not to mention being error-prone. Here is a shell function which enables you to simply write down the chains on command-line:
        testchain ()		# string OP string OP string ...
        {
    	if [ $# -lt 3 ]; then
    	    echo "Usage: testchain string OP string [OP string ...]"
    	    return 2
    	fi
    	while [ $# -ge 3 ]; do
    	    test "$1" "$2" "$3" || return 1
    	    shift 2
    	done
        }
    
    where 'OP' is any binary operator accepted by test command. You use it much like test command:
        testchain a '<' c '>' b
        testchain 1 -lt 3 -gt 2
    

    Summary

    The source code for the 6 shell functions listed in this article is also available from string.sh. To use it, just source it,
        . string.sh
    
    In the next article, we'll see how strcat(), strcpy(), strlen(), and strcmp() shell functions can be written in C and compiled as builtin commands. And that will be the first introduction to my patched Bash shell. :-)

     

    Posted by '김용환'
    ,
     
     
    Article
    Asking "Why?" at Sun Microsystems Laboratories: A Conversation with Director, Glenn Edens
      
     
    By Janice J. Heiss, January 2005  

    Articles Index

    In 1991, Sun Microsystems created Sun Microsystems Laboratories with the express purpose of solving difficult technical problems brought to Sun by customers. Over the years, the results have been impressive. (See sidebar for more details.)

    In the fall of 2003, Glenn Edens was named Senior Vice President and Director of Sun Labs. Edens himself has an inspiring record of technological innovation. In 1979, he co-founded Grid Systems Corporation, the company that developed the first laptop computer. He also founded WaveFrame Corporation in 1985, which developed the first all-digital audio workstations for the motion picture, television, and recording industries. From 1992 to 1998, Edens managed the transfer of research results into external product companies at Interval Research Corporation. From 1998 to 2001 he was president of AT&T Strategic Ventures, while also serving as VP of Broadband Technology there. From 2001 to 2003 he was Vice President for Strategic Technology at Hewlett-Packard.

    We met with him to learn about the direction he is taking Sun Labs.

    questionYou've asked the question, "What follows the Java language? What follows Solaris?" Can you hint at some answers?

    answerThose are rallying questions that are designed to give the Labs permission to think about these issues so we can experiment with alternatives. It's not clear that we're actually going to come up with anything better, though we may come up with something better in specific areas. So, for example, there's been a long tradition of work in the Labs challenging Java technology, called Self, which was a totally different model of object-oriented programming, factoring, and reflection.

    About Sun Microsystems Laboratories
    Sun Microsystems Laboratories claims from 175 to 200 researchers at any given time, with roughly 60% having Ph.D.s. They have a support staff of about 30, along with 20 to 50 interns. Over the years, Sun Labs has created a wealth of books, technical reports, and patents. Funded by Sun's corporate treasury, Sun Labs has offices in Mountain View, California, and Burlington, Massachusetts. Sun Labs technology transfer projects have generated over $2 billion dollars for Sun over the years -- far more if intangibles are accounted for. Since its inception in 1991, the Labs have generated 12% of Sun patents and intellectual property.

    To learn more:
    http://research.sun.com/about.html
    For Sun Labs projects:
    http://research.sun.com/projects/index.php
    For technical reports
    http://research.sun.com/techrep/index.html

    The Java platform is a very robust franchise. It's a marketplace. It's a community. It's a programming tool. So we ask questions: What are the alternatives? How do we make the Java runtime smaller? How do we make it faster? How would we change the memory model for the hardware? We're looking at different versions of virtual machine and garbage collection technology. Sometimes in research experiments, we'll change a language feature and experiment with it. And the jury's out as to whether those will ever be significant enough to then launch a JSR process. If you look at the history of programming languages, they don't last forever, because the technology changes, programming styles change, and the good languages last 15 or 20 years.

    "We're looking at different versions of virtual machine and garbage collection technology."

    - Glenn Edens, Director,
    Sun Microsystems Laboratories

    So, I would bet money that no matter what happens, whether Sun Labs existed or not, 10 years from now, the Java language will look different than it does today. Humans are really interesting, because we love to build tools, and we learn from that prior building experience to build better tools. So, it's conceivable to me that the Labs could develop an interesting alternative that would be commercially successful. At this point, we're really working in two main areas: How do we make current Java implementations better and how do we make them smaller and faster?

    One area of current research explores the link between a Java type object-oriented work load and hardware. In the Labs, the real exciting work isn't about instruction sets. It's about the memory model. So, we have projects like Mayhem and Barcelona, which we don't talk about much, where we're working hard to construct hardware and system software differently. So we're looking at different run time environments. If a large bank or a large customer's main workload is a Java 2 Platform, Enterprise Edition workload, then there's a good chance we could design computers differently to run those workloads better.

    We also have a project code-named Squawk, in which we're working on a very compact, high performance Java environment written entirely in the Java language. We're also interested in offering developers in the device world a complete Java stack that doesn't require integration with numerous other system software vendors.

    Running but not Managing Sun Labs

    questionYou are quoted as saying that you can run a research lab, but you can't manage one. What did you mean by that?

    answerA research lab attracts a different personality than a pure product group. And pure academic research and big science attract an even different personality type. So, we're kind of in the middle. My joke about this -- and I get a lot of grief over it, but I still think it's a good metaphor -- is that product organizations are mostly staffed with engineers. And engineers are mostly nerds, who ask: "How are we going to get this done? How does this work? How can we make it better?" How, how, how.

    "When managing a set of independent people, you can't tell them what to do."

    - Glenn Edens, Director,
    Sun Microsystems Laboratories

    A research lab tends to consist of hippies, and hippies just ask why. Why, why, why. Why do I have to do it this way? Why should I do that? Why do I need to fill out this form? Why do I have to -- anything. Everything is a question. There is nothing that happens here without an argument. But that's part of our robust culture, and it's the "why" versus the "how". The reason I get in trouble with that analogy is, of course, there are very good engineers in the labs, and there are very good hippies in the product groups.

    When managing a set of independent people, you can't tell them what to do. There are only three areas that I directly affect: First, I have some control over the people we hire. Second, I can present questions we ask, bringing in customers, suggesting something to discuss in Sun's Executive Management Group. And third, I can decide what to fund. But that's about it. That's why I say that you can run Sun Labs, but you can't manage it.

    Five Kinds of Projects at Sun Labs

    questionSun Labs has reinvented the way it works in the last year. You divide projects into five kinds: consulting projects that solve specific customer problems; advanced development projects that support business units with new technology; long-term vision projects; micro-business projects; and community projects.

    answerWe decided that we wanted to be crisper about where and how researchers spend their time. So, we perform our role as a teaching organization through consulting with the business units and our customers. We get called on to attend project briefings and hold workshops where we transfer our knowledge. We consult for free, which gives us the freedom to say, "No, we don't want to work on that one." If we charged for consulting, then we're a business. Some of our peer company research labs have gone to that model, but I think that's death for a research lab. Once you start chasing money on a per person basis, you turn yourself into a professional services organization with a lot of Ph.D.s and are no longer a research lab.

    Advanced development, the next category, is something we do rarely. But sometimes a business unit will ask us to solve a problem, and we'll take it all the way to a releasable state. That's an expensive proposition for the labs. However, we're taking the Honeycomb project, an integrated storage and server project, very far through this process.

    The vision projects are the core of what we do, and we do some interesting things in this area. Each researcher has a project that they pick by themselves and work on for some part of Fridays. They can work on anything they want. The only rule is they have to publish some results. But they get to pick how they spend Friday. Then we have our regular vision research projects, which are funded and evaluated, and we review them and nurture them through to hopefully get transferred to business units. That's probably more than 60% of what we do.


    questionIt's interesting that Sun Labs actually launches products through the micro business units with the intent of breaking even, in an effort to keep projects alive.

    answerOften we'll have a technology which is a little too small to transfer to a business unit, so we decide to launch the product ourselves. We run these break even, not wanting to lose money on them, but not needing to make money. We want to keep the technology alive and get customer engagement. Real-Time Specification for Java (RTSJ) was headed down that path. We were initially engaging with customers, and then things changed, and we were able to transfer RTSJ to the business unit.

    Finally, we have the community projects. And those are everything from open source work to patents, which eventually become public when they get issued. Community projects include chairing conferences, being on program committees, speaking, publishing technical reports and papers. We try to be very interactive with other universities and other conferences, and I think that really helps get that two-way information flow going.

    Moving Data at 60 to 100 Times Current Speeds

    questionSun Labs recently was awarded a 49.7 million dollar contract from the Defense Advanced Research Projects Agency (DARPA) to help design next-generation supercomputers. This asynchronous design research, advanced by Dr. Ivan Sutherland and Dr. Robert Drost, has already yielded a breakthrough in silicon design with the potential to move data at 60 to 100 times as fast as current top speeds. They are developing Proximity Communication whereby a pair of chips are positioned face-to-face within microns of each other, but not necessarily touching.

    answer The proximity IO work at Sun Labs got us the DARPA contract. This is a research project, so there are many questions. It's a substitute for printed circuit boards that allows you to design the hardware and connect chips together differently. The data rates between chips are now as fast as the data rates inside a chip. And so the distance controls the data delay. You can now start putting cache memories and different parts of systems outside in different chips, and the system will run just as fast. This research could change the way we approach silicon for processor design. It might have interesting applications for how switches and routers are built. If we're lucky, this could change how people design high performance computers -- we'll just have to see.

    Knowing Customers

    questionIt is a given that a lot of the projects at Sun Labs will eventually "fail" -- or perhaps, eventually show up in products in a different form, or become part of human knowledge. In a recent interview on java.sun.com, we talked to Sun's Rick Catell, who spent six years at Xerox PARC watching the invention of brilliant technology that went nowhere, he argued, because the researchers did not know their customers. In doing visionary research, how close should researchers be to customers? Do visionary products fail because researchers are out of touch with customers?

    answerOne thing that I find very amusing is that, from the perspective of Xerox, Xerox PARC was a complete success. There was no business model that required Xerox PARC to produce technology that shipped. Xerox PARC was funded because Xerox was afraid that IBM would invent the paperless office; then you wouldn't need Xerox. So, what's paradoxical is that everyone criticizes Xerox PARC, but from their perspective, it was a complete success.

    "At the end of the day, the spark of innovation still comes from someone asking, 'Why, why, why, why, why?'"

    - Glenn Edens, Director,
    Sun Microsystems Laboratories

    At Sun Labs, we work hard to make sure that our research staff is grounded in what's happening in the world. What's happening in pop culture? What are kids doing? What's this IM and learning to type with your thumbs about? Because kids, artists, and renegades are going to define how the technology gets used going forward. We bring in speakers and projects and work with other research labs. We work with schools. We bring in a lot of customers. We make sure that for the areas we're working in, we know as much as we can about what other labs are doing and what people's perceived problems are, because they can rarely articulate their real problems. So, a customer might say, "I'm spending too much money on IT." Well, what does that really mean? Does that mean that the money they're spending is not effective? Or does it really mean that it's effective, but they want to spend less? Do they believe it can be cheaper? Is it really a service problem? You have to decompose that.

    But at the end of the day, the spark of innovation still comes from someone asking, "Why, why, why, why, why? Why do I have to do it that way? Why is this done this way?" And you cannot replace that spark with any automated or procedural mechanism. It just has never happened. Now, maybe someone will eventually stumble onto the science to "make" innovation occur, which would be quite interesting. What you can do is equip your research lab with as much intelligence, creativity, and knowledge about what's happening in the world as you can. And the more you do that, the more relevant the solutions are going to be.

    See Also
    Rate and Review
    Tell us what you think of the content of this page.
    Excellent   Good   Fair   Poor  
    Comments:
    If you would like a reply to your comment, please submit your email address:
    Note: We may not respond to all submitted comments.

    copyright © Sun Microsystems, Inc 
     

    'paper and essay' 카테고리의 다른 글

    bash 스트링 조작하기 - String 함수 구현하기  (0) 2008.01.18
    bash shell  (0) 2008.01.18
    Becoming A Real Programmer  (0) 2005.02.28
    Why Do Universities Fail Teaching Software Engineering?  (0) 2005.02.28
    How to write papers  (0) 2005.02.15
    Posted by '김용환'
    ,

    (퍼옴) http://users.actcom.co.il/~choo/lupg/essays/becoming-a-real-programmer.html

     

    v1.0.0

    Becoming A Real Programmer (thinking about thinking...)

    Table Of Contents
    1. How long will it take?
    2. How critical is self-criticism?
    3. This is too theoretical - how about some examples?
    4. Letting ideas "sink"
    5. Broadening the scope of lessons learned
    6. Short-cuts don't let lessons sink-in
    7. Learning from other people's mistakes
    8. The better programmer you become - the more humble you get
    9. Being lazy the smart way
    10. Conclusions

    So you want to become a programmer. an independent programmer, that is not dependent on specific people to hold their hand, that can design a project and lead its development. A real programmer.

    Assuming that's what you want to become, and assuming you're not there yet - how do you go about doing that?


    How long will it take?

    Quite often, it will take you several years to become a real programmer. If you happen to have around you good programmers who are also good teachers, the time could shrink by much. But nothing will make this time shrink more then by you thinking about what you do, trying to develop a plan for your self-advancement, and criticizing your progress, your plan, and your changes to the plan.


    How critical is self-criticism?

    If you do something, and you think you did well - you limit your ability to do it better next time - because you don't see what wasn't good enough.

    If you leave self-criticism to certain occasions (such as after fully completing a given project), you miss the opportunity to learn during this project. Learning means seeing something that wasn't good enough, thinking how to do it better, trying the new way, checking if it improved something, and continuing that until you feel this isn't your worst problem any more. The longer you wait between cycles, the longer the overall process takes to converge.

    Of-course, changing things all the time won't work either - cause some methods of operation only justify themselves if used for a long period of time.

    Assuming that initially even usage of simple methods of operation will make us work better, we can start with using rather quick cycles, and as we make progress and master the simple methods, we can increase the time between cycles, in order to assess more complicated methods of operation.


    This is too theoretical - how about some examples?

    Let us take the following example - we were told that documenting code is useful. How useful is it? How much and where to document? we need to write 'according to the book' in our first project. Leave the code for one week, and then come back and try to add a feature. Did we need to read something several times in order to remember what's going on? then lets add a comment there. Some comments were not clear? lets try to make them clear - perhaps write more? perhaps write less? perhaps improve our English grammar?

    After we played with documentation for a few month we want to get to work on a larger document - something that explains the general design of a software module, for example. This takes longer to write, and it is hard to assess its quality without fully writing it, leaving that software project for a month, and then getting back to it. Our cycles slowed, because we already learned the simple things (documentation of single functions), and the more complicated methods take longer to complete, and require waiting longer in order to assess their usefulness (you don't forget the design of a module after 1 week, but you easily forget the internals of a specific function after a few days).


    Letting ideas "sink"

    The method of leaving something and getting back to it later is based on two principles:

    • we need to wait a while in order to be able to look at something in a new perspective - we might have got locked in one manner of thinking, and simply leaving the material for a while often helps us to unlock - because we forgot what it was that kept us locked in.

    • when we need to deal with something new, we often don't fully understand it. If we leave it for a while and then come back to it, we suddenly see things we didn't see before - understand little nuances we overlooked when we were busy grasping the major principles. It could also be that we worked on a different project meanwhile, and when we got back to the original project, we saw how something we learned during the second project, could have been applied to the first project. We correlate.


    Broadening the scope of lessons learned

    When we find a mistake we made, we can simply find a fix for it and use this fix next time, or we can instead try to check if there is a more general class of mistakes, to which this specific mistake belongs. In the later case, we can find a solution to a whole class of mistakes, and thus not have to learn from different mistakes in the same class - we will avoid doing those other mistakes in the first place.

    For example, suppose that we made an error of forgetting to allocate the extra null character when allocating a string in a "C" program. We coul just fix this bug and check the program again. We could think "oh, we didn't think about it", and go over all string allocations in our program to check they don't contain the same bug. We might decide that memory allocation is error-prone in general, and instead of doing the allocation and calculation of required space all over the code - we should write a function that allocates strings. We can broaden this to other types of allocations - and write functions that allocate objects of other types. If we had this problem with allocation, perhaps we have a similar problem with objects initialization - lets write functions that initialize objects, and use them, instead of writing the same initialization code all over the place. We start to see that even very small code re-use reduces the number of bugs in our code. We move from "ah, this initialization only requires 2 lines of code - why write it in a function?", to "repeating these 2 lines of code again and again will mean that if we make a mistake in 1 out of 4 locations in the code - then with 20 such code locations, we will have 5 bugs - all because we were too lazy to write a 2-line function".

    See how we got from a specific memory-allocation error, to learning something about avoiding code repetition, which we would have dismissed as "a waste of time" if we were directly asked to do this in the first place.


    Short-cuts don't let lessons sink-in

    We can argue that an experienced programmer could have shown us all of this immediately, and with enough patience, show us why something that looks trivial can save us a lot of time in the total development process. However, using such a short-cut prevents from the lesson to sink-in. We will still be tempted to choose the quicker path over using the slower path, that makes the overall journey shorter. We have to make our own mistakes in order to learn. Or we have to see how our friends made mistakes and learn from them...


    Learning from other people's mistakes

    When we learn of a mistake that someone else made, it is easy to think "this won't happen to me, I'm smarter" and dismiss it. But if we already invested time in seeing this mistake, why not stop, reminding ourselves we are only human and in certain situations we might do a similar (stupid) mistake? After we admit this to ourselves, we can go about learning from this mistake, as if it was our own mistake.

    One possible conclusion that follows is that helping other programmers fix their own bugs can help us learn, and thus is a useful activity - not just an annoying burden.


    The better programmer you become - the more humble you get

    Pride is a major obstacle for learning. "I am smart, i won't make this mistake again" is an error that will lead us to do a very similar mistake soon after. "I write good code, so i don't need to check it" will mean our simple local bugs will be hidden, and get exposed later when our module is used by other modules, which make it behave differently then our feeble tests did. By then, the bugs will be harder to track down, because the test-case is more complicated. Thus, we should reverse the cause and the result - "I check my code, and thus i write good code".

    Pride will also make us think we can learn everything on our own. Given infinite time this might be true - but life is short. We want to learn faster. Let us, then, learn how to listen to other people's criticism, and weed out the useful parts in their criticism, even if we think the majority of this criticism is wrong or pointless. For example, if someone keeps telling us that we did not test our code properly, while we spent a lot of time on testing, instead of dismissing the criticism - let us listen to it. Several examples that we will be given will be wrong - we did test those parts of the code properly. But once in a while some claim for lack of testing will be correct - aha, we indeed forgot to check that input option. Now that we see it, we can start our generalization process - how do we find all possible inputs and test all of them? if there are too many possible inputs - how do we choose selected test-cases that will help identify most of the probable bugs? How do we choose test-cases in general, not just for testing inputs - what about testing timing problems?


    Being lazy the smart way

    "I will find the bugs when i debug the code" is the claim of the sloppy lazy programmer, who refuses to read their own code again after they wrote it. The smart lazy programmer will claim "if i put more time re-reading my code now when it is fresh, I will probably spend less time over-all on writing and testing this code module - if I consider the time I spend on it now, as well as during system integration and system testing later on".

    The smart ultra-lazy programmer will think even further then this - "if I spend time now on learning lessons, in the long run i will be able to finish programming tasks in a shorter duration, and the time saved in the future will be much more then the extra time i spend now on my lessons learning".


    Conclusions

    In order to become real programmers, we need to think of what we plan to do. We need to think of what we just did, and of what we did a short while ago, of what we did a long while ago... Then we need to learn lessons. And then we need to broaden the lessons to more generalized classes of mistakes.

    We also need to listen to other people - they might see now something that we will only see next year - even if they are not smarter then us. They are simply not locked-in by things locking us in, that we did not identify yet. Or they had the chance to learn a lesson due to a mistake they made in the past, that we didn't come across yet. Perhaps they come from a completely different background, and have completely different methodologies of thinking, that make some bug easier to spot. So we humble ourselves, and listen.

    And we must avoid letting our short-term laziness hurt our much-more-useful long-term laziness.

    Posted by '김용환'
    ,

     

    (퍼옴) http://users.actcom.co.il/~choo/lupg/essays/software-engineering-and-uni.html


    v1.0.2

    Why Do Universities Fail Teaching Software Engineering?

    Table Of Contents:
    1. Abstract
    2. What Is Software Engineering?
    3. Software Engineering And Students
    4. More On Students
    5. More On Universities
    6. How To Make It Work?
    7. Financing Academic Software Projects

    Abstract

    Many universities and other institutions try to teach software engineering concepts to their students, either as part of their regular programming courses, in courses designed to teach just software engineering, or as a set of such courses.

    In this short essay, I'll supply a loose definition of "Software Engineering", show why it is so hard (or impossible) teaching it to inexperienced programmers, and try to illustrate a few methods that may be used to still put some sense of engineering into inexperienced programmers.


    What Is Software Engineering?

    Software engineering is a methodological process of writing software, in a manner that can be repeated for various software projects in a high level of accuracy, and produce good software, under given time and budget constraints.

    Lets explore this definition a bit. The methodology means that the software creation process is broken down into several steps, each of which is self-contained, and can be described easily, without using "magical" terms, as is common in the software industry ("i didn't know where to start, so i just hacked down something, and somehow it worked").

    For example, one may break software creation into steps such as "requirements specification", "architectural design", "interface design", "detailed design", "implementation", "integration" and "testing". Each of these steps can be properly defined (e.g. "requirements specification is a step in which we define the set of functionalities our software will support, without defining yet how it will support them, or how any kind of user-interface would look like").

    Good software would imply that the software does what it is supposed to do, that it has few bugs, that it can be easily maintained, and that it is relatively cheap to extend and add new features without introducing many new bugs.

    The software doing what it is supposed to do might sound trivial, but in many cases the original requirements get massively cut down because the software fails to perform various operations properly. easy maintenance would mean that it would be easy for a new programmer to learn how the software works and how to fix bugs in it, and that fixing bugs does not require rewriting complete parts of the software. Easy extension would mean, for example, that the software can be easily ported to new platforms, can easily have its user interface replaced (text UI to graphical UI, or web UI) without rewriting the rest of the system, and so on.

    Finally, every software development project has some limits on the amount of time until it has to be ready, and the amount of money that can be spent on the software. The engineering process should make it possible to supply a rather accurate forecast for the time and effort it will take to develop different modules of the software, using different designs. The time limits often come on expense of future maintainability and expend-ability of the software, and these issues need to be weighed against each other, and weighted appropriately, depending on the software requirements.


    Software Engineering And Students

    From the above description, one can see that software engineering introduces a lot of overhead to software development, and that this overhead might only be worthwhile for large software development. Using such process for small class exercises of few hundreds lines of code is an overkill and makes students despise or even ridicule the idea of software engineering.

    Another problem with software engineering, is that it can't be practiced without understanding that small decisions have big implications on large programs. For example, suppose that a method of a communications class returns a pointer to an object it has allocated. Who should be in charge of freeing that memory? The caller of the method, or the object that initially allocated the memory? What happens if in one place its easier to have the caller free the memory, and in another place its easier to make the allocating object free the memory? an inexperienced programmer would most likely do the easier thing in each case, claiming that the simplicity of the code is important, and would overlook the importance of consistency. For a small program, it won't do much harm - since the program is written in a short time, the programmer can remember who should free the memory in each case. Even if they don't, and have a memory leak, they are not going to run this program long enough to notice - once it works, it gets dumped.

    The same little decision would have a much bigger impact on a large software, that is supposed to last. A large software tends to have hundreds or thousands of classes, and not each one of them is used very often. If you had consistent rules (e.g. "the object allocating memory is always in charge of freeing it"), it will be easy to remember when to free allocated memory, and thus having less memory leaks and memory corruptions to chase.


    More On Students

    As we saw, software engineering requires large projects to make sense. It also requires experience to make sense. In particular, bad experience - if you write software in the right way, you don't get to see how wrong badly written software can get, and thus don't learn to appreciate the right ways. Thus, part of learning software engineering is achieved by seeing how lack of it can hurt large software projects. For students "a large project" might be something they have written in one semester, in which they also studied a few other courses.
    Given a software made of a few thousands lines of code, or a few tens of classes, inexperienced programmers consider the software to be a large project. Later on, when they get out to work in the industry, they will begin to realize those were in fact rather small projects. In such small projects, lack of proper engineering won't usually reveal the problems it causes, since those projects only need to work once or twice (when demonstrating them to the teacher) and don't get developed further afterwards.

    Another aspect of software engineering is designing the software to be easy to maintain. Since most student projects don't get tested by end-users users, many of their bugs remain hidden, and thus the programmer isn't exposed to the amount of time it would take to debug and fix it until it becomes on the level of usable release software - something which often would take more than the amount of time it took to originally write the code and make it run. The original developer of the code tends not to stress-test their code in its weak spots, since they subconsciously know it'll cause the software to crash or malfunction - something which will require more work, that isn't really appreciated when the project is graded. Thus, the programmer cannot see how their software design affected the ability to isolate bugs in the code, and get the false impression that their design generated bug-free software.

    Another aspect of learning about software engineering, is seeing how it affects the life cycle of a software project. Sometimes, experienced software engineers make decisions that look like small neat-peaking to the naked eye. Only after a while, as the project evolves to different directions, these original decisions begin to make sense to an inexperienced programmer. Some people will claim that this ability to see the need for those small decisions in advance comes with experience - and yet, this is what software engineering strives for - the ability to make these decisions using a methodological process, that generates repeated success.

    Finally, there are students that understand the rules of thumb, and believe that they might be useful, but still prefer not using them for their exercises on the grounds that understanding is enough, and when they get involved in large projects, they will know how to deal with them. The problem is that by the time they get to working on large projects, they might gather bad habits and find it hard to free themselves of these bad habits. They also overlook the little things that can only be achieved with real practice, and thus will stay behind fellow students, who have spent a few years of their undergraduate studies to actually apply these rules, and gained some experience, and thus more insight.

    So the conclusion we come to is that you need good familiarity and hands-on involvement in large and lasting software projects, both successful and failures, in order to grasp the essence of software engineering, and appreciate it. And in university environments (or various programming courses, for that matter) the ability to participate in such activities is rather limited.


    More On Universities

    What do universities do in order to try and teach software engineering? One thing they do is try to teach it as a set of rules of thumb, hoping that students will follow them, even if only because they are being enforced somehow when grading exercises and exams. The problem with this approach is that often the people who do the actual grading are graduate students, who themselves haven't had the chance to grab the concept of software engineering (especially if they entered graduate school directly after finishing undergraduate school).

    Even if some of the teachers, or teaching assistants, do have experience with large and lasting software projects, often their students don't know about that, and hence don't trust them. When you don't trust someone, you don't listen to advise they give you if you cannot see an immediate benefit (and in software engineering, there is no benefit for very small exercises). Thus, the students actually tend to ignore their teachers' rules of thumb, seeing them as a burden, and this causes more damage than if those rules were never given in the first place.

    At other times, there might be a good software engineering teacher, that indeed has experience in the field, and tries to show some real life examples to their students. These efforts, however, might be lost if the students don't get their own hands-on experience with such software. Learning software engineering on a theoretical bases, and using small code examples (since there is no time to really delve into large code examples) makes no sense, except for people who already understand software engineering in the first place - kind of a chicken-and-egg problem.


    How To Make It Work?

    After seeing what is needed to make students appreciate software engineering, we might as well spell out a few things that will make teaching it possible. First, we need to have accredited teachers. These teachers may either be people with past or current experience in the industry, that can use it to back their claims to students. They could also be people who participated in large academic projects, that got enough credit for being large and lasting. A good example would be the work done in the MIT university, and their Athena project (see also A review of - MIT project Athena: a model for distributed campus computing). Another good example is the work done at the Washington university in Seattle, by the Distributed Object Computing (DOC) group. There exist various other such examples. The important factor is that they are large projects, involve quite a few staff members (including graduate students), and last for quite a few years, and thus carry a scope similar to that of large industrial projects.

    It is also important that the students will know that their teachers have that experience. This is not to be used as a method of bragging, but rather to assure the students that their teacher is not just talking about theoretical software engineering methods; That the teacher has actually applied them, and can show them good, real-life examples, of why these methods are useful, and should be practiced even for smaller projects.

    Carrying out large projects by university staff members is also good as it allows graduate students to participate in such projects, and thus be more credible to serve as teaching assistants in software engineering related courses. With good project management, it is also possible to allow undergraduate students to take part in such projects, and witness, from first hand, the complexity of such a project. When they have to delve into code created by other programmers, possibly code that is 2-3 years old, they will learn to appreciate how hard it is to get into code parts that weren't properly engineered, and how relatively easy it is to get into parts that were properly engineered. And having specific parts of the code that are badly engineered on purpose, would serve the teaching goal quite well.

    Of-course, getting students involved in large software projects should be done gradually. At first, they may be introduced to small modules, learn them, and be guided in making small changes to them. It is a very useful quality to be able to delve into existing source bases, and inexperienced programmers often find it hard to do. At later phases, these students will be able to write new classes or modules. Getting credit for such projects will be more desirable than letting these students design their own software in a software project course, that will turn out to be small (they don't have enough time to work on it, and usually only 2-3 of them work on the code of such project) and having to create software that will most likely not last, and not be a part of a lasting project.


    Financing Academic Software Projects

    One of the major problems with carrying large software projects in universities is financing them. You need more equipment than with theoretical research, more system management staff, and more researchers than for a theoretical research.

    The equipment needed is often not so hard to get as a donation from large hardware manufacturers and resellers. They already have such donation relationship with universities, sometimes donating full labs for students to work on, in a hope that these students will get used to their development environments, and endorse them when they get some influence in their future working place.

    Another option is carrying software research projects that are useful for large industrial companies. Showing these companies how this research can help them, it is possible to convince them to sponsor such projects. The fact that financing a project in which graduate students and undergraduate students perform large parts of the work, would be cheaper than financing it inside the industry, it might look appealing to industrial companies. The TAO project carried by the DOC group at the Washington university and university of California, is a good example of such a relationship.

    Another major problem is attracting good software engineers that both wish to carry out research work in their field, and have the skills to manage large projects at the same time. The success of such a project in fact often relies on one or more such enthusiast leaders, that carries a good reputation in the academic field, as well as in the industry. It would be easier to attract such people to the academy, if they know they will get a supportive environment, and financing to projects that will seem feasible and are personally appealing to them. Sometimes, it does not require paying them better than in the industry. The fact that they get more freedom, and without the pressure of marketing personnel, would be enough to attract a few of them to moving to the academic world.



    [
    LUPG Home] [Tutorials] [Related Material] [Essays] [Project Ideas] [Send Comments]

    This document is copyright (c) 2001-2002 by guy keren.

    The material in this document is provided AS IS, without any expressed or implied warranty, or claim of fitness for a particular purpose. Neither the author nor any contributers shell be liable for any damages incured directly or indirectly by using the material contained in this document.

    permission to copy this document (electronically or on paper, for personal or organization internal use) or publish it on-line is hereby granted, provided that the document is copied as-is, this copyright notice is preserved, and a link to the original document is written in the document's body, or in the page linking to the copy of this document.

    Permission to make translations of this document is also granted, under these terms - assuming the translation preserves the meaning of the text, the copyright notice is preserved as-is, and a link to the original document is written in the document's body, or in the page linking to the copy of this document.

    For any questions about the document and its license, please contact the author.

    'paper and essay' 카테고리의 다른 글

    bash 스트링 조작하기 - String 함수 구현하기  (0) 2008.01.18
    bash shell  (0) 2008.01.18
    Asking &quot;Why?&quot; at Sun Microsystems Laboratories  (0) 2005.02.28
    Becoming A Real Programmer  (0) 2005.02.28
    How to write papers  (0) 2005.02.15
    Posted by '김용환'
    ,

     How to Organize your Thesis
     Advice to Authors of Extended Abstracts
     How to write good systems paper (Loy Leven.)
     How to give a good research talk(Simon L. Jones)

     

    논문을 어떻게 쓰는지에 대해서 알려주는 글.

    Posted by '김용환'
    ,