2014년 12월 26일 금요일

2014년 4분기 읽은 책들

애드센스

일단 롱테일 경제학이라는 측면에서 애드센스가 만들어진걸 보면, 
역시 구글!
네이버가 광고보다는 구글 광고가 훨씬 좋은 이유에 대해서 알수 있습니다.
이제는 롱테일의 시대!

새로운디지털시대

새로운 디지털 시대
나에게는 다소 이런책이 어렵고 불편합니다.
미래의 국가, 정치, 사회 를 이야기하고 있기때문에 어려운 측면도있구요.
번역을 너무 어렵고 길게 해놓아서 읽기 불편한 점도 있었습니다.
하지만 정말 미래에 대해서 이야기하고 있습니다.

일본전산이야기

일본전산 이야기

일본 전산 이야기를 읽고서, 똑똑한 사람이 애자일 스럽게 일하는것이
과연 성공을 가져다 줄까? 라는 의문점을 가지게 되었습니다.
똑똑한 사람이 정말 더 hard-working 하기때문에 성공한 회사들이 많다고 생각들더군요.
안철수 연구소가 그런 종류라고 생각합니다.

린 분석

린 분석
이건 정말 이렇게 까지 스타트업을 해야하는가, 정말 대단하다는 생각이 드네요.
이런 분석을 회사에 tool 에 적용하면 더 좋을것 같습니다. 


SPARK:: A Parallelizing Approach to the High-Level Synthesis

오래전에 사두었다가 짱박은 책입니다. 최근에 읽어보았는데 내용은 좋더군요.
이걸보고 구현하면 c 코드를 합성할수 있을것 같습니다.
그런데 요즘은 fHDL (fragmented HDL) 이라고 c 코드를 바로 합성하는것보다
한단계 상위레벨에서 합성을 시도하는 trend 인것 같습니다. 


DSL 고객과 함께하는 도메인 특화언어 

DSL

제가 좋아하는 마틴 파울러 아저씨의 책입니다.
최근에 DSL 을 체계적으로 공부하시고 책을 쓴것 같습니다.



린 마인드셋

THE LEAN MINDSET 린 마인드셋
메리포펜틱 부부의 최근 책입니다. 아주큰 상위레벨에서 LEAN 을 생각하게 해줌니다.
책의 두께는 아주 얇지만, 내용은 너무나도 충실하고, 고민할 부분이 많아서
오랫동안 읽었습니다.
다시 읽어야지 하고 생각하는 책중에 하나입니다.


Head First SQL 

Head First SQL

저는 sql 을 잘몰라서 한번 사서 공부해봤습니다.
처음부터 끝까지  table 이더군요. 


롱테일 경제학

롱테일 경제학
주로 기술책만 보다가 간만에 읽은 경제학책입니다.
이런!! 책을 이제야 보다니, 
정말 대단한 내용이 들어있습니다. 
아마존, 구글등은 이런 책이 나오기전에 이미 시대의 흐름을 간파하고 있습니다.
이제는 롱테일의 시대입니다.!!
인텔칩이 좋긴하지만,, 왜 다양한 모바일 시스템에 사용이 안될까요?
저는 언젠가 SoC 쪽도 롱테일의 흐름이 올거라고 생각합니다.


이번 분기는 9권 읽었습니다.
 기술서적이 내용이 어려워서 읽다보면 한달에 3권정도가 한계내요.





2014년 12월 6일 토요일

일본전산 이야기를 읽고 바뀐 생각들..

제가 거의 20년 동안 착각속에 빠져있던것 같았는데, 오늘 깨달은것이 있습니다.

고등학교때는 공부를 제법해서 서울대 최상위권은 아니더라도 적당한 학과는 안정권으로 갈수 있을 성적이었습니다.

하지만 제가 가고싶은 최상위권 학과는 갈수가 없었습니다.

아이큐는 100도 안되었고, 난 내 머리가 나빠서 그런줄 알았습니다.

그런데 아래 책을 읽다보니... 생각난게 있습니다.


일본전산 이야기


대학교때 공인회계사 공부하는 친구는 아침6시에서 밤12시 까지 하루종일 365일 공부만하더군요.

대학교때 스탠포드를 4년만에 석,박을 마치신 교수님은 본인이 1달간 잠을 자지않고 공부했다고 하더군요.

잘되고 성공하는 사람들은 머리가 좋아서 성공하기도 합니다.

하지만, 아주 지적으로 뛰어난 사람중에서 남들잘때 더 2배 열심히 하는 사람들이 있습니다.

그런 사람들이 세계최고가 되어 성공하게 되는것 같습니다.

여러분은 그런사람을 알고 있습니다.

바로 안철수입니다. V3 만들때 의대 공부하면서 새벽 3시에 일어나서 프로그래밍을 했다는 것은 이미 모두 알고 계실겁니다.

본인의 회사가 잘 나가지 못한다고 한탄하고 계신가요?

그럼 본인은 안철수만큼 노력했냐고 묻고 싶습니다.

현재까지 제가 가지고 있던 자세에 대해서 무척 반성하게 됩니다.

애자일 에서는 칼퇴근하고, 창의성을 가져라 라고 이야기합니다.

그래서 적당히 쉬면서 해야한다는 것에, 무게를 두었던것 같습니다.

아래와 같은 책을 읽고 나름 합리화를 했던것 같습니다.
(물론 애자일의 좋은 점들은 많이 적용하고, 도움을 받고있습니다.)

애자일 마스터








그런데 그런 애자일을 하는사람들이 사실은 젊었을때는 더 노력한 시간이 있었을 겁니다.
(사실 미국 유명 대학 출신들이 많습니다.)

만약 현재 좋은 아이디어가 있다면, 시간이 없어서 못한다고 한탄하지 말아야 할것 같습니다.

그냥 야근을 하던 주말에 나와서 하던 그냥 하면 됩니다.

어짜피 나와 똑같이 똑똑한 사람들이 비슷한 시간을 투자해서 일하고 있습니다.

더 많은 열정과 속도를 가져야 합니다.

좋은 아이디어를 인텔리전트하게 남들보다 2배 빠르게 만들면,
세계 최고에 점점 가까워 질겁니다.

물론 노가다는 하지 말아야합니다.

노가다를 없애는 인텔리전트한 방식으로 남들보다 더 빨리 만들어야합니다.

여태까지 실패한 이유에 변명을 하기보다는, 더 열심히 해야하는것 같습니다.

그런데 나는 변한다치고, 직원들은 어째야 할까요?

1. 원래 그런 직원들을 뽑도록 노력한다.

잘못뽑은 직원한명이 회사물을 완전히 흐려놓을수 있습니다.

2. 내가 그렇게 행동한다.


책을읽는 부모및에서 자란 아이가 책을 읽습니다.
부모가 하루종일 텔레비젼을 보면서 아이에게는 공부하라고 하면 할까요?
또한 본인이 먼저 행동하면 직원들이 존경하고 따라하게 됩니다.

어렵습니다. 매일매일 칼을 갈고 또 갈아야 합니다.





















10년후에 내가 어떻게 바뀌었을까?

ted 에 미래에 자신에 대한 심리학이라는 내용을 보았습니다.
http://www.ted.com/talks/dan_gilbert_you_are_always_changing?language=ko

나의 생각이나 철학이나 직업이 10년후에 얼마나 바뀔까요?

대부분 별로 안바뀔것이라 생각하지만.

내가 예상하는것보다 훨씬더 많이 바뀐다고 합니다.

증거가 있습니다. 아래와 같이 생각해보지요.

10년전에 내가 무엇을하고 있었고 현재와 얼마나 다른지를 떠올려보세요.

무지하게 많이 바뀌었을겁니다.

앞으로 10년은 그렇게 또 바뀝니다.




2014년 11월 20일 목요일

c++ unit lite (from legacy code)

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월 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 등의 예외처리도 쉬워서, 이제는 예외 처리가 아주 능숙해졌습니다.





Dateperlrubypython
Fri Jan 16 2004 12:00:00 GMT+0900 (대한민국 표준시)944048
Sun Feb 15 2004 12:00:00 GMT+0900 (대한민국 표준시)1004447
Tue Mar 16 2004 12:00:00 GMT+0900 (대한민국 표준시)964246
Fri Apr 16 2004 01:00:00 GMT+0900 (대한민국 표준시)943946
Sun May 16 2004 12:00:00 GMT+0900 (대한민국 표준시)894244
Wed Jun 16 2004 00:00:00 GMT+0900 (대한민국 표준시)914344
Fri Jul 16 2004 12:00:00 GMT+0900 (대한민국 표준시)914445
Mon Aug 16 2004 12:00:00 GMT+0900 (대한민국 표준시)884043
Thu Sep 16 2004 00:00:00 GMT+0900 (대한민국 표준시)863445
Sat Oct 16 2004 12:00:00 GMT+0900 (대한민국 표준시)803245
Tue Nov 16 2004 00:00:00 GMT+0900 (대한민국 표준시)763142
Thu Dec 16 2004 12:00:00 GMT+0900 (대한민국 표준시)733343
Sun Jan 16 2005 12:00:00 GMT+0900 (대한민국 표준시)683343
Tue Feb 15 2005 00:00:00 GMT+0900 (대한민국 표준시)753645
Wed Mar 16 2005 12:00:00 GMT+0900 (대한민국 표준시)703344
Sat Apr 16 2005 01:00:00 GMT+0900 (대한민국 표준시)633341
Mon May 16 2005 12:00:00 GMT+0900 (대한민국 표준시)673445
Thu Jun 16 2005 00:00:00 GMT+0900 (대한민국 표준시)693643
Sat Jul 16 2005 12:00:00 GMT+0900 (대한민국 표준시)623639
Tue Aug 16 2005 12:00:00 GMT+0900 (대한민국 표준시)603840
Fri Sep 16 2005 00:00:00 GMT+0900 (대한민국 표준시)563339
Sun Oct 16 2005 12:00:00 GMT+0900 (대한민국 표준시)593757
Wed Nov 16 2005 00:00:00 GMT+0900 (대한민국 표준시)553740
Fri Dec 16 2005 12:00:00 GMT+0900 (대한민국 표준시)513939
Mon Jan 16 2006 12:00:00 GMT+0900 (대한민국 표준시)503938
Wed Feb 15 2006 00:00:00 GMT+0900 (대한민국 표준시)544139
Thu Mar 16 2006 12:00:00 GMT+0900 (대한민국 표준시)524140
Sun Apr 16 2006 01:00:00 GMT+0900 (대한민국 표준시)494138
Tue May 16 2006 12:00:00 GMT+0900 (대한민국 표준시)473937
Fri Jun 16 2006 00:00:00 GMT+0900 (대한민국 표준시)493937
Sun Jul 16 2006 12:00:00 GMT+0900 (대한민국 표준시)464336
Wed Aug 16 2006 12:00:00 GMT+0900 (대한민국 표준시)464339
Sat Sep 16 2006 00:00:00 GMT+0900 (대한민국 표준시)444239
Mon Oct 16 2006 12:00:00 GMT+0900 (대한민국 표준시)454239
Thu Nov 16 2006 00:00:00 GMT+0900 (대한민국 표준시)454139
Sat Dec 16 2006 12:00:00 GMT+0900 (대한민국 표준시)424037
Tue Jan 16 2007 12:00:00 GMT+0900 (대한민국 표준시)404136
Thu Feb 15 2007 00:00:00 GMT+0900 (대한민국 표준시)424837
Fri Mar 16 2007 13:00:00 GMT+0900 (대한민국 표준시)414537
Mon Apr 16 2007 00:00:00 GMT+0900 (대한민국 표준시)404536
Wed May 16 2007 12:00:00 GMT+0900 (대한민국 표준시)394737
Sat Jun 16 2007 00:00:00 GMT+0900 (대한민국 표준시)394736
Mon Jul 16 2007 12:00:00 GMT+0900 (대한민국 표준시)394536
Thu Aug 16 2007 12:00:00 GMT+0900 (대한민국 표준시)374134
Sun Sep 16 2007 00:00:00 GMT+0900 (대한민국 표준시)333932
Tue Oct 16 2007 12:00:00 GMT+0900 (대한민국 표준시)333833
Thu Nov 15 2007 23:00:00 GMT+0900 (대한민국 표준시)353935
Sun Dec 16 2007 12:00:00 GMT+0900 (대한민국 표준시)324134
Wed Jan 16 2008 12:00:00 GMT+0900 (대한민국 표준시)313833
Fri Feb 15 2008 12:00:00 GMT+0900 (대한민국 표준시)324234
Sun Mar 16 2008 13:00:00 GMT+0900 (대한민국 표준시)313934
Wed Apr 16 2008 00:00:00 GMT+0900 (대한민국 표준시)323835
Fri May 16 2008 12:00:00 GMT+0900 (대한민국 표준시)293734
Mon Jun 16 2008 00:00:00 GMT+0900 (대한민국 표준시)304034
Wed Jul 16 2008 12:00:00 GMT+0900 (대한민국 표준시)314034
Sat Aug 16 2008 12:00:00 GMT+0900 (대한민국 표준시)294034
Tue Sep 16 2008 00:00:00 GMT+0900 (대한민국 표준시)283535
Thu Oct 16 2008 12:00:00 GMT+0900 (대한민국 표준시)273535
Sat Nov 15 2008 23:00:00 GMT+0900 (대한민국 표준시)263735
Tue Dec 16 2008 12:00:00 GMT+0900 (대한민국 표준시)253734
Fri Jan 16 2009 12:00:00 GMT+0900 (대한민국 표준시)243834
Sun Feb 15 2009 00:00:00 GMT+0900 (대한민국 표준시)273937
Mon Mar 16 2009 13:00:00 GMT+0900 (대한민국 표준시)263937
Thu Apr 16 2009 00:00:00 GMT+0900 (대한민국 표준시)253837
Sat May 16 2009 12:00:00 GMT+0900 (대한민국 표준시)234134
Tue Jun 16 2009 00:00:00 GMT+0900 (대한민국 표준시)233833
Thu Jul 16 2009 12:00:00 GMT+0900 (대한민국 표준시)244236
Sun Aug 16 2009 12:00:00 GMT+0900 (대한민국 표준시)233835
Wed Sep 16 2009 00:00:00 GMT+0900 (대한민국 표준시)213435
Fri Oct 16 2009 12:00:00 GMT+0900 (대한민국 표준시)193135
Sun Nov 15 2009 23:00:00 GMT+0900 (대한민국 표준시)193233
Wed Dec 16 2009 12:00:00 GMT+0900 (대한민국 표준시)183230
Sat Jan 16 2010 12:00:00 GMT+0900 (대한민국 표준시)173229
Mon Feb 15 2010 00:00:00 GMT+0900 (대한민국 표준시)183532
Tue Mar 16 2010 13:00:00 GMT+0900 (대한민국 표준시)183432
Fri Apr 16 2010 00:00:00 GMT+0900 (대한민국 표준시)183432
Sun May 16 2010 12:00:00 GMT+0900 (대한민국 표준시)173432
Wed Jun 16 2010 00:00:00 GMT+0900 (대한민국 표준시)163631
Fri Jul 16 2010 12:00:00 GMT+0900 (대한민국 표준시)163629
Mon Aug 16 2010 12:00:00 GMT+0900 (대한민국 표준시)153530
Thu Sep 16 2010 00:00:00 GMT+0900 (대한민국 표준시)153231
Sat Oct 16 2010 12:00:00 GMT+0900 (대한민국 표준시)163633
Mon Nov 15 2010 23:00:00 GMT+0900 (대한민국 표준시)153933
Thu Dec 16 2010 12:00:00 GMT+0900 (대한민국 표준시)143331
Sun Jan 16 2011 12:00:00 GMT+0900 (대한민국 표준시)144431
Tue Feb 15 2011 00:00:00 GMT+0900 (대한민국 표준시)144333
Wed Mar 16 2011 13:00:00 GMT+0900 (대한민국 표준시)143732
Sat Apr 16 2011 00:00:00 GMT+0900 (대한민국 표준시)143833
Mon May 16 2011 12:00:00 GMT+0900 (대한민국 표준시)133433
Thu Jun 16 2011 00:00:00 GMT+0900 (대한민국 표준시)133232
Sat Jul 16 2011 12:00:00 GMT+0900 (대한민국 표준시)123432
Tue Aug 16 2011 12:00:00 GMT+0900 (대한민국 표준시)123230
Fri Sep 16 2011 00:00:00 GMT+0900 (대한민국 표준시)123133
Sun Oct 16 2011 12:00:00 GMT+0900 (대한민국 표준시)123034
Tue Nov 15 2011 23:00:00 GMT+0900 (대한민국 표준시)123234
Fri Dec 16 2011 12:00:00 GMT+0900 (대한민국 표준시)113131
Mon Jan 16 2012 12:00:00 GMT+0900 (대한민국 표준시)113131
Wed Feb 15 2012 12:00:00 GMT+0900 (대한민국 표준시)113434
Fri Mar 16 2012 13:00:00 GMT+0900 (대한민국 표준시)113334
Mon Apr 16 2012 00:00:00 GMT+0900 (대한민국 표준시)103434
Wed May 16 2012 12:00:00 GMT+0900 (대한민국 표준시)103335
Sat Jun 16 2012 00:00:00 GMT+0900 (대한민국 표준시)103432
Mon Jul 16 2012 12:00:00 GMT+0900 (대한민국 표준시)103833
Thu Aug 16 2012 12:00:00 GMT+0900 (대한민국 표준시)103435
Sun Sep 16 2012 00:00:00 GMT+0900 (대한민국 표준시)93535
Tue Oct 16 2012 12:00:00 GMT+0900 (대한민국 표준시)103636
Thu Nov 15 2012 23:00:00 GMT+0900 (대한민국 표준시)93436
Sun Dec 16 2012 12:00:00 GMT+0900 (대한민국 표준시)83432
Wed Jan 16 2013 12:00:00 GMT+0900 (대한민국 표준시)93536
Fri Feb 15 2013 00:00:00 GMT+0900 (대한민국 표준시)93537
Sat Mar 16 2013 13:00:00 GMT+0900 (대한민국 표준시)93639
Tue Apr 16 2013 00:00:00 GMT+0900 (대한민국 표준시)93438
Thu May 16 2013 12:00:00 GMT+0900 (대한민국 표준시)83538
Sun Jun 16 2013 00:00:00 GMT+0900 (대한민국 표준시)83437
Tue Jul 16 2013 12:00:00 GMT+0900 (대한민국 표준시)83536
Fri Aug 16 2013 12:00:00 GMT+0900 (대한민국 표준시)73441
Mon Sep 16 2013 00:00:00 GMT+0900 (대한민국 표준시)83339
Wed Oct 16 2013 12:00:00 GMT+0900 (대한민국 표준시)83542
Fri Nov 15 2013 23:00:00 GMT+0900 (대한민국 표준시)83947
Mon Dec 16 2013 12:00:00 GMT+0900 (대한민국 표준시)73241
Thu Jan 16 2014 12:00:00 GMT+0900 (대한민국 표준시)73240
Sat Feb 15 2014 00:00:00 GMT+0900 (대한민국 표준시)73542
Sun Mar 16 2014 13:00:00 GMT+0900 (대한민국 표준시)73544
Wed Apr 16 2014 00:00:00 GMT+0900 (대한민국 표준시)73343
Fri May 16 2014 12:00:00 GMT+0900 (대한민국 표준시)73841
Mon Jun 16 2014 00:00:00 GMT+0900 (대한민국 표준시)74039
Wed Jul 16 2014 12:00:00 GMT+0900 (대한민국 표준시)73744
Sat Aug 16 2014 12:00:00 GMT+0900 (대한민국 표준시)63637
Tue Sep 16 2014 00:00:00 GMT+0900 (대한민국 표준시)73543
Thu Oct 16 2014 12:00:00 GMT+0900 (대한민국 표준시)73544
Sat Nov 15 2014 23:00:00 GMT+0900 (대한민국 표준시)63744

2014년 안철수근황

안철수의 팬으로서 뉴스에도 안나오고 어디에도 안나오길래 찾아보니

페이스 북만 하시더군요..


안철수의 새정치 ==> 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 클린 코드

프로그래밍 심리학이 이론서였다면 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 관련책들만 소개합니다.




 GoF의 디자인 패턴Head First Design Patterns리팩토링Product Details패턴을 활용한 리팩터링리팩토링xUnit 테스트 패턴

모두 읽어서 실전에 적용했습니다.

최근에는 루비로 디자인패턴을 많이 적용하는 편입니다.
(리팩토링하기가 너무 좋습니다.)








2012 - 읽은 책들


글로벌 소프트웨어를 꿈꾸다

글로벌 소프트웨어를 꿈꾸다
스탠포트 출신의 엔지니어이자, 실리콘벨리의 CEO 를 거쳐, 안철수 연구소 최고기술경영자(CTO)였던 김익환씨가 쓴책.
주로 큰 회사가 되기위한 프로세스및 문서화 중요성을 이야기한다. 실리콘 벨리에서는 어떻게 개발하는지 알수있어 매우 도움이 되었다. 
얼마나 주먹구구 식으로 하고있었는지 스스로를 반성하게 하는 책이다. 
아래 말이 마음에 와닫는데,

엔지니어링이란 문화를 기반으로 한 현실이다.
단순하게 기술적 으로 뛰어나려고 한다거나 또는 관리만 하려고 해서는 회사가 성공할수 없다는것을  의미한다.
회사의 문화가 매우 중요함을 의미한다.
책에서는 예를들어 회사의 문화란 아래와 같다고 합니다.
나의 코드를 commit 하기전에 누가 리뷰해주는것이 당연한가?
당연한것을 해야하는것 ... 그것이 문화입니다.

그 다음편 신간이나왔습니다....
글로벌 소프트웨어를 말하다, 지혜


실용주의 프로그래머











10년간. 3번째 읽어보았습니다.
Agile 및 실용주의 시리즈로 유명한 앤드류헌터, 데이브토마스의 불후의 명작입니다.
자동화 및 개발 철학등을 담고 있습니다. 이 책을 읽었을때의 느낌은 개발시 정체되어있던 부분을 한단계 업그레이드 시켜주는 기분이 었습니다.
자신보다 뛰어난 개발자들의 생각을 알고싶으시다면  필수적으로 읽어보아야 할것입니다. 3번정도 읽었지만 다시 읽어도 내가 부족한점을 느끼게하는 아주 좋은 내용의 책입니다.  
모 게임회사에서는 면접시 이 책을 읽지 않는 개발자는 채용하지 않는다는 일화도 있습니다.


허드슨을 이용한 지속적인 통합

허드슨을 이용한 지속적 통합








유명한 허드슨입니다. 이제는 이름이 jenkins 로 바뀌었지만 내용은 그대로 입니다.
회사는 생산성을 높이기 위해 CI 에 모든것을 투자해야합니다. 






사용자 스토리


사용자 스토리
애자일책중 마지막에 산 책입니다.
회사에서 간단한 batch 나 tool 을 개발할때 스토리 위주로 기능을 추가해가면 좋은것 같습니다.
이제는 애자일의 유행이 지나가고 (애자일은 당연한 프로세스로서 자리잡습니다)
Lean 이 유행이네요 ㅎㅎ



애자일 채용론

애자일 AGILE 채용론








면접보기전에 읽어보고 사람을 뽑아야겠네요.
내용이 좋습니다.
회사에 필요한 사람을 걸러낼때 중요합니다.





Release It


Release It 릴리스 잇

웹서버를 실전에 배치하고나서 생기는 문제들에대해서 논의하고 있습니다.
SoC 입장에서보면 Chip 이 나오고 생기는 문제들에대해서 어떻게 할것인가에 대한 내용인것 같습니다.









6권밖에 안되네요. 더 읽은것 같은데 읽은책 정리하기 시작한게 얼마 안되서 기록이 업센요..