서버개발자가 프로토타입을 만들때 유용할 듯. 물론 실무에도 적용 가능.
시간날 때 반드시 정독!
tiles와 sitemesh 사이에서 엄청 고민하고 있었는데, sitemesh로 해야겠네요.
Spring3 + MyBatis3 을 적용할 때 버전을 반드시 맞출 것.
http://www.mybatis.org/spring/
Spring ~ Mybatis ~ Mybatis-Spring 버전이 안맞으면 에러.
환경설정 부터 친절한 설명. 감사합니다.
스프링에서 제공하는 예제
‘시지프스를 다시 생각하다-신승환’을 읽고
10년간 일중독(?)으로 일년에 일주일 이상을 쉬어보지 못한 내게 적당한 휴식은 나를 돌아보는 계기가 되었다. 그리고 가족의 소중함을 다시 느끼게 되었다. 지금은 직장인들의 놀이터인 회사와 적당한 긴장감을 즐기며 앞으로 나아가는 것이 즐겁다.
시간날때 보면 좋을 듯…
"국내에는 수퍼개발자가 많다. 개발자가 분석. 설계, 코딩,빌드, 테스트, 기반시스템 관리 등 모든 업무를 가 한다. 그러나 그 말은 전문성이 없다는 말과 100% 일치한다.
…
소프트웨어 역사를 돌아볼 때 기술의 평균 수명은 3년이다. … 기술은 단기적으로 필요한 만큼만 배우면서 사는 것이 효율적이다.
…
SRS는 좋은 품질의 소프트웨어를 최소비용과 최소시간에 개발하기 위해 적는 문서다. 그게 목적이다. … IEEE에서 말하길 소프트웨어 개발에서 가장 중요하고 어려운 것이 SRS를 적는 것이라고 했다.
…
변하는 것들이 매력적이기는 하지만 오래 지속되는 진정한 자산은 아니다. 그런것은 필요시에 배우면 된다. 반면 소프트웨어에서 변하지 않는, 그래서 중요하다고 하는 것은 극히 간단하고 상식적인 것들이다. 예를 들어 ‘개발을 잘하려면 분석과 설계를 충분히 해라’, ‘동료검토를 하라’ 등과 같이 누구나 다 아는 예기다.
…
훌륭한 소프트웨어는 먼저 자신이 감동할 수 있어야 한다. 그러기 위해서는 소프트웨어 개발을 기술이 아닌 예술로 이해하는 자세가 필요하다.
…
소프트웨어를 개발하는 사람을 Software Engineer라고 하지 Software Technician 혹은 Software Scientist라고 부르지 않는다. 현실적인 제춤르 만들어 내는 것이 Software Engineer인데 사실 Technician이나 Scientist에 비해 남들에게 보여지는 것이 매력적이지는 않다.
…
프로세스 위주로 관점을 바꿔서 KPI를 정하는 것은 어떨까? 다음처럼 말이다.
1) 스펙은 적는가?
2) 동료검토는 자주 하는가?
3) 자기 관련 문서를 제대로 업데이트하는가?
4) 소스코드를 체크인할 때 주석을 제대로 남기는가?
5) 모든 버그나 기능 추가사항은 이슈관리시스템에 등록하고 일하는가?
이런 프로세스 관점의 평가지수를 사용하는 것이 훨씬 효과적이다."
…
소프트웨어 역사를 돌아볼 때 기술의 평균 수명은 3년이다. … 기술은 단기적으로 필요한 만큼만 배우면서 사는 것이 효율적이다.
…
SRS는 좋은 품질의 소프트웨어를 최소비용과 최소시간에 개발하기 위해 적는 문서다. 그게 목적이다. … IEEE에서 말하길 소프트웨어 개발에서 가장 중요하고 어려운 것이 SRS를 적는 것이라고 했다.
…
변하는 것들이 매력적이기는 하지만 오래 지속되는 진정한 자산은 아니다. 그런것은 필요시에 배우면 된다. 반면 소프트웨어에서 변하지 않는, 그래서 중요하다고 하는 것은 극히 간단하고 상식적인 것들이다. 예를 들어 ‘개발을 잘하려면 분석과 설계를 충분히 해라’, ‘동료검토를 하라’ 등과 같이 누구나 다 아는 예기다.
…
훌륭한 소프트웨어는 먼저 자신이 감동할 수 있어야 한다. 그러기 위해서는 소프트웨어 개발을 기술이 아닌 예술로 이해하는 자세가 필요하다.
…
소프트웨어를 개발하는 사람을 Software Engineer라고 하지 Software Technician 혹은 Software Scientist라고 부르지 않는다. 현실적인 제춤르 만들어 내는 것이 Software Engineer인데 사실 Technician이나 Scientist에 비해 남들에게 보여지는 것이 매력적이지는 않다.
…
프로세스 위주로 관점을 바꿔서 KPI를 정하는 것은 어떨까? 다음처럼 말이다.
1) 스펙은 적는가?
2) 동료검토는 자주 하는가?
3) 자기 관련 문서를 제대로 업데이트하는가?
4) 소스코드를 체크인할 때 주석을 제대로 남기는가?
5) 모든 버그나 기능 추가사항은 이슈관리시스템에 등록하고 일하는가?
이런 프로세스 관점의 평가지수를 사용하는 것이 훨씬 효과적이다."
—
글로벌 소프트웨어를 꿈꾸다 - 김익환
멋진 책이다.
스프링 프레임워크 설정을 쉽게 설명. 감사합니다.
