본문 바로가기

97 Things Every Software Architect Should Know19

가장 큰 문제가 기술이 아니라 기회들을 잡을 수 있느냐이다. - Mark Ramm - 블로그 : http://compoundthinking.com/blog/ Mark Ramm은 TurboGears 2의 BDFL이며, 파이선 열광자이고, 전반적으로 굉장한 멋쟁이이다. 소프트웨어 아키텍트에서 네트워크 관리자, lobster-trap thrower, biker-bar cleaner에 이르기까지 상상할 수 있는 거의 모든 직업을 가졌다. 그는 프로와 아마츄어 프로그래머들이 더 생산성이 있게 도와주는 도구를 만드는 데에 열정이 있다. 지금 이순간에도 누군가는 급여 시스템을 구축하기 위해 실패하고 있는 프로젝트를 진행하고 있습니다. 아마 한 명 이상 있을 것입니다. 왜 그런걸까요? 자바 대신 루비를 선택하거나, Smalltalk 대신 파이썬을 선택했기 때문일까요? 혹은 오라.. 2009. 3. 12.
본질적인 복잡성을 단순화시키고, 예상치 못한 복잡성을 줄여라. - Neal Ford Neal Ford는 ThoughtWorks사의 소프트웨어 아키텍트이자 meme wrangler이고, end-to-end 소프트웨어 개발과 제공에 독점적인 집중을 하는 세계적인 IT 컨설턴트이다. 그는 어플리케이션, 교육자료, 잡지 기사, 교육용 소프트웨어, 비디오/DVD 프레젠테이션의 설계자/개발자이고, 5권 서적의 집필자이자 편집자이다. 그는 또한 수많은 컨퍼런스에서 강연했다. http://www.nealford.com 에서 여러분의 강한 호기심을 충족시킬 수 있다. 본질적인 복잡성에는 모든 문제에 포함되어 있는 어려움이 나타납니다. 예를 들어, 어떠한 국가든지 간에 항공 교통을 통제하는 것은 본질적으로 복잡한 문제입니다. 공중과 활주로에서 충돌을 방지하기 위해 모든 항공기의 정확.. 2009. 3. 11.
고객의 요구사항보다 당신의 이력에 더 우선순위를 두지 말라. - Nitin Borwankar - 블로그 : http://tagschema.com/blogs/tagschema/ Nitin Borwankar는 1990년 초반에 Ingres 와 Sybase에서 일했다. 그는 SybPerl과 OraPerl을 사용하여 가장 초창기 웹-데이터베이스 어플리케이션의 형태와 관련된 일을 했고, 곧이서 초기 엔터프라이즈 자바와 관련된 일을 했다. 그는 또한 새로운 EDI인 인터넷에서의 EDI에 대한 IETF 표준 절차에서 활발한 참여자였다. 1994년 이래로 독립적으로 컨설턴트와 연구자로 일을 했고 기업형 데이터와 메시징을 사용하는 통합에 초점을 맞추었다. 현재 관심사는 기업에서 태깅 (folksonmy) 어플리케이션에 대한 DB 스키마와 기업의 어플리케이션을 사용한 소셜 네트워크.. 2009. 3. 10.
반응형