lagacy code 책을 보면...
CppUnitLite 라는 단위 테스트 도구가 나옵니다.
그때 코드는 쉽게 다운로드 받을수 있습니다.
http://c2.com/cgi/wiki?CppUnitLite
코드가 대충 아래와 같습니다.
예를들어 TEST( Stack, creation ) 이라고 치면
아래와 같은 이름의 class 가 만들어지네요...
class creationStackTest
class <group><test>Test 와 같은 이름입니다.
C 코드에서 test 이름을 <group> + <test> 조회해보는것이 가능합니다.
그런데 . Programming Gems 에서 본 autotest pattern 코드도 이와 비슷합니다.
2014년 11월 20일 목요일
2014년 11월 19일 수요일
DSL(Domain Specific Language)
일러스트러티브 프로그래밍
DSL (마틴파울러) 책을 읽다보니 일러스트러티브 프로그래밍이라는 이야기가 나옵니다..
이게 script 짜는것보다 엑셀로 표를 만들어서 보면서 작성하는게 10배는쉽다는 이갸기 입니다.
무언가 자동화를 할때도 완전감춰진채로 자동화 하기보다는 눈으로 볼수있는
중간 결과물로 무언가를 만들어주는게 좋은것 같습니다.
(원본소스) ---> (사람이 볼수있는 무언가) ---> 실행
프로젝티브 프로그래밍
이건 intentional workbench 라는 제품이 있는것 같습니다.
보아하니 새로운 Domain 에 최적화된 언어를 만든는 toolbox 같은데요.
언어의 구조를 객체(object) 에 투영(project) 하면서 설계하는 환경인듯 보입니다.
동영상:
SoC 에서는 PrimeTime 이라는 tcl 로 최적화된 STA(Static Timing Analysis) 언어가 있는데요. 이건 Timing close 할때 쓰는 언어입니다.
개인적으로는 마음에 들지 않습니다. 너무 자유도가 높은 나머지 결국
SoC 에서 는 STA(Static Timing Analysis) 는 통합시 표준화에 실패하는것이죠.
따라서 회사들은 어떤형태로든 STA 를 DSL 형태로 표현하게 됩니다.
억지로 표준화를 하려하지만 결코 깔끔하지는 않죠.
오히려 Xililx 의 UCF format 이보다 STA domain 에 특화되어있다는 느낌이 있습니다.
여기에는 어떤 자유도도 없기때문에 오히려 통합하기에 유리합니다.
하지만 UPF 도 단점이 있는데, 자유도가 너무 없는 나머지 지원 안되는 clock scheme 이 나오면 적용이 안된다는 단점이 있습니다.
따라서 어쩔수 없이 SoC 업계에서는 PrimeTime tcl 을 사용할수밖에 없는것 가네요.
2014년 11월 14일 금요일
perl, ruby, python 비교
perl, ruby, python 비교
뭘 써야할까요??
일단 google trend 를 돌려볼까요?
아래와 같네요.
perl 은 완전 하향 곡선(perl의 개발자인 래리왕께서도 이제 perl 보다 ruby 라고 인정했다는 걸 어디서 본것 같네요)
ruby 는 rails 나오면서 인기가 올라갔다가 요즘 잠깐 시들하고
python 은 요즘 점점 인기가 높아지네요.
python 은 각종 tool 들이 많이 open 되어서 탄력받고 있는것 같습니다.
( frame work 구축에 python 이 매우 용이한것 같습니다. 아마도 아직 ruby 가 안정성 면에서 불안한 면이 있기 때문인것 같습니다.)
개인적으로 최고의 script 언어는 ruby 라고 생각합니다. (perl을 알고 있다면 ruby 를 사용하세요) 그런데 가끔씩 메모리를 무식하게 쓰면 Segmentation Fault 가 발생할때가 있어서
안정성은 아직 떨어져 보입니다. (하지만 SoC 개발시에 사용할 정도면 괞찬죠 ㅎㅎ)
주제
perl
검색어
ruby
검색어
python
검색어
+검색어 추가
시간 흐름에 따른 관심도 변화
예측
뉴스 제목
심리학적 관점에서 ruby 인가? python인가?
python장점큰 규모의 회사에서 장기적 생산성을 본다면 python 이 좋다고 생각합니다.
코드 분석시에 code reading 은 python 이 매우 쉽습니다.
아마도 google 이 python을 계속 사용하는이유가 이러한 장기적 생산성 때문이라봅니다.
파이썬의 철학대로 하나의 일을 하는 방법이 하나만 있으면,
장기적으로 심리적 오해로인한 버그가 없어집니다.
(프로그래밍 심리학적인 관점이지요. )
ruby장점
이타적인게 중요한데, ruby 는 프로그래머의 행복을 위한 언어이다 보니 ruby를 사랑하는 사람이 많습니다.
아마 장기적으로 많은 사람들이 기여를해서 천천히 발전할 언어라 봅니다.
ruby는 대부분 reading 이 python보다 간결할수가 있으나.
가끔식 자유로움을 지나치게 사용한경우 python과는 달리 읽기가 어려워질수가 있습니다.
결론은?
프로그래머 개인 입장에서는 ruby가 좋고
회사 입장에서는 python이 좋네요. ( 비자아적 프로그래밍 ... )
전 ruby 씁니다.
프로그래머의 실력이 느는 관점에서보면 ruby가 빨리 느는것 같네요.
ruby 덕분에 많은걸 배웠습니다.
예를들어 raise 등의 예외처리도 쉬워서, 이제는 예외 처리가 아주 능숙해졌습니다.
Date | perl | ruby | python |
---|---|---|---|
Fri Jan 16 2004 12:00:00 GMT+0900 (대한민국 표준시) | 94 | 40 | 48 |
Sun Feb 15 2004 12:00:00 GMT+0900 (대한민국 표준시) | 100 | 44 | 47 |
Tue Mar 16 2004 12:00:00 GMT+0900 (대한민국 표준시) | 96 | 42 | 46 |
Fri Apr 16 2004 01:00:00 GMT+0900 (대한민국 표준시) | 94 | 39 | 46 |
Sun May 16 2004 12:00:00 GMT+0900 (대한민국 표준시) | 89 | 42 | 44 |
Wed Jun 16 2004 00:00:00 GMT+0900 (대한민국 표준시) | 91 | 43 | 44 |
Fri Jul 16 2004 12:00:00 GMT+0900 (대한민국 표준시) | 91 | 44 | 45 |
Mon Aug 16 2004 12:00:00 GMT+0900 (대한민국 표준시) | 88 | 40 | 43 |
Thu Sep 16 2004 00:00:00 GMT+0900 (대한민국 표준시) | 86 | 34 | 45 |
Sat Oct 16 2004 12:00:00 GMT+0900 (대한민국 표준시) | 80 | 32 | 45 |
Tue Nov 16 2004 00:00:00 GMT+0900 (대한민국 표준시) | 76 | 31 | 42 |
Thu Dec 16 2004 12:00:00 GMT+0900 (대한민국 표준시) | 73 | 33 | 43 |
Sun Jan 16 2005 12:00:00 GMT+0900 (대한민국 표준시) | 68 | 33 | 43 |
Tue Feb 15 2005 00:00:00 GMT+0900 (대한민국 표준시) | 75 | 36 | 45 |
Wed Mar 16 2005 12:00:00 GMT+0900 (대한민국 표준시) | 70 | 33 | 44 |
Sat Apr 16 2005 01:00:00 GMT+0900 (대한민국 표준시) | 63 | 33 | 41 |
Mon May 16 2005 12:00:00 GMT+0900 (대한민국 표준시) | 67 | 34 | 45 |
Thu Jun 16 2005 00:00:00 GMT+0900 (대한민국 표준시) | 69 | 36 | 43 |
Sat Jul 16 2005 12:00:00 GMT+0900 (대한민국 표준시) | 62 | 36 | 39 |
Tue Aug 16 2005 12:00:00 GMT+0900 (대한민국 표준시) | 60 | 38 | 40 |
Fri Sep 16 2005 00:00:00 GMT+0900 (대한민국 표준시) | 56 | 33 | 39 |
Sun Oct 16 2005 12:00:00 GMT+0900 (대한민국 표준시) | 59 | 37 | 57 |
Wed Nov 16 2005 00:00:00 GMT+0900 (대한민국 표준시) | 55 | 37 | 40 |
Fri Dec 16 2005 12:00:00 GMT+0900 (대한민국 표준시) | 51 | 39 | 39 |
Mon Jan 16 2006 12:00:00 GMT+0900 (대한민국 표준시) | 50 | 39 | 38 |
Wed Feb 15 2006 00:00:00 GMT+0900 (대한민국 표준시) | 54 | 41 | 39 |
Thu Mar 16 2006 12:00:00 GMT+0900 (대한민국 표준시) | 52 | 41 | 40 |
Sun Apr 16 2006 01:00:00 GMT+0900 (대한민국 표준시) | 49 | 41 | 38 |
Tue May 16 2006 12:00:00 GMT+0900 (대한민국 표준시) | 47 | 39 | 37 |
Fri Jun 16 2006 00:00:00 GMT+0900 (대한민국 표준시) | 49 | 39 | 37 |
Sun Jul 16 2006 12:00:00 GMT+0900 (대한민국 표준시) | 46 | 43 | 36 |
Wed Aug 16 2006 12:00:00 GMT+0900 (대한민국 표준시) | 46 | 43 | 39 |
Sat Sep 16 2006 00:00:00 GMT+0900 (대한민국 표준시) | 44 | 42 | 39 |
Mon Oct 16 2006 12:00:00 GMT+0900 (대한민국 표준시) | 45 | 42 | 39 |
Thu Nov 16 2006 00:00:00 GMT+0900 (대한민국 표준시) | 45 | 41 | 39 |
Sat Dec 16 2006 12:00:00 GMT+0900 (대한민국 표준시) | 42 | 40 | 37 |
Tue Jan 16 2007 12:00:00 GMT+0900 (대한민국 표준시) | 40 | 41 | 36 |
Thu Feb 15 2007 00:00:00 GMT+0900 (대한민국 표준시) | 42 | 48 | 37 |
Fri Mar 16 2007 13:00:00 GMT+0900 (대한민국 표준시) | 41 | 45 | 37 |
Mon Apr 16 2007 00:00:00 GMT+0900 (대한민국 표준시) | 40 | 45 | 36 |
Wed May 16 2007 12:00:00 GMT+0900 (대한민국 표준시) | 39 | 47 | 37 |
Sat Jun 16 2007 00:00:00 GMT+0900 (대한민국 표준시) | 39 | 47 | 36 |
Mon Jul 16 2007 12:00:00 GMT+0900 (대한민국 표준시) | 39 | 45 | 36 |
Thu Aug 16 2007 12:00:00 GMT+0900 (대한민국 표준시) | 37 | 41 | 34 |
Sun Sep 16 2007 00:00:00 GMT+0900 (대한민국 표준시) | 33 | 39 | 32 |
Tue Oct 16 2007 12:00:00 GMT+0900 (대한민국 표준시) | 33 | 38 | 33 |
Thu Nov 15 2007 23:00:00 GMT+0900 (대한민국 표준시) | 35 | 39 | 35 |
Sun Dec 16 2007 12:00:00 GMT+0900 (대한민국 표준시) | 32 | 41 | 34 |
Wed Jan 16 2008 12:00:00 GMT+0900 (대한민국 표준시) | 31 | 38 | 33 |
Fri Feb 15 2008 12:00:00 GMT+0900 (대한민국 표준시) | 32 | 42 | 34 |
Sun Mar 16 2008 13:00:00 GMT+0900 (대한민국 표준시) | 31 | 39 | 34 |
Wed Apr 16 2008 00:00:00 GMT+0900 (대한민국 표준시) | 32 | 38 | 35 |
Fri May 16 2008 12:00:00 GMT+0900 (대한민국 표준시) | 29 | 37 | 34 |
Mon Jun 16 2008 00:00:00 GMT+0900 (대한민국 표준시) | 30 | 40 | 34 |
Wed Jul 16 2008 12:00:00 GMT+0900 (대한민국 표준시) | 31 | 40 | 34 |
Sat Aug 16 2008 12:00:00 GMT+0900 (대한민국 표준시) | 29 | 40 | 34 |
Tue Sep 16 2008 00:00:00 GMT+0900 (대한민국 표준시) | 28 | 35 | 35 |
Thu Oct 16 2008 12:00:00 GMT+0900 (대한민국 표준시) | 27 | 35 | 35 |
Sat Nov 15 2008 23:00:00 GMT+0900 (대한민국 표준시) | 26 | 37 | 35 |
Tue Dec 16 2008 12:00:00 GMT+0900 (대한민국 표준시) | 25 | 37 | 34 |
Fri Jan 16 2009 12:00:00 GMT+0900 (대한민국 표준시) | 24 | 38 | 34 |
Sun Feb 15 2009 00:00:00 GMT+0900 (대한민국 표준시) | 27 | 39 | 37 |
Mon Mar 16 2009 13:00:00 GMT+0900 (대한민국 표준시) | 26 | 39 | 37 |
Thu Apr 16 2009 00:00:00 GMT+0900 (대한민국 표준시) | 25 | 38 | 37 |
Sat May 16 2009 12:00:00 GMT+0900 (대한민국 표준시) | 23 | 41 | 34 |
Tue Jun 16 2009 00:00:00 GMT+0900 (대한민국 표준시) | 23 | 38 | 33 |
Thu Jul 16 2009 12:00:00 GMT+0900 (대한민국 표준시) | 24 | 42 | 36 |
Sun Aug 16 2009 12:00:00 GMT+0900 (대한민국 표준시) | 23 | 38 | 35 |
Wed Sep 16 2009 00:00:00 GMT+0900 (대한민국 표준시) | 21 | 34 | 35 |
Fri Oct 16 2009 12:00:00 GMT+0900 (대한민국 표준시) | 19 | 31 | 35 |
Sun Nov 15 2009 23:00:00 GMT+0900 (대한민국 표준시) | 19 | 32 | 33 |
Wed Dec 16 2009 12:00:00 GMT+0900 (대한민국 표준시) | 18 | 32 | 30 |
Sat Jan 16 2010 12:00:00 GMT+0900 (대한민국 표준시) | 17 | 32 | 29 |
Mon Feb 15 2010 00:00:00 GMT+0900 (대한민국 표준시) | 18 | 35 | 32 |
Tue Mar 16 2010 13:00:00 GMT+0900 (대한민국 표준시) | 18 | 34 | 32 |
Fri Apr 16 2010 00:00:00 GMT+0900 (대한민국 표준시) | 18 | 34 | 32 |
Sun May 16 2010 12:00:00 GMT+0900 (대한민국 표준시) | 17 | 34 | 32 |
Wed Jun 16 2010 00:00:00 GMT+0900 (대한민국 표준시) | 16 | 36 | 31 |
Fri Jul 16 2010 12:00:00 GMT+0900 (대한민국 표준시) | 16 | 36 | 29 |
Mon Aug 16 2010 12:00:00 GMT+0900 (대한민국 표준시) | 15 | 35 | 30 |
Thu Sep 16 2010 00:00:00 GMT+0900 (대한민국 표준시) | 15 | 32 | 31 |
Sat Oct 16 2010 12:00:00 GMT+0900 (대한민국 표준시) | 16 | 36 | 33 |
Mon Nov 15 2010 23:00:00 GMT+0900 (대한민국 표준시) | 15 | 39 | 33 |
Thu Dec 16 2010 12:00:00 GMT+0900 (대한민국 표준시) | 14 | 33 | 31 |
Sun Jan 16 2011 12:00:00 GMT+0900 (대한민국 표준시) | 14 | 44 | 31 |
Tue Feb 15 2011 00:00:00 GMT+0900 (대한민국 표준시) | 14 | 43 | 33 |
Wed Mar 16 2011 13:00:00 GMT+0900 (대한민국 표준시) | 14 | 37 | 32 |
Sat Apr 16 2011 00:00:00 GMT+0900 (대한민국 표준시) | 14 | 38 | 33 |
Mon May 16 2011 12:00:00 GMT+0900 (대한민국 표준시) | 13 | 34 | 33 |
Thu Jun 16 2011 00:00:00 GMT+0900 (대한민국 표준시) | 13 | 32 | 32 |
Sat Jul 16 2011 12:00:00 GMT+0900 (대한민국 표준시) | 12 | 34 | 32 |
Tue Aug 16 2011 12:00:00 GMT+0900 (대한민국 표준시) | 12 | 32 | 30 |
Fri Sep 16 2011 00:00:00 GMT+0900 (대한민국 표준시) | 12 | 31 | 33 |
Sun Oct 16 2011 12:00:00 GMT+0900 (대한민국 표준시) | 12 | 30 | 34 |
Tue Nov 15 2011 23:00:00 GMT+0900 (대한민국 표준시) | 12 | 32 | 34 |
Fri Dec 16 2011 12:00:00 GMT+0900 (대한민국 표준시) | 11 | 31 | 31 |
Mon Jan 16 2012 12:00:00 GMT+0900 (대한민국 표준시) | 11 | 31 | 31 |
Wed Feb 15 2012 12:00:00 GMT+0900 (대한민국 표준시) | 11 | 34 | 34 |
Fri Mar 16 2012 13:00:00 GMT+0900 (대한민국 표준시) | 11 | 33 | 34 |
Mon Apr 16 2012 00:00:00 GMT+0900 (대한민국 표준시) | 10 | 34 | 34 |
Wed May 16 2012 12:00:00 GMT+0900 (대한민국 표준시) | 10 | 33 | 35 |
Sat Jun 16 2012 00:00:00 GMT+0900 (대한민국 표준시) | 10 | 34 | 32 |
Mon Jul 16 2012 12:00:00 GMT+0900 (대한민국 표준시) | 10 | 38 | 33 |
Thu Aug 16 2012 12:00:00 GMT+0900 (대한민국 표준시) | 10 | 34 | 35 |
Sun Sep 16 2012 00:00:00 GMT+0900 (대한민국 표준시) | 9 | 35 | 35 |
Tue Oct 16 2012 12:00:00 GMT+0900 (대한민국 표준시) | 10 | 36 | 36 |
Thu Nov 15 2012 23:00:00 GMT+0900 (대한민국 표준시) | 9 | 34 | 36 |
Sun Dec 16 2012 12:00:00 GMT+0900 (대한민국 표준시) | 8 | 34 | 32 |
Wed Jan 16 2013 12:00:00 GMT+0900 (대한민국 표준시) | 9 | 35 | 36 |
Fri Feb 15 2013 00:00:00 GMT+0900 (대한민국 표준시) | 9 | 35 | 37 |
Sat Mar 16 2013 13:00:00 GMT+0900 (대한민국 표준시) | 9 | 36 | 39 |
Tue Apr 16 2013 00:00:00 GMT+0900 (대한민국 표준시) | 9 | 34 | 38 |
Thu May 16 2013 12:00:00 GMT+0900 (대한민국 표준시) | 8 | 35 | 38 |
Sun Jun 16 2013 00:00:00 GMT+0900 (대한민국 표준시) | 8 | 34 | 37 |
Tue Jul 16 2013 12:00:00 GMT+0900 (대한민국 표준시) | 8 | 35 | 36 |
Fri Aug 16 2013 12:00:00 GMT+0900 (대한민국 표준시) | 7 | 34 | 41 |
Mon Sep 16 2013 00:00:00 GMT+0900 (대한민국 표준시) | 8 | 33 | 39 |
Wed Oct 16 2013 12:00:00 GMT+0900 (대한민국 표준시) | 8 | 35 | 42 |
Fri Nov 15 2013 23:00:00 GMT+0900 (대한민국 표준시) | 8 | 39 | 47 |
Mon Dec 16 2013 12:00:00 GMT+0900 (대한민국 표준시) | 7 | 32 | 41 |
Thu Jan 16 2014 12:00:00 GMT+0900 (대한민국 표준시) | 7 | 32 | 40 |
Sat Feb 15 2014 00:00:00 GMT+0900 (대한민국 표준시) | 7 | 35 | 42 |
Sun Mar 16 2014 13:00:00 GMT+0900 (대한민국 표준시) | 7 | 35 | 44 |
Wed Apr 16 2014 00:00:00 GMT+0900 (대한민국 표준시) | 7 | 33 | 43 |
Fri May 16 2014 12:00:00 GMT+0900 (대한민국 표준시) | 7 | 38 | 41 |
Mon Jun 16 2014 00:00:00 GMT+0900 (대한민국 표준시) | 7 | 40 | 39 |
Wed Jul 16 2014 12:00:00 GMT+0900 (대한민국 표준시) | 7 | 37 | 44 |
Sat Aug 16 2014 12:00:00 GMT+0900 (대한민국 표준시) | 6 | 36 | 37 |
Tue Sep 16 2014 00:00:00 GMT+0900 (대한민국 표준시) | 7 | 35 | 43 |
Thu Oct 16 2014 12:00:00 GMT+0900 (대한민국 표준시) | 7 | 35 | 44 |
Sat Nov 15 2014 23:00:00 GMT+0900 (대한민국 표준시) | 6 | 37 | 44 |
2014년 안철수근황
안철수의 팬으로서 뉴스에도 안나오고 어디에도 안나오길래 찾아보니
페이스 북만 하시더군요..
안철수의 새정치 ==> https://ko-kr.facebook.com/ahncs111
가보고 너무 감동받았습니다.
정책을 만들기위한 조직(정책네트워크 내일) 을 만들었네요.
뛰어난 사람들을 채용해서 정책네트워크 내일이라는 회사(?) 같은걸 만든것 같습니다.
당원들이 하는게 아닌것 같습니다.
정치인들이 아니라 연구원을 따로 고용해서 정책 연구만 시키네요.
페이스북에 계속 올라오는데 바람직해보입니다. (흐믓~ 하달까?)
도데체 지금까지 우리나라 정당들은 무엇을 해왔던거지? (기존의 바보정치와는 너무 다르네요.) 라고 생각이드네요.
체계적이고, 합리적이고, 열정적인 사람들을 모아서 국민에게 도움이되는게 무언지 연구하고 있습니다.
안철수 잘합니다.
(말을 카리스마있게 못해서 그렇지)
하지만 말을 카리스마있게 못하는 사람이 Good-to-Great 책에서 최고 지도자 5레벨에 해당한다고하니, 역시 말보다는 행동!!
페이스북에 가보고 더 팬이 되었습니다.
제가 Good-to-Great 를 언급하면서 안철수가 배에 같은 사람을 태울것이라고 블로깅을한 바가있습니다. 아래 링크를 보시기 바랍니다. 정말 그렇게 하고있네요~ (저도 미래 예측이 가능한가?)
http://yukibung.blogspot.kr/2014/01/blog-post.html
페이스 북만 하시더군요..
안철수의 새정치 ==> https://ko-kr.facebook.com/ahncs111
가보고 너무 감동받았습니다.
정책을 만들기위한 조직(정책네트워크 내일) 을 만들었네요.
뛰어난 사람들을 채용해서 정책네트워크 내일이라는 회사(?) 같은걸 만든것 같습니다.
당원들이 하는게 아닌것 같습니다.
정치인들이 아니라 연구원을 따로 고용해서 정책 연구만 시키네요.
페이스북에 계속 올라오는데 바람직해보입니다. (흐믓~ 하달까?)
도데체 지금까지 우리나라 정당들은 무엇을 해왔던거지? (기존의 바보정치와는 너무 다르네요.) 라고 생각이드네요.
체계적이고, 합리적이고, 열정적인 사람들을 모아서 국민에게 도움이되는게 무언지 연구하고 있습니다.
안철수 잘합니다.
(말을 카리스마있게 못해서 그렇지)
하지만 말을 카리스마있게 못하는 사람이 Good-to-Great 책에서 최고 지도자 5레벨에 해당한다고하니, 역시 말보다는 행동!!
페이스북에 가보고 더 팬이 되었습니다.
제가 Good-to-Great 를 언급하면서 안철수가 배에 같은 사람을 태울것이라고 블로깅을한 바가있습니다. 아래 링크를 보시기 바랍니다. 정말 그렇게 하고있네요~ (저도 미래 예측이 가능한가?)
http://yukibung.blogspot.kr/2014/01/blog-post.html
SoC 개발과 clean code (프로그래밍을 잘해야하나?)
SoC 하는 사람이 프로그래밍을 잘해야하나요?
대부분 언어가 spec 을 기술하는 언어가 됩니다. DSL(Domain Specific Language) 가 많습니다.
몇개만 보아도 그렇지요...
- STA : tcl
- Synthesis : tcl
따라서 얼마나 clean 하게 coding 하는가가 중요합니다.
깔끔한 코드 .
누가봐도 이해가 가는 명확하고 단순한 코드.
code 를 지저분하게 짜기때문에 회사의 재정이 어려워진다는
믿기 어려운 사실을 믿어야 합니다.
clean code 를 만드는 좋은 SoC 개발자가 되고싶다면 아래 책을 읽어보세요. .
프로그래밍 심리학이 이론서였다면 Clean Code 는 프로그래밍 심리학 실전 편입니다.
대부분 언어가 spec 을 기술하는 언어가 됩니다. DSL(Domain Specific Language) 가 많습니다.
몇개만 보아도 그렇지요...
- STA : tcl
- Synthesis : tcl
따라서 얼마나 clean 하게 coding 하는가가 중요합니다.
깔끔한 코드 .
누가봐도 이해가 가는 명확하고 단순한 코드.
code 를 지저분하게 짜기때문에 회사의 재정이 어려워진다는
믿기 어려운 사실을 믿어야 합니다.
clean code 를 만드는 좋은 SoC 개발자가 되고싶다면 아래 책을 읽어보세요. .
프로그래밍 심리학이 이론서였다면 Clean Code 는 프로그래밍 심리학 실전 편입니다.
SoC 개발자가 design pattern (C++) 을 알아야하나?
DFT , STA 등을 하는 개발자가 C++ 을 알아야 할까요?
Chip 을 Integration 하는 개발자가 C++ 을 알아야 할까요?
저의 답은 yes 입니다.
C++ 을 공부하면 패턴에 기반한 아키텍처를 익힐수 있습니다.
design pattern 의 visitor pattern 을 SoC 개발에는 적용하지 못할까요?
예를들어볼까요?
시뮬레이션시에 아래와 같이 실행한다고 합시다.
% cd test_a
% run sim
% cd test_b
% run sim
합성시에 아래와 같이 실행한다고 합시다.
% cd test_a
% run synthesis
% cd test_b
% run synthesis
위와 같이 특정 directory 에 들어가서 똑같은 일을 반복하는게 SoC 개발자의 업무의 대부분이 라고 가정해보지요.
위 상황에서 directory 구조는 하나의 동일한 db 입니다.
그런데 행위가 sim 에서 synthesis 로 바뀌었습니다.
이것이 visitor 패턴입니다.
따라서 C++ 을 배워야하는데 이것이 C보다 10-100배는 어렵습니다!
열정과 재미와 사랑을 느끼지 못하면 안되는겁니다.
휼륭한 SoC 개발자가 되고싶다면 프로그래밍의 모든 분야에 대해서 공부를 게을리 하면 안됩니다.
시대변화를 따라가려면 내가 변화해야하고,
엄청나게 학습해서 계속 변화하는 사람이되어야 합니다.
제가 공부한 pattern 관련책들만 소개합니다.
모두 읽어서 실전에 적용했습니다.
최근에는 루비로 디자인패턴을 많이 적용하는 편입니다.
(리팩토링하기가 너무 좋습니다.)
Chip 을 Integration 하는 개발자가 C++ 을 알아야 할까요?
저의 답은 yes 입니다.
C++ 을 공부하면 패턴에 기반한 아키텍처를 익힐수 있습니다.
design pattern 의 visitor pattern 을 SoC 개발에는 적용하지 못할까요?
예를들어볼까요?
시뮬레이션시에 아래와 같이 실행한다고 합시다.
% cd test_a
% run sim
% cd test_b
% run sim
합성시에 아래와 같이 실행한다고 합시다.
% cd test_a
% run synthesis
% cd test_b
% run synthesis
위와 같이 특정 directory 에 들어가서 똑같은 일을 반복하는게 SoC 개발자의 업무의 대부분이 라고 가정해보지요.
위 상황에서 directory 구조는 하나의 동일한 db 입니다.
그런데 행위가 sim 에서 synthesis 로 바뀌었습니다.
이것이 visitor 패턴입니다.
따라서 C++ 을 배워야하는데 이것이 C보다 10-100배는 어렵습니다!
열정과 재미와 사랑을 느끼지 못하면 안되는겁니다.
휼륭한 SoC 개발자가 되고싶다면 프로그래밍의 모든 분야에 대해서 공부를 게을리 하면 안됩니다.
시대변화를 따라가려면 내가 변화해야하고,
엄청나게 학습해서 계속 변화하는 사람이되어야 합니다.
제가 공부한 pattern 관련책들만 소개합니다.
모두 읽어서 실전에 적용했습니다.
최근에는 루비로 디자인패턴을 많이 적용하는 편입니다.
(리팩토링하기가 너무 좋습니다.)
2012 - 읽은 책들
글로벌 소프트웨어를 꿈꾸다
스탠포트 출신의 엔지니어이자, 실리콘벨리의 CEO 를 거쳐, 안철수 연구소 최고기술경영자(CTO)였던 김익환씨가 쓴책.
주로 큰 회사가 되기위한 프로세스및 문서화 중요성을 이야기한다. 실리콘 벨리에서는 어떻게 개발하는지 알수있어 매우 도움이 되었다.
얼마나 주먹구구 식으로 하고있었는지 스스로를 반성하게 하는 책이다.
아래 말이 마음에 와닫는데,
엔지니어링이란 문화를 기반으로 한 현실이다. |
---|
단순하게 기술적 으로 뛰어나려고 한다거나 또는 관리만 하려고 해서는 회사가 성공할수 없다는것을 의미한다.
회사의 문화가 매우 중요함을 의미한다.
책에서는 예를들어 회사의 문화란 아래와 같다고 합니다.
나의 코드를 commit 하기전에 누가 리뷰해주는것이 당연한가? |
---|
자동화 및 개발 철학등을 담고 있습니다. 이 책을 읽었을때의 느낌은 개발시 정체되어있던 부분을 한단계 업그레이드 시켜주는 기분이 었습니다.
자신보다 뛰어난 개발자들의 생각을 알고싶으시다면 필수적으로 읽어보아야 할것입니다. 3번정도 읽었지만 다시 읽어도 내가 부족한점을 느끼게하는 아주 좋은 내용의 책입니다.
모 게임회사에서는 면접시 이 책을 읽지 않는 개발자는 채용하지 않는다는 일화도 있습니다.
허드슨을 이용한 지속적인 통합
회사는 생산성을 높이기 위해 CI 에 모든것을 투자해야합니다.
회사에서 간단한 batch 나 tool 을 개발할때 스토리 위주로 기능을 추가해가면 좋은것 같습니다.
이제는 애자일의 유행이 지나가고 (애자일은 당연한 프로세스로서 자리잡습니다)
Lean 이 유행이네요 ㅎㅎ
이제는 애자일의 유행이 지나가고 (애자일은 당연한 프로세스로서 자리잡습니다)
Lean 이 유행이네요 ㅎㅎ
애자일 채용론
내용이 좋습니다.
회사에 필요한 사람을 걸러낼때 중요합니다.
Release It
SoC 입장에서보면 Chip 이 나오고 생기는 문제들에대해서 어떻게 할것인가에 대한 내용인것 같습니다.
6권밖에 안되네요. 더 읽은것 같은데 읽은책 정리하기 시작한게 얼마 안되서 기록이 업센요..
6권밖에 안되네요. 더 읽은것 같은데 읽은책 정리하기 시작한게 얼마 안되서 기록이 업센요..
2013 - 읽은 책들
프로그래밍심리학
프로그래밍 심리학... 으로 바꿔야 될것 같네요.
개발 자체에 아주 지대한 영향을 '바로 지금' 주고 있습니다.
이책을 읽고난 전과 후는 '제 스타일' 많이 달라져 있습니다.
위대한 게임의 탄생
요즘 게임이 참 발전했다는 생각을하게됩니다. 게임 만드는 친구들을 보면 정말 대단한 '열정' 이 있습니다.
최고의 조직은 어떻게 만들어지는가?
내용에 생태계라는것도 나옵니다. 버전관리를 사용한다거나 , uvm 을 사용한다거나 하는것이 생태계이지요.
조직을 어떤식으로 구성할지 고민할때 도움이 되는 책입니다.
관리자라면 반드시 읽어보아야 할것 같습니다.
개발자도 알아야할 소프트웨어 테스팅 실무
내용을 보면 너무 수준이 높은것 같기도하고, 무언가 '실용주의적' 접근은 부족한것 같습니다.
항상 국내 책은 왜 어렵습니까!!
일단 이책은 추천하고 싶지는 않습니다. 너무 학술적입니다.
켄트벡의 구현패턴
그 유명한 켄트벡 씨가 쓴 책입니다.
정말 얇습니다. 책이 어렵지는 않습니다. 쉽습니다.
그런데 정말 읽는데 오래걸립니다. 하나하나 저자의 노하우가 담아져 있어 정말 고민하면서 읽게되서 그렇네요.
한번 읽고 버리기보다는 계속 옆에두면서 참고해야하는 책입니다.
이런책을 읽고나서 ruby 로 객체지향을 작성하기 시작하니 매우 쉽네요. 진입장벽이 사라진 느낌입니다.
100 Power Tips For FPGA Designers
최근에 본 책중에 1주일안에 읽은 책인 매우 간만입니다. 쏙쏙 이해가 됩니다.
이렇게 쉬운것들을 많이 읽어야 하는데. 맨날 어려운것만 보다보니 시간이 오래걸리네요.
timing 을 잘 잡는 방법 대해서도 나와있어서 매우 도움이 됩니다.
- timing closure (STA)
- floor planing
아마존에 서평을 따르면 이책을 읽으면 FPGA 10년차정도 된다고 하네요.. ㅎㅎ
UVM 1.1
cadence verification part 의 수석 개발자가 uvm 을 이끄는것 같습니다.
바로 그사람이 쓴 내용이라서 권장사항과, 안따라 해도 되는 uvm 의 feature 까지도 알려줍니다.
TLM Driven Design
cadence 의 야심을 엿볼수 있습니다. 내용이 너무 좋아서 장기 소장해야할것 같은데 아직 구매를 못하고 있습니다.
RTL level 이 없어지고 보다 상위 level 로 가야하는 전환기를 말하는 책입니다.
이미 ARM 은 mali 등을 generation 할때 RTL 보다 상위 level 을 사용하고 있음이 드러났습니다.
RTL 은 없어지지는 않겠지만, memory interface 등 그냥 다양하게 configuration 하는 block 들은 generation 하는 세상이 다가오고 있습니다.
ruby on rails
단점은 벌써 4.0 이나와서 이책의 내용이 옛날것이 되어버렸다는것입니다.
책을 하나더 사야겠습니다.
아... 4.0 책은 번역이 않좋고, 내용도 2.0이 훨씬 좋습니다.
2.0 은 web 디자인에대한 단위테스트 방법도 나오고 내용도 두껍습니다.
4.0 은 그냥 책을 왜쓴거야!!
아... 4.0 책은 번역이 않좋고, 내용도 2.0이 훨씬 좋습니다.
2.0 은 web 디자인에대한 단위테스트 방법도 나오고 내용도 두껍습니다.
4.0 은 그냥 책을 왜쓴거야!!
xUnit 테스트 패턴
테스트 실행기와 같은 패턴들이 왜 중요한지 이유가 나와있어서, 좋습니다.
Junit in Action
하지만 smoke test 등을 JUnit 에서 어떻게 하는지 패턴을 배울수 있는것 같습니다.
이책도 역시 대충 필요한 부분만 본것 같습니다.
annotation programming 방법에 대한 것을 처음 배웠습니다.
annotation programming 방법에 대한 것을 처음 배웠습니다.
Pro Git
세계 git 의 2인자가 쓴 책이라고 합니다. 정말 Git 의 내부구조까지 자세하게 기술합니다.
그만큼 원초적으로 Git 을 이해하기에 좋은 책입니다.
다른 Git 책보다는 확실히 좋습니다.
당신은 전략가 입니까?
약간 다른점은 Good to Great 는 나와 같은 뜻을 가진 사람들을 배에 태워야 한다고 말하지만
이책은 내 뜻을 직원들에게 심어주어야 한다고 말하는 면이 있는것 같습니다.
또한 보다 디테일하게 전략가로서의 CEO 가 해야하는 일들에 대해서 적고 있습니다.
게임프레임
결국은 빠르고, 적절하고, 재미있는 feedback 을 직원들에게 제공해주면 생산성을 높일수 있다고 보입니다.
왜 테스트를 잘하지 않게 되는가? 왜 coverage 를 보지 않는가에 대한 답을 얻을수 있는것 같습니다.
저는 개인적으로 일본기업들이 실패한이유를 이러한 게임 이론에서 찾고싶습니다. 관리와 프로세스만 중요한건 아닙니다. 개발자들이 동기를 얻을수 있는 프레임(회사의 환경)이 중요합니다. 적절한 feedback 만 주면 개발자들은 관리하는것보다 더 열심히 그리고 창의적으로 다른 사람보다 수십배 더 잘 일할수 있습니다. 저는 일본식 (또는 우리나라 대기업식 ) 의 관리보다는 미국식 관리에 좀더 마음이 갑니다. (틀릴수도 있죠 ㅎㅎ)
저는 개인적으로 일본기업들이 실패한이유를 이러한 게임 이론에서 찾고싶습니다. 관리와 프로세스만 중요한건 아닙니다. 개발자들이 동기를 얻을수 있는 프레임(회사의 환경)이 중요합니다. 적절한 feedback 만 주면 개발자들은 관리하는것보다 더 열심히 그리고 창의적으로 다른 사람보다 수십배 더 잘 일할수 있습니다. 저는 일본식 (또는 우리나라 대기업식 ) 의 관리보다는 미국식 관리에 좀더 마음이 갑니다. (틀릴수도 있죠 ㅎㅎ)
Debug It 실용주의 디버깅
'실용주의 프로그래머' 같은 류의 책인것 같습니다.
.
Head First 통계학
머리에 쏙쏙들어오는게. 완전 좋네요. 역시 head first 입니다.
통계는 수학수업 마지막쪽에 있어서 항상 부실하게 공부했던것 같습니다.
이기회에 100% 마스터 하고자 합니다.
Head First Java
java 는 기본적인 문법은 대충 알기는 합니다만,
중요한것은 쉬운것을 잘 이해하는것 같습니다. java 의 기초를 딱아보고 싶어서 샀습니다.
전문가를 위한 10년활용 리눅스 시스템
지금까지 샀던 linux 책중에 가장 좋습니다. 여기서 배워서 바로 사용하고있는것들이 좀 됩니다.
linux 에서 막혀있던 부분들이 있었는데, 이책을 통해 많이 배우게 됩니다.
역시 국내 저자들이 쓴것보다는 외국친구들게 좋네요.
이클립스 RCP
드디어!! 제대로된 이클립스 책을 샀습니다. 요즘 이클립스는 완전 대세입니다.
간단한 메신저 프로그램을 만드는 예제로 설명합니다.
이클립스의 기초를 완전 딱을수 있는책으로 보입니다.
손에 잡히는 정규 표현식
아주 얇은데 내용은 충분합니다.
앞에는 정규표현식의 쉬운부분이 나오지만 뒤로가면 모르지만 배워도야하는 식들도 나옵니다.
모두 합치니 21권 밖에 안되네요...
피드 구독하기:
글 (Atom)