<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://mediawiki.zeropage.org/index.php?action=history&amp;feed=atom&amp;title=PyIde%2FSketchBook</id>
	<title>PyIde/SketchBook - Revision history</title>
	<link rel="self" type="application/atom+xml" href="https://mediawiki.zeropage.org/index.php?action=history&amp;feed=atom&amp;title=PyIde%2FSketchBook"/>
	<link rel="alternate" type="text/html" href="https://mediawiki.zeropage.org/index.php?title=PyIde/SketchBook&amp;action=history"/>
	<updated>2026-05-14T21:12:53Z</updated>
	<subtitle>Revision history for this page on the wiki</subtitle>
	<generator>MediaWiki 1.39.8</generator>
	<entry>
		<id>https://mediawiki.zeropage.org/index.php?title=PyIde/SketchBook&amp;diff=37965&amp;oldid=prev</id>
		<title>imported&gt;Unknown at 05:24, 7 February 2021</title>
		<link rel="alternate" type="text/html" href="https://mediawiki.zeropage.org/index.php?title=PyIde/SketchBook&amp;diff=37965&amp;oldid=prev"/>
		<updated>2021-02-07T05:24:08Z</updated>

		<summary type="html">&lt;p&gt;&lt;/p&gt;
&lt;p&gt;&lt;b&gt;New page&lt;/b&gt;&lt;/p&gt;&lt;div&gt;툴 Idea 관련 여러 생각들.&lt;br /&gt;
----&lt;br /&gt;
** 몇몇 생각 - 소스코드에 대해 flat text 관점으로 보지 못하도록 강요한다면, 구조적으로만 볼 수 있게끔 강요한다면 어떤 일이 일어날까. 어떠한 장점이 생기고 어떠한 단점이 생길까.&lt;br /&gt;
     &amp;#039;&amp;#039;스몰토크 비슷한 환경이 되지 않을까. 소스 코드의 구조적 뷰로는 LEO라는 훌륭한 도구가 있다. 크누스교수의 Literate Programming을 가능케 해주지. 나는 SignatureSurvey를 지원해 주면 어떨까 한다. --JuNe&amp;#039;&amp;#039;&lt;br /&gt;
        &amp;#039;&amp;#039;계속 생각했던것이 &amp;#039;코드를 일반 Editor 의 문서로 보는 관점은 구조적이지 못하고 이는 필요없는 정보를 시야에 더 들어오게끔 강요한다. 그래서 구조적으로 볼 수 있도록 해야 한다.&amp;#039; 였는데, SignatureSurvey를 생각하면 정말 발상의 전환같다는 생각이 든다는. (코드를 Flat Text 문서를 보는 관점에서 특정정보를 삭제함으로서 새로운 정보를 얻어낸다는 점에서.) --&amp;amp;#91;1002&amp;amp;#93;&amp;#039;&amp;#039;&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
Eclipse 쓰던중 내 코드 네비게이팅 습관을 관찰해보니.. code 를 page up/down 으로 보는 일이 거의 없었다. 이전에 VIM 을 쓰면서 &amp;#039;VIM 으로 프로그래밍하면 빠르다&amp;#039; 라고 느꼈던 이유를 생각해보면&lt;br /&gt;
* 짧은 손가락 동선 - I,J,K,L - 손가락이 멀리 갈 일이 없다.&lt;br /&gt;
* Source Folding - 화일 하나가 긴 경우라도 짧게 줄여놓고 쓰므로.&lt;br /&gt;
* search - Function 이동시 편리. 게다가 일반 텍스트 에디터에 비해 search 기능을 수행하는 비용이 작다. / 한번, 그리고 바로 키워드 입력. (다른 녀석은? Ctrl+F , 키워드 입력, enter &amp;amp; enter. incremental search가 아닌 경우는 한단계가 더 있게 된다.)&lt;br /&gt;
&lt;br /&gt;
하지만, 손가락 동선의 경우 - ctrl + O 를 누르고 바로 메소드 이동을 한다. 일반 이동도 메소드 중간 이동은 CTRL +커서키. (이는 VIM 에서의 W, B) 위/아래는 커서키. 클래스로의 이동은 CTRL+SHIFT+T. Source Folding 도 주로 Outliner 에 의한 네비게이팅을 이용한다면 별로 쓸 일이 없다. 보통 의미를 두고 하는 행동들은 클래스나 메소드들 단위의 이동이므로, 그 밑의 구현 코드들에 대해 깊게 보지 않는다. (구현코드들에 대해 깊게 보는 경우가 생긴다면 십중팔구 Long Method 상황일것이다.)&lt;br /&gt;
----&lt;br /&gt;
코드 에디터 사이즈는 큰게 좋을까? 또는, 코드 에디터 사이즈가 컸으면 하던 때는? 그 이유는 무엇이였을까? &lt;br /&gt;
&lt;br /&gt;
Python 으로 HTML Code Generator 를 작성하던중. 좀 무식한 방법으로 진행했는데, 원하는 HTML 을  expected 에 고스란히 박아놓은 것이다. 이는 결과적으로 test code 를 네비게이팅 하기 어렵게 만들었고, 해당 Generating 되는 HTML 의 추상도도 상당히 낮게 된다. 한화면에 보여야 할 HTML 데이터도 많아야 한다. 이는 결국 내가 에디터 창을 최대로 놓게 만들더니, 더 나아가 에디터 창의 폰트 사이즈을 11에서 8정도로 줄이고 모니터를 앞당겨 보게끔 만들었다. (15인치 LCD 모니터여서 해상도가 최대 1024*768 임.) 해당 상황에 대해 사람이 맞추는 것이 좋을까, 또는 툴의 Viewing 이 도움을 줄 방법이 있을까, 또는 사람이 이를 문제상황으로 인식하고 프로그램 디자인을 바꾸게끔 하는것이 좋을까.&lt;br /&gt;
&lt;br /&gt;
또는... 그냥 사람이 툴을 바꿀것인가. -_-; (상황에 대한 인식, 그리고 툴에 대한 선택을 하는 주체는 결국 사람이다.)&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
Wiki:FitNesse 의 맨 앞 문구 &amp;#039;Beyond Literate Programming&amp;#039; 이라는 말이 참 인상적으로 보인다. &lt;br /&gt;
----&lt;br /&gt;
현재의 UML Case Tool들은 Beyond Literate Programming 일까?&lt;br /&gt;
----&lt;br /&gt;
[[PyIde]]&lt;br /&gt;
&lt;/div&gt;</summary>
		<author><name>imported&gt;Unknown</name></author>
	</entry>
</feed>