Sangpil Research

Terminal.

Check the version of Apache : https – v

Apache restart : sudo apachectl graceful

Apache stop : sudo apachectl stop

Apache start : sudo apachectl start

PHP

Check the version of PHP : php -v

Check this post when php doesn’t work properly.

MySql

Check  MySql version : mysql –version (usr/local/mysql/bin/mysql)

Export Path : echo ‘export PATH=$PATH:/usr/local/mysql/bin’ >> ~/.bash_profile

Export Path Check : cat .bash_profile

Setup Root Password : sudo mysql_secure_installation

That’s because the main key feature of this project is Organizing thoughts and facts on image which is gathered by personal user.

Web Standard. : HTML5

Define the class structure of animated object.

AC3 – PHP – MySql  한글 문제 해결.

Image Upload -> Byte Array -> SQL

Image File Upload-> DIR

2D map base.

3D map base.

Geo map base.

DB structure.

Bitmap Drawing Class.

Vector Drawing Class.

Definition about Time

PHP Class to control DB.

Vector Shape Series.

RSS(google) feed.

Connect Twitter API.

Connect Facebook API.

Log in Structure.

Arrange Sets

Definition of Selecting.

Control Clip Board on Air.

어떻게 생각을 공유할 것인가.

어떻게 상기시킬 것인가.

어떻게 자료를 배치할 것인가.

정보를 어떻게 모을것인가.

기본적인 목적은 (1)외부로 부터 관찰되는 자료의 수집 및 (2)일상 속에서 드는 단편적인 생각들을 기록하고, (3)이를 재구성 함으로서 (4)내 생각을 정리하고 이러한 (5)사고과정을 쉽게 상기시킬 수 있는 표상을 부여한다. 동시에 축적된 사고의 지도를 통해 타인에게 (6)맥락적인 형태로 발표할 수 있어야 하며,  (7)각 사고 단계가 분절되어 타인과 공유할 수 있는 것 이어야 한다.

이 과정은 가능한 실용적이여야 하며 따라서 반드시 Be as clear, straight forward, and comprehensible as possible 해야한다..

시작하게 된 이유는 최근 일상이나 인터넷 망을 통해 접하게 되는 많은 양의 정보를 스스로 종합하고 나만의 결론을 도출하는데 어려움을 느껴서이며, 동시에 스스로 판단한 관점들의 근거를 가능한 편리하게 확보하고, 이를 발표에 적극적으로 활용하기 위해서이다.

비단 생각을 발표하는 것 뿐 만 아니라 주어진 프로잭트 진행시 검토된 체크포인트를 상기시키기위한 용도로도 좋을 것이다.

현재 내가 크게 인식하는 형태는 이런듯.

시각 개체를 이루는 각각의 단계에서 데이터가 직접적으로 관여하고 있는점도 모든걸 어지럽게 만들지만, 이들간의 이벤트를 교환하는 부분도 상당히 버겁다. 가장 큰 이유는 양이 많기때문.

재사용과 클래스의 독립성을 위해 Factory 패턴으로 부분 부분 시도해 보고 있는데, interface 와 creater 를 상황에 맞게 적절하게 적용하기가 힘들다. 추상적인 부분에서는 합의를 볼 수 있겠지만 실제적으로 사용하는데는 무리가 따르는데다 양적으로 지나치달지. 실력이 부족한 탓이겠지만, 지금쯤이면 어느정도 내가 찾는 해법의 가능성은 보여줘야 할 맛이 나는게 아닐까. 결국은 하나 하나 노가다로 해결을 봐야하는 건가.

다만 계속 드는 생각은 구성요소의 기본적인 속성들을 체계적으로 잘 정리해 두고 개념을 잘 정립해 둘 필요가 있는 것 같다.

계획(Planning) -> 작업(Work) -> 검증(Verifing)

보통 작업 시작 전에 확실했으면 하는 것들은 다음과 같다.

1. 이것의 목적이 뭐냐 : S
2. 어떤 방법을 쓸거냐 : P1
3. 이에 들어가는 구성요소 뭐냐 : P2
4. 구체적으로 어떻게 할거냐 : p3

작업 진행 중 항상 듣는 질문은 다음과 같다.

1. 언제까지 할 수 있나 : Total Play Time
2. 어디까지 했나 : Current Time Marker
3. 지금 뭐하나 : P

작업이 끝난 뒤 검토하는 것들은 보통 다음과 같다.

1. 잘 작동하나 : V1
2. 잘 연동 되는가 : V2
3. 쓸만하나 : V3

이를 간단히 도식화 해보니 아래와 같다.

추상적인 과정들은 파란색으로, 실질적인 작업은 녹색으로 해 두었는데, P 부분은 Total Play Time 안에 있는 요소라고 봐야할 듯 하다. 다시 그려야 할듯. 어쨌거나, 논리적인 계획 및 검증 과정이 진행됨에 따라 실제 작업 시간이 영향을 받는다. 그리고 Process(P)단계는 이 전체구조를 하위 구조에 복제하여 끝없이 반복될 수 있다. 사실 전체 시간이란 시계에서 표시되는 것 과 같이 절대적인 시간으로서 프로잭트에 들어가는 시간 외에 다른 요소들, 밥먹는 것이나, 수면시간 등등을 모두 포함한 완전한 시간의 개념이다. 즉 주제에 의해 엮이는 시간이 아니다. (이같은 관점 : 일년은 365일, 하루는 24시간, 1분은 60초.) 따라서 실생활에서 쓰이는 시간에 따라 한 프로잭트에 들어가는 계획 과정에 영향을 준다라고 막연하게 잡아본다. 엉성한 스케치지만 계속 관찰해 봐야지.