2011/02/23 17:23
RL.T hink.
[RL.Application] - DE File Numberer. v0.1. 파일명을 일괄로 바꿔주는 프로그램.
을 만들면서 느꼈던 것들입니다.
뭐가 이리 오래걸린걸까요?
완전 초 단순한 프로그램이라서 만드는데 별로 안걸릴 줄 알았습니다.
Visual Studio 2008 개발환경.
그리고 제가 가장 익숙하게 다루는 언어가 c#이라서 이걸로 뚝딱뚝딱 만들었죠.
프로토타입이 만들어질때까지 약 1-2시간정도 걸렸습니다.
그랬더니 바로 두가지 문제를 지적당했습니다.
2.1. 저 선택취소 버튼이 뭘 의미하는가?
선택취소 버튼을 누르면 어떻게 되냐고 묻더군요.
그 래서 선택취소 버튼은 말 그대로 이미 리스트에 올라가있는 파일들을 다 지워버린다고 말해줬습니다. 그랬더니 파일들을 체크박스로 선택하고 그 선택된것만 지워버리는게 어떻냐고 피드백을 줘서, 그렇게 고쳤습니다. 이렇게 뜯어고치는데 한시간 정도 더 소요됐고요.
2.2. 이 간단한 프로그램을 돌리는데 왜 1G 남짓이나 되는 프로그램을 설치해야 하는데?
닷넷 프레임워크는 인터넷에서 다운받아보면 약 1G 조금 안되는 용량을 가지고 있습니다.
그런데 제가 생각해도 막막한 겁니다. 도대체 왜 이걸 돌리는데 닷넷 프레임워크를 깔아야 한다고 설명할 수 있을까. 프레임워크 레이어라서 사실상 필요한 라이브러리가 다 그안에 들어있다..라고 말해줘야 하는데, 깊이 들어가다보면 설명이 너무 복잡해지더군요.
그래서 다른 언어로 다시 짜야겠다고 생각했습니다. 최소한 복잡한 닷넷 프레임워크 필요없이 간단하게 동적 DLL링크시키는 방식으로요.
뭘로 짤까 고민좀 해봤습니다. 그리고 목록이 쭉 나왔죠.
Python IDE.
Python으로 실제로 파일을 불러오고 변경시키는 논리 자체는 어렵지 않습니다. 오히려 C#에서 사용하는 제네릭 형식을 훨씬 편하게 쓸 수 있고, 제가 즐겨 사용하는 리스트 형식이 내장되어 있어서 프로그램을 개발하는데 편리하죠. 동적 언어의 특성때문에 조금 느리기는 하지만, 이 간단한 프로그램에는 별 상관없을꺼라 생각했습니다.
그런데 문제가 하나 생깁니다. 바로 괜찮은 IDE가 없다는 거죠. 저는 4GL 형식의 아주 심플한 화면 구성이 필요했습니다. 일일이 Tkinter 를 코드로 치고싶지는 않았어요. 간단하게 만들 수 있는거면 간단한게 최고다..라는 주의라서, 괜찮은 IDE가 있나 찾아봤습니다.
4.1. Boa-Constructor
이거야 됐어! 라고 생각했지만.. 왠지 모르게 작동하지 않았습니다(...)
BOA는 설치파일 형식으로 배포는 되지만, 실제 실행은 Lib 폴더 안에 들어가서 boa.pyw 을 실행해야 하는 형태입니다. 그런데 왠지 모르게 IDE만 뜨고 보아 자체는 전혀 실행되지 않았습니다. 그리고 Reference 를 영어로 봐야하는 압박 귀찮음도 있었고요.
물론 공식 그래픽 라이브러리인 Tkinter가 아니라 WxPython을 사용하는 거라서 바게님의 포스트를 참고하여 PyWin을 설치했습니다. wxPython은 python 3.1용 버전이 릴리즈된게 없어서 일단은 py27버전을 설치했고요. (이게 문제인지도..)
여하튼 되지 않습니다. 봵!
4.2 PythonCard
PythonCard는 제가 원하는 모양이 아니라서 포기.
4.3. KomoDo
ActiveState사의 KomoDo는 유료라서 포기 ($382 = 2011.02.23일 오후 4시 기준 428,604 원..)
Small Basic IDE.
Small Basic은 예전 GW-Basic의 추억을 생각하며 그냥 막코딩해볼까 하고 찾아봤습니다만, 그래픽 라이브러리는 있는데 너무 제한이 많고.. GOTO 문이 난무하는걸 보면서 포기...
게다가 재미있는 게, Small Basic은 퍼블리싱을 할 경우 Visual Basic .net 으로 자동으로 코드를 바꿔줍니다. 결국은 스몰 베이직도 닷넷 프레임워크가 실행시에 필요하단 얘기죠.
FBEdit 는 FreeBasic 이라는 Quick-Basic의 추억을 되살리면서 만든 베이직 컴파일러의 IDE입니다. 현재 FreeBasic 프로젝트 자체는 정체 상태입니다만, 이미 완성도가 높아질만큼 높아졌으므로 그냥 써보기로 했습니다. 언어에 최소한 프로시져랑 함수 정도는 있더라구요.
FBEdit 외에 FBIDE 프로젝트도 있습니다만... 만들다 만건지.. 사이트가 엉망이길래 포기.
FBEdit 소스코드
그런데.. 이게 ... 너무 MFC 방식입니다.
윈폼 개발시에 C++ 로 하는것처럼.. 보라 윈폼이 시작할때 파라미터의 포인터 난무를....
처음부터 C++ 로 만들 생각을 안했던게, 너무 귀찮고 복잡하거든요. 논리를 세우는데 집중할 수 있는게 아니라, 컴퓨터가 어떤식으로 동작하는지를 먼저 머리속에 그리고, 그다음에 논리를 세워야 하는데.. 이걸 가능하면 피하고 싶었습니다.
Lazarus는 Delphi의 오픈소스 구현입니다. 정확히 말하면, 위에서 말한 FreeBasic과 FBEdit의 관계처럼 FreePascal이라는 Object Pascal의 오픈소스 구현이 있고, 그 위에 Lazarus라는 IDE가 올라가는 형태입니다.
한때는 시대를 풍미했던 터보 파스칼의 기억을 되살려가며 한번 해보려고 했습니다만..
이게 IDE 기능 자체는 놀랍도록 좋습니다. 구현체 자체는 Delphi 2005랑 상당히 비슷하게 되어 있고, 기능도 훌륭해요. 인텔리센스도 잘 먹습니다. 그리고 4GL시대에 (한때는 Visual Basic과 어깨를 겨루었던) 맞춘 기능을 모조리 구현해놨습니다.
조금 특이한 것이, 각각의 창이 둥실둥실 떠다닙니다. 그러니까, 소스코드창은 소스코드창대로, Object Inspector 는 Object Inspector 대로, 디버거는 디버거대로 떠다닙니다. 위치를 잘 맞춰주지 않으면 어느순간 소스코드창에 가려져서 디버그 트레이스가 사라져 버립니다 (...)
이걸 포기한 이유는 두가지인데요.
하나는 디버깅 트레이스에서 조사식을 찍어보면, Object의 Property 와 Method 목록이 펼쳐지지 않아요. 저는 개체 하나의 값이 전체적으로 어떻게 변하나를 조사식으로 일일이 찍어보는 버릇이 있는데, 이게 힘들더군요.
다른 하나는 파스칼 언어 자체의 한계입니다. 이걸 한계라고 해야 할 지는 모르겠는데, C언어 계열에서는 각 변수가 컨텍스트 안에서만 존재한다는 규칙이 있습니다.
예를들면
여기서 BeginNumber는 For 문 밖에, innerVar 변수는 For문 안에서만 존재하는 변수죠.
그런데 파스칼은 이게 안됩니다. 모든 변수는 프로시져(혹은 메서드) 시작점에서 정의되어야 합니다. 즉, 각 변수는 필요한 컨텍스트가 있는데, 이걸 지정하는게 안되더군요.
그래서 또 포기.
드디어 대망의 Visual Basic입니다.
4GL 시대를 주름잡았던 툴이죠. 그리고 많은 초보자들을 프로그래밍의 세계로 이끌었던 툴이기도 합니다.
사실 Visual Basic 언어 자체가 그리 잘된 언어는 아닙니다만.. 언어에 비해서 IDE 수준은 높은 편이고, 필요한 기능을 COM 을 통해 아주 쉽게 확장할 수 있다는 면에서 너무 좋더군요. 여하튼 저는 원하는것만 할 수 있으면 되니까.. 라고 생각하고 대충 다 만들어 놨었습니다.
리스트 구현체가 동적 배열을 끊임없이 Allocation해야 하니까 불편하긴 한데, 이건 뭐 그냥 그럭저럭 쓸만하니까 무시했습니다.
그런데 이게 결정적으로 파일을 읽어들이는 CommonDialog 와 File Rename 하는 부분에서 버그가 있는 겁니다. (...)
처음에 파일 목록을 CommonDialog로 읽어들일때는 아무 문제가 없지만, FILE A as B로 파일 이름을 한번 바꾸고 나면 문제가 생깁니다. CommonDialog에서는 파일이름이 변경되었다고 나오는데, 실제로 탐색기에서 체크해보면 전혀 안바뀌는겁니다. (-_-)
제가 잘 몰라서 그러는건지, 아니면 NTFS 시스템상에서 제대로 작동을 안하는건지, 아니면 제가 패치를 안받아서 그런건지는 모르겠는데... 어쨌든 안됩니다.
게다가 이미 버림받은 언어기 때문에 (더이상 제품군 출시가 안돼죠..) VBA로만 살아남은듯하고요.
그래서 개발 툴을 약 열개를 깔아보고 테스트해보고 만들어보고 하다가 위에 언급했던 한계들로 인해 결국 포기하고 c#으로 만들수밖에 없었습니다. -_-
이과정이 약 13일 걸렸군요.
나머지 하루 정도는 테스트하고 간단한 설명글 넣고 하는데 투자했습니다. 뭐 프로그램 자체를 만드는 시간은 약 3시간 정도였고, 테스트하는데 그것보다 오랜 시간이 걸렸으니 TDD 가 되는건가요 (...)
그런데 다 만들어놓고 릴리즈해놓고 나니 이런 생각이 문득 듭니다.
지금은 사장되어 버린 툴을 쓰던 사람들은 다 어디로 갔을까.. 새로운 길을 찾아 VB.NET으로, 혹은 다른 언어를 선택했을까. 관리자로 변신했을까. 아니면 이바닥을 은퇴했을까..
IT는 정말 무섭도록 빨리 변화합니다. 하루밤만 지나고나면 신기술이 나와있고, 무슨 방법론이 이리 쏟아져 나오는지 이제는 이름도 못외우겠습니다. 과거에는 네트워크 컴퓨팅이라고 불리던게 뜬금없이 클라우드라는 이름표를 달고 나와서는 신기술이 되어버리고, 미묘한 부분만 바뀐 프로토콜은 이게 최고라고 선전합니다.
프로그래밍 언어는 (요새는 좀 덜합니다만 ) 여전히 마이너리그에서 미친듯이 쏟아져나오고 있죠. Rails가 유행할때는 모두가 루비를 할 줄 알아야 했고, 와우에 Lua가 쓰였다고 하니까 게임기획자들의 필수언어가 되어버렸던 기억이 있네요. (지금도 그런가요?)
ORM이 유행할때 자바 개발자들은 Hibernate 정도는 할 줄 아는게 기본이어야 했고 .net 쪽은 ado.net에 덧대어 Linq를 쓸 수 있어야 했죠. (공부할 시간은 대체 언제...)
게다가 웃긴게 이제는 다시는 사용하지 않을꺼라던 언어를 유지보수 과정에서 써야 할 일도 생깁니다. 멀리 볼 것도 없이 Y2K 사태 기억하시나요? 갑자기 Cobol 프로그래머 단가가 상상을 초월하게 올라갔었죠.
문득 생각합니다.
신기술이 나오는 건 좋고, 우리 (개발자)들의 삶을 편안하게 해주려는 목적은 잘 알겠지만, 이게 정말 나를 편안하게 해주는 길일까..하고요.
긴글 읽어주셔서 고맙습니다.
을 만들면서 느꼈던 것들입니다.
제작기간 : 자그마치 15일!
뭐가 이리 오래걸린걸까요?
1. 프로토타입.
완전 초 단순한 프로그램이라서 만드는데 별로 안걸릴 줄 알았습니다.
그리고 제가 가장 익숙하게 다루는 언어가 c#이라서 이걸로 뚝딱뚝딱 만들었죠.
프로토타입이 만들어질때까지 약 1-2시간정도 걸렸습니다.
2. 알파버전을 보여줬다.
그랬더니 바로 두가지 문제를 지적당했습니다.
2.1. 저 선택취소 버튼이 뭘 의미하는가?
선택취소 버튼을 누르면 어떻게 되냐고 묻더군요.
그 래서 선택취소 버튼은 말 그대로 이미 리스트에 올라가있는 파일들을 다 지워버린다고 말해줬습니다. 그랬더니 파일들을 체크박스로 선택하고 그 선택된것만 지워버리는게 어떻냐고 피드백을 줘서, 그렇게 고쳤습니다. 이렇게 뜯어고치는데 한시간 정도 더 소요됐고요.
2.2. 이 간단한 프로그램을 돌리는데 왜 1G 남짓이나 되는 프로그램을 설치해야 하는데?
닷넷 프레임워크는 인터넷에서 다운받아보면 약 1G 조금 안되는 용량을 가지고 있습니다.
그런데 제가 생각해도 막막한 겁니다. 도대체 왜 이걸 돌리는데 닷넷 프레임워크를 깔아야 한다고 설명할 수 있을까. 프레임워크 레이어라서 사실상 필요한 라이브러리가 다 그안에 들어있다..라고 말해줘야 하는데, 깊이 들어가다보면 설명이 너무 복잡해지더군요.
3. 다른 언어로 짜야겠다
그래서 다른 언어로 다시 짜야겠다고 생각했습니다. 최소한 복잡한 닷넷 프레임워크 필요없이 간단하게 동적 DLL링크시키는 방식으로요.
뭘로 짤까 고민좀 해봤습니다. 그리고 목록이 쭉 나왔죠.
4. Python은 어떨까.
Python으로 실제로 파일을 불러오고 변경시키는 논리 자체는 어렵지 않습니다. 오히려 C#에서 사용하는 제네릭 형식을 훨씬 편하게 쓸 수 있고, 제가 즐겨 사용하는 리스트 형식이 내장되어 있어서 프로그램을 개발하는데 편리하죠. 동적 언어의 특성때문에 조금 느리기는 하지만, 이 간단한 프로그램에는 별 상관없을꺼라 생각했습니다.
그런데 문제가 하나 생깁니다. 바로 괜찮은 IDE가 없다는 거죠. 저는 4GL 형식의 아주 심플한 화면 구성이 필요했습니다. 일일이 Tkinter 를 코드로 치고싶지는 않았어요. 간단하게 만들 수 있는거면 간단한게 최고다..라는 주의라서, 괜찮은 IDE가 있나 찾아봤습니다.
4.1. Boa-Constructor
이거야 됐어! 라고 생각했지만.. 왠지 모르게 작동하지 않았습니다(...)
BOA는 설치파일 형식으로 배포는 되지만, 실제 실행은 Lib 폴더 안에 들어가서 boa.pyw 을 실행해야 하는 형태입니다. 그런데 왠지 모르게 IDE만 뜨고 보아 자체는 전혀 실행되지 않았습니다. 그리고 Reference 를 영어로 봐야하는 압박 귀찮음도 있었고요.
물론 공식 그래픽 라이브러리인 Tkinter가 아니라 WxPython을 사용하는 거라서 바게님의 포스트를 참고하여 PyWin을 설치했습니다. wxPython은 python 3.1용 버전이 릴리즈된게 없어서 일단은 py27버전을 설치했고요. (이게 문제인지도..)
여하튼 되지 않습니다. 봵!
4.2 PythonCard
PythonCard는 제가 원하는 모양이 아니라서 포기.
4.3. KomoDo
ActiveState사의 KomoDo는 유료라서 포기 ($382 = 2011.02.23일 오후 4시 기준 428,604 원..)
5. Small Basic
Small Basic은 예전 GW-Basic의 추억을 생각하며 그냥 막코딩해볼까 하고 찾아봤습니다만, 그래픽 라이브러리는 있는데 너무 제한이 많고.. GOTO 문이 난무하는걸 보면서 포기...
게다가 재미있는 게, Small Basic은 퍼블리싱을 할 경우 Visual Basic .net 으로 자동으로 코드를 바꿔줍니다. 결국은 스몰 베이직도 닷넷 프레임워크가 실행시에 필요하단 얘기죠.
6. FBEdit
FBEdit 외에 FBIDE 프로젝트도 있습니다만... 만들다 만건지.. 사이트가 엉망이길래 포기.
그런데.. 이게 ... 너무 MFC 방식입니다.
윈폼 개발시에 C++ 로 하는것처럼.. 보라 윈폼이 시작할때 파라미터의 포인터 난무를....
처음부터 C++ 로 만들 생각을 안했던게, 너무 귀찮고 복잡하거든요. 논리를 세우는데 집중할 수 있는게 아니라, 컴퓨터가 어떤식으로 동작하는지를 먼저 머리속에 그리고, 그다음에 논리를 세워야 하는데.. 이걸 가능하면 피하고 싶었습니다.
7. Lazarus.
Lazarus는 Delphi의 오픈소스 구현입니다. 정확히 말하면, 위에서 말한 FreeBasic과 FBEdit의 관계처럼 FreePascal이라는 Object Pascal의 오픈소스 구현이 있고, 그 위에 Lazarus라는 IDE가 올라가는 형태입니다.
한때는 시대를 풍미했던 터보 파스칼의 기억을 되살려가며 한번 해보려고 했습니다만..
이게 IDE 기능 자체는 놀랍도록 좋습니다. 구현체 자체는 Delphi 2005랑 상당히 비슷하게 되어 있고, 기능도 훌륭해요. 인텔리센스도 잘 먹습니다. 그리고 4GL시대에 (한때는 Visual Basic과 어깨를 겨루었던) 맞춘 기능을 모조리 구현해놨습니다.
조금 특이한 것이, 각각의 창이 둥실둥실 떠다닙니다. 그러니까, 소스코드창은 소스코드창대로, Object Inspector 는 Object Inspector 대로, 디버거는 디버거대로 떠다닙니다. 위치를 잘 맞춰주지 않으면 어느순간 소스코드창에 가려져서 디버그 트레이스가 사라져 버립니다 (...)
이걸 포기한 이유는 두가지인데요.
하나는 디버깅 트레이스에서 조사식을 찍어보면, Object의 Property 와 Method 목록이 펼쳐지지 않아요. 저는 개체 하나의 값이 전체적으로 어떻게 변하나를 조사식으로 일일이 찍어보는 버릇이 있는데, 이게 힘들더군요.
다른 하나는 파스칼 언어 자체의 한계입니다. 이걸 한계라고 해야 할 지는 모르겠는데, C언어 계열에서는 각 변수가 컨텍스트 안에서만 존재한다는 규칙이 있습니다.
예를들면
int BeginNumber = 20;
For (int i=0;i<10;i++) { int innerVar = i + 2; BeginNumber += innerVar ;}
For (int i=0;i<10;i++) { int innerVar = i + 2; BeginNumber += innerVar ;}
여기서 BeginNumber는 For 문 밖에, innerVar 변수는 For문 안에서만 존재하는 변수죠.
그런데 파스칼은 이게 안됩니다. 모든 변수는 프로시져(혹은 메서드) 시작점에서 정의되어야 합니다. 즉, 각 변수는 필요한 컨텍스트가 있는데, 이걸 지정하는게 안되더군요.
그래서 또 포기.
8. Visual Basic.
드디어 대망의 Visual Basic입니다.
4GL 시대를 주름잡았던 툴이죠. 그리고 많은 초보자들을 프로그래밍의 세계로 이끌었던 툴이기도 합니다.
사실 Visual Basic 언어 자체가 그리 잘된 언어는 아닙니다만.. 언어에 비해서 IDE 수준은 높은 편이고, 필요한 기능을 COM 을 통해 아주 쉽게 확장할 수 있다는 면에서 너무 좋더군요. 여하튼 저는 원하는것만 할 수 있으면 되니까.. 라고 생각하고 대충 다 만들어 놨었습니다.
리스트 구현체가 동적 배열을 끊임없이 Allocation해야 하니까 불편하긴 한데, 이건 뭐 그냥 그럭저럭 쓸만하니까 무시했습니다.
그런데 이게 결정적으로 파일을 읽어들이는 CommonDialog 와 File Rename 하는 부분에서 버그가 있는 겁니다. (...)
처음에 파일 목록을 CommonDialog로 읽어들일때는 아무 문제가 없지만, FILE A as B로 파일 이름을 한번 바꾸고 나면 문제가 생깁니다. CommonDialog에서는 파일이름이 변경되었다고 나오는데, 실제로 탐색기에서 체크해보면 전혀 안바뀌는겁니다. (-_-)
제가 잘 몰라서 그러는건지, 아니면 NTFS 시스템상에서 제대로 작동을 안하는건지, 아니면 제가 패치를 안받아서 그런건지는 모르겠는데... 어쨌든 안됩니다.
게다가 이미 버림받은 언어기 때문에 (더이상 제품군 출시가 안돼죠..) VBA로만 살아남은듯하고요.
결국엔 ..
그래서 개발 툴을 약 열개를 깔아보고 테스트해보고 만들어보고 하다가 위에 언급했던 한계들로 인해 결국 포기하고 c#으로 만들수밖에 없었습니다. -_-
이과정이 약 13일 걸렸군요.
나머지 하루 정도는 테스트하고 간단한 설명글 넣고 하는데 투자했습니다. 뭐 프로그램 자체를 만드는 시간은 약 3시간 정도였고, 테스트하는데 그것보다 오랜 시간이 걸렸으니 TDD 가 되는건가요 (...)
그런데 그 많던 델파이, 비주얼 베이직 개발자들은 다 어디에 갔을까?
그런데 다 만들어놓고 릴리즈해놓고 나니 이런 생각이 문득 듭니다.
지금은 사장되어 버린 툴을 쓰던 사람들은 다 어디로 갔을까.. 새로운 길을 찾아 VB.NET으로, 혹은 다른 언어를 선택했을까. 관리자로 변신했을까. 아니면 이바닥을 은퇴했을까..
IT는 정말 무섭도록 빨리 변화합니다. 하루밤만 지나고나면 신기술이 나와있고, 무슨 방법론이 이리 쏟아져 나오는지 이제는 이름도 못외우겠습니다. 과거에는 네트워크 컴퓨팅이라고 불리던게 뜬금없이 클라우드라는 이름표를 달고 나와서는 신기술이 되어버리고, 미묘한 부분만 바뀐 프로토콜은 이게 최고라고 선전합니다.
프로그래밍 언어는 (요새는 좀 덜합니다만 ) 여전히 마이너리그에서 미친듯이 쏟아져나오고 있죠. Rails가 유행할때는 모두가 루비를 할 줄 알아야 했고, 와우에 Lua가 쓰였다고 하니까 게임기획자들의 필수언어가 되어버렸던 기억이 있네요. (지금도 그런가요?)
ORM이 유행할때 자바 개발자들은 Hibernate 정도는 할 줄 아는게 기본이어야 했고 .net 쪽은 ado.net에 덧대어 Linq를 쓸 수 있어야 했죠. (공부할 시간은 대체 언제...)
게다가 웃긴게 이제는 다시는 사용하지 않을꺼라던 언어를 유지보수 과정에서 써야 할 일도 생깁니다. 멀리 볼 것도 없이 Y2K 사태 기억하시나요? 갑자기 Cobol 프로그래머 단가가 상상을 초월하게 올라갔었죠.
문득 생각합니다.
신기술이 나오는 건 좋고, 우리 (개발자)들의 삶을 편안하게 해주려는 목적은 잘 알겠지만, 이게 정말 나를 편안하게 해주는 길일까..하고요.
긴글 읽어주셔서 고맙습니다.
TAG
boa-constructor,
c#,
cobol,
DE File Numberer,
Delphi,
FBEdit,
FBIDE,
FreeBasic,
Hibernate,
komodo,
Lazarus,
LINQ,
Lua,
ORM,
pascal,
Python,
pythonCard,
RUBY,
Small Basic,
visual basic,
개발자들은 다 어디에.. Ruby on Rails,
닷넷 프레임워크,
델파이,
라자루스,
레인레테,
보아 컨스트럭터,
비주얼 베이직,
스몰 베이직,
코모도,
파스칼,
파이썬,
파이썬카드,
프로그램 개발과정,
프로토타입
