posted by By훈트 2012.02.27 11:35

 출처 - http://www.cyworld.com/gaephlhome2/7832995 


낭비를 제거하라

 - 소프트웨어 개발에서의 가장 큰 낭비 세가지

   : 가외기능 (80%의 가치를 제공하는 20%의 기능에 초점을 맞춰 개발하는 프로세스가 필요하다)

   : 혼란 (요구사항 혼란을 겪는 다면 스펙을 너무 일찍 결정한 것이다. 테스트하고 수정하는데 혼란을

             겪는 다면 테스트를 너무 늦게 하는 것이다.)

   : 경계넘어가기 (조직간의 경계는 통상 25% 이상의 비용을 증가시키는데, 버퍼를 만들고 응답시간을

                         늦푸며 커뮤니케이션을 방해하기 때문이다.)

 

품질을 내재화하라

 - 검증단계에서 늘상 결점이 발견된다면 그 프로세스에 결함이 있는 것이다.

   : 테스트 주도 개발을 통해 코드의 실수를 방지하라. (요구사항 문서 대신 실행 가능한 명세를 작성하라.)

   : 레거시 코드를 만들지 마라. (레거시 코드는 자동화된 단위 테슨트와 인수 테스트가 없는 코드다.)

   : 빅뱅 통합은 진부하다. (지속적 통합과 중첩된 동기화 기법을 사용하라.)

 

지식을 창출하라.

 - 계획은 유용한 것이며, 학습은 필수적인 것이다.

   : 과학적 방법을 사용하라. (가설을 세우고, 신속하게 다양한 실험을 해보고, 문서를 간결하게 작성하고, 최선의

                                        대안을 구현할 수 있도록 답을 가르쳐라.)

   : 표준은 도전받고 개선되기 위해 존재한다. (모든 사람들이 따라하고 잘 알려진 실천법을 표준에 포함하되,

                                                               누구든지 표준에 도전하고 변경하도록 장려한다. )

   : 예측 가능한 성과는 피드백에 기반한다. (예측 가능한 조직은 미래를 추측하고 그것을 계획이라고 하지 않으며,

                                                         그 보다는 미래가 펼쳐질 때 신속하게 대응하기 위한 역량을 개발한다.)

 

확정을 늦춰라

 - 완벽한 명세서를 가지고 개발을 시작하는 것이 좋은 아이디어라는 생각을 버려라

   : 의존성을 깨뜨려라 (시스템 아키텍처는 언제 어떤 기능이 추가 되더라도 그것을 수용할 수 있어야 한다.

   : 옵션을 유지하라 (코드를 실험으로 생각하라. 변화를 수용 할 수 있게 작성하라.)

   : 돌이킬 수 없는 결정은 마지막 결정의 순간에 하라. (돌이키 ㄹ수 없는 결정을 내리기 전에 가능한 많이 학습)

 

빨리 인도하라.

 -  리스트와 대리열은 일의 속도를 늦추는 조직간의 버퍼다.

   : 신속한 인도, 고 품질, 저 비용은 공존할 수 있다. (속도의 경쟁에서 승리하는 회사는 큰 비용우위를 갖고

                                                                     월등한 품질의 제품을 인도하며 고객의 요구에 더 귀기울인다.)

   : 대기행렬이론을 개발에 적용하라. (가동률을 강조하면 오히려 정체를 일으켜 가동률이 떨어진다.

                                                    배치 크기를 작게하고 진행중인 작업량을 줄여 주기시간을 줄여라)

   : 일의 양을 할 수 있는 만큼으로 제한하라. (반복 개발에 안정적이고 반복가능한 속도를 가져라.

                                                고객에게 인도할 수 있는 역량에 맞게 대기열의 길이를 정지적으로 제한하라.)

 

사람을 존중하라.

 - 주도적으로 참여하고 연구하는 사람들이 최고의 지속가능한 경쟁 우위를 제공한다.

   : 팀은 자부심, 책임감, 신뢰, 칭찬을 통해 번성한다.

                           (무엇이 팀을 만드는가? 팀원들은 공동 목표를 달성하기 위해 상호간 책임의식으로 뭉쳐있다.)

   : 효과적인 리더쉽을 제공하라. (효과적인 팀에는 팀을 최고로 이끄는 훌륭한 리더가 존재한다.)

   : 파트너를 존중하라. (조인트 벤처를 위한 헌신은 절대로 이해상ㄹ반을 만들지 않는다.)

 

전체를 최적화하라.

 - 빼어난 제품은 기회와 기술의 특별한 만남에서 나온다.

   : 전체 가치 흐름에 초점을 맞춰라. (컨셉에서 현금까지, 고객요구에서 소프트웨어 배포까지)

   : 완전한 제품을 인도하라. (소프트웨어만이 아닌 완전한 제품을 개발하라.

                                        완전한 제품은 완전한 팀에 의해 만들어 진다.)

   : 더 높은 것을 측정하라. (주기시간으로 프로세스 역량을 측적하라. 인도된 비즈니스 가치로 팀 성능을

                                      측정하라. 순추천고객지수<NPS>로 고객만족을 측정하라.)

Ps. 린소프트웨어 개발의 적용 이라는 도서에 대한 요점이다. 요즘 정체기인 나에게 자극이 될수 있을거같다.

* 관련도서

1. 린 소프트웨어 개발의 적용
2. 린 소프트웨어 개발



 

'Daily > 훈트의일상' 카테고리의 다른 글

린소프트웨어 개발 방법론  (3) 2012.02.27
나이키 신발 사이즈  (0) 2011.03.11
Dr.Dre 헤드폰  (0) 2010.12.28
와우 방문자 1만찍었...ㄷㄷㄷ  (1) 2010.11.19
토탈 5000 뿌 ㅎㅎㅎ  (0) 2010.10.02
Total 1004 기념~~  (0) 2010.08.18
posted by By훈트 2011.08.22 16:38

ASP.NET 으로 웹사이트 구축시
일반적으로 연결스트링등의 주요 변수들은 web.config 에 입력하여 사용을 한다.

그런데 web.config 파일은 보통 암호화가 되어 있지않기 때문에 누군가가 마음만 먹고 web.config 파일을
가져간다면 DB의 사용자ID, 암호, 해당IP 등의 주요정보를 가로채서 해킹시도를 할 우려가 있다.

MS에서는 이러한 web.config 에 대해 편리한 방식으로 암호화를 시켜주는 기능을 제공하고 있다.

아래의 명령어를 프롬프트창(실행에서 cmd 하면 나오는 도스창)에서 실행시켜준다
aspnet_regiis 파일을 찾을 수 없다고 나온다면

C:\windows\Microsoft.NET\Framework\v2.0.50727   로 이동한 후 아래명령을 실행해 준다.

<암호화>
aspnet_regiis -pef "connectionStrings"  [web.config가 있는 디렉토리 예) d:\MyHome]
aspnet_regiis -pef "system.web/machineKey" [web.config가 있는 디렉토리 예) d:\MyHome]


<복호화>
aspnet_regiis -pdf "connectionStrings"  [web.config가 있는 디렉토리 예) d:\MyHome]
aspnet_regiis -pdf "system.web/machineKey" [web.config가 있는 디렉토리 예) d:\MyHome]

암호화는 해당 컴퓨터의 OS에 활당되어져 있는 머신키(Machine Key) 에 의해 RSA 방식으로 생성이 된다. 그러므로 다른 컴퓨터에서는 복호화가 불가능하다. 단, 머신키에 의해 암호화 되어있는 만큼 똑같은 머신키를 복제하여 복호화 하고자 하는 컴퓨터에서 암호키를 입력해주고 복호화를 해주면 원상태의 값으로 돌아가게 된다.

덧)
나의 경우 
'RsaProtectedConfigurationProvider' 공급자를 사용하여 'connectionStrings' 섹션을 암호화하지 못했습니다. 공급자의 오류메시지 : 개체가 이미 있습니다.

와 같은 오류메시지를 받고 한참을 헤맨적이 있다. 이런 현상은 윈도7 등의 보안이 강화된 O/S 에서 나타나는듯하다(아직 더 확인된 바는 없다. 내가 지금 쓰고 있는데 윈7이라 그렇게 추측..)
이 때 cmd, 도스명령어창을 관리자권한으로 실행한 후 위의 암호화 명령을 입력하면 암호화가 성공했다는 아주 흐뭇한 메세지를 볼 수 있을 것이다,.


 


[출처] http://azbdc.tistory.com/288

posted by By훈트 2011.07.04 18:16

지금 twitpic4j api를 이용해서 트위터에 사진을 올리는 부분을 디버깅중인데


겔러리에서 사진을 선택해서 올릴때 사진에 따라 OutOfMemoryError를 내며 죽는 현상이 나타났다.


모든 그림이 그런건 아니고 특정 그림만 올릴려고 하면 에러가 났다.


그림이 커봐야 고작 몇메가인데 그것땜에 에러나나 하고 용량을 확인한결과


에러나는 사진은 1.2메가 정도의 크기

 (한계점이 어느정도인지는 모르겠다)


그리고 인터넷을 검색한결과 안드로이드에도 메모리 누수 버그가 있다는 흥미로운 사실과

http://android-developers.blogspot.com/2009/01/avoiding-memory-leaks.html


나말고도 이런일을 겪오 있는 사람이 또 있다는 사실을 알았따.

http://www.androidpub.com/8933


여튼 용량이 큰 이미지를 처리하려고 할때 에러가 발생 할 수 있다는 사실...


정확한 에러발생 위치는 아직 모르겠다. TwitPic4j 의 upload메소드에서 발생하는 에러이다.



대처법으로 클래스 맴버인 Bitmap 객체에 static을 붙여보라는 말도 있었지만 소용 없는듯...


그런데 문제는 공직 트위터 어플을 이용해서 사진을 올리면 잘올라간다는것이다 -_-


그렇다고 사진의 화질이 줄어들거나 그러지도 않는다. 아 어쩌면 좋지




-----

검색하다 얻은 글이다.

http://www.androidpub.com/31659

각 어플당 힙영역을 2.8메가 이하로 밖에 사용을 못하고 그이상을 사용하려고하면

OutOfMemoryError가 난다고한다. 결국 큰 이미지로 이런저런 처리를 하는 과정에서 힙영역을 많이 사용하게 된 탓인것같다. Bitmap을 byte배열로 변환하는작업이 그런것같다.


위 글에선 해결책으로 BitmapFactory.Option 클래스를 이용해서 그림파일을 메모리에 올리지 않고 너비와 높이를 구한뒤

너무 큰 그림이라고 판단되면 그림을 줄여서 OutOfMemoryError을 피하는 방법을 소개하고 있다.


BitmapFactory.Options options = new BitmapFactory.Options();
18.options.inJustDecodeBounds = true;
19.BitmapFactory.decodeFile(fileName, options);
20. 
21.return options.outHeight;


힙영역에서의 메모리 제한이기때문에 위에서 언급했던것처럼 Bitmap 변수를 static으로 하는 해결책도 틀리진 않는것같다. 다만 나의경우 Bitmap 도 그렇지만 Bitmap을 처리하는 byte

array가 있었고  (array 는 new을 해야해서 힙영역에 밖에 선언을 못할것같다.) TwitPic4J api에서 자체적으로 그림을 업로드하기위해 또 뭔가 사용하는게 있어서 용량을 초과한것 같다.


그리고 아래 주소는 Bitmap크기를 줄이는 방법과 관련된 내용이 잘설명된 포스팅 이다.

http://chiyo85.tistory.com/entry/Android-Bitmap-Object-Resizing-Tip


 
[출처] 카페인님의 블로그