'이런저런 얘기들...'에 해당되는 글 21건

  1. 2014.02.16 석사학위 논문작성관련 참조
  2. 2013.07.05 꿈을 실현하는 방법
  3. 2013.06.15 레트로스펙티브(Retrospective)
  4. 2013.04.21 임백준의 소프트웨어 산책
  5. 2013.04.06 Ten steps to a good research paper (How to study 사이트의 내용)
  6. 2013.04.06 졸업논문을 준비하면서...
  7. 2013.04.06 '천재와 싸워 이기는 방법' 이라는 만화가 이현세 선생님의 글
  8. 2013.01.26 2013년 JCO 컨퍼런스
  9. 2013.01.23 TED영상
  10. 2012.07.15 내가 생각하는 좋은 커피숍의 조건은...

석사학위 논문작성관련 참조

석사학위 관련 논문작성방법


- 자기주장 1~2문자을 만든 것 임, 학문적인 큰 기여를 목표로 하지 말것


- 참조할 논문 1~2개를 Key Paper로 선정

   해당 논문의 Further Work 에서 idea를 찾아라 (토픽선정)


- 각 Chapter는 독립적으로 구성, 각 문장은 문어체, 5W1H 기준으로 작성 


- 참고문헌을 많이 표기


참고

 http://kimstar.pe.kr/blog/322


강의영상

 https://www.youtube.com/watch?v=cKk0fGb56WA&noredirect=1#t=3727






꿈을 실현하는 방법

꿈을 실현하는 방법이라는 것이 생각보다 간단하게 와닿는 문구이다.

당장 실천에 옮길 수도 있을 것 같고...


역시 꾸준하게 실천에 옮기는게 중요할 것이다. 

구체화된 형태로 목표를 잡고, 차근차근 준비하고 또 끈기있게 열정을 가지고

진행해야 할 것이다... 




A dream written own with a date becomes a goal,

A goal broken down becomes a plan,

A plan backed by action makes your dream come true.



꿈을 날짜와 함께 적어놓으면 그것은 목표가 되고,

목표를 잘게 나누면 그것은 계획이 되며,

그 계획을 실행에 옮기면 꿈은 실현되는 것이다.

- 그레그 S 레이드





레트로스펙티브(Retrospective)

팀의 능력을 향상하는데 있어서 많은 도움이 될 것 같다.


http://story.pxd.co.kr/733


임백준의 소프트웨어 산책

오랜만에 약간 휴식을 취할 겸 지하철 출퇴근에 읽었는데 생각보다 흥미로워서 정리를 해본다.


1. 객체지향

 - 퍼즐문제: 1~100의 사물함, 1번학생 부터 100번까지 문을 열기/닫기

    완전제곱수(1,4,9,...)의 특성을 파악해서 해결

 - 객체지향 언어에서 polymorphism, inheritance,encapsulation에 대한 본인의 입장과 

    철학은 무엇인가?        

 - 객체란 무엇인가?

 - 분산사건(discrete event) 시뮬레이션에 적합한 SIMULA 개발 (나이가드, 요한달)

    > SIMULA에서 클래스와 객체의 개념을 정립, 

       but 범용언어로 대중지지가 없어 Smalltalk가 최초라는 주장도 있음

    > 눈문 The Simula 67 Common Base Language

     "무수하게 많은 세세한 내용을 담고있는 시스템이나 문제를 다룰 때는, 분해(decomposition)가 제일 중요하다. 인간의 마음은 집중을 필요로 한다. 연관된 개념의 숫자를 충분히 작게 줄이는 것은 명확하고 조리있는 사유를 위해서 필수적이다. 커다란 문제를 분해하면 제한된 수의 세부사항을 담고 있기 때문에 한번에 다룰 수 있는 크기의 문제를 얻게 된다. 분석과 프로그래밍에 한 사람 이상이 참여하는 경우에는 적절한 분해가 받드시 요구된다.


  - Smalltalk (Alan Kay)

    세포(cell)라는 metaphor를 이용해서 프로그래밍을 쉽게 만드는 문제에 집중, 

    세포가 일종의 객체, 캡슐화의 개념

    나이가드와 달이 '복잡성의 극복'을 추구, 케이는 '단순성의 구현'을 추구함

    Object Oriented 라는 말을 처음 사용

    워드커닝험과 켄트백도 모두 smalltalk 프로그래머임

  - Parametric polymorphism : 컴파일타임에 파라메터로 지정된 형태, Java의 Generic

     Ad-hoc polymorphism  : 일반 overriding  

     다형성은 객체를 수정에 닫히고, 확장에는 열리도록 구성하는 'Open-close'원리에 

     입각해서 정의하는 가장 강력한 무기

  - 코드의 재사용과 상속   

     코드재사용의 방법을 찾기 위해 다익스트라(Dijkstra)나 베이커(Baker)는 

     구조적 프로그래밍의 방법론을 연구

      > 핵심은 모듈의 응집(module cohesion)과 모듈의 결합(module coupling)

         응집도는 높고, 결합도는 낮게...


2. 디자인패턴

  - 패턴은 반복적인 문제에 대한 공통의 해결방법(참조용)

  - 프로그래머간의 의사소통의 좋은 수단

  - 패턴의 본질을 파악, 카탈로그를 암기할 것이 아니라 해당 패턴을 사용하는 

    상황과 본질을 정확하게 이해 (해당 문제에 대한 이해 필요)

 - 크리스토퍼 알렉산더(Christopher Alexander)의 

    [A Pattern Language:Towns, Buildings, Construction ; 1977] 

    > 도시를 설계하는 방식, 방에 창문을 다는 방법 등 다양한 건축의문제를 다룬다

 - 워드커닝험(Ward Cunningham)과 켄트 벡(Kent Beck)가 1987년 OOPSLA

   (Object-Oriented Programming, Systems, Languages & Application)에 보고서를 제출

   "우리는 건축가이자 환경구조물센터의 창립자인 크리스토퍼 알렉산더의 연구를 적용해 정립한 개념을 이용해서 소프트웨어를 설계하고 구현하는 과정에 근본적인 변화를 꾀할 것을 제안한다. 알렉산더는 집과 사무실이 궁극적으로 그 안에서 살아갈 사람들에 의해서 설계되고 지어져야 한다고 주장했다. 그에 의하면 바로 그런 사람들이야 말로 특정한 구조물이 갖추어야 할 요구조건들을 가장 잘 이해하고 있기 때문이다. 우리는 이에 동의하며, 또한 동일한 원칙이 컴퓨터 프로그램에도 적용되어야 한다고 생각한다. 건물이든 프로그램이든 그들이 갖는 크기나 복잡성, 그리고 전문적인 설계를 위해서 필요한 오랜 훈련과정을 고려한다면 이와 같은 주장이 엉뚱하게 들릴지 모른다. 그렇지만 알렉산더는 매우 설득력있는 시나리오를 제시했다. 그것은 바로 '패턴언어'라고 불리는 개념이다"


 -  워드과 켄트가 '패턴언어'를 프로그래밍 세계에 끌어들이는 대한 최초의 불꽃을 당겼다면

    에릭감마(Erich Gamma)는 기름을 부어 큰불을 만들어낸사람

    (Junit과 Eclipse와 같은 오픈소스 개발자)


3. 리펙토링

  - 리펙토링은 소프트웨어 시스템의 원래 기능은 그대로 두면서 내부의 구조를 개선하는 것을 의미한다. 그것은 버그의 가능성을 최소화하기 위해서 코드를 깔끔하게 정리하는 엄정한 방법이다. 한마디로 리팩토링을 한다는 것은 이미 작성된 코드의 설계를 나중에 개선하는 것이다

 (마틴파울러의 Refactoring책 서문)


  - 폴 그레이엄: 인공지능언어인 LISP에 관한 교과서 저술할 정도의 깊은 내공

     Hackers & Painters 저자

     그레이엄이 고백한 프로그래밍 스타일은 마치 화가가 붓을 놀려서 그림을 완성해 나가는 것과 같은 점진적이고 반복적인 과정으로 이루어져 있다. 그는 프로그래밍을 시작할 때 전체적인 설계를 마치고 코딩을 시작하기 보다는 캔버스에 그림을 그릴 때처럼 조금씩 반복되는 작업을 통해서 코드에 살을 붙여 나갔다. 이과저에서 키보드는 붓이 되고 모니터는 캔버스가 되었다.

     (프로그래밍도 마치 스케치를 하는 방식과 다르지 않으며 예술적인 작업이다)


   - Refactoring의 전도사인 마틴 파울러(Marting Fowler)는 이런 방식에 대해서

      "리팩토링이 코딩에 앞선 설계(upfront design)를 대체할 수 있다는 주장도 존재한다.

       피팩토링을 염두에 둔다면 여러분은 설계를 할 필요가 전혀 없다. 머릿속에 가장 먼저 

       떠오르는 생각을 대충 코드로 구현한 다음, 그것이 제대로 동작하도록 수정하고, 

       리팩토링을 통해서 제대로 된 모양을 갖추도록 만들어 나간다. 이와 같은 방법은 아무 

       문제가 없다. 나는 이러한 방법을 통해서 대단히 잘 설계된 소프트웨어를 완성한 사람들을

      본적이 있다" 

      > 건축과 같이 리팩토링의 비용이 심한 경우는 해당되지 않지만, 사이버 세계에서는 가능함


  - 복잡성에 대한 두려움

     기본적인 초식과 멀티스레딩 등 심오한 분야도 정통한 영국의 개발자들이 개발한 

     컴포넌트는 지나치게 완벽한 시스템의 전형이었음

     객체간의 치밀한 연관관계, 요구조건을 뛰어넘는 보편적인 시스템을 만들려고 '과욕'을

     부린 지나치게 완벽한 시스템의 전형

     확장을 위한 일반화가 필요하지만, '과욕의 일반화'에 가까웠음

     > 잘못된 버그에 대해서, 컴포넌트의 커널에 해당 부분을 재설계해야 하는 상황이 됨

        '복잡성'에 대한 두려움 없는 용맹함 -> 본인들의 내공과 명석한 두뇌를 너무 신뢰

     > 단순성(Simplicity) : 프로그래머의 으뜸 덕목, 

        'Practice of Programming' (브라이언 커니건, 롭 파이크) 책에서 끊임없이 강조한 것

     > 단순함에 대한 미학

        좋은 프로그램의 특징: 단순성(Simplicity), 명확성(Clarity), 

          확장을 위한 일반성(Generality), 

          사람이 해야하는 수고를 덜어주는 자동화(Automation) 


  - 후각을 발달시키기

     Bad Smells

     . 중복된 코드 (Duplicated Code)

     . 긴 메소드 (Long Method)

     . 커다란 클래스(Large Class)

     . 긴 인수 (Long Parameter List)

     . 스위치 명령문 (Switch Statements)

     . 병령적인 상속구조 (Parallel Inheritance Hierarchies)

     . 추측에 근거한 일반화 (Speculative Generality)

     . 임시필드 (Temporary Field)

     . 설명문 (Comments)

   

 4. 소프트웨어 공학

   - 3명의 매니저를 만났음

     1) 꼼꼼한 여성 매니저: micro management 타입

          프로그래머의생산력을 극대화하는 장점, 자율적인 창의성은 억압하는 측면

     2) 자유방임스타일 흑인 매니저: 일정만 관리, 기술문제는 팀의 리더가 해결하도록 장려, 

          자신은 보고만 받음

          프로그래머의 창의력은 발휘할 수 있으나, 도덕적 헤이 발생

          소수의 프로그래머를 제외하면 스스로 동기부여를 하지 못하고 방황하기 쉬움

      3) 현재 소프트웨어를 설계한 매니저: 프로그래머로써의 모습이 남아있음, 

          자기 코드에 대한 애정(애착)이 강렬

         이런 애착을 배경으로 '프로그래머의 시각'에서 프로젝트를 관리하려고 노력

         시스템에 대한 강렬한 애착과 남다른 책임감, 프로그래머입장에서의 문제의식

         > 여성매니저의 꼼꼼함과 흑인 매니저의 자유방임이 갖는 장점이 결합

         > 선수 겸 코치에 가까워, 간혹 다른 선수들의 포지션을 정확히 결정해서 활용하지 못함

            실제 문제발생 시 적절한 프로그래머를 활용하기 보다 직접 키보드를 안고 해결하려 함

            당장은 그의 마음이 편해도 장기적으로 팀의 실력을 키우는 데 도움이 되지 않음 

    - 소프트웨어 프로젝트 관리

       컴퓨터 프로그래밍이 '컴퓨터를 위한 알고리즘'을 작성하는 것이라면, 

       소프트웨어 프로젝트관리는 프로그래머를 이용해서 '프로젝트를 위한 알고리즘'을 작성

       프로그래밍은 '논리의 예술', 프로젝트 관리는 '의사소통의 예술'


    - 애자일 소프트웨어 개발선언 http://agilemanifesto.org/principles.html

       > 경험이 풍부한 강사는, but 애자일이나 XP 원리의 일반적인 원칙은 동의하지만, 

         만능은 아님 


    - XP 프로그래밍

       "XP는 마치 퍼즐(jig saw puzzle)과 비슷하다. 많은 조각들이 존재하는 것이다.

       각각의 조각은 아무런 의미가 없다. 그렇지만 그들을 모두 결합하고나면 큰 그림이 보인다.

       이것은 XP가 전통적인 소프트웨어 개발 방법론과 결정적으로 다른 지점이다. 

       이렇게 함으로써 우리는 프로그래밍을 하면서 동시에 변경을 할 수 있는 길을 찾는다"

      > XP의 4가지 키워드: 의사소통, 단순성, 피드백, 용기 

      > Incremental and Iterative 개발모델과 차이점

         XP는 반복적인 회전 주기를 미리 상정하지 않음, 

        단 한번의 과정을 하더라도 수시로 의사소통과 피드백의 기회를 마련할 것을 권장함 

        일반적인 방법론과 주요차이점: Pair Programming, TDD

     

    - Pair Programming

      한사람은 코딩을하고 한사람은 생각, 바로 옆에 앉아서 같은 화면을 바라보는 형태

     "페어 프로그래밍은 소프트웨어 개발 일정에 영향을 주지 않음녀서 소프트웨어의 질을 향상

     시킨다. 이것은 직관적인 느낌에 반한다. 하지만 두 사람이 하나의 컴퓨터에서 일하는 것은 

     그것이 훨씬 더 높은 질의 소프트웨어를 생산하다는 사실을 제외하면 그들이 각자의 컴퓨터에

     서 일하는 경우와 (시간이라는 면에서) 다를 것이 없다. 이와 같은 품질의 향상은 프로젝트의

     후반부에 접어들수록 비용을 크게 절약해 준다"

     " 페어 프로그래밍을 하는 최선의 방법은 두 사람이 하나의 모니터 앞에 나란히 앉는 것이다.

       두 사람이 키보드와 마우스를 옆 사람에게 순서에 따라 넘겨준다. 한 사람이 코딩을 하면서

       현재 개발하고 있는 메소드에 대한 전술적인 사색을 한다. 한편 옆에서 앉아 있는 사람은

       그 메소드가 전체 클래스에서 어떤 위치를 점하는지 등을 전략적인 관점에서 고민한다.

       페어 프로그래밍에 익숙해지려면 시간이 좀 걸리므로, 처음에는 그것이 이상하게 느껴지

      더라도 걱정하지 않기 바란다"

     > 저자는 code review의 경험

         한 명이 개발한 내용은 반드시 검토자를 지정(해당 Task에 명시)하여 code review 실시

         문제 발생시 공동의 책임을 묻게 함

          즉, code review를 하는동안 해당 과정이 형식적이지 않은 매우 진지한 일부가 됨

          코드의 소유권을 희석시켜주며, 버그의 수정도 빠름


   - TDD

      "테스트를 실제 코드보다 먼저 작성해보면, 원하는 코드를 훨씬 더 빨리 작성할 수 있게된다

      는 사실을 깨닫게 될 것이다. 유닛 테스트와 그 유닛 테스트가 적용될 코드를 작성하는데 

      걸리는 시간은  유닛 테스트를 생략한 채 본래 코드만 작성하는 시간과 별로 차이가 없다. 

      만약 유닛 테스트가 이미 존재하는 경우에는 시간을 더 절약할 수도 있다"

      

    - 소프트웨어 공학

      프로그래밍을 절묘한 알고리즘을 고안해내는 창조적인 활동으로 국한시키는 것은 

      초보자가 저지르는 잘못임, 마치 축구를 '골'을 넣는 행위로 국한시키는 것과 같음

      축구란 골을 넣는 골잡이 외에 수비수, 미드필더, 골키퍼 등의 역할도 중요함

      무엇보다 실력과 카리스마를 갖춘 감독의 역할도 중요

      소프트웨어 공학의 핵심은 프로젝트의 성공을 위해서 사람들 사이에 의사소통이

      알맞게 형성되도록 만드는데 있다.


      정답은 없다. 어느 곳에서 'XP'가 최선이면 다른 곳에서는 '폭포수모델'이 최선일 수도 있다.

      어느곳에서는 그 둘을 합친 것이 효율적인 모델이 될 수도 있다.

      무수한 선택의 골짜기에서 바른 판단을 내리고, 의사소통이라는 강물을 트는 것이

      소프트웨어 공학이다.



5. XML

   - 경험담: 데이터 포맷을 XML로 변경할 때 데이터 처리속도에 대한 문의

    >  "별로 없다" 라는 답변: 

        하지만, 해당 데이터의 용량이 커질 수록 영향력이 커졌음

        "별로없다"와 "없다"는 같은 의미가 아니였음

        개발을 책임지는 사람이 다른 사람의 '조언'을 무비판적으로 수용하지 말아야 함

        유행어(Buzzword) 에 현혹되지 않는 냉철한 균형감각의 중요성을 깨달았음


  

Ten steps to a good research paper (How to study 사이트의 내용)

논문작성의 팁 (How to study의 내용에서... )


[Ten steps to a good research paper]

To write a good research paper, you must be specific about your topic,

know what you want to say, and say it effectively.

Following these ten steps will help you write a good research paper.



1. choose your topic

 When choosing a topic, choose one in which you are interested, and for which

 which there is enough information.

 If your topic is too broad, you will have difficulty completing your paper.

 "The Effects of Pollution" is too broad because there are so many effects of

 pollution. "The Effects of Pollution on Geese in the Northeast Section of Duluth,

 Minnesota" is too narrow. You are not likely to find much information that 

 is ths specific. "The Effects of Pollution in Yosemite National Park" is just

 about right as a topic.


2. locate information


3. prepare biblography cards


4. prepare note cards


5. prepare an outline


6. write a rought draft


7. revise your rough draft


8. prepare your biblography


9. prepare a title page and table of contents


10. final checklist.

    before handing in your paper, be sure you can answer "Yes" to each of the following questions

    - did i include a title page?

    - did i include a table of contents?

    - did i number all pages correctly?

    - did i provide footnotes for quatations and major sources of information?

    - did i include a biblography?

    - did i keep a second copy for my files?

    

    

    

졸업논문을 준비하면서...

졸업논문을 준비하면서 흥미로운 알고리즘을 알게되었다.

유전알고리즘





'천재와 싸워 이기는 방법' 이라는 만화가 이현세 선생님의 글

'천재와 싸워 이기는 방법' 이라는 만화가 이현세 선생님의 글




살다 보면 꼭 한번은
재수가 좋든지 나쁘든지
천재를 만나게 된다.


대다수 우리들은 이 천재와 경쟁하다가
상처투성이가 되든지, 아니면 자신의 길을 포기하게 된다.


그리고 평생 주눅 들어 살든지,
아니면 자신의 취미나 재능과는 상관없는
직업을 가지고 평생 못 가본 길에 대해서
동경하며 산다.


이처럼 자신의 분야에서 추월할 수 없는
천재를 만난다는 것은 끔찍하고 잔인한 일이다.



어릴 때 동네에서 그림에 대한 신동이 되고,
학교에서 만화에 대한 재능을 인정받아
만화계에 입문해서 동료들을 만났을 때,
내 재능은 도토리 키 재기라는 것을 알았다.


그러나 그 중에 한두 명의 천재를 만났다.
나는 불면증에 시달릴 정도로
매일매일 날밤을 새우다시피 그림을 그리며 살았다.


내 작업실은 이층 다락방이었고
매일 두부장수 아저씨의 종소리가 들리면
남들이 잠자는 시간만큼 나는 더 살았다는 만족감으로
그제서야 쌓인 원고지를 안고 잠들곤 했다.


그러나 그 친구는 한달 내내 술만 마시고 있다가도
며칠 휘갈겨서 가져오는 원고로
내 원고를 휴지로 만들어 버렸다.


나는 타고난 재능에 대해 원망도 해보고
이를 악물고 그 친구와 경쟁도 해 봤지만
시간이 갈수록 내 상처만 커져갔다. 


만화에 대한 흥미가 없어지고
작가가 된다는 생각은 점점 멀어졌다. 
 

내게도 주눅이 들고 상처 입은 마음으로
현실과 타협해서 사회로 나가야 될 시간이 왔다.

그러나 나는 만화에 미쳐 있었다. 


새 학기가 열리면 이 천재들과 싸워서 이기는 방법을
학생들에게 꼭 강의한다.


그것은 천재들과 절대로
정면승부를 하지 말라는 것이다. 


천재를 만나면 먼저 보내주는 것이 상책이다. 
 

그러면 상처 입을 필요가 없다.  


작가의 길은 장거리 마라톤이지
단거리 승부가 아니다.
천재들은 항상 먼저 가기 마련이고,
먼저 가서 뒤돌아보면 세상살이가 시시한 법이고,
그리고 어느 날 신의 벽을 만나 버린다.


인간이 절대로 넘을 수 없는 신의 벽을 만나면
천재는 좌절하고 방황하고 스스로를 파괴한다.
그리고 종내는 할 일을 잃고 멈춰서 버린다.



이처럼 천재를 먼저 보내놓고
10년이든 20년이든 자신이 할 수 있다는 생각으로
하루하루를 꾸준히 걷다 보면
어느 날 멈춰버린 그 천재를 추월해서
지나가는 자신을 보게 된다. 
 

산다는 것은 긴긴 세월에 걸쳐 하는
장거리 승부이지 절대로 단거리 승부가 아니다.  



만화를 지망하는 학생들은 그림을 잘 그리고 싶어한다.

그렇다면 매일매일 스케치북을 들고
10장의 크로키를 하면 된다.

1년이면 3500장을 그리게 되고
10년이면 3만 5000장의 포즈를 잡게 된다.
그 속에는 온갖 인간의 자세와 패션과 풍경이 있다.


한마디로 이 세상에서 그려보지 않은 것은
거의 없는 것이다.

거기에다 좋은 글도 쓰고 싶다면,
매일매일 일기를 쓰고 메모를 하면 된다.
가장 정직하게 내면 세계를 파고 들어가는
설득력과 온갖 상상의 아이디어와 줄거리를 갖게 된다. 


자신만이 경험한 가장 진솔한 이야기는
모두에게 감동을 준다.


만화가 이두호 선생은 항상
“만화는 엉덩이로 그린다.”라고
후배들에게 조언한다.
이 말은 언제나 내게 감동을 준다.
평생을 작가로서 생활하려면
지치지 않는 집중력과 지구력보다 더 중요한 것은 없다.


가끔 지구력 있는 천재도 있다.
그런 천재는 존재하는 것만으로도 축복이고
보는 것만으로도 감사하다.

그런 천재들은 너무나 많은 즐거움과
혜택을 우리에게 주고 우리들의 갈 길을 제시해 준다.
나는 그런 천재들과 동시대를 산다는 것만 해도
가슴 벅차게 행복하다. 


나 같은 사람은 그저
잠들기 전에 한 장의 그림만 더 그리면 된다. 
 

해 지기 전에 딱 한 걸음만 더 걷다보면
어느 날 내 자신이 바라던 모습과 만나게 될 것이다.


그것이 정상이든, 산중턱이든
내가 원하는 것은 내가 바라던 만큼만 있으면 되는 것이다

2013년 JCO 컨퍼런스


2013년 JCO 컨퍼런스가 2/23에 있습니다. 매년 참석하는 컨퍼런스인데 전체적인 트렌드를 파악하기에 도움이 많이 됩니다. 올해도 기대가 많이 됩니다.


http://jcoorkr.tistory.com/32


"나는 홍보왕 이벤트"에 참여하신 두 분을 추첨하여 행사 당일 경품 추첨때 
리얼포스 키보드와 삼성 SSD를 드립니다.

아래 URL을 클릭하여 JCO 블로그에 게재된 내용을 자신의 블로그에 홍보하고 여기(JCO blog)에 댓글 or 
JCO Conference 페이지 (https://www.facebook.com/jcoconf) 을 달면 끝입니다.

참가해 주신 분들중 두분을 선정하겠습니다.
컨퍼러스에 대한 많은 관심과 참여부탁드립니다. 감사합니다.


TED영상

스타트업 CEO에게 추천하는 TED 강연 Top10


http://platum.kr/archives/5999


내가 생각하는 좋은 커피숍의 조건은...

요즘 워낙 커피숍이 많이 생겨나서 어딜가나 커피숍이 넘쳐나는 것 같다.

커피숍이 단순히 커피를 마시는 곳이 아니라 대화를 나누기 편하고 뭔가 공부를 하기에도 적당한 곳이다.


일단 나는 무선인터넷을 제공해야 한다. 컴퓨터와 아이패드를 사용해야 하므로....

의자가 편안한 의자에 테이블간의 간격이 최소 테이블 하나가 들어갈 간격이 되어야 한다.

(너무 가까우면 옆테이블의 모르는 사람의 사생활을 너무 깊이 알게되서....)

바깥풍경이 잘 보이면 좋다. 물론 바깥풍경이 너무 삭막한 곳이면 그다지 좋지 않을 수 있지만....

음악은 너무 시끄럽지 않은.... 가급적 한국말이 아닌 가사가 나오는 음악으로... 

가사를 너무 잘 알아들으면 나도모르게 가사를 따라하고 있어서 집중도가 많이 떨어진다.... 영어를 잘하지는 않아서 영어가사는 그렇지 않다. ㅠㅠ

가격은 4000원을 넘지 않는정도.....


그러고보니 생각보다 커피맛은 높은 비율로 평가하지는 않고 있다. 어느정도 상향평준화가 되어 있어서인지 아주 저렴한 길거리 커피가 아닌경우를 제외하면 그 차이 때문에 카페를 선택하지는 않는다.


소프트웨어에도 그런 선택의 기준들이 있을텐데... 



'이런저런 얘기들...' 카테고리의 다른 글

2013년 JCO 컨퍼런스  (0) 2013.01.26
TED영상  (0) 2013.01.23
내가 생각하는 좋은 커피숍의 조건은...  (0) 2012.07.15
1년 뒤에는....  (0) 2012.07.15
문제해결을 위한 방안  (0) 2012.06.18
매트릭스  (0) 2012.06.16