정치를 통한 세상의 변화를 체감할 수 있는 바로미터....

Essay/General 2013/03/29 13:32

 자기 개발 서적에서 많이 나오는 이야기 중 하나가. "모든 것을 '자기 탓'으로 돌려라."이다. 그래야 자기 발전이 있고, 문제해결의 실마리가 보이기 때문이다. 문제의 원인을 외부의 탓으로 돌리면, "어쩔 수 없다."는 결론 이외에는 얻을 수 있는 것이 없다.


 이런 관점에서 보면, 국내 정치환경이 나아지기 까지는 앞으로도 많은 시간이 필요한 듯 하다. 


 정치에 불만을 가지는 대부분의 글이 "저 정치인은 이래서 문제고, 저래서 문제고..." 등의 글이다. 즉, 문제의 원인을 "잘못된 정치인" - 외부 - 에서 찾고 있다. 그래서, "정치인은 어쩔 수 없다." 혹은 "정치가 다 그렇지 뭐" 식의 이야기가 나오게 되는 것이다. 위에서 "자기 개발 서적"을 예로 든 내용과 거의 유사한 흐름이다.


정말 문제를 해결하고 싶다면, 원인을 "자기 탓"으로 돌려야 한다. 즉 "내가 왜 저런 정치인에게 표를 줬을까?" 혹은 "왜 저 정치인에 표를 준 많은 사람들 중 한명이라도 더 설득하지 못했던가?" 등의 방식으로...


정치에 대한 불만을 표출하는 글과 말들이, 정치인을 주어로 하지 않고, 자기 자신을 주어로 하는 식으로 변해갈 때, 비로소 우리는 "변화"를 이야기 할 수 있지 않을까?...

Trackback 0 : Comment 0

[Shell] Variable Name Expansion

Domain/Linux 2013/03/28 16:53


Variable operator

Action 

Description 

${varname}

Nonambiguous variable substitution 

Simple variable substitution occurs with the value of varname being substituted

${varname:=value}

Assign a default value for the variable if a value does not exist.

If varname does not have a value or is set to null, then varname is set to value.

Varname is then substituted in the statement.

${varname:+value} 

Utilize value if varname is set 

If the variable, varname, contains a value and is not null, then the alternate value, value, is substituted instead of the value of the variable varname. Otherwise nothing is substituted.

${varname:-value} 

Assign a temporary default value for a variable if one does not exist 

If the variable, varname, contains a value and is not null, then it is substituted; otherwise the value, value, is substituted but is not assigned to varname. (different from = operator)

${varname:?value} 

Issue an error message if the value of variable is not set to any value. 

If the variable, varname, containsa value and is not null, then it is substituted; otherwise an error message containing the value, value, is printed and the Shell exits.

${#varname}
(Korn and Bash only) 

Return the length of the value contains in varname or the number of positional parameters.

If varname is set, the length of the value of varname is returned. If the special variable * or @ is used as varname then the number of positional parameters are returned. 

${varname#pattern}

${varname##pattern}

(Korn and Bash only) 

Substitue varname with pattern removed from the beginning of varname .

If the pattern matches the begining of varname, then pattern is removed from varname. If the # form is used, then the shortest match is removed. If the ## form is used, then the longest match is replaced. 

${varname%pattern}

${varname%%pattern}

(Korn and Bash only) 

Substitute varname with pattern removed from the end of varname. 

If the pattern matches the end of varname, then pattern is removed from varname. If the % form is used, then the shortest match is removed. If the %% form is used, then the longest match is replaced. 

${#arrayname[*]}
(Korn only) 

Substitute the number of elements in the array. 

The number of elements in the array arrayname is substituted. 


<From : UNIX Shell Programming, FOURTH EDITION, LOWELL JAY ARTHUR, TED BURNS - WILEY COMPUTER PUBLISHING>

Trackback 0 : Comment 0

"Programming skill"의 정의와 거기에서 파생되는 문제점...

Essay/Software 2013/01/21 18:10

Software업계에서 Programming skill 이라는 단어가 많이 사용되고 있는데 비해, 그 정의가 명확하지 않은 것 같다.

아니, 정의가 명확하지 않은게 아니라, 정의를 실체화 하는 방법이 명확치 않다고 해야 하나?


일단 "좋은 코드/소프트웨어"라는 말에 대한 정의는 어느 정도 합의된 실체가 있는 것 같다.

그럼에도 불구하고, 정량적인 측정 기준이 없기 때문에 여전히 관념적인 형태에 머물러 있긴 하지만...

그런데, "좋은 소프트웨어"를 만드는 것 => Programming skill 이 뛰어난 것"이 되지 못하는 이유는 현실적으로, 보통 '시간'으로 대표되는 '비용'이라는 요소가 들어가기 때문이다.

그래서 결국, Programming skill은 "적은 비용으로 좋은 소프트웨어를 만드는 기술"이라고 정의되어 질 수 밖에 없다.


문제는 앞서 이야기한 것처럼, "좋은 소프트웨어"라는 요소는 정량적인 기준이 없고, 측정방법 또한 모호하다. 그렇지만, '비용'은 객관적이고 명확한 측정 방법을 가진다. 그러다보니, 두 요소 중 '비용'이라는 요소에 더 집중하게 되고, 그것을 기준으로 Programming skill 을 말하는 경우가 많다.

그러다 보니, 극단적으로, "적인 비용으로 소프트웨어를 만드는 기술"이 Programming skill 로 왜곡되어 정의되어 버리게 된다.

(이 경우, 소프트웨어의 품질은 전혀 고려 대상이 아니다.)


실제, 계약에서도, 측정할 수 없는 "좋은 소프트웨어"라는 항목을 계약서에 기술할 수 없으므로, "비용"에 초점이 맞추어 질 수 밖에 없게되고, "적은 비용"이라는 기준을 만족시키는 쪽이 "기술력이 있는 곳"이라는 평가를 받게 되는 기이한 현상이 벌어지게 된다.

이는 계약에서 뿐만아니라, 국내 기업의 업무 형태에서도 쉽게 찾아볼 수 있다 - 물론 모든 기업이 그렇다는 이야기는 아니지만, 대부분(특히 소프트웨어가 주 제품이 아닌 곳들)의 경우 해당될 것이다.

소프트웨어를 만드는데, 연봉이 높은 우수 인력을 사용하는 것은 '과다 비용'으로 받아들이고, 경력이 짧은 미숙한 엔지니어에게 일을 맞겨 소위 "돌아가는 소프트웨어"를 만들어 내는 것을 "잘 했다"고 평가한다. 즉, 소프트웨어의 "품질"은 무시되고, "비용"부분만 고려된 "평가"인 것이다.


이와 같은 현상은 계속 반복된다.

위와 같은 방식으로 만든 소프트웨어는 필연적으로 수많은 문제점(버그)를 내포하게 된다. 이제 이 문제점들을 수정해야 하는데, 이 역시 '비용'만을 고려해서, 미숙한 엔지니어가 처리하게 되고, 수많은 fix-on-fix를 양산하는 악순환을 반복한다.

그러면서, "소프트웨어는 당연히 많은 버그를 내포할 수 밖에 없고, 약간의 수정도 많은 문제점을 동반할 수 밖에 없다."라는 이상한 결론을 내려 버린다.


위의 이야기는 좀 극단적인 측면이 있지만, 국내 현실을 상당히 잘 반영한다고 생각한다.

"소프트웨어의 비용 감소"라는 측면에서 시작된 것이 아니라, 순수하게 "소프트웨어 품질의 정량화"라는 측면에서 시작된, 소프트웨어 관련 연구가 활발하게 이루어 졌다는 이야기는 들어 본적이 없다. 물론, 내가 잘못 알고 있는 것일 수도 있지만...

각설하고... 슬프지만... Programming skill에 대한 가장 현실적인 정의는 "적은 비용으로 소프트웨어를 만들어 내는 기술"이라고 할 수 밖에....


주저리 주저리... 문맥도 안맞고... 내용도 정리가 안되어 있고.. 쩝..

Trackback 0 : Comment 0
◀ PREV : [1] : [2] : [3] : [4] : [5] : ... [76] : NEXT ▶