Framework/Library/3rd-Library/SDK 등등에 대해서 많은 것들이 결국에는 Packaging 의 FRAME 을 설정하는데 있는 것으로 생각이 됩니다... 


거의 많은 기술의 Pallett 에 대해,, 


그것이 그저 Pallett 이기 때문에 어느정도의 Specification 에 대해서 Context 수준에 대해 닫혀있는 것이 사실인 것같습니다. 


기본적으로 이러한 기술들이 무엇인가? 라는 의문에 대해,, 


많은 분들이 생각을 하기를 C 언어에 대해서 생각을 하거나 WinAPI 등을 생각하기도 합니다.... ^^


결과적으로 이것도 하나의 APIs 에 대한 객체가 되는 것이고 그렇지 않다고 해도,, 


Frame 에 대한 Complete-ness 를 얻어내는 것이 APIs 에 대해 작업공간을 만들어내는 일에 대해서 조잡하다는 말이 나올 수도 있는 것에 대해서는 


그래도 일단락을 시키자면,, 대부분이 System 아래의 상황에서 프로그램이 동작하는 Parts 로 일이 이루어지기를 기대하는 경우가 많습니다... 


만약에 Program 이 Parts 가 될 수가 없다면 대부분의 APIs 의 기기성에 대해서 일이 성립을 할 수가 없습니다. ^^


결국에는 어느정도 단순하고 별 것없어 보여도 이러한 Framework/Library Combination Frame/Software Development Kit 를 쓰는 이유가,, 


Systemic 한 Frame 을 잡아놓을 수가 있기에 다른 Programmer 에 대해 의존하는 형세에 있는 것이 대부분의 Normal 프로그래머들입니다. ^^;;


그래서 이러한 Systemics 가 많이 있을 수가 있는가? 에 대해서는 Object To/From 에 대한 명령어로써,, 


대부분의 Computer Logic 을 Utilize 시키는 것이 대부분의 이러한 Framework/Library Combination/Software Development Kit 이기 때문에,, 


추상화의 고급성에 대해서 당연히 한계에 부닺칠 수 밖에 없고 범위의 크기에 대해 한계분량이 있는 것은 확실합니다. 


그래서 이 부분에 대해서는 <<Computer Process Utilization Packaging>> 이라는 관념이 성립을 하고 많은 용어들이 이러한 Packaging 아래에서 


잔존한다고 할 수 있는 것이 Normal 프로그래머의 사실들이 있다고 보이는 형세가 적지가 않습니다.... 


결과적으로 이것도 또한 Utilization 에 대한 Package 입니다..... ^^; 


Package 의 무한반복은 좋지를 않거나 애초에 시도가 잘못되었다고 취급을 해야하고 고급화를 시도를 해야합니다. 


그런데 일단의 것에 이러한 Package 에 대해 그것은 Object 라는 가상의 기구를 사용할 수 밖에 없는 것이 당위적이라고 하기에는 확실히 분명합니다.... 


결과적으로 Utilization 에 대해서 Objectify 의 한계분량은 확실히 있어 보입니다... 


적어도 저수준의 Computer Ability 에 대해서는 흔히들 <<운영체제>> 라는 것에 대해 Runnable Environment 가 성립을 한다는 것이 주로는 


Middleware 가 이러한 평가맥락에서 용어로써 자리잡고 있습니다.... ^^


그렇다면 이러한 Middleware 위에서 Runnable Object 에 분량수준의 한계가 있을 것이어야 합니다.. 


그런데 대부분의 Computer Interface 에 대한 수준의 추상화를 만들어놓는 Object 가 이러한 <<Program Utilizing Package>> 라고 볼 수가 있습니다. 


그래서,, 대부분의 APIs 에 비스무리한 것들에 대해서는 모든 것이 Computer Interface 를 설계하기 위함에 대해서 있다고 볼 수가 있습니다. 


구체적인 Algorithms 이 잔재할 수 있는 것을 제외한다면 Middleware 를 사용한다는 전제에서는 이러한 바가 틀림이 없는 사실입니다. ^^;;;


그렇다면 대부분의 이러한 Package 가 무엇의 대응이 되는 Package 인가? 를 따져볼때, 그것은 Runnable Interface 라고 생각이 듭니다. ^^


그렇다면 그러한 <<Runnable Interface>> 에 대해서 Programmer 는 무엇을 작성을 해야할까요?? 


일단의 Complete-ness 에 대해 Programmer 가 Packaging 을 하는 일에 대해서 많은 것들이 그렇게 복잡하지가 않고 Linker 만 설정이 어려울 수 있지만 


그 정도는 거의 대부분의 인터넷에서 보여지는 상황에 대해서는 충분히 간편한 것같습니다..


그렇다면 <<Runnable Interface>> 에서 구현을 해야할 것에 대해 Package 자체는 일단 숙지만 하면 복잡하고 분량이 많아도 상관은 없습니다. 


어디에 Recipe 처럼 적어놓고 다시 기억을 잘 하려고 하면 그냥 충분합니다...


그렇다면 중요한 것은 <<Runnable Interface>> 에서 <<Interaction>> 을 <<Interaction Execute>> 시키는 것이 대부분의 진짜 Programmer 의 일이 


되는 것입니다. 


결과적으로 Programmer 가 C 언어로 저수준을 Master 한다니, Java 할 줄 안다. 라거나, 크게는 REST APIs 를 할 줄 안다. 등등에 대해서 그것은 


그렇게 중요하지 않고 사실 병신 짓거리입니다. 


Node.JS 가 뭐니 어쩌니, CUDA 배우고 싶다니, 그것은 그냥 배우면 되는 것이지만 자료가 부족한 것같기는 합니다. React 고수다. 이런 것은 그냥 필요없습니다. 


^^


배우는 것이 복잡하고 처음 나타나는 생소한 문법과 버그수정의 어려움 등등이 많을 수는 있지만 대강 지금 쯤에는 다 필요가 없고 A.I 의 존재가 이를 


보충해주기에 시대적으로 기술이 충분하고 배우기도 A.I 의 존재로부터 일이 쉬워졌습니다.. ^^;


그래서 Interaction Cycle 이라는 것이 중요합니다. 이 부분에 대해서 대부분의 Package 의 부분들로 부터 진짜 <<구현>> 할 것이 나타나는 것입니다. 


대부분의 Programmer 들은 행거의 Cycle 에 대해서 전산처리에 의한 빠르고 동시적이며 전환이 가능한 Cyclic System 을 구현을 해야합니다. 


대부분의 그것이 정보처리라기 보다는 정보처분에 대한 전산 Cycle 을 설계하는 것입니다. ^^;; 


나머지는 그저 Network 나 User Interface 그리고 Reaction Cycle 등등을 (대부분이 Reaction Cycle 이기는 함.) 만들어내는데 있어서,, 


<<문법적인 고생>>이 있을 뿐입니다... 



Thank you 1234