자잘한 자작 프로그램,스크립트 등을 어떤 식으로 보관하세요?
아예 규모가 큰 프로그램들은 (소스 파일도 다수이고 리소스나 설정 파일 등등이 같이 있는) 어차피 독자적으로 디렉토리 하나 따로 만들어서 그 아래에 둘 테니 그렇다치고...
예를 들어 리눅스로 작업하다가 "에잉, 텍스트 파일 수백개를 일괄 수정해야 하게 생겼네.." 이러면 KLDP 분들이라면 에디터로 하나 열어 수정하고 저장하고 이러지 않으시겠죠 ^^; 분명히 에디터에서 그런 기능을 제공하는지 알아보거나, 쉘이든 펄/파이썬/루비/C/C++/JAVA/ 아니면 어셈블리-_-;;로라도 일괄 변환하는 프로그램을 만들 거란 말이죠.
이런 자잘한 스크립트를... 제 경우는
- 리눅스라면 ~내계정/local/bin/ 아래 넣습니다.
- 윈도우라면 D:\Local\bin 정도에 두기도 하고요.
자주 쓸 때 편하라고 이 디렉토리들 PATH에 포함도 시켜두겠죠.
그런데 이런 스크립트가 10개, 20개, 30개 쌓여가면
- ls ~/local/bin/ 했다가 일단 흠칫 한 번 하고...
- "도대체 이 rename.pl 은 뭐의 이름을 어떻게 바꾼다는 걸까;;" 생각도 안 나서 들여다봐야 하고
- 반대로 "내가 반 년 쯤 전에도 이 작업 하느라 스크립트 하나 만들었던 기억은 나는데 그게 어느 거더라.." 하면서 뒤지게 되고 (파일 수정 시각 가지고 대충 유추는 됩니다만, 그 후에 하드 교체하면서 통채로 복사해왔다면 모두 동일한 날짜로 바뀌어 있겠죠 ㅠ,.ㅠ)
- 게다가 이 중 어떤 프로그램들은 실행 도중에 따로 데이타를 파일로 저장하거나 로드하기 때문에.. 이젠 내가 짠 스크립트에다가 "그 스크립트가 생성한 데이타 파일"까지 섞이고..
- 3년 전에 만들어서 며칠 쓰고 그 후로 실행해 본 적 없는 스크립트라면 사실 지워버려도 됩니다만... 이런 거 지우긴 아깝잖아요 (저만 그런가;;;) 게다가 내가 3년 내내 쉘스크립트만 다루며 산 게 아니니 만일 나중에 또 같은 작업을 하게 될 경우는 똑같은 스크립트를 작성하는데 더 오래 걸리거나 아예 못 만들수도 있다는 생각을 하면 더더욱 지우지 못하게 되죠.
..
결국 참다못해 다시 하위디렉토리를 나눠서 각각의 디렉토리에 스크립트를 따로 뒀더만...
- 이 디렉토리 수가 늘어나면 뭐가 뭔지 찾기 힘든 건 파일이 수십개일 때와 마찬가지 상황이고,
- 이젠 그 디렉토리들을 다 PATH 지정하자니 이건 참 지저분해지고 안 하자니 불편하고,
- 리눅스는 그나마 심볼릭 링크란 좋은 게 있어서 실행파일만 한 곳에 다시 링크를 쭉 놔둘 수 있는데 윈도우는 이거 "바로 가기.lnk" 이런 거 만들기도 뭣하고...
..
게다가 이런 류의 작업들을 다 한 컴퓨터에서 하는 게 아니다보니 어떤 건 리눅스 머신에 어떤 건 윈도우 머신에 또 어떤 건 저기 공용 서버의 내 계정에...
오직 서버에서만 돌릴 수 있는 프로그램이라 서버에 만들어놨는데, 이걸 보관 차 내 윈도우 머신에 복사를 했다면? 이젠 사본이 생기면서 나중에 수정한 거 제때 복사해주지 않으면 버전 차이가 나기 시작하고... 에휴~
..
또 고민되는 경우 중 하나가, 예를 들어 내가 어떤 프로젝트를 수행하다가 그 프로젝트의 관련 자료들을 정리하는 작업을 하다가 그에 필요한 스크립트를 만들었다고 하면...
- 이 스크립트를 "D:\내문서\매우\하기싫은\프로젝트\관련자료" 폴더에 같이 둘까? 이 폴더는 하위 폴더100개, 파일3600개가 있고 용량이 다 합쳐 1GB쯤 되는데, 이 안에 묻혀있으면 나중에 찾기는 쉬우려나? 게다가 따지고 보면 그 1GB 분량의 pdf 파일들은 설령 하드가 날라가도 다시 인터넷에서 검색해서 받으면 되는 거지만 내가 만든 이 30라인, 1KB짜리 스크립트는 분실하면 다시 만들 자신이 없는데? 빈번하게 백업하는 작은 용량의 폴더 쪽에 두는 게 낫지 않을까?
- 그렇다고 이 스크립트만 생뚱맞게 D:\local 아래에 두자니 그건 그거대로 뭔가 너무 붕 뜨는 느낌이고...
- 양쪽에 다 두자니 또 사본이 생기는 샘이라 양쪽 버전 동일하게 맞춰주는 거 신경써야 하고...
..
암튼 요런 걸로 고민을 자주 하게 되더군요. 다른 회원님들은 이런 자잘한 것들을 어떤 식으로 관리하세요?
"10라인 짜리 스크립트를 하나 짜도 README 파일 따로 만들고 언제 어떻게 무슨 용도로 사용하기 위한 것인지 50줄짜리 설명을 적어놓고 이걸 CVS로 등록해두어 관리하고 상세한 내역은 위키에 저장해둡니다!" 이러실지도... :-D
인용:"10라인 짜리
비슷하게 하고 있습니다. 자작 프로그램용 저장소와 설정 파일용 저장소를 따로 구분해서 쓰고 있습니다. 전자의 저장소는 털려도 상관 없는데, 후자의 저장소는 털리면 곤란한 내용이 좀 많죠.
---- 절취선 ----
http://blog.peremen.name
인용:비슷하게 하고
허억 진짜로 그러고 계시군요...
제 경우 전에 비슷하게 꾸며봤다가 귀찮아서 중단한 적이 있었는데, 저장소를 어디 둘까 이런 것까지도 고민거리가 되더군요 ^^ (음 고민을 사서하는 것 같기도) 항상 켜져 있는 공용 서버의 내 계정 아래 둘까 하다가도 아무래도 내 개인 컴퓨터가 낫지 싶어서 왔다갔다 하게 되더라고요. 뭐 이런 선택이야 케이스마다 다르니 답이란 건 없겠지만, 다른 분들은 어떻게 하는지 듣다보면 아무래도 이게 더 낫겠군 하고 결정하는 데 도움이 되더라고요 ^^
제 근처에 오프라인에서 물어볼 만한 사람들은... 딱히 이런 신경까지 쓰지 않는 사람들이라 OTL
좋은 하루 되세요!
과거 SVN을 쓸 때는
과거 SVN을 쓸 때는 저장소와 작업 사본을 무조건 따로 만들어야 했죠. Mercurial로 이동하고 나니까 저장소와 작업 사본을 따로 관리하지 않아도 된다는 장점이 있습니다. :)
---- 절취선 ----
http://blog.peremen.name
저도 비슷합니다.
~/src/프로젝트이름 으로 디렉토리를 만들어서 넣어둡니다. (자잘하거나 자잘하지 않거나 모두) 버전관리도 물론 하구요.
실행파일은 ~/bin에 심볼릭 링크를 걸어둡니다.
작은 프로젝트라면 README를 따로 만들지는 않지만, 적어도 소스파일 앞부분에 주석으로 설명(사용법 등)은 적어둡니다.
음 버전 관리 다들
음 버전 관리 다들 자잘한 것에도 꼼꼼히들 하시는군요...;;;
CVS, Subversion 만 좀 써 본 상태인데 peremen님 말씀하신 Mercurial? 이것도 한번 알아봐야겠네요.
사용법 주석은 저도 꼼꼼히 적고 있습니다. 이런 자잘한 잡동사니는 그게 참 중요하더라고요. 안 적어두면 한달만 지나면 이게 뭐였더라만..하게 되어서 ^^;
좋은 하루 되세요!
인용:반대로 "내가 반
스크립트의 코멘트에 스크립트가 하는 일이 무엇인지 적어두는 습관과 함께 나중에 Beagle이나 구글 데스크톱 같은 데스크탑검색프로그램을 설치하시고 스크립트를 인덱스에 넣어두시면 편하지요.
혹은 스크립트에 코멘트로 tag를 달아주면 나중에 grep (ack-grep)으로 찾을 수 있습니다. 예를 들어 텍스트파일을 받아서 각 라인에 번호를 매겨주는 스크립트를 작성했다면 다음과 같은 라인을 스크립트파일에 코멘트로 넣어둡니다.
그러면 10년 후에 머리를 긁으며 "라인에 번호 매겨주는 스크립트가 어디 있지? 10년 전에 작성해봤던 것 같기도 하고 안한 것 같기도 하고"라고 해매고 있을 때 "음... (텍스트)와 (번호) 태그로 찾아볼까?" 라고 머리 속에 떠오르게 되서 grep과 pipe를 이용해서 (텍스트)와 (번호)가 동시에 들어간 스크립트 파일을 찾으면 금방 찾게 됩니다. (블로그의 태그 혹은 꼬리표 개념이 바로 이런 거죠. 마가린이나 딜리셔스같은 온라인 즐겨찾기 등록 웹서비스도 비슷한 컨셉, 어떤 웹사이트가 나중에 유용할 것 같기도 하고 안 유용할 것 같기도 해서 그냥 온라인 즐겨찾기 서비스에 태그 왕창 달아서 등록시키자... 라는 거죠.) 태그는 수십 개의 텍스트 파일로 노트정리하는 사람들에게도 유용한 개념.
지우지 말고 자신만의 archive폴더에 던져넣으세요. 더이상 안 쓰는 문서나 스크립트 같은 건 나중에 혹시 참조할지도 모르니까 몽땅 archive폴더에 던져넣는 겁니다. 그리고 archive파일도 백업합니다. 요즘 하드디스크 값도 싸고... 사실 스크립트나 문서 같은건 영화파일이나 야동에 비하면 싸이즈도 작아서 괜찮아요. 그리고 폴더별로 나눠서 저장하는 건 너무 많이 신경 안 써도 괜찮아요, 태그와 데스크톱 검색이 있으니까. 자기가 작성한 스크립트 중에서 좀 유용하다 싶은 건 인터넷이라는 거대한 바다에 던지는 건 어떨까요? 블로그에 포스팅한다거나,,, 아니면 여기에 올린다거나 그러면 나중에 님과 같은 궁리를 하는 사람들이 구글링으로 쉽게 찾아서 님의 노고를 취할 수 있지요. 게다가 님도 10년 후에 구글로 찾을 수 있구요. 누군가가 님의 스크립트를 보고 "제가 당신의 스크립트를 ....의 용도로 개선해봤습니다...."라고 답글달수도 있고 ... 이런 게 인터넷의 좋은 점 아니겠어요.
자세한 조언
자세한 조언 감사드립니다 ^^
그렇잖아도 여러 해 지나면서 점점 더 아무리 자잘한 거라도 주석은 잘 달아두려고 하고 있는데, 태그 형태는 또 생각해보지 못했네요. "태그들을 수집해서 보여주는" 스크립트를 또 만들 수도 있겠군요. ^^
인터넷에 올리는 건 뭐 상관은 없는데 올리는 건 올리는 거고 보관은 보관이라... dl3zp3님 말씀처럼 검색 툴이 좋은 것들이 많으니 분류라거나 하는 쪽에 신경을 덜 쓸 수도 있겠죠.
좋은 하루 되세요!
저는 일단 script를
저는 일단 script를 CVS에 등록, $HOME/bin에 받아두고, 각 script는 모두 `-h' 또는 `--help' 옵션을 지원하도록 만들고 있습니다. 나중에 봐도 무엇을 하는 script인지 알기 위해..
--
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
Korean Ver: http://www.cinsk.org/cfaqs/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
Korean Ver: http://cinsk.github.io/cfaqs/
음 역시 버전관리는
음 역시 버전관리는 대세...
확실히, 저도 "한번 쓸 거 걍 대충" -> "주석에 사용법이라도 잘 적어놓자" -> "usage를 출력하는 옵션을 넣어두자"로 진화하게 되더군요. ^^
좋은 하루 되세요!
음...
대부분 생각은 비슷한 거 같네요... ㅎㅎ
근데 이런거 관리하는 것들도 일이라.. 버전관리는 안 하고..
작업 공간에서 grep 으로 적절히 필요한 루틴이 있을만한 파일들 검색해서..
그때그때 가져다 고쳐서 쓰고...
자주 쓰는 것들만 엄선해서 ~/bin 에 help, usage 포함해서 만들어 놓고 쓰는데..
되면 한다! / feel no sorrow, feel no pain, feel no hurt, there's nothing gained.. only love will then remain.. 『 Ｍｉｚｚ 』
되면 한다! / feel no sorrow, feel no pain, feel no hurt, there's nothing gained.. only love will then remain.. 『 Ｍｉｚｚ 』
지금보니 전부다
지금보니 전부다 지우는 저는 막장인거군요 = _=);;
아,, 그것보다,,, 저는 스크립트마다 usage 옵션을 두지 않고
script 상단 주석에 도움말 내용을 전부 쳐넣고
wth이라고 = ㅅ=);; 그 상단부를 출력하는 스크립트를 뒀었습니다.
이러면 스크립트가 비교적 깔끔하게 나옵니다. = ㅅ=)b;;;
버전 관리
코드는 버전 관리 합니다. 버전 관리. 무조건.
다른 사람 줍니다.
그냥 다른사람에게 email로 보내버립니다.
그리고, 지우죠.
뭐... 필요할때는 아무한테나 다시 달라고 하고... 우헤헤헤헤.
경쟁에 살아남는 (시간이 지난후에 누군가가 가지고 있는) 것만 쓰게 되겠죠.
스, 스크립트조차
스, 스크립트조차 무한 경쟁의 세계에 있군요······.
저도 내가 짜서 누구한테 보낸 스크립트를
찾기 위해 백업용 하드를 마운트시키기 전에 먼저 메일 검색부터 해봅니다 ㅎㅎ
~/bin에 잘 모셔다 둔 '저질' 스크립트를 간만에 다시 이용하려니 사용법이 가물가물하다... 이럴 때도 일단 메일 검색;; 물론, 메일로 누군가에게 보낼 때 친절한 설명을 본문에다 꼭 포함시켜야 합니다~ =D
스크립트나 tip
스크립트나 tip 적어놓은 txt 파일 쪼가리들이 들어있는 디렉토리는 무조건 버전관리 대상입니다.
subversion 없이는 한줄도 작성 안합니다. (놋북에서는 svk) ^^
=-=-=-=-=-=-=-=-=
http://youlsa.com
=-=-=-=-=-=-=-=-=
http://youlsa.com
서브버전 사용.
서브버전 사용.
========================
조직 : E.L.D(Embedded Linux Developer/Designer)
블로그 : poplinux@tistory.com
카페 : cafe.naver.com/poplinux
임베디드 리눅스 관련 프리렌서 지향
음.. 서브버전을
음.. 서브버전을 이용하신다는 분이 많으신데, 그 svn 서버는 어디에 설치해서 쓰시나요?
회사의 프로젝트라면 회사의 서브버전을 이용하고 있는데, 작업의 편의를 도와주거나 유용한 스크립트 등도
회사 버전관리에서 같이 쓰시나요? 아니면 따로 어디 설치해서 쓰시는 건지.. 문득 궁금하네요.
ㅎㅎ
저도 요즘 이 문제로 어떻게 할까..생각하다보니 결국은 버전관리인데..
검색해보니 무료 svn 호스팅 정리된 글이 있더군요ㅋ
http://www.teamdtr.net/blog/19
팀으로 쓸게 아니라 혼자 쓸거니 인원제한이 있는게 오히려 좋아보인달까요ㅋ
----
자신을 이길 수 있는자는
무슨짓이든 할수있다..
즉..무서운 넘이란 말이지 ^-_-^
나? 아직 멀었지 ㅠㅠ
----
자신을 이길 수 있는자는
무슨짓이든 할수있다..
즉..무서운 넘이란 말이지 ^-_-^
나? 아직 멀었지 ㅠㅠ
개인적으로 사용하는
개인적으로 사용하는 script들은 파일한개만 신경쓰면 되니까 간단하다고 여겨져서 RCS로 버젼관리하고 작업 flow나 목적이 최대한 잘 드러나게 소스를 작성하고 파일제목을 아주 상세하게 만든다음 가능한 주석은 달지 않습니다.
요즘은 밖에 돌아다니거나 여러 시스템을 쓸일이 많아지면서 gmail 계정을 따로 하나 만들어서 gspace로 디렉토리 분류해서 올려놓고 씁니다. 그리고 버젼관리는 아무리 봐도 다시 예전걸 쓰는 일이 드물어서 따로 하지 않고 최신버젼만 유지하고 그때 그때 수정해서 사용합니다.
=================================================
오늘 우리는 동지를 땅에 묻었습니다. 그러나 땅은 이제 우리들의 것입니다.
아직도 우리의 적은 강합니다. 그러나 우리는 그들보다 많습니다.
항상 많을 것입니다.
오늘 우리는 동지를 땅에 묻었습니다. 그러나 땅은 이제 우리들의 것입니다.
아직도 우리의 적은 강합니다. 그러나 우리는 그들보다 많습니다.
항상 많을 것입니다.
서브버전 한표..
서브버전 한표..
저도 버전 관리를
저도 버전 관리를 합니다. 더불어 스크립트도 리팩토링하고, 만들어뒀는데 안쓰는 것들은 주기적으로 지웁니다. (그래도 이력엔 남죠.) 리팩토링한다는 것은 여러 스크립트에서 비슷하게 하는 삽질은 나름대로 라이브러리로 만들어서, 그걸 여러 스크립트에서 불러다 쓰게끔 하는 식입니다.
예를 들어, 옷 보는 걸 좋아하는 편인데, 대부분의 국내 쇼핑몰이 RSS를 지원하지 않아서 처음엔 하나씩 RSS 추출하는 스크립트를 만들다가, 나중에는 XPath/CSS 셀렉터를 가지고 사이트 메타정보를 적으면 알아서 RSS 생성되게끔 리팩토링한 경험이 있습니다.
도대체 이분들
도대체 이분들 스크립트로 뭘 하시길레 버전관리까지... - _-)...;;;
댓글 달기