Software Development

The Secret Source of Google’s Power
http://blog.topix.net/archives/000016.html
 
처로군이 보내준 link. 제목 그대로 구글 파워의 원천을 세가지 정도로 기술하고 있다.
 
첫번째로, 하드웨어의 실패를 소프트웨어로 커버한다는 철학. 이러한 철학의 한 예가 바로 Google사의 proprietary distributed, fault-tolerent, petabyte filesystem인 Google Filesystem이라고 한다. 디스크나 머신 하나가 고장나면, 직접 교체하는 것이 아니라, 자동으로 replication이 추가되고, 다른 시스템이 그 역할을 대신하는 것이다.
 
두번째는, 값싼 하드웨어를 사용한다는 것. 이건 현재의 우리나라 웹 서비스 업체들에서는 보편적인 현상이므로, 굳이 많이 설명할 필요는 없을 듯 하다. 네오위즈도 이것을 네오위즈를 성공하게 만든 커다란 요인으로 보고 있는 것으로 알고 있다.
 
세번째, OS researchers. 구글의 엔지니어들은 OS, networking, distributed systems, compiler optimization, thread migration, distributed shared memory에 research background를 가지고 있다. 위 아티클에서 다음 말을 인용하고 싶다.
‘Wouldn’t it be great, as an engineer, to have production versions of all this great research.’
내가 만약에 컴퓨팅에 관련된 엔지니어로서 계속 남는다면, 바로 저런 모습을 목표로 삼을 것이다.
 
구글은 연구실로부터 자신의 시스템을 구축할 때까지, 10년간의 system software research를 행했다고 한다. 과연 우리나라의 성공적인 IT 기업들 중 어느 누가 10년을 내다보고 system software 기술에 투자를 할 수 있을까? 반면에, 10년 후 유명해질 어느 누군가는 어느 초라한 연구실에서 연구를 하고 있을지도 모를 일.

http://www.notes.co.il/benbasat/5240.asp
 
기존의 테스트와 구분되는 것은 각 pigeon의 load를 증가시켜서 TCP(Transmission by Carrier Pigeon)가 ADSL보다 빠른 transfer rate를 가질 수 있음을 증명하기 위한 목적으로 수행되었다는 것이다. 세마리의 pigeon에 4GB이 data를 적재함으로써 약 2.27Mbps의 bandwidth를 증명했다. (원래 ADSL은 0.75-1.5Mbps)
 
Some Fun!
 
사진과 함께 “Scalability achieved by natural reproduction“이란 comment.
 

 
 
 
 
 
 
 
 
 
마지막엔 이런 comment도…
Note: In a case of emergency when you cann’t find pigeons, use chickens.
링크는 ‘The Teach Your Chicken to Fly Training Manual’이란 책의 아마존 페이지. (어..어째서 저런 책도 존재하는 건지…)
 
Reference
 
RFC1149: A Standard for the Transmission of IP Datagrams on Avian Carriers
http://www.ietf.org/rfc/rfc1149.txt
 
The highly unofficial CPIP WG
http://www.blug.linux.no/rfc1149/
 
RFC 2549: IP over Avian Carriers with Quality of Service
http://www.ietf.org/rfc/rfc2549.txt
 
CNET: Pigeon-powered Internet takes flight
http://news.com.com/2100-1001-257064.html?legacy=cnet&tag=mn_hd
 
Pigeons Enabled Internet – Technical Appendix
http://www.notes.co.il/benbasat/5265.asp

얼마전(3월 11일자) 최근의 security product들이 DDOS(distributed DOS)에 대한 대책으로 counter attack을 선택하는 것에 관한 slashdot article을 읽었는데, 다음 comment들이 그야말로 예술.
 
 Can you see the tech guy trying to explain that their company was knocked off, not by the attack, but by the counter attack? “It’s okay, sir. It was friendly fire”.
 
 this is the stupidest idea i’ve heard of in a long time – if you have the network infrastructure to try and launch a DDOS attack, then you probably have the ability to survive and/or defend from DDOS attacks without resorting to insanity like this. Of course, companies in the US will probably love this, it fits well with their governments’ ‘first strike’ foreign policy directives as pushed by Mr S…
 

IFF for DDOS는 세라비군과 케케(4quake; amister; 대체 정체가 뭐냐)군과 이 주제에 대해 대화하다가 케케군이 제안한 만우절 RFC 거리. DDOS나 DDOS에 대한 counter-attack에 있어서의 위와 같은 문제점 때문에 DDOS를 수행하는 agent는 자신이 공격하고 있는 호스트(or some entity)가 공격을 의도한 호스트, 즉 적군이 맞는지 확인하는 방법이 필요하다. flight simulation에 관심있는 사람이라면 알겠지만, 이렇게 적군과 우군을 식별하는 것을 IFF(Identification Friend or Foe)라고 부른다. IFF가 보편화된다면, 당연히 IFF system을 기만하는 (즉, foe이면서 friend를 칭하는) spy agent도 생길 것도 예측해볼 수 있다.
 
DDOS에 있어서 대체로 target은 매우 좁은 범위에 한정되기 때문에, DDOS에 IFF가 실제로 필요한 경우는 매우 드물다는 생각이 들긴 하지만, 언젠가 인터넷 상의 전쟁이 벌어질 때가 온다면 DDOS외에도 IFF가 활용될 곳은 의외로 많을지도 모르는 일 아닌가 (웃음). 이를 위해서, IFF는 rules of engagement를 따르기 위한 시스템의 일부일 뿐이기 때문에, DDOS agent간의 명령 체계를 구축할 수 있는 시스템을 보완할 필요가 있을 듯 하다. 미래에는 이런 시스템들에 의해 자동화된 agent들의 대규모 전투 사례를 보게될런지도 모른다. (점점 생각이 fiction으로 흘러가고 있음)
 

자신의 관심분야를 프로필에 설정하고 검색하면, 관심분야에 personalized된 검색결과를 얻을 수 있다. 사용자가 직접 관심분야를 명시하기보다는 사용자가 클릭하는 패턴에 따라, 관심분야를 자동으로 알아내도록 하면 더욱 좋지 않을까..
 
검색 하나로 참으로 여러가지를 시도해보는 구글, 부럽다!
 
http://labs.google.com/personalized/
 
@ url을 보면 알겠지만 베타 상태의 lab 서버이기 때문에 검색결과를 가져오는데 시간이 걸린다.

Engineering이 발전하는 양상은 자연 과학이나 인문학이 발전하는 것과는 다르다. Enginering을 구분짓는 조건 중 하나는 저비용이다. 저비용을 획득하는 가장 쉬운 방법 중, 하나는 단순성(simplicity)을 달성하는 것이다.
 
단순성을 확보하는데에는 역시 다른 비용(단순성 이면의 복잡성)들이 들게된다.
주요한 것으로 생각되는 것은,
– 경험(experience; 예측 가능한 것은 단순해진다),
– 경험에서 파생되는 감각(sense; 단순성을 얻어낼 수 있는 six sense), 그리고
– 패러다임의 변환(paradigm shift; 제약받는 단순성을 해방시키기)
라고 생각된다.
 
세가지의 목표 모두 성취하기 어려운 것들이다.
하지만, 그 중 경험과 감각은 노력과 시간을 필요로 하지만,
패러다임 변환은 +alpha가 필요한 것이 아닐까. 더 고민해볼 것.
 
—
 
Engineering의 표면에 있는 단순성의 미학에 매료되어, 중요한 것을 보지 못하는 것은 아닌지 고민해보아야겠다. 어제 재민군의 비판에 뜨끔하여 아침에 생각난 것들을 적어보다.
 

Aspect-oriented programming: Introduction
http://portal.acm.org/citation.cfm?id=383853&coll=Portal&dl=GUIDE&CFID=18628671&CFTOKEN=48022287
 
OOP has difficulty

– localizing concerns involving global constraints and pandemic behaviors
– segregating concerns
– applying domain-specific knowledge
 
POP (Post-object programming) mechanism

– domain-specific languages
– generative programming
– generic programming
– constraint languages
– reflection and metaprogramming
– feature-oriented development
– view/viewpoints
– asynchronous message brokering
 
AOP(aspect-oriented programming)

– one important POP technology
– computer systems are better programmed by separately specifying the verious concerns of a system and some description of their relationships and then relying on mechanisms in the underlying AOP environment to weave or compose them together into a coherent program
– attempts to realize scattered converns as first-class elements and eject them horizontally from the object structure
– forcusd on mechanisms for simplifying the realization of cross-cutting converns
 
AOP vs. subprogram
 
subprogram: a concern whose code becomes tangled into other structural elements becomes a mess
AOP: aspect, weaving aspects and base code into coherent system
 
subprogram: require both knowledge and cooperation on the part of the programmers of the calling components
AOP: offer implicit invocation mechanisms for invoking behavior in code whose writer were unaware of the additional concerns
 
AOP goals
simpler system evolution, more comprehensible systems, adaptability, customizablity, and easier reuse
 
AOP issues
 
– clear-box approach
AOP can examine the program and aspect internals, producing a mixture of program and aspects
– black box approach
shroud components with aspect wrappers
 
– How an AOP system specifies aspects
– What composition mechanisms the system provides
– Implementation mechanisms
– Decoupling
– Software process
 
history of AOP
 
Karl Lieberherr (early researchers in the field)

The Law of Demeter: Objects shoud only have knowledge of closely releated objects
“Aspect-Oriented Programming with Adaptive Methods” the use of adaptive methods to avoid tangling by abstrating over the class structure
 
William Harrison and Harold Ossher

– separate specification of different class hierarchies, each implementing a concern with subsequent composition of appropriate hierarchies to build system varients (subject-oriented programming)
 
Peri Tarr

– allow multiple, simultaneous decompositions of the same software, extraction of concerns from existing software
– “Using Multidimensional Separation of Concerns to (Re)shape Evolving Software” by Ossher and Tarr
 
Mehmet Aksit and his group at Twente Univ.

– the earliest and most prominent proponents of filter-based approaches to AOP.
(In the late 1980s) filter principle was developed to express a generic data abstration mechanism)
– Bergmans and Aksit’s article “Composing Multiple Concerns Using Composition Filters”
how to embody aspects in explicit filters, by wrapping the filters around base components
 
AOP group at Xerox PARC
– the focus on crosscutting concerns is what distinguishes AOP from previous speration of concerns technologies
– developed a series of AO languages, culminating in AspectJ – “Getting Started With AspectJ”

Further Readings
 
the value of AOP technology
“Analyzing the Role of Aspects in Software Design”
“Does Aspect-Oriented Programming Work?”
 
discussions of the applications of AOP to systems development
“Structuring Operating System Aspects”
“A Layered Approach to Building Open Aspect-Oriented Systems”

the application of AOP to virtual design
“Handling Crosscutting Constraints in Domain-Specific Modeling”

an overview of using reflection techniques to implement aspects
“Aspect-Oriented Programming Using Reflection and Metaobject Protocols.”
 
Reference
 
Aspect-Oriented Software Development Web site
http://aosd.net/

KeKe군과 대화中, 현재 소장하고 있는 E-Book들을 제대로 활용하기가 힘든 이유 중 하나가, E-Book들의 메타 정보가 부족하고, 검색이 힘들기 때문이라고 생각이 들었다.
그래서 구상한 E-Book 관리 시스템의 functionality들을 적어보면…
 
1) E-Book의 commit 시스템.
 
E-Book을 파일 이름을 기반으로 아마존에서 해당 ISBN을 찾아냄.
(E-Book들의 파일 이름은 일반적으로 책의 제목으로 되어있다는 가정)
이 과정에서 human intervention이 있을 수 있으나, 여러 ISBN 중 맞는 것을 선택하는 것 외의,
대부분의 작업은 자동화 가능.
 
2) ISBN을 기반으로 해당 E-Book의 (아마존에서) 메타 정보를 얻어와서 cache.
 
3) E-Book 파일과 메타 정보의 효율적인 추가/삭제.
 
4) E-Book을 검색할 수 있는 웹 인터페이스.
 
구현의 대부분은 특정 DB와 아마존 Web Service API,
E-Book의 메타정보를 나타낼 XML 정도로 가능해보인다.
 
기능들은 단순하지만, 이런 정도의 시스템만 있어도,
여러곳으로 산재되어 관리하는 E-Book들을 지인들끼리 모아서,
다른 여러가지 시너지 효과를 기대할 수 있을 듯.
 
—
 
언제나 불편한 것들에서 아이디어들은 많이 생각해내지만, 실제로 완전히 구현하는 일은 드물다.
(나는 기획자적인 인간인가? -_-)
대체로 GUI의 벽이 가장 크다고 볼 수 있는데, 이 벽을 깨내는 방법이 없을까. >.<
최근에는 XUL을 통해 타개할 수 없을까 고심中.
 
Amazon Web Service
http://www.amazon.com/gp/browse.html/104-5247989-7236768?node=3435361