Search Results for 'Development'


47 posts related to 'Development'

  1. 2016/09/29 넘이 만든 정보 -개발에 완전 도움이 되는 웹사이트와 도구들
  2. 2016/08/01 [펌]jQuery로 체크박스(checkbox) 제어(control) 하기
  3. 2016/02/11 MS-SQL-좀비 프로세스 해결방법
  4. 2015/08/01 if / else 문을 한줄로 간단히 표현
  5. 2015/04/30 나쁜 프로그래머가 되는 18가지 방법
  6. 2014/02/20 개발자에게 야근은 미친 짓이다
  7. 2013/07/15 스트레스
  8. 2012/12/26 [펌]개발자, 회사의 과거인가 미래인가
  9. 2010/11/17 페북 API
  10. 2010/08/25 ASP 트로이잔 Webshell의 예방 및 문제해결방법
<< Previous Page 1 2 3 4 5 Next Page >>

넘이 만든 정보 -개발에 완전 도움이 되는 웹사이트와 도구들

Development/기술관련 |  2016/09/29 09:49


정규표현식


개발문서


위지윅 개발도구

네트워크


라이센스


개발기획도구



프로젝트 관리 & 코드 공유

코드 테스트 & 공유 도구


웹기반의 IDE && 클라우드 통합


개발관련 북마크


모조텍스트 생성도구



개발자 블로그 & 미디어

  

퍼포먼스 튜닝


그래픽


UI KIT


쉘

서버 보안 점검


HTML & CSS

  • http://css3maker.com/ - CSS3 코드를 생성해주는 웹사이트
  • http://d2.naver.com/news/3552619 - html,css 기초 개념 잘 정리되어 있는 곳
  • https://modernizr.com/ - 브라우저 지원 여부 확인 하는 곳

전자공학


코딩 및 컴퓨터 사이언스 공부 할 수 있는곳


개발자 채용 사이트


기타


인터뷰 준비


 출처: 생활코딩, 그동안 모아둔 사이트,계속 업데이트 중인 사이트

http://mojosoeun.tistory.com/79


2016/09/29 09:49 2016/09/29 09:49
No trackbacks, No comments.

[펌]jQuery로 체크박스(checkbox) 제어(control) 하기

Development/JScript |  2016/08/01 16:44

jQuery checkbox 컨트롤


1. checkbox checked 여부 :

id인 경우 : $('input:checkbox[id="checkbox_id"]').is(":checked") == true

name인 경우 : $('input:checkbox[name="checkbox_name"]').is(":checked") ==  true

 

=>  $('input[id="checkbox_id"]') + 옵션 형태로 작성 해도 문제는 없다

Ex) $('input[name="checkbox_name"]').is(":checked")


2. checkbox 전체 갯수 : $('input:checkbox[name="checkbox_name"]').length

3. checkbox 선택된 갯수 : $('input:checkbox[name="checkbox_name"]:checked').length

* 2,3번은 name 인 경우에만 가능

 

4. checkbox 전체 순회 하며 처리(동일한 name으로 여래개인 경우 전체를 컨트롤 할 수 있다.)

 $('input:checkbox[name="checkbox_name"]').each(function() {

      this.checked = true; //checked 처리

      if(this.checked){//checked 처리된 항목의 값

            alert(this.value);

      }

 });


5. checkbox 전체 순회 하며 값을 값을 비교하여 checked 처리

 $('input:checkbox[name="checkbox_name"]').each(function() {

     if(this.value == "비교값"){ //값 비교

            this.checked = true; //checked 처리

      }

 });


* 동일한 name 으로 1개 or 여러개 있을 경우에는 같은 name 으로 된 모든 checkbox 가 checked 처리된다.


6. checkbox value 값 가져오기 :  $('input:checkbox[id="checkbox_id"]').val(); //단일건

7. checkbox checked 처리 하기 : $('input:checkbox[id="checkbox_id"]').attr("checked", true); //단일건

8. checkbox checked 여부 간단 확인: $("#checkbox_id"]').is(":checked"); //단일건

 

=== Reference ===

* 만약 해당 id, name이 존재하지 않더라도 javascript 에러가 발생하지 않는다.



출처: http://openlife.tistory.com/381 [물고기 많은 바다]





2016/08/01 16:44 2016/08/01 16:44
No trackbacks, No comments.

MS-SQL-좀비 프로세스 해결방법

Development/MS-SQL |  2016/02/11 09:57
스케줄 도는 프로시저를 맹글다가 버그가 있는 바람에 스케줄 도는거 실패나고.. ;; 해당 프로세스 찾아서 kill로 죽여도 죽지 않는 좀비 프로세스가 돼 버린 경우!!!

 순서

   1. sp_who와 sp_lock를 사용해 lock이 걸려있는 프로세스를 찾고

  2. sp_inputbuffer(spid) 를 이용해 해당 쿼리가 뭔지도 확인해보는 센스...

  3. 그러구 죽일 만한 놈들은 죽여버린다. kill spid with statusonly (요건 프로세스 상태 보는거)


 데드락이 자꾸 걸리거나 하는 경우 안생기게 하는게 최선이겠지만, 일단 벌어진 상태라믄... 급한 김에

  select @@lock_timeout 으로 lock 해제 timeout값이 어떻게 설정되어 있는지 확인한 담에

  set lock_timeout [time_period] 값으로 자동 롤백 타임아웃 값을 설정해준다..

  이렇게 해서 해결을 했는데..

 잘못해서 "트랜잭션 롤백이 진행 중입니다. 예상 롤백 완료율은 100%, 남은 시간은 0초입니다." 요딴 식으로 메세지가 자꾸 나오고 해당 프로세스도 삭제가 안되는 경우가 MS 에서 얘기한 좀비 버그가 된 것이다..

 요럴 때는 먼저 관리도구 -->  구성요소 서비스 --> 분산트랜잭션 코디네이터 --> 트랜잭션 목록에서 안지워졌던 프로세스들이 있는지 확인하고.. (얘네들이 좀비..)

  서비스에서 Distributed Transaction Coordinator 서비스를 재시작~

  일케하믄 SQL 서비스 재시작 안하고 해결 가능~

출처 : http://www.econote.co.kr/main/view_post.asp?post_seq_no=43381


2016/02/11 09:57 2016/02/11 09:57
No trackbacks, No comments.

if / else 문을 한줄로 간단히 표현

Development/기술관련 |  2015/08/01 13:14
f / else 문의 사용에서 각 조건에 대하여 처리하는 연산이 하나(또는 한줄) 인 경우, 이를 간단히 표현할 수 있다.

?
1
2
3
4
5
6
int v = 30, x;
 
if (v > 30)
    x = 100;
else
    x = 0;


위의 if / else 문을 한줄로,

?
1
x = (v > 30) ? 100 : 0;


코드가 길어지는 것이 싫을 때, 사용하면 좋지 아니할까?
2015/08/01 13:14 2015/08/01 13:14
No trackbacks, No comments.

나쁜 프로그래머가 되는 18가지 방법

Development |  2015/04/30 09:48
소프트웨어 개발자는 끊임없이 변화하면서 성장한다.
스스로 길을 잘 찾아서 성장하는 경우도 있고, 좋은 환경에서 개발을 하다 보니 자연스럽게 실력이 향상되기도 한다. 하지만 열악한 환경에서 열심히 일만하다가 개발자로서의 실력은 점점 잃어가는 경우도 있다.
아무리 사회가 어떻고, 회사가 열악하다고 불평을 해봤자 남는 것은 자신의 개발자로서의 실력밖에 없다.
이번 글에서 나쁜 프로그래머가되는 18가지 방법을소개한다. 물론 본의 아니게 주변의 환경이 나를 이렇게내모는 경우도 있지만 이를 반대로 해보는 노력을 해보자.
내가 대단한 사람이라서 이런 얘기를 하는 것은 결코 아니다.
나도 독자들과 똑같은 개발자로서 18가지 중에서 잘 안되는 항목도 있다. 단지 20년 넘게 개발을 하면서 느끼는 바를 공유하고자 함이다.
 1. 익숙한 기술만 고집한다 대부분의 사람들은 변화를 싫어한다.
익숙한 것을 사용할 때 업무의 효율도 높다. 하지만 지식노동자인 개발자는 익숙한 기술만 고집한다면 한계에 다다른다. 물론 환경이 그렇게 만들기도 하고, 다른 분야의 기술을 익힐 만한 시간과 여유가 없는 경우도 많다. 그러다 보면 새로운 기술이 필요한 상황에서도 익숙한 기술을 고집하는 고집쟁이가 되기도한다.
 2. 공유를위해 노력하지 않는다 현재 내가 하고 있는 일은 나만 안다.
내가 퇴사하면 당장 이 일은 마비된다. 지금은 내가 하는 일에 다들 관심들이 별로 없지만 내가 없는 빈자리는 매우 클 것이다. 내 업무에 관련된 지식의 90%는 내 머리속에 있다. 주변의 다른 개발자들도 비슷한 상황인데 굳이 내가 깃발들고 공유를 위해 나설 필요가 있을까?
 3. 후배에게 시키지 않고 직접 처리하는 것이 속편하다 후배들이 많이 있지만 실력도 부족하고 일을 시키면 답답하다. 내가 하면 한시간이면 할 수 있는 일을 신입사원을 시키면 하루종일해도 못끝낼 뿐만 아니라 신입사원이 해놓은 것을 검토하고 고치고 가르치는데 몇시간이 소모된다. 그러니 차라리 내가 빨리 끝내버리는 것이 낫다. 그래서 우리 회사는 신입 개발자보다 고참 개발자가 훨씬 바쁘다.
 4. 후배나 동료들이 작성한 소스코드를 봐주지 않는다 회사에서 코드리뷰를 하라고는 하는데, 내 할 일이 바빠서 다른 사람 코드를 봐줄 시간이 없다. 나 뿐만 아니라 다들 이런 상황이다 보니 코드리뷰는 유야무야되었다. 과거에도 코드리뷰를 몇번해 봤지만 바쁜 와중에 잠깐시간내서 봐주기는 했는데 제대로 봐주지도 못했다. 그냥 코딩 스타일을 가지고 트집을 잡는 정도다. 그러다보니 이제 코드리뷰는 모두들 꺼려 한다.
 5. 남이 내 코드를 보는 것을 꺼려 한다 리뷰가 활성화된 조직에서는 지위고하를 막론하고 소스코드를 리뷰한다. 고참의 소스코드를 신입사원이 리뷰하고 지적할 수도 있다. 이런 거북함이 싫고, 귀찮고, 바쁘다. 내가 작성한 코드는 충분히 정상동작하는데굳이 다른 사람이 내 코드를 보고 지적을할 필요가 있을까? 개발할 시간도 부족하다.
 6. 문서화를 꺼려한다 문서작성은 무조건 싫다. 귀찮기도하고 잘 작성하지도 못한다. 하지만 회사에서 꼭 문서를 만들고 개발을 하라고는 한다. 그러면서 개발시간은 턱없이 부족하게 준다. 그래서 문서는 개발 다 끝나고 형식적으로 문서를 만든다. 한달동안 개발하고 나면 문서는 하룻밤 세워서 대충 문서를 만든다. 물론 이렇게 만든 문서를 나중에는 보지도 않는다.
 7. 커뮤니케이션 스킬 향상에 관심이 없다 개발자는 프로그래밍을 잘하면 되지 커뮤니케이션 스킬은 별로 중요하지 않다고 생각한다. 개발자가 아닌 다른 사람들은 기술에 대해 잘 이해하지 못해서 기술에 대한 대화를 하기가 어렵다. 설명을 해도 잘 이해 하지 못한다. 난 컴퓨터와의 커뮤니케이션은 잘 되는 것 같다.
 8. 책임지고 자신의 일을 마무리하지 않는다. 벌려만 놓는다 나는 개발을 엄청나게 빠르게 한다. 남들이 일주일 걸려서 하는 일도 나는 하루, 이틀이면 해치운다. 대신 완성도는 좀 떨어진다. 동작하도록 만드는 것은 나의 일이지만 귀찮은 버그를 잡는 일은 후배들을 시킨다.나는 새로운 일을 좋아하지 버그 잡는 것은 싫다.
 9. 소스코드가 주석 하나 없이 깨끗하다 항상 주석 같이 읽기 쉬운 소스코드를 주장하면 주석 하나 없이 깨끗하게 코딩을 한다. 하지만 후배들은 주석이 없으면 이해하기 어렵다고 불평이다. 하지만 프로젝트 일정이 항상 너무 촉박해서 소스코드에 주석을적을 시간이 없다.
 10. 소스코드가 읽기 난해하다 내 소스코드는 정상동작하지만 읽기는 어렵다. 워낙 바빠서 소스코드를 읽기 쉽게 정리할 수가 없다. 한 파일이 너무 크기도 하고 함수 이름도 난해하다. 내 소스코드는 최적화가 많이 되어서 짧은 코드로 어려운 로직을 기가 막히게 처리한다. 내 소스코드를 분석해 본 사람은 감탄을 할 것이다.
 11. 낮에는 집중해서 일하지 않고 주로 밤에만 일한다 회사가 낮에는 집중해서 개발할 수 없는 환경이다. 회의도 많고 시끄럽다. 그래서 밤에만 일을 하다 보니, 낮에는 여건이 되도 개발이 잘 안 된다. 밤에만 일하는 것이 완전히 습관이 되었다. 밤에 개발하는 것이 썩나쁘지는 않지만 나이를 먹어 갈수록 내 생활이 없어지는 것 같아서 걱정이다.
 12. 소프트웨어 공학에는 관심이 없다 오로지 코딩, 코딩, 코딩만 잘하면 된다. 알고리즘, 알고리즘, 알고리즘은 관심이 많다. 소프트웨어공학이란말은 많이 들어 봤지만 이게 뭔지 설명하라고 하면 애매하다.
 13. 영어는 잘못하지만 공부할 시간은 없다 원래 영어는 잘못했고 당장 영어공부를 따로 하지 않아도 개발을 하는데 큰 문제는 없다. 가끔 인터넷에서개발 관련 검색을 할 때는 주로 한글사이트만 검색한다. 스택오버플로우(Stack overflow)도 영어로 되어 있어서 잘 안 본다. 외국 소프트웨어 회사에 취업을 하고 싶어도 영어 때문에 포기했다.
 14. 기초, 원리는 잘 모르고 응용만 하려고 한다 시스템의 원리나 깊은 지식은 잘 모른다. 필요한 알고리즘이 있어도 원리는 잘 모르지만 인터넷에서 다운받아 그냥 사용하는 데는 큰 지장이 없다. 바빠서 따로 공부할 시간은 없다. 학교 다닐 때 전공수업 공부 열심히 할 걸 그랬다.
 15. 카피&패이스트(Copy & Paste)는 나의 무기 소스코드 복사하는 것이 일상이다. 다른 프로젝트에 비슷한 기능이 있으면 복사해서 사용한다. 공통모듈을만들려면 여러 사람하고 얘기하고 조율을 해야 하는데 시간도 없고 내가 깃발들고 나서기는 싫다. 복사가 훨씬 빠르다. 소스코드를 복사해서 써도 지적하는 사람이 없다.
 16. 수학을 못한다. 관심도 별로 없다 학교다닐 때부터 수학은 관심이 없었다. 잘 하지도 못한다. 소프트웨어를 개발하는데 수학이 왜 필요한가? 코딩만 잘하면 되지. 어려운 알고리즘은 인터넷을 조금만 뒤지면 라이브러리가 다 있다.
 17. 변변한 취미가 하나도 없다 지난번 건강검진에서 의사가 술을 줄이고 운동을 하라고 했지만 매일 야근에 운동은 꿈도 못꾼다. 그나마 가끔 시간이 날 때 친구, 동료들과 술을 마시는 것이 유일한 낙이다. 숙취 때문에 다음날 일은 망친다.
 18. 개발밖에 모른다 회사가 어떻게 돌아가는지 잘모른다. 회사의 전략이나 경영 상황은 잘 모른다. 그런데 관심을 가질 시간이 별로 없다. 나는 회사일 신경 안 쓰고 내가 좋아하는 개발이나 평생하면 좋겠다.

 나는 소프트웨어 개발자는 참 좋은 직업이라고 생각한다.
물론 본인이 일 자체를 즐긴다면 정말 좋다. 말들도 많지만 대우도 그리 나쁘지 않고 성취도도 높다.
하지만 열악한 환경에서 일하는 수많은 개발자들은 그렇게 느끼지 못하고 있다.
물론 좋은 환경에서 일한다면 만족도도 높아지겠지만 개발자가 오랫동안 즐겁게일하는데 제일 중요한 것은 본인 스스로의 실력이다. 나쁜 개발자가 되는 방법을 한가지씩 지워가면서 좋은개발자가 되는 노력을 해보자.

원본 글 : http://www.zdnet.co.kr/column/column_view.asp?artice_id=20150430090928&type=xml
2015/04/30 09:48 2015/04/30 09:48
Tags:
No trackbacks, No comments.

개발자에게 야근은 미친 짓이다

Development |  2014/02/20 18:38

칼럼니스트 : 임백준

이메일

baekjun.lim@gmail.com

약력

한빛미디어에서 『누워서 읽는 퍼즐북』(2010), 『프로그래밍은 상상이다』(2008), 『뉴욕의 프로그래머』(2007), 『소프트웨어산책』(2005), 『나는 프로그래머다』(2004), 『누워서 읽는 알고리즘』(2003), 『행복한 프로그래밍』(2003)을 출간했고, 로드북에서 『프로그래머 그 다음 이야기』(2011)를 출간했다. 삼성SDS, 루슨트 테크놀로지스, 도이치은행, 바클리스은행 등에서 근무했고 현재는 뉴욕에 있는 모건스탠리에서 자바, C#, 스칼라 언어를 이용해서 금융관련 소프트웨어를 개발하고 있다. 뉴저지에서 아내, 두 딸과 함께 살고 있다.

이러저러한 사정 때문에 며칠 야근을 하게 되었다. 아침 8시부터 코딩을 시작해서 밤 12시까지 멈추지 않았다. 더 이상 몸이 견딜 수 없을 때 잠을 잤고, 다시 아침에 일어나서 새벽부터 코딩을 시작했다. 미국 동부에 폭설이 내려서 아침저녁으로 눈을 치워야 했던 것은 덤이다. 이런 식으로 끝까지 ‘달린’ 것은 5년 만의 일인 것 같다. 그리고 결론을 내렸다. 야근은 미친 짓이다.
프로그래머가 정신을 집중해서 양질의 코드를 만들어낼 수 있는 시간의 최대치는 하루에 2~3시간이라는 것이 정설이다. 내 경험에 비추어 봐도 그렇다. 나는 아침 9시에 사무실에 도착하고 오후 6시에 퇴근을 한다.
점심시간을 빼면 하루에 8시간을 컴퓨터 앞에 앉아 있는 셈이다. 하지만 컴퓨터 앞에만 앉아 있을 수는 없다. 미팅도 해야 하고, 클라이언트도 만나야 하고, 친구들과 잡답도 해야 하고, 커피를 마시느라 들락거리기도 해야 하고, 개인적인 용무도 봐야 한다.
이런저런 시간을 다 빼고 나면 손끝에서 코드를 뽑아낼 수 있는 물리적인 시간의 최대치는 5시간을 넘지 않는다. 그 5시간만 제대로 집중해서 코드를 만들어내면 그날 내가 할 수 있는 일은 모두 한 셈이다. 그나마 여기에서 5시간은 실제로 코딩을 하는 시간이 아니라 차분하게 컴퓨터 앞에 앉아 있을 수 있는 시간을 의미한다.
그럼 6시에 퇴근하는 대신 밤 11시까지 책상에 앉아 있으면 (즉, 야근을 하면) 코드를 뽑아낼 수 있는 시간이 5시간에서 10시간으로 늘어나는 것이 아닐까. 생산성이 두 배로 늘어나는 것이 아닐까. 바로 이것이 프로그래밍의 본질을 이해하지 못하는 책상물림들의 셈법이다.

기계적으로 키보드를 두드리는 ‘타자’와 코드를 짜는 프로그래밍을 같은 일로 착각하는 것이다. 그러한 착각이 참이면 이런 식의 셈법도 성립한다. 하지만 프로그래밍은 ‘양’의 노동이 아니라 ‘질’의 노동이다. 손가락이 아니라 머리로 하는 일이다.
프로그래밍을 할 때 프로그래머의 두뇌는 CPU 레지스터와 메모리의 확장된 버전이 된다. 수많은 변수의 상태와 상호작용이 두뇌에 기억되고, 각종 클래스와 패키지 이름, 구현해야 하는 알고리즘 개요, 다른 하위시스템과의 상호작용, 방금 수정한 버그 내용, 사용자 요구사항 내용 등이 모두 기억된다.
1차원적인 기억의 문제가 아니다. 기억한 내용들이 서로 다차원적인 방식으로 상호작용하는 것을 실시간으로 파악하고 판단해야 한다. 엉망으로 꼬이고 엉킨 실타래의 끝을 놓치지 않고 추적하는 것이다. 열 개의 볼링핀을 저글링하는 서커스 단원처럼 한순간도 잡생각을 할 수 없는 고도의 집중력을 요구하는 일이다.
이런 수준의 집중력을 하루에 2~3 시간 이상 발휘할 수 있는 사람은 없다. 괴물 같은 사람이라도 5시간이 한계다. 사람에 따라서 하루 평균 2~3시간 발휘할 수 있는 집중력을 특정한 날에 몰아서 발휘하는 사람도 있다. 대신 그런 사람은 더 긴 휴식시간을 필요로 한다.
핵심은 지속가능한(sustainable) 양질의 집중력을 하루 평균 얼마나 발휘할 수 있느냐 하는 것이다. 매일 10시간씩 컴퓨터 앞에 앉아 있는다고 해서 10시간 내내 양질의 코드를 생산할 수 있는 것이 아니라는 이야기다.
사람이 사용할 수 있는 정신적인 에너지는 정해져 있다. 그날 쓸 분량을 다 쓰고 나면 당연히 회복할 시간이 필요하다. 책을 읽거나, 영화를 보거나, 연인과 데이트를 하거나, 친구와 잡담을 나누어야 한다. 충분한 수면을 취해야 하는 것은 물론이다.
에너지가 바닥난 사람을 컴퓨터 앞에 앉혀두면 그가 할 수 있는 일은 “잠자코 앉아있기”말고 아무 것도 없다. 키보드 위에서 영혼이 담기지 않은 손가락 놀림만 분주하다.
그래서 '코드를 짜기 위한 야근'이라는 표현은 '따뜻한 얼음'이나 '둥근 삼각형'처럼 형용모순이다. 말 자체가 성립하지 않는다. 에너지가 고갈된 상태에서는 정상적인 코드를 만들어내는 것이 불가능하다. 코드가 아니라 버그만 생산한다.
일하는 시늉만 무성하고 실제로 일은 아무 것도 이루어지지 않는다.
야근을 하면서 실제로 프로그래밍을 할 수 있는 경우는 낮에 집중력을 발휘할 만한 일을 아무것도 하지 않았을 경우로 국한된다.
이런 이유 때문에 익스트림 프로그래밍 진영에서는 오래 전부터 프로그래머가 일주일에 40시간 이상의 노동을 수행하지 말아야 한다고 주장해왔다. 프로그래머의 인권이나 노동권에 대해서 말하는 것이 아니다. 소프트웨어 프로젝트의 진정한 ‘성공’을 원한다면 프로그래머를 양계장의 닭처럼 쥐어짜는 것이 결코 도움이 되지 않는다는 사실을 깨달아야 한다고 말하고 있는 것이다.
생산성 하락도 문제지만, 정상적인 시간과 비용에 포함되지 않는 암시장이 형성되는 것도 큰 문제다. 프로젝트 관리자나 물주들이 프로그래머들의 ‘야근’을 당연한 것으로 여기면서 의존하기 때문에 프로젝트의 단가가 비정상적인 방식으로 산정된다.
이러한 암시장 효과로 인해서 프로젝트 일정이 주먹구구식으로 정해지고 프로젝트에 참여한 프로그래머들의 개인적인 삶이 담보로 저당 잡힌다. 이러한 악순환 속에서 소프트웨어의 ‘품질’을 찾는 것은 알래스카에 가서 야자나무를 찾는 것과 마찬가지다.
결론을 내려 보자. 그대가 프로그래머라면 하루에 2시간 이상 코드를 생산할 수 없다고 해서 조금도 자책하지 않기 바란다. 2시간 이상 코드를 만들어낼 수 있는 사람은 세상에 없다. 그대의 상사가 야근을 하라고 하면 어쩔 수 없이 야근을 하되 '시체처럼 앉아있기' 이상을 하려고 노력하지 마라. 그렇게 하지 않아도 된다.
열심히 야근을 하는 것처럼 보이는 세상의 다른 모든 프로그래머도 그대와 다르지 않다. 원래 다 그런 것이다.
그대가 프로그래머에게 일을 맡기는 사람이라면 (프로젝트 관리자든 아니면 프로젝트에 돈을 대는 물주든) 하루에 2시간 이상 코드를 생산할 수 있다고 말하는 사람을 진심으로 두려워하기 바란다. 시키지도 않았는데 기꺼이 야근을 하겠다고 말하는 사람을 호환마마보다 더 무서워하기 바란다.
그 사람은 프로그래머가 아니기 때문이다. 그는 좀비다. 언제 그대를 물어뜯을지 모르는 영혼 없는 존재다.
*본 칼럼 내용은 본지 편집방향과 다를 수 있습니다.


원본 :http://www.zdnet.co.kr/column/column_view.asp?artice_id=20140218180039&type=xml
2014/02/20 18:38 2014/02/20 18:38
Tags: ,
No trackbacks, No comments.

스트레스

Development/기술관련 |  2013/07/15 15:55
*** 웹 사이트 스트레스 테스트 범위 산정

1. 스트레스 테스트  정의

- 웹 사이트에 다수의 사용자(고객)들이 동시에 접속하였을 때, 일정 시간에 요청한 페이지를 조회할 수 있는가를 평가합니다.

- 모든 페이지를 대상으로 하는 것은 무의미 하기 때문에,
초기 페이지 및 고객이 자주 접속하거나, 관심을 가지거나, 트랜잭션이 발생하는 페이지들을 한정하여 테스트를 수행합니다.

- 테스트 결과를 통해 타 사이트와 비교한다거나, 웹 사이트 품질평가 기준이 될 수는 없습니다.

(웹 사이트 성능은 다양한 소프트웨어 및 하드웨어 환경을 통해 결정되기 때문입니다.)

- 다만 웹 사이트 운영을 대비하여 중대한 결점 여부를 파악하고,

실제 운영 시 하드웨어 및 소프트웨어가 어느 정도의 부하를 견딜 수 있는지 판단하며,
향후 동시 사용자 증가가 발생할 경우, 어느 정도의 투자가 필요한지 예측하기 위한 보조 자료로 사용될 수 있습니다.


2. 스트레스 테스트 시나리오


- 고객과 개발사 간 협의를 통해 스트레스 테스트 대상 페이지를 도출하며,

- 스트레스 테스트(부하테스트) 툴(tool)을 사용하여, 동시 접속자 수를 최대 *명으로 설정하고,
일정 시간 동안 인위적으로 웹 서버 부하를 발생 시킵니다.

- 스트레스가 발생한 시간 동안 CPU 및 메모리 사용량을 측정하며, 스트레스 테스트 툴 자체적으로 로그를 생성합니다.

- 스트레스 테스트 완료 결과를 정리하여, 보고서를 작성하고 제출합니다.

- 이와 같은 절차를 수행하는데 있어, 2~5일 정도 소요 됩니다.

4. 추가 의견


- * 웹 사이트는 트랜잭션이 많지 않은 일반적인 사이트 수준로 판단됩니다.
따라서 위와 같은 테스트 조건이면 무난하리라 판단됩니다.

- 만일 은행,증원사 등 대형 금융권에서 요구하는 대용량 부하테스트 수준을 적용할 경우,
별도의 견적을 산정한 후, 전문 성능분석 업체에 의뢰하여야 합니다.

2013/07/15 15:55 2013/07/15 15:55
No trackbacks, No comments.

[펌]개발자, 회사의 과거인가 미래인가

Development |  2012/12/26 09:49

개발자는 소프트웨어 회사의 가장 중요한 자산이면서 서로 상반된 2가지 가치를 가지고 있다.

첫 번째는 ‘과거의 가치’이고
두 번째는 ‘미래의 가치’이다.

나는 과거의 개발자일까? 미래의 개발자일까? 스스로 판단하기는 어려울 것이다. 동료나 경영진에게 내가 퇴사를 하면 어떻게 될까?라는 질문을 해보면 짐작할 수 있다.

내가 퇴사를 하면 과거에 개발해 놓은 제품들을 어떻게 하지?라는 생각이 가장 먼저 들면 ‘과거의 개발자’에 가깝다.

반대로 내가 퇴사를 하면 과거에 개발해 놓은 제품들은 문제가 없는데 미래에 개발할 제품은 누가 개발하지?라는 생각이 들면 ‘미래의 개발자’라고 볼 수 있다.

회사나 개발자 입장에서 권장되는 개발자 타입은 미래 가치를 많이 지닌 “미래의 개발자”이다. 미래의 개발자가 지금은 가치가 적은데 미래에 가치가 높다는 의미가 아니다. 미래에 가치가 더 있고 시간이 흐를수록 점점 가치가 높아진다는 의미다.

과거의 가치를 더 많이 가지고 있는 ‘과거의 개발자’는 본인이 아니면 유지보수가 어렵게 소프트웨어를 개발해 놓았고, 대부분의 지식이 머리 속에 있기 때문에 동료나 신입개발자와 지식을 공유하기 어렵다. 본인이 의도해서 그렇게 한 것은 아니지만 결과적으로 자신이 과거에 만들어 놓은 소프트웨어를 인질삼아 회사와 인질극을 벌이고 있는 것과 같다.

물론 이런 개발자가 퇴사를 한다고 회사가 망하는 것은 아니지만 적게든 많게든 타격을 입게 되고 심한 경우 회사는 퇴락의 길을 걷기도 한다. 따라서 회사는 이런 개발자에게 질질 끌려 다니곤 한다. 이런 상태의 개발자는 스스로도 상황의 피해자일 뿐이다.

미래의 가치를 가진 ‘미래의 개발자’는 자신이 과거에 만들어 놓은 소프트웨어들은 후배들이 유지보수를 수월하게 할 수 있도록 개발 과정에서 적절히 문서화를 해 놓았고, 아키텍처를 깨끗하게 만들었으며 모든 이슈는 이슈관리시스템에 기록으로 남겨 놓았다. 그리고 Peer review를 통해서 이미 많은 지식을 동료들과 공유를 한 상태다.

이런 합리적인 개발 과정을 통해서 본인은 분석, 설계 능력이 꾸준히 향상되어 왔으며, 회사도 성장에 걸맞게 프로세스와 개발문화가 발전되어 왔다. 유지보수에 허덕이지 않으므로 신기술에 대한 연구에 소홀하지 않아서 미래에는 과거 제품들보다 한 단계 수준 높은 제품을 만들어 낼 것이다.

언뜻 보기에는 과거의 엄청난 폭풍 코딩을 통해서 짧은 시간에 많은 제품을 만들어내는 성과를 낸 ‘과거의 개발자’가 영웅처럼 보이지만 미래의 가치를 지닌 ‘미래의 개발자’가 진정한 영웅이다.

필자는 대기업부터 작은 소기업까지 여러 소프트웨어 회사를 다니면서 개발자와 경영진을 대상으로 소프트웨어 개발에 대해서 강연이나 세미나를 많이 한다. 그럴 때 이런 질문을 하곤 한다.

“오늘 회사를 그만둬도 당장 큰 문제가 발생하지 않는 사람 손들어 보세요”.
“오늘 회사를 그만두면 회사가 당장 큰 일 나는 사람 손들어 보세요”.

이 두 가지 질문 중에서 두 번째 질문에 손을 드는 사람이 상당히 많다. 특히 주변에 특정인을 가리키며 손을 들라고 하는 경우가 많다. 이런 사람은 십중팔구 ‘과거의 개발자’이다.

과거에 엄청나게 많은 일을 해냈지만 대부분은 유지보수에 치여 본인도 발전 못하고 격무에 시달리고 있는 경우이다. 수많은 문제와 이슈는 본인만 알고 있어서 수시로 불려 다니고 정작 본인은 개발할 시간이 없고 발전도 어렵다.

물론 ‘과거의 개발자’양산이 개발자에게 책임이 있는 것은 아니다. 소프트웨어 개발 환경이 회사에서 제공하는 프로세스, 시스템이 열악한 상태에서 전적으로 개발자의 내공에 의존을 하기 때문에 개발자도 어쩔 수 없이 ‘과거의 개발자’가 되어 버리는 것이다.

‘과거의 개발자’가 주도하는 회사는 엄청난 개발자 Risk를 안고 있는 것이다. 뛰어난 개발자가 많지만 이들이 한두 명만 나가도 회사가 휘청대며, 유지보수에 발목을 잡혀서 앞으로 나가기 어려운 상태인 경우가 많다.

회사는 개발자가 개발에 전념할 수 있고 개발 과정에서 꾸준히 성장할 수 있도록 환경을 제공해야 한다. 개발자 경력을 보장하는 것은 물론이고 프로세스와 기반시스템을 제대로 갖추고 개발문화 구축에 제도적인 노력해야 한다. 그렇게 해서 개발자 내공에 의존하는 개발이 아닌 시스템에 의존한 개발이 되어야 한다. 그런 환경에서야 개발자가 최고의 활약을 할 수 있다.

그래야 개발자도 행복하게 개발을 할 수 있고 회사도 개발자 Risk가 줄어든다. 이런 환경에서 성장하는 개발자는 신참때는 주로 코딩을 하지만 고참이 되어 갈수록 설계, 분석에 집중하고 문서를 통한 협업에 능숙해진다. 이런 방법이 개발자와 회사 모두에게 좋은 방법이다.

여전히 개발자의 내공에 의존한 개발 환경을 가진 회사에서 유지보수에 허덕인다고 개발자를 탓하지는 말자. 지금이라도 ‘미래의 개발자’를 위한 환경에 대해서 고민해보자.

책에도 다 있고 이론은 많지만 현실에서 실천이 어려운 것이다. 이론으로는 배울 수 없고 경험에 의해서 밖에 배울 수 없기 때문이다. 책과 이론은 약간의 도움을 줄 뿐이다.


원본 : http://techit.kr/14467


2012/12/26 09:49 2012/12/26 09:49
Tags:
No trackbacks, No comments.

페북 API

Development/기술관련 |  2010/11/17 10:09
facebook open api에 대한 자료를 수집하여 봅니다.
  Graph API 오픈소스 사이트와 커넥트 설정

출처 : http://www.sitehis.com/spb3/sboard3/read.php?db=talk&cateuid=12&uid=235

2010/11/17 10:09 2010/11/17 10:09
No trackbacks, No comments.

ASP 트로이잔 Webshell의 예방 및 문제해결방법

Development/기술관련 |  2010/08/25 13:05
ASP 트로이잔 Webshell의 예방 및 문제해결방법
 

Source from：[S.S.R.E.T]ServersTeam.Org [F.N.S.T]Fineacer.Org
url：http://www.Serversteam.org/docs/Microsoft_Win_ASP_Webshell_Security.htm

개요：본문에서는 Microsoft 윈도우 계열의SERVER (IIS5.0、IIS6.0)에서 간단하고 빠르게 ASP 위험성 있는 컨포넌트를 WEB서버 시스템으로부터 멀리하는 것을 설명한다. 본문을 읽는 후 자기가 관리하고 있는 서버를 asp 트로이잔, Webshell 권한상승 및 시스템 보안위협 등으로부터 벗어날 수 있다.

본문：
주의：본문에서 언급된 설정방법 및 설정환경은：Microsoft Windows 2000 Server/Win2003 SERVER | IIS5.0/IIS6.0에 적용함.

1、우선 일반적인ASP트로이잔을 살펴본다, Webshell에서 사용한 ASP 컨포넌트는 아래와 같다. 중국산 webshell인 HY2006를 예를 들어보면,

<object runat="server" id="ws" scope="page" classid="clsid:72C24DD5-D70A-438B-8A42-98424B88AFB8"></object>
<object runat="server" id="ws" scope="page" classid="clsid:F935DC22-1CF0-11D0-ADB9-00C04FD58A0B"></object>
<object runat="server" id="net" scope="page" classid="clsid:093FF999-1EA0-4079-9525-9614C3504B74"></object>
<object runat="server" id="net" scope="page" classid="clsid:F935DC26-1CF0-11D0-ADB9-00C04FD58A0B"></object>
<object runat="server" id="fso" scope="page" classid="clsid:0D43FE01-F093-11CF-8940-00A0C9054228"></object>
shellStr="Shell"
applicationStr="Application"
if cmdPath="wscriptShell"
set sa=server.createObject(shellStr&"."&applicationStr)
set streamT=server.createObject("adodb.stream")
set domainObject = GetObject("WinNT://.")

이상은 HaiYang webshell의 일부 소스다, webshell에서는 아래 여러 종류의 ASP컨포넌트를 사용하고 있는 것을 알 수 있다.
① WScript.Shell (classid:72C24DD5-D70A-438B-8A42-98424B88AFB8)
② WScript.Shell.1 (classid:F935DC22-1CF0-11D0-ADB9-00C04FD58A0B)
③ WScript.Network (classid:093FF999-1EA0-4079-9525-9614C3504B74)
④ WScript.Network.1 (classid:093FF999-1EA0-4079-9525-9614C3504B74)
⑤ FileSystem Object (classid:0D43FE01-F093-11CF-8940-00A0C9054228)
⑥ Adodb.stream (classid:{00000566-0000-0010-8000-00AA006D2EA4})
⑦ Shell.applicaiton....

2: 해결방법：

① 아래 위험성 있는 ASP 컨포넌트를 삭제 혹은 명칭을 변경한다.
WScript.Shell、WScript.Shell.1、Wscript.Network、Wscript.Network.1、adodb.stream、Shell.application
[시작->실행->Regedit]을 실행하여 레지스토리를 수정한다. “Ctrl+F”으로 찾기를 실행한다. 순서대로 위에 Wscript.Shell등 컨포넌트의 명칭 혹은 그와 매칭한 ClassID을 입력한다. 해당 명칭을 삭제하거나 변경한다. (여기서 명칭변경을 권장한다. 만약 일부 웹 페이지의ASP프로그램에서 위에 열거한 컨포넌트를 사용했다면, ASP코드작성시 수정된 컨포넌트의 명칭을 사용하면 모든 것이 정상적 사용을 가능하다. 만약 ASP프로그램에서 이상의 컨포넌트를 사용하지 않는다면 삭제하는 것이 좋다. 삭제 혹은 명칭 변경 후, iisreset으로 IIS재 동작 후 적용한다.)
[주의：Adodb.Stream 컨포넌트는 많은 사이트에서 사용하기 때문에  만약 서버가 Virtual machine 이면 상황에 따라 조치 바람.]

② File System Object (classid:0D43FE01-F093-11CF-8940-00A0C9054228) 보안 문제에 대해 만약 서버에서 FSO를 사용해야 한다면(일부 Virtual Machine에서는 FSO기능을 사용함), FSO보안 해결방법은 “Microsoft Windows 2000 Server FSO 安全隐患解决办法” 문서를 참고하시길 바란다. 사용할 필요 없는 경우 직접 사용중지 하면 된다.

③ 사용중지 혹은 위험성 있는 컨포넌트를 삭제하는 방법：(방법① 및 방법②를 번거롭다고 생각하는 분은 본 방법을 참고함.)

wscript.shell 오브젝트를 해제하는 방법은 아래와 같다. cmd 모드에서[：regsvr32 /u %windir%\system32\WSHom.Ocx]를 실행한다.
FSO 오브젝트를 cmd 에서 아래 내용을 실행하여 해제한다. [regsvr32.exe /u %windir%\system32\scrrun.dll]
stream 오브젝트의 해제는 cmd에서 [regsvr32 /s /u "C:\Program Files\Common Files\System\ado\msado15.dll" ]를 실행한다.
만약 실행취소를 원한다면 위에 명령에 [/U] 옵션만 제거하면 된다. 즉, 관련 ASP컨포넌트를 재실행 가능하다. 예를 들면, regsvr32.exe %windir%\system32\scrrun.dll

④ Webshell 중에 set domainObject = GetObject("WinNT://.")을 사용하여 서버 프로세스, 서비스 및 사용자 정보 등을 획득하는 것에 대한 예방 방법은 아래와 같다. 서비스 중의 Workstation[네트워크 연결 및 통신을 제공함] 즉, Lanmanworkstation서비스를 중지하면 문제해결 된다. 이렇게 처리하면 Webshell 프로세스를 디스플레이 하는 곳에 공백으로 표시된다.

3 위에 방법1、2에 따라 ASP관련 위험한 컨포넌트에 대해 처리 후, Ajiang asp probe으로 테스트하면,"서버CPU상세내역" 및 "서버운영체제"를 찾을 수 없으며 내용은 모두 공백으로 디스플레이 된다. HaiYang을 사용하여 Wscript.Shell를 테스트 하면, cmd commend line에서 Active를 만들 수 없다는 메시지가 디스플레이 된다. ASP 트로이잔이 서버 시스템에 대한 보안 위협을 완화할 수 있다.
본문에서 소개한 내용은 단지 본인이 ASP트로이잔、Webshell에 대한 소견뿐이다. 향후 여러분께 어떻게 간단하게 타인 컴퓨터에 net user 와 같은 명령의 실행을 방지하고, 버퍼 오버플로우를 통해 cmdshell 획득을 방지 및 사용자 추가의 방지, NTFS 설정권한에서 터미널 서비스 등록 등에 대한 간단하고도 효과적인 방어방법을 소개할 예정이다.


저자： 李泊林/LeeBolin
[S.S.R.E.T 服务器安全研究专家小组 CTO] Http://www.serversteam.org
[F.N.S.T 情长计算机网络安全在线 技术顾问] Http://www.fineacer.org
E-mail:leebolin#serversteam.org QQ:24460394 본문관련 질문 사항은 메일 혹은 QQ에 연락하시길 바람 
 
2010/08/25 13:05 2010/08/25 13:05
No trackbacks, No comments.
<< Previous Page 1 2 3 4 5 Next Page >>