Polpid's Pensieve

javascript 객체를 JSON 객체로 변환하는 함수.

JSON.parse() : JSON 형태 문자열을 자바스크립트 객체로 변환

JSON.stringify() : 자바스크립트 객체를 JSON 형슥으로 변환

1. <script type="text/javascript">
2.     var obj = {
3.         name : "TEST",
4.         gender : "Male"
5.     };
6.     console.log(obj);
7.     console.log(JSON.stringify(obj));
8.  
9.     var date = new Date();
10.  
11.     console.log(date);
12.     console.log(date.toJSON());
13.     console.log(JSON.stringify(date));
14.     console.log(JSON.stringify(date.toJSON()));
15. </script>

결과값

---

위대한 IT 벤처의 탄생

저자

양준철 지음

출판사

지앤선 | 2013-04-22 출간

카테고리

경제/경영

책소개

한국을 대표하는 9개의 IT 스타트업, 그들의 진솔하고 위대한 ...

---

한참 벤처 열풍이 일어났던 때가 있었다. 여기저기에서 벤처 기업이 생겨났고 그들의 앞날은 정말 탄탄대로일것만 같았다. 하지만 현실은 그렇게 만만하지 않았다. 바로 몇년후에 벤처 기업들이 문을 닫는 기사를 자주 접할 수 있었다. 

그런 시련속에서도 그래도 살아 남은 벤처들이 있다. 과연 그 차이점은 무엇이었을까? 

이 책에서는 벤처 기업을 만들고 이끌어온 사람들의 인터뷰를 통해 그들이 경험 했던 이야기를 알려주고 있다. 

이름과 성격이 다 다른 벤처기업이지만 인터뷰 속에서 공통점을 찾을 수 있었다. 

1. 남들과 다른 아이템.
- 유행을 쫓아가서는 안된다. 좀더 앞을 내다볼 수 있는 아이템이어야 한다.

2. 너무 급하게 생각하지 말자.
- 1.2년 하다가 포기해버릴 정도의 끈기 가지고는 안된다. 꾸준히 기술과 능력을 성장시키고 지속적으로 발전 시켜야 한다.

3. 사람이 재산이다.
- 기업이나 벤처도 다 마찬가지 이다. 사람이 모여서 하는것인 만큼 구성원과의 의사소통이 정말 중요하고 구성원 하나하나의 능력이 모두 소중 하다.

그리고 인터뷰한 사람들 모두 "아직은.." 이라고 말한다. 나쁜 의미에서가 아니다. 벤처를 설립하고 꾸준히 키워나가서 사람들에게 주목을 받고 어느정도 이름은 알려졌으나 "성공" 이란 단어를 섣불리 꺼내지 않는다. 바로 앞에 어떤 어려움이 있을지 모르기 때문이다. 이런 굴곡을 넘는 경험을 하면서 성장을 하고 있으니 그들의 땀방울이 얼마나 값진 것인가 새삼 느끼게 된다. 그리고 창업이라는 것이 정말 쉽게 생각할 일이 아니다라는 것을 실감하게 되었다.

책 구성

모르는 용여들에 대해서 주석으로 잘 설명해 줘서 읽는데 많은 도움이 되었다. 책 뒷편에 있는 벤처 창업 절차에 관한 내용도 실제 창업을 앞두고 있는 사람들에게 많은 도움이 될것 같다.

단점이라고 한다면..

책 표지를 보고 와이프가.. "욱일승천기" 아냐?? -_-;; 생각해보니 비슷하다. 내용은 정말 가벼우면서도 무게감 있었는데 책표지는 정말 가벼워 보이고 싸보인다.

그리고 개인적으로 정리 문구 마지막에 있는 "파이팅" 은 손발이 오그라 든다... 첫 인터뷰 읽다가 설마 다음 인터뷰에도 있는것은 아니겠지.. 라고 생각했으나. -_-.. 끝 마무리 문구가... 전부 파이팅...그냥 웃어넘겼다. ^^;;

[지앤선 소셜 프론티어 2기]

원문 : Ebooks and the future of research 

http://www.hanbit.co.kr/network/category/category_view.html?cms_code=CMS1548255504

번역한지 꽤나 됐는데. 이제올라왔네 ^^

 과거를 알지 못하면 지식은 발전할 수 없다. 지식을 추구하는 사람은 지난 세대가 경험했던 일들을 참고해야만 한다. 문학가들은 책으로, 음악가들은 악보로, 예술가들은 박물관에 있는 유물로, 각각 그들의 업적을 남겨놓았다. 

참고 자료들의 지속적인 효용성은 우리의 전체적인 연구 시스템을 뒷받침 해준다. 그것은 우리들이 간신히 유지하기 위한 가치 목록을 등록하는 방법에 뿌리깊게 자리잡게 되었다. 그 효용성은 신기루처럼 사라질지 모르지만, 놀랍게도 조금씩 효과가 나타나고 있다. 

출판의 지속성은 출판한 책의 양과 권위 있는 버전에서 갖고 있는 편의성에 의해서 결정된다. 어떤 연구가도 정당하게 얻을 수 없거나 존재 자체가 무시되는 책을 참고하지는 않을 것이다. 

eBook들의 성공은 우리가 ebook 유통에 대한 잘못된 인식 때문에 매력적으로 보일지 모른다. 하지만 대부분의 상업적인 플랫폼들은 마음대로 수정하고 삭제할 수 있는 유일한 원본을 의미한다. 킨들과 아이패드에서 사용하는 수많은 ebook들이 있지만 실제로는 애플과 아마존이 가지고 있는 책은 2권 뿐이다. 

Amazon에서 판매하던 조지오웰의 "1984"는 기록을 쉽게 삭제할 수 있다는 것을 입증하였다. 검열의 위험에 대해 말하자면, Nook 사용자들은 최근에 전쟁과 평화(War and Peace)의 기괴한 버전을 접하게 되었다. 바로 kindled 이라는 단어 대신에 nooked로 바꼈던 것이다. 이렇게 너무나도 우스운 실수는 빨리 잊혀졌지만 더 위험한 편집이 쉽게 발생할 수 있다. 

Apple과 Amazon이 가장 수준 높은 학문의 표준을 지키고 있다고 할 지라도 이들의 플랫폼이 만들어진 형식들은 그들을 생존할 수 있도록 설계되지 않았다. 예측하건데 일반 텍스트 문서는 나중에 판독될 수 있다. 하지만 상표로 등록되어 암호화된 문서들은 어떨까? 미래에 연구가들이 암호를 해독을 위해 신경을 쓸까? 

역사적으로 도서관 제도는 개인적으로 사용된 수 백만권의 책들을 백업하기 위한 곳으로 여겨졌다. 이런 신뢰할만한 제도들은 모든 책들을 보호하는 데에 그 의미를 두고 있다. 그 시대의 사람들이 재미없어 하거나 어리석고 불필요하다고 생각했던 책들도 포함해서 말이다. 

그들은 지금 개개인의 연구들로부터 오랫동안 버려졌던 훌륭한 보관소를 가지고 있습니다. 가장 중요한 점은 이들 도서관들이 예측 불가능한 정치적 변화로부터 그들의 의무를 지키려 한다는 점이다. 

개인 독자들이 배포되고 인쇄되어 판매되는 책들을 멀리 하고 도서관들이 ebook의 "구매"를 대행한다면 지금 시대의 출판물들은 사라질 위험에 처하거나 점점 믿을 수 없게 될 것이다. 

나는 책들을 암호화하는 관행에 동의하지는 않지만 출판사들이 이러한 행동을 하는 이유는 이해한다. 그러나 사회는 광범위하게 퍼져있는 지식 자산을 잃어버려서는 안된다. 

나는 출판사들에게 정치적이고 상업적인 압력으로부터 책들을 보호할 수 있고, 세계적으로 컴퓨터 사용에 능한 기관들에게 그들이 디지털 형태로 발간한 모든 책들의 암호화되지 않은 원본들을 맡기라고 말하고 싶다. 

그렇게 되면 책들은 저작권이 없는 채로 온라인에 출판될 것이다. 그렇게 함으로써, 미래의 연구가들에게 오늘날을 참고할 수 있는 글들이 믿을 수 있고 증명할 수 있는 형태라는 확신을 심어줄 수 있을 것이다.

가끔 이런것이 필요할 때가 있다.

userId 를 USER_ID 로 바꾸는 기능.

1. public class Test {
2.     public static void main(String[] args) throws Exception {
3.         String regex = "([a-z])([A-Z])";
4.         String replacement = "$1_$2";
5.                 String str = "UserId";
6.                 String value = "";
7.                 value = str.replaceAll(regex, replacement).toUpperCase();
8.                 System.out.println(value);
9.     }
10. }

해당 workspace 아래에 있는 

.metadata\.plugins\org.eclipse.wst.server.core\tmp0\wtpwebapps\프로젝트 명\WEB-INF

이 폴더를 찾아가서 lib가 제대로 들어가 있는지 확인해 보자..

이클립스 화면에 보인다고 해서 다 돌아가는게 아니더라...-_-;;

프로젝트 publising 할대 위에 폴더로 jar 파일이랑 다 들어가는데 그때 안들어가는 경우가 생기기도 한다..

그러니... 잘 기억해두고 찾아보자..

---

프로그래머로 사는 법

저자

샘 라이트스톤 지음

출판사

한빛미디어 | 2012-10-04 출간

카테고리

컴퓨터/IT

책소개

성공하는 소프트웨어 프로그래머를 위한 경력 관리 비결!『프로그래...

---

- 2013.03.27

4월이 되어가고 있지만 아직까지 읽기를 마치지 못했다.

그래서 이렇게 적어가면 좀더 자극을 받지 않을까 해서 적어본다. 

중간 조금 넘게 읽은 시점에서 현재까지 느낀점이 있다.

서로 다른, 아니 여러명의 프로그래머들에게 동일한 질문을 한 결과, 접근 방법은 다르지만 한가지 동일한 점이 있다는 것을 알게 되었다.

"프로그래밍을 즐겨라"

한결같이 이렇게 말 하고 있다.

자기가 하고 싶은 일을 하면서, 일을 즐길 수 있는 직업은 프로그래머 밖에 없다고 말 하고 있다. 또 놀면서 돈을 벌 수 있는 유일한 직업이라고 말 하고 있다.

즐긴다, 논다.

전에  "노력하는 자는 즐기는 자를 따라갈 수 없다" 라는 말을 자주 들었다. 과연 나는 프로그램을 개발 하면서 즐기고 있는지 한번 생각해 봤다. 딱히 관심은 있지만 막상 개발 할 때에는 즐긴다는 표현 하고는 어울리지 않는것 같다. 그때 그때 닥쳐서 하고 있는 느낌이라고 할까? 

변명을 좀 하자면 현실의 개발 환경이라든지 상황이 그렇게 즐길수 있을만한 상황이 아니다.. 라는 변명을 늘어 놓을 수 있겠지만.... 막상 따지고 보면 이 책에 나와있는 분들이 자신들의 업적을 이루어 냈을 시기에도 딱히 상황이 좋았을 것 같지는 않다. 더 나빴겠지... 결론은 이건 변명이 되지 못한다는 이야기 이다. 

그래서 이제는 좀더 즐기면서 해보려고 한다. 수박 겉 핥기 식으로 하지 않고 좀더 깊은 곳을 바라보고 생각하는 습관을 가져야 겠다. (이렇게 적어 놓으면 뭔가 도움이 되겠지... )

- 2013.04.02

어제 읽다가 기억에 남는 부분이 있어서 메모를 한다. ^^

새로운 것을 시작한다는 것은 언제나 두렵고 기대되는 일이다. 물이 흐르지 않으면 썪어 버리듯이 사람도 마찬가지다. 자신을 계발하지 않고 계속 넉놓고 있다가는 언젠가는 다른 사람들보다 한참 뒤에 서있는 자신을 발견할 것이다. 

- 2013.04.03

책을 다 읽었다.

전체적으로 책 내용면에서 보자면 각자의 경험과 일화등을 수필같은 형식으로 풀어놓았다.

다만 생각보다 분량이 많다는 느낌이 들었다. 조금씩 아침에 읽어서인지는 몰라도 다 읽는데 굉장히 오래 결렸다...

프로그래머라는 직업을 가지고 있으면서 그들이 살아온 날들에 대한 이야기. 

예전보다 요즘들어 이런 내용의 책들이 많이 나오는데, 이 분야의 일들이 그만큼 쉽지 않다는 의미라고 생각한다. 한가지 아쉬운 점이라면 그들이 말하는 것은 다 동일한데 그것을 실천에 옮기기가 쉽지 않다는 것이다.

위에서 썼듯이 개발을 즐기면서 하면 좋을텐데, 그게 쉽지 않으니 말이다.

10년 전에도 이런 이야기들이 오고 갔을것이고 지금도 나오고 있고 앞으로도 계속 될것이다. 뭔가 이 분야의 기반을 송두리째 엎어버릴 그런 일들이 일어나지 않는한.

이 책에 나온 이 분야에서 뭔가 위대한 일들을 해낸사람들.

하지만 그들이 분명 슈퍼 천재이거나 한 사람들이 아니었다는 점이 포인트인것 같다. 나도 즐기고 생각하고 한다면 그들과 같은 사람이 될수 있다는 생각을 이책을 읽으면서 느끼게 되었다.

ExecutorService

1. newFixedThreadPool vs newCachedThreadPool

일단 doc 문서를 참고 하자면 아래와 같이 설명이 되어있다..

newFixedThreadPool();

Creates a thread pool that reuses a fixed number of threads operating off a shared unbounded queue. At any point, at most nThreads threads will be active processing tasks. If additional tasks are submitted when all threads are active, they will wait in the queue until a thread is available. If any thread terminates due to a failure during execution prior to shutdown, a new one will take its place if needed to execute subsequent tasks. The threads in the pool will exist until it is explicitly shutdown.

newCachedThreadPool();

Creates a thread pool that creates new threads as needed, but will reuse previously constructed threads when they are available. These pools will typically improve the performance of programs that execute many short-lived asynchronous tasks. Calls to execute will reuse previously constructed threads if available. If no existing thread is available, a new thread will be created and added to the pool. Threads that have not been used for sixty seconds are terminated and removed from the cache. Thus, a pool that remains idle for long enough will not consume any resources. Note that pools with similar properties but different details (for example, timeout parameters) may be created using ThreadPoolExecutor constructors.

newFixedThreadPool은 pool size가 다 차고 나면 다음 thread가 실행되기 위해서는 먼저 실행되었던 thread가 종료되어야 한다. 

newCachedThreadPool는 기존에 사용되던 thread가 사용가능하면 재사용하고, 아니면 새로운 thread를 생성한다. 그리고 일정시간 동안 사용하지 않는 thread는 종료시킨다. 

이런 의미에서 newChacedThreadPool이 성능면에서 좋다는 의미인것 같다. 

execute vs submit

자바 스크립트를 보다보면 편리하다는 느낌이 들긴 하는데 한편으로는 멘붕이 오기도 한다. -_-;;

정의를 안해도 그냥 가져다 쓰면 되고.. 

파라메터리 변수, 함수 등을 맘대로 넘기고.. 참... 편리한건지.. 난장판인건지....

아래 소스를 보게 되면.. 같은 이름의 변수들이 계속 정의된다. -_-;;;

허용이 되긴 하지만.. 저렇게 사용하지 말아야지.. 라는 생각이 든다. 

원문 : The future of programming 

http://www.hanbit.co.kr/network/category/category_view.html?cms_code=CMS7197890408

점점 더 번역을 할 수록 어렵다는것이 느껴진다.

의미는 이해가 가는데 말로 표현하고 글로 작성하는 부분이 여전히 부족한 점이 많다.

여러번 퇴고를 해야하는데.. 핑계삼아서 반복을 못한것도 하나의 원인인것 같다.

"누가 읽더래도 이해하기 쉽게 번역을 하자"!!

----------------------------------------------------------------------------------------------------------------------------------------------------------------------

프로그래밍은 변화하고 있습니다. PC의 시대가 끝나고 소프트웨어 개발자들의 시대가 오고 있습니다. 그들은 수많은 장비와 업무 기능들, 그리고 기종에 따라 다른 접근방법들이 필요한 문제점들을 해결하고 있습니다. 데이터가 증가하는 지금 시대에, 많은 종류의 프로그래밍을 할 수 있는 능력은 모든 분야에서 점점 중요하게 여겨지고 있습니다. 그리고 프로그래밍도 더 이상 엔지니어 영역이라는 인식도 사라지고 있습니다. 

 앞으로 몇 년에 걸쳐, 저는 프로그래밍이 변화해 가는 모습과 그것이 영향을 미치는 요인을 연구해 보려고 합니다. 그리고 이 기사는 그러한 몇 가지 영향력에 대해 다루고 있습니다. 이러한 변화에 대한 의견이나 같이 할 연구할 의사가 있다면 언제든지 알려주기 바랍니다. 

우선 무엇을 먼저 해야 할까요? 목표는 다가올 10년동안 프로그래머들이 필요한 필수적인 기술과 그들이 우선시 해야 할 교육, 그리고 단기간의 경향과 장기적 변화간의 차이에 대해 서술하는 데에 있습니다. 

분산 컴퓨팅 

오늘날에 "평범한" 환경에서 개발을 한다는 것은 10년전과는 의미가 달라졌습니다. 웹 애플리케이션이나 모바일 또는 빅 데이터와 같은 환경이 생기면서 프로그램이 오직 한대의 컴퓨터에서만 사용한다는 생각은 바뀌게 되었습니다. 

그렇게 되면서 프로그래머들은 동시성, 락, 비동기 네트워크 통신, 프로토콜과 같은 문제들을 처리 하게 되었습니다. 가장 기본적인 웹 프로그래밍을 할 때라도 캐싱과 같은 친근한 문제와 마주치게 될 것입니다. 

이러한 문제들과 관련해서 우리는 컴퓨팅 스택에 있는 단계별 현상들을 볼 수 있습니다. 

상위 단계인 클라우드 컴퓨팅은 다양한 기계와 네트워크를 유지하는데 발생하는 번거로운 상황을 줄이기 위한 방법을 찾고 있습니다. 애플리케이션 개발 단계에서는 익숙한 패턴을 사용하여 프레임워크를 구현하고 복잡한 세부 내용들을 추상화하고 있습니다. 그리고 개발 언어 단계에서는 Go나 Scala 같은 언어가 제공하는 기능에 의해 동시성이나 네트워크 컴퓨팅이 좀더 간단해 지고 있습니다. 

디바이스 컴퓨팅 

주위를 둘러보면 당신이 가지고 있는 모든 전자 제품에는 프로세서와 프로그램을 가지고 있습니다. 그리고 당신의 컴퓨터 또한 그 중에 하나입니다. 모든 사람들이 제품에 내장된 프로그램에 관심을 갖지는 않지만 많은 개발자들은 분명히 모바일 폰으로 개발하기 위한 방법이 무엇인지 배워야 합니다. 가까운 미래에 자동차나 무인항공기, 안경, 스마트 더스트에 적용시켜야 할 수도 있습니다. 

심지어 기존의 컴퓨터 사용에서도 다양한 고급 데이터를 고속으로 처리하는 보조 프로세서로 GPU 수가 늘어나게 되면서 기존과 다른 프로그래밍이 필요해졌습니다. 다른 형태의 요인들은 다른 방법의 프로그래밍 접근을 요구하게 되었고 Hobbyist와 prototype들은 비슷하게 Arduino와 Processing이라는 하드웨어를 도입하게 되었습니다. 그리고 프로그래밍 언어들과 프로그래머들은 메모리의 부족, CPU 속도, 파워 소비, 주파수 통신, 실시간 처리 등과 같은 특별한 분야의 이슈들에 대해 미리미리 대응 해야만 했습니다. 

데이터 컴퓨팅 

오늘날 많이 사용하는 객체 지향 프로그래밍은 일반적으로 데이터에 적대적입니다. 이 방법은 접근하는 메소드를 통해 데이터를 감싸는 행위에 초점을 맞추고 있기 때문에 이전보다 데이터를 더 타이트하게 보호하게 됩니다. 수학적인 의미로 데이터는 행동이 없는 말 그대로 데이터에 불과하지만 C++이나 java와 같은 영역에서 개발자들은 데이터의 접근 방법에 대해 생각해야만 합니다. 

데이터와 데이터 분석의 중요성이 커짐에 따라 first class citizen 처럼 데이터를 처리하는 언어들의 인기와 사용이 증가하게 되었습니다. 그리고 분명히 R과 같은 통계적인 언어들도 이러한 흐름에 따라 사용이 증가하고 있습니다. 하지만 일반적으로 프로그래밍의 목적면에서 Python이나 Clojure가 데이터를 다루는데 더 쉽다는 의견이 대부분을 차지하고 있습니다. 

보편화된 컴퓨팅 

점점 많은 사람들이 프로그래밍을 하고 있습니다. 이 영리하고 수많은, 돌발적인 개발자들은 엑셀 매크로의 마법과 같은 기능과 자바스크립트 기술, IFTTT 또는 Zapier와 같은 웹 서비스를 지원하는 것들에 골머리를 앓고 있습니다. 그들은 소프트웨어 개발에 대해 약간 알고 있긴 하지만 그 이상 관심을 갖고 있지는 않기 때문이죠. 

이렇게 무심한 프로그래머들은 쉽게 문제들을 발생시키고 오랫동안 이런 문제들이 해결될 때까지 곤경에 빠지게 됩니다. 아무리 낙관적으로 생각해도 이건 짜증스럽고, 최악의 경우에는 고용주에게 책임을 묻는 경우도 발생하게 됩니다. 게다가 이건 프로그래머의 잘못도 아닙니다. 

프로그램이 작동 가능한 환경을 제공하는 사람들은 어떻게 더 나은 "돌발적인 개발자" 를 찾을 수 있을까요? 우리는 기존의 언어보다 새로운 개발 언어와 더 나은 프레임워크를 사용해야만 할까요? 이건 교육적인 문제인걸까요? 아니면 이건 문제가 아니라 단지 시기상의 문제일까요? 

Bre Victor"s work와 Scratch, Light Table과 같은 프로젝트에서 다른 미래에 대한 힌트를 얻을 수 있습니다. 

위험한 컴퓨팅 

마침내, 우리가 소프트웨어 개발에 대한 지금의 접근 방법으로 만든 불안정한 계획을 시험해볼 가치가 있게 되었습니다. 두뇌가 오직 두뇌 안에서 풀 수 있는 문제들만 해결 할 수 있듯이 문제는 단순합니다. 오늘날 프로그래머가 되기 위해서는, 머릿속으로 생각해서 만든 프로그램을 실행시킬 수 있는 능력을 갖춰야 합니다. . 

만약 문제에 대한 영역이 점점 커지면 프레임워크를 사용해서 문제에 대한 영역을 줄이면 됩니다. 우리는 CPU 위에 운영체제를 설치하고 라이브러리들과 사용자 인터페이스들은 운영체제 위에서 실행합니다. 그리고 애플리케이션 프레임워크는 이들 라이브러리 위에서 실행되고, 웹 브라우저는 프레임워크 위에서 실행됩니다. 그리고 자바스크립트는 브라우저 위에서 실행되고 자바스크립트 라이브러리는 자바스크립트 위에서 실행됩니다. 여기에서 끝이 아닙니다. 

우리는 다른 쪽 위에 한 개의 찻잔을 쌓아 올리는 야심찬 웨이터와 같습니다. 바로 지금은 약간 흔들려 보일지도 모릅니다. 우리는 더 빠르고 강력한 CPU를 만든 것이 아니라 지난 10년전에 만들었던 같은 종류의 애플리케이션을 만들었을 뿐입니다. 그리고 결국 수많은 시스템들을 위험으로 몰아놓는 보안상 문제점을 프레임워크 상에 만들어 냈습니다. 

왜 우리는 컴퓨터를 사용하면서 불안한 문제점들을 만들고 프로그래머가 컴퓨터의 능력을 그들의 머리에서 활용할 수 있는 정도로만 국한시킬까요? 이런 소프트웨어의 관점을 바꿀 수 있는 방법이 있을까요? 

결론 

나는 미래의 프로그래밍을 연구하면서 이러한 트렌트를 지켜볼 것입니다. 만약 경험이나 관점을 가지고 있거나 다른 방법으로 연구를 하고 계신 분들이 있다면 의견을 듣고 싶습니다. 그리고 이 기사에 대한 의견을 남겨주면 감사하겠습니다.