출처: http://blog.naver.com/hursh1225/40192159662


C:\Windows\System32\libcurl.dll 파일을 삭제

저작자 표시 비영리 동일 조건 변경 허락
신고


  회사 생활을 하다 보면 평소 일하던 방식이 급격히 변경될 때가 있다. 조직 개편으로 인해 다른 조직으로 발령이 나거나 새로운 업무 방식이 도입될 때가 그렇다. 이때 역시 변화에 대처하는 방법에 썼던 '회피자형', '얼리어답터형', '추종자형'이 나타난다. 자신에게 변화가 찾아올 때 '얼리어답터'는 아니더라도 '회피자'는 되지 말자고 했었다.


빠른 적응력이 요구된다.


  하지만 이렇게 급격한 변화가 일어날 때에는 이야기가 다르다. 적응할지 말지 재는 행동이 오히려 독이 된다. 이 업무방식은 내게 안 맞아. 도대체 위에서는 왜 이런 결정을 내리는 거지? 보나 마나 6개월 정도 있으면 또 바뀔 거야. 이런 부정적인 생각을 빨리 버리는 게 좋다. 일은 이미 벌어졌다. 자신이 그 변화를 원래대로 바꿀 수 없는 위치에 있다면 빨리 적응하는 편이 낫다. 변화에 적응하지 않으면 도태된다. 인류가 30만년동안 진화해 오면서 살아남기 위해 환경에 적응했던 유전자가 꿈틀대게 해야 한다. 길을 가는 데 갑자기 튀어나온 사자로부터 목숨을 건지기 위해서는 발바닥에 땀나게 뛰거나 가지고 있는 무기를 냅다 휘둘러야 한다.



이 업무가 내게 맞는 것일까?


  내 아이의 미래를 위해 적성에 맞는 일을 찾아주려고 한다고 하자. 처음에는 아이의 적성이 어떤지 재능은 있는 지 알 수가 없다. 이를 찾기 위해서는 아이에게  많은 경험을 하도록 해야 한다. 하지만 그 아이가 적어도 어떤 일에 재능이 있고 재미있어 하는 지를 판단을 하기 위해서는 시간이 필요하다. 몇 달 동안은 그 일에 최선을 다 해 보라고 격려하고 필요하면 푸시를 가해야 한다고 본다. 모든 일이 그렇겠지만 기초가 항상 중요하고, 기초는 지루하고 반복적인 작업이 많다. 축구를 잘 하기 위해서는 체력을 기르고 달리기와 민첩성을 기르는 훈련을 반복해야 하고, 피아노를 잘 치기 위해서는 기본 음계의 건반을 두드리는 일을 반복해야 한다. 이 일이 익숙해지면 이를 당연하게 여기고 운동 전 스트레칭을 하는 것처럼 받아들이게 된다. 이런 자기 검증화 과정이 필요하다. 적성에 맞고 재능까지 겸비되었는 지를 아는 방법은 의외로 단순하다. 일단 최선을 다해 부딫혀 보는 이다. 그 후의 평가가 좋지 않다면 깨끗하게 포기하고 다른 것을 찾아보는 게 낫다.


  새로운 업무도 마찬가지다. 처음에는 익숙하지 않아 업무 진행이 더디다. 다른 방식으로 일하는 것이 자기 몸에 맞지 않는 옷을 입은 것처럼 어색할 지도 모른다. 하지만 그 방법이 자신에게, 자신의 조직에 맞는 방법인지는 먼저 최선을 다해 수행해 보고 평가할 일이다. 이렇게 반박할 수도 있다. 그렇게 실패할 게 뻔한데 뭣 하러 처음부터 시도하나. 시간 낭비일 뿐이다. 맞는 말이다. 그러면 실패할 지 성공할 지는 어떻게 알 수 있나? 직접경험을 할 수는 없으니 책이나 논문 또는 성공한 사례를 통해 간접경험을 얻을 수 있다. 경영진이나 파트 리더는 이런 간접경험을 이미 거쳤을 가능성이 99.99%다. 실패 가능성을 줄이기 위해 당연한 절차다.  물론 팀원의 의견을 무시해서는 안 된다. 다만 팀원이 자신의 견해와 다르다고 리더의 의견을 무시해서는 안 된다고 생각한다. 적어도 최선을 다해 몇 차례 수행해 보고 피드백을 주어서 방향을 수정해 나가는 것이 좋다. 이게 민주적이라고 생각되지 않나? 처음부터 팀원의 의견을 반영해서 결정하면 좋겠지만 조직원의 모든 의견을 수렴하기에는 너무 오랜 시간이 걸린다. 이것이 리더와 정치가 존재하는 이유다. 리더의 의견을 따르고 그 의견을 평가해서 수정, 보완하는 것이 조금씩 좋은 방향으로 갈 수 있는 가장 빠른 길이다.

저작자 표시 비영리 변경 금지
신고


Project Euler에 있는 재미있는 문제를 하나 풀었습니다.

6번째 문제로 제목은 Sum square difference 입니다.


The sum of the squares of the first ten natural numbers is,


12 + 22 + ... + 102 = 385

The square of the sum of the first ten natural numbers is,


(1 + 2 + ... + 10)2 = 552 = 3025

Hence the difference between the sum of the squares of the first ten natural numbers and the square of the sum is 3025  385 = 2640.


Find the difference between the sum of the squares of the first one hundred natural numbers and the square of the sum.


1부터 100까지 각 숫자의 제곱의 합에서 1부터 100까지 더한 수의 제곱을 빼면 얼마인지 묻는 문제입니다.


일단 무식하게 for문을 돌려서 각 제곱의 합을 구하고, 

또한 매 루프마다 더한 sum을 제곱하면 될 것 같습니다.

하지만 100까지가 아니라 더 큰 수까지의 값을 구하라고 하면 integer의 범위를 넘어가 버리기 때문에 다른 방법이 필요합니다.

그리고 알고리즘 문제니까 뭔가 속도도 빠르게 할 수 있는 방법이 있을 것입니다.


저는 이렇게 풀어 보았습니다.


(a+b) = a2 + b2 + 2ab 이므로, 


이렇게 됩니다.


각 숫자의 제곱 부분을 좌항으로 옮기면 남는 부분이 결국 우리가 구하고자 하는 값입니다.



각 부분에 포함된 2를 앞으로 묶어 내면 뭔가 규칙이 생기네요.

n=3 일 때는 2번의 덧셈, n=4일 때는 3번의 덧셈이 됩니다.

즉 n-1번 loop를 돌리면 될 것 같습니다.

그리고 각 항에서 곱셈으로 연결된 좌측 숫자는 n-1에서 1까지 작아지고,

우측 숫자는 (좌측 숫자+1)부터 n까지 더한 값입니다.


이를 구현하면 이렇게 됩니다.

public int sumSquareDifference(int n) { if (n < 1) { return -1; }

int sum = 0; for (int i = n - 1; i > 0; i--) { int _sum = 0; for (int j = i + 1; j <= n; j++) { _sum += j; }

sum += 2 * (i * _sum); } return sum; }

정답!!


하지만 이 알고리즘의 성능은 O(n2)으로 그다지 좋지 않습니다.

Project Euler에서 제시한 정답은 단 3줄의 코딩으로 끝납니다.

성능은 O(1)입니다. loop를 쓰지도 않았다는 말입니다.


여러분도 정답을 보기 전에 다른 방법으로 한 번 풀어보시길 바랍니다. 풀이를 보면 아하! 하고 느끼실 수 있을 겁니다.


평소 문제를 접할 때에도 바로 컴퓨터 앞에서 키보드를 두들기기 전에 좀더 간단한 문제로 바꿀 수 있는 방법을 고민해 보세요.

만약 성공한다면 메모리와 수행 시간을 획기적으로 줄일 수 있을 겁니다.

저작자 표시 비영리 동일 조건 변경 허락
신고

테스트 하려는 APK를 일일이 설치하는 것도 일이다.

batch파일로 만들어서 한 방에 설치하자.


dir/d/b/a:-d > list.txt

FOR /F %%i IN (list.txt) DO (adb install %%i)


dir/d/b/a:-d > list.txt ==> 현재 폴더에 있는 파일 목록을 만든다.

FOR /F %%i IN (list.txt) DO (adb install %%i) ==> 목록을 읽어서 설치한다.


list.txt를 만들지 않고 설치하려면,

FOR %%f IN (*.apk) do adb install -rf %%f



저작자 표시 비영리 동일 조건 변경 허락
신고


  SW 개발 과정에는 수많은 테스트 절차가 있다. 회사마다 실시하는 종류는 다르겠지만 위키피디아에 기록된 것만 해도 무려 16가지나 된다.[각주:1] 요즘 읽고 있는 책에 테스트에 관한 흥미로운 견해가 있어 본문을 옮겨 본다.


  테스트를 많이 할수록 품질이 좋아진다고 생각하는 사람도 있다. 정말 그랬으면 좋겠지만, 안타깝게도 그렇지가 않다. 테스트하면 결함을 찾는 데 도움이 되긴 하지만 코드 여기저기 숨어있는 결함을 테스트만으로 찾아내는 건 불가능하다. 아무리 열심히 테스트해도 상당수의 결함이 잡히지 않고 남아있을 것이고, 여기서부터 불편한 진실이 나타나기 시작한다. 테스트에서 기존 결함 중 특정 비율(예를 들어 65%)만큼을 찾아낸다고 해 보자. 그러면 테스트를 통해 찾아낸 결함이 많아질수록 찾아내지 못한 결함도 많아지리라고 예상할 수 있다. 테스트에서 결함이 많이 발견되면 실제 출시된 제품에 있는 결함 개수가 줄어드는 게 아니라 늘어나는 것이다. 직관적으로 보면 말이 안된다는 생각이 들 수도 있는데, 테스트 과정이 버그를 다 잡아내기 위한 절차라기보다는 품질을 측정하기 위한 통계적인 방법이라고 보면 이해가 될 것이다. 이런 이유 때문에 소프트웨어 공학 분야에서는 기능 테스트와 시스템 테스트를 각각 "기능 검증 테스트", "시스템 검증 테스트"라고 부른다. 소프트웨어 공학을 과학적으로 공부해 온 사람은 테스트 작업이 문제를 고치기 위한 작업이라기보다는 검증 절차에 가까운 것으로 봐야 한다는 인식이 자리 잡았기 때문이다. (..중략..) 안타깝게도 아직은 아무도 버그가 없는 소프트웨어를 개발하는 방법을 발견하지 못했다. 테스트를 통해 모든 버그를 찾을 수는 없기에, 테스트만을 통해서 최고 품질의 코드를 만들어내는 것은 불가능하다. 많은 회사에서 그런 시도를 했지만 모두 실패로 돌아가고 말았다. 역사적으로 보면, 코드 품질을 개선하고 버그를 없애는 데 있어서 가장 좋은 방법은 코드 검토다. 최고 품질의 코드를 개발하기 위해서는 설계 및 명세서, 코드 검토, 형식적인 인라인 (런타임) 확인 테스트, 측정 코드(Instrumented Code), 철저한 테스트 중 어느 하나도 소홀히 해서는 안 된다.

- 프로그래머로 사는 법, 한빛미디어, p324


  결론은 버그는 다음 그림과 같이 개발 후반부로 늘어나는 수정하는 비용이 늘어나기 때문에 초반에 잡으라는 말이다.



  위 그림은 SW를 업으로 삼는 사람이라면 책이나 교육을 통해 몇 번은 보았을 것이다.[각주:2] 물론 폭포수 모델을 가정하고 있기는 하지만 개발 방법론이 무엇이 됐든 프로젝트 후반부로 갈수록 버그 수정 비용이 늘어난다는 점이다. 하지만 현실에서는 잘 지켜지지 않는다. 당장 눈앞에 구현해야 할 기능과 지난번에 만들어 둔 버그들이 쌓여 있기 때문이다. 시간이 항상 부족하기 때문에 본인이 작성한 코드를 대충 테스트하고 검증 부서에 넘겨 버리기 일쑤다. 악순환이다. 더 문제는 이게 반복되면 '기능 완료'의 정의가 기본기능만 돌아가지만 벌레가 스멀스멀 기어 다니는 상태로 받아들여진다는 것이다.


  많은 코드를 작성하고 버그는 있지만 기능은 완료시킨 것이 성과의 지표가 되는 문화도 이런 엉성한 SW가 만들어 지는 데에 한 몫 한다. 버그 트래킹 시스템에 올라와 있는 버그를 많이 수정한 사람이 일을 잘한다고 여기기도 한다. 물론 그 사람이 수정한 이슈가 다른 사람이 만든 버그를 잡았다면 훌륭한 일이다. 그런데 자기가 버그를 왕창 만들어 낸 장본인이라면? 그 사람은 일을 잘 하는 사람인가, 그렇지 않은 사람인가? 관리자는 지표로 나타나는 분석 내용을 좋아하기 마련이지만 버그 수정 개수만을 가지고 성과를 판단하는 오류는 범하지 말아야 한다.


  습관은 반복적인 행동으로 이루어진다. 나쁜 습관도 마찬가지다. 아직 나쁜 습관에 물들지 않았다면 좋은 습관을 가지도록 노력하자. 코드리뷰를 귀찮게 여기지 말고 개발과정의 필수과정으로 인정하는 문화가 정립돼야 한다. 테스트 코드의 커버리지가 70%밖에 되지 않는다면 나머지 30% 부분은 직접 실행해 보아야 할 것 이다. 당신이 관리자라면 기능 완료의 정의를 돌아가는 SW가 아니라 완성도 높은 SW로 받아들여야 한다. 


  테스트는 검증부서만의 몫이 아니다. 검증부서는 현재 SW의 상태를 "검증"한다는 것을 다시 한 번 명심하자.



  1. https://en.wikipedia.org/wiki/Software_testing [본문으로]
  2. 그린 코드 구현 전략 - 정적 프로그램 분석, http://www.imaso.co.kr/?doc=bbs/gnuboard.php&bo_table=article&wr_id=33321 [본문으로]
저작자 표시 비영리 동일 조건 변경 허락
신고

티스토리 툴바