원두를 갈아서 내리는 것을 좋아해서 캡슐 커피는 자주 이용하는 편이 아닌데,
새로 옮긴 사무실에 있길래 몇번 내려 먹어봤다.
일단 맛 굿, 그 간편함도 굿굿.

어떤 원리로 동작하는 걸까.. 캡슐을 뜯어봤다.  직업병이지 이것도..

뚜껑 비닐을 뜯으면 이렇게 안에 투명한 비닐이 또 있다.



자세히 보면 이 비닐에 구멍이 뚫려있다. 이 구멍을 통해서 고압의 물이 가해지게 된다. 

    



비닐을 뜯어내고 원두 찌꺼기를 걷어내면...



이렇게 거름망이 나온다.  재질은 두꺼운 은박지 같음.



그 밑에 플라스틱이 또 있다. 

  

  




편리하기는 한데,
비닐과 플라스틱에 고온 고압의 물을 통과시키는 것이 별 문제 없을지 걱정된다.
환경 호르몬 같은거.

그리고 편리함을 위해서 또 이만큼의 쓰레기를 만들어내는 것도 아닌것 같고..

내부 구조를 보니 단가가 비쌀수 밖에 없을 것 같다.

결론은:  
  • 대단한 발명
  • 환경호르몬 걱정
  • 쓰레기 증가 걱정
  • 맛은 훌륭


'일상' 카테고리의 다른 글

커피.  (0) 2013.08.28
기분 나빴던 일들의 기억  (0) 2013.08.27
더위가 가시려나  (0) 2013.08.23
다섯번째, 그리고 여섯번째 조깅  (0) 2011.04.28
몸싸움  (0) 2011.04.24
무더운 여름이 온다.
에어컨을 어떻게 운영하면 전기료를 아낄 수 있을까?
떠도는 소문에 의하면 실외기가 안돌더라도 에어컨이 먹는 전기는 똑같다라는 말도 안되는 얘기가 있길래  
에어컨 소비 전력을 측정해봤다.

에어컨 스펙은
  • LG 휘센 거실 스탠드형 LPNC122S (20평형 이었던 것 같음)
  • 냉방능력 4700W
  • 냉방 소비전력 1480W

측정 장치
  • Korins 측정기 
  • 코인 배터리를 넣어야 하기 때문에 불편하지만 측정하는데는 문제 없음.

      



에어컨을 켠 상태에서 측정결과
  • 실외기가 돌지 않을때는 76W
  • 실외기가 돌때는 1426~1600W 소비
  • 제습 기능 중일때는 측정하지 않음.  아마 동일하지 않을까..


결론은
  • 전기료를 아끼려면, 목표 실내온도를 25도나 26도 정도로 설정해서 실외기가 도는 시간을 최대한 줄여야 한다.



한달 전기료 계산 예:
  • 전기료 계산은 곱셈과 덧셈이다.  어렵지 않아요 
  • 조건이 다음과 같다면 
    • 목표 실내온도 27도 
    • 실외기 도는 비율이 1시간에 10분 정도 (1/6) 라고 하고, 
    • 하루 10시간 켜둔다고 하면
  • 한달간 에어컨이 소비한 전력 = 1500W * 10시간 / 6 * 30일 = 75000Wh = 75kWh
  • 원래 한달 전기 사용량이 240kWh 였다고 하면 31570 원 냈던 것을
  • 에어컨 때문에 사용량이  315kWh 가 되었으므로 47590 원을 내게 된다. (아래 한전 계산표 참조)


240kWh일때의 전기요금 



315kWh일때의 전기요금 



전기 요금표 - 개편후 만 보면 된다. 



끝.


Effective Programming



2018.6.21~25, 정독도서관에서 읽다.
프로그래머로서 다음단계로 어떻게 하면 진화할수 있을 것인가에 대해서 고민하고 있다.
이번 독서로 얻은 것은, 글쓰기, 블로그를 시작해야 겠다고 마음먹은 것이다. 



01. 들어가며
  • 누구나 코딩을 할줄 알아야 한다는 말은 누구나 브리태니커 백과사전을 처음부터 끝까지 읽어야 한다는 말과 같다
  • 프로그래밍은 열정에 대한 것이다.
  • 진정한 프로그래머는 코딩을 사랑하는 사람을 대번에 알아본다.
  • 프로그래머의 여덟단계
    1. 죽은 프로그래머: 작성한 코드가 끝까지 살아 남음
    2. 성공적인 프로그래머: 널리 알려져 있음
    3. 유명한 프로그래머: 자신의 분야에서 긍정적인 영향을 미치고 있음
    4. 일하는 프로그래머: 성공적인 경력, 쉬운 취업
    5. 평균적인..
    6. 아마추어
    7. 알려지지 않은: 그저 직업일 뿐
    8. 나쁜: 능력이 없는 상태에서 프로그래밍 수행 
  • 위대한 프로그래머는 다른 사람을 설득함으로써 영향력을 확대한다.
    명확한 설명, 기술적인 스펙으로 자신의 코드를 잘 이해하게 만들고, 새로운 코드를 작성하는 대신
    자신의 코드를 사용할 수 있게 만든다.
  • 글을 쓰는 것은 운동과 같다. 자꾸 써봐야 한다.  블로그를 시작하라.
  • 존스키트: 글을 명확하게 하는 것은 자신의 내면적 사고의 흐름을 명확하게 하는 데 도움을 준다.
       

      



02.엉터리 같은 일을 마무리 하는 기술
  • 다니엘핑크 Daniel Pink:
    • 인센티브는 반복적이고 기계적인 일을 할때 성과가 있다.
    • 창의적 일의 경우 내적동기가 중요하다.
  • 톱날갈기:
    • 변명: "하지만 저는 톱날을 갈고 있을만큼 한가하지가 않아서요" 
    • 프로그래밍 블로그 읽기
  • 저 길로 가라, 총알 처럼
    • 보이드: 어지러운 전투에서 승리하려면 - 관찰하고, 방향을 잡고, 계획을 세우고, 더 빠르게 움직이는 것. 
  • 멀티태스킹
    • 프로그래머는 업무를 전환할때 드는 비용이 크다. 
    • 이메일이나 메신저 조차도 방해가 된다.

03.좋은 프로그래밍의 원리
  • 첫번째 원리: 그것은 언제나 당신의 잘못이다.
  • 자신의 코드에 대해 책을 져라.  일단 자신이 작성한 코드에서 시작하고, 결정적인 증거가 나타날때 까지
    점점 더 바깥쪽을 향해 나아가야 한다.
  • 코드의 작성은 간결함에 가치를 둬야 한다.
  • 주석 없이 코딩하기: 코드 자체로 이해하기 쉽도록 리팩토링 한다. 주석을 달때는 신중하게.
  • 숙련된 개발자라면 문서보다 소스코드를 읽는 편이 더 빠를때가 많다. 다른 사람이 작성한 코드를 읽는데 익숙해져야 한다.
  • 고무오리 문제 해결법: 
    • 질문을 던지기 시작하는 것은 실제로 자신의 문제를 스스로 디버깅 하는데 도움을 준다.
    • 자신의 문제를 자세하게 설명하는 과정은 새로운 통찰과 발견으로 안내해줄 것이다.
  • 성공은 아이디어가 아니라 실행의 질에 의해 결정된다.  좋은 팀은 프로젝트 성공의 기본 요소다. 
  • 왜 코딩을 하는지 설명할 수 있어야 한다. 낯선 사람에게 라도. 
    • 지금 무슨 일을 하고 있는가? 왜 하나? 왜 버그인가? ...
    • 소프트웨어 개발자가 하는 일은 코딩이 아니다.  고객의 문제를 해결하는 것이다.
    • 프로젝트의 비젼이 명확해야 한다.
  • 성능/속도는 기능이다: 
    • 웹사이트 상단에 렌더링 속도 표시
    • 웹사이트는 두가지: 빠른 웹사이트 또는 죽은 웹사이트

04.프로그래머를 제대로 채용하는 법
  • 코딩을 제대로 하지 못하는 사람은 작은 문제조차 해결하지 못한다
  • 피즈버즈 FizzBuzz 질문: 코딩 못하는 사람 걸러내기
    • 1 - 100 출력, 3의 배수에서는 Fizz를, 5의 배수에서는 Buzz를, 3||5 배수에서는 FizzBuzz를 출력
  • 채용 방법
    1. 헬로 월드 온라인 테스트, 온라인 코딩 검증 서비스(interview Zen, Codility) https://www.interviewzen.com/
    2. 포트폴리오 살펴보기: 오픈소스, 블로그, 텀블러..
    3. 문화적으로 어울리는 사람 고용하기
    4. 전화 인터뷰
    5. 오디션 프로젝트: 짧고 분리된 일감 시켜보기
    6. 인터뷰
  • 몇년을 경험했는가 라는 질문에 담긴 미신
    • 특정 언어에 상관없이 제대로 된 코드를 작성할 수 있는 능력을 갖춘 열정적이고, 근면하고, 유연하고,
      스스로 배워나가는 사람을 채용해야 한다.
  • 자신의 전문분야를 20분간 프리젠테이션 하도록 한다
    • 이 사람은 자신의 일에 열정을 가지고 있는가?
    • 소규모 그룹에서 효율적인 의사소통을 할 수 있는가?
    • 자신의 전문 분야에 대해서 잘 알고 있는가?
    • 당신의 팀원들은 이 사람과 즐거운 마음으로 일할 수 있는가?

05.팀이 함께 일하도록 만들기
  • 결국 사람과 관련된 문제다
    • 함께 일하는 사람들이야말로 직업 만족도에 정확한 척도다.
  • 썪은 사과를 다루는 방법: 제거하는 것을 두려워 하지 말아야 한다. 
  • 썪은 사과 징후
    • 동료로 부터 배우기 보다 자신의 무지를 감추기 위해 노력한다.
    • 프라이버시에 집착한다.
    • 팀에서 내린 결정에 대해서 투덜거리고, 낡은 논의를 다시 꺼낸다.
    • 팀원들이 동일한 한 사람에 대해 불만을 토로한다.
    • 팀 활동에 참여하지 않는다. (프로젝트 마감 등)
  • 원격근무 규칙
    • 코딩 하는 사람 두명 이상
    • 베테랑 프로그래머 이어야 함. 초보자 안됨
    • 자율적으로 일해야 하고, 강력한 비젼이 있는 리더가 있어야 함

6부.프로그래머를 위한 효율적인 작업 공간
  • 권리장전
    • 두대의 모니터
    • 빠른 PC
    • 마우스 키보드 선택
    • 편안한 의자
    • 인터넷 연결
    • 조용한 작업 환경
  • 배경조명
    • 천정등은 모니터에 반사된다, 배경 조명 이용

7부.사용자를 염두해 두고 설계하기
  • 당신의 소프트웨어와 프로젝트는 결국 작은 디테일의 모음이다. 
  • 디테일을 무시한다면, 그 제품은 사용자를 짜증나게 할 것이다.
  • 처음에는 누구나 디테일을 제대로 구현하지 못한다.
    • 사용자 피드백을 받고 바로 바로 개선
  • 사용자 입장에서는 UI가 어플리케이션 자체이다. 우선순위를 둬야 한다.
  • UI를 우선시 하는 소프트웨어 개발: 종이 프로토타이핑, PPT 프로토타이핑
  • 사용자의 좁은 시야 다루기: 필요한 내용은 바로 코 앞에 둬야 한다.
  • 피츠의 법칙 Fitts’ Law: 
    • 시간 = a + b log2(D/S +1)
    • D:커서와 목표물 거리, S: 목표물 넓이 
    • 맥 메뉴의 경우에는 S가 거의 무한대이다.  더 빠름
    • 화면 구석의 활용 권장
  • 버젼 1은 엉망이지만 어쨌든 출시하라: 실제 사용자의 피드백을 받고 빠르게 대응한다.

8부.사용자의 데이터를 보호하라
  • https 를 사용하라: 하드웨어의 발전으로 더 빨라졌다
  • 사전공격에 대비: 로그인 실패시 지연 시간 추가
  • 인터넷 운전면허: 구글이나 페이스북을 통한 로그인 
      


      




9부. 코드를 테스트해서 그것이 필요이상으로 엉망이 되지 않게 만들기 
  • 고객의 고통을 공유하기: Dogfood 
  • 무질서한 원숭이와 함께 일하기: 진짜 실패를 피하는 방법: 지속적으로 작은 실패를 거듭하는 것. 
  • 코드리뷰: 그냥 하라: 테스트 만으로는 모든 오류를 잡아낼 수 없다. 
  • 무식한 방식의 테스트: 한두개의 테스트 케이스 만으 로는  충분하지 않다. 
  • Unit Test: 디버깅을 위한 출력문에 뭔가를 집어 넣는 대신 테스트를 작성하라. 
  • Unit Test 보다는 베타 테스트가 낫다.  별 상관없는 버그를 잡을 필요는 없다.
  • 사용성 테스트: 복잡할 필요 없음. 사람 많을 필요 없음. 
  • 실패를 즉각적으로 가시화 하라
    • 문제를 안전하게 해결할 수 있으면 그렇게 하고
    • 그럴수 없다면 사용자의 데이터를 보호하는 것을 최우선으로 하라.

10부. 커뮤니티로 부터 이익 얻기 
  • 커뮤니티 의견 듣기
    • 90퍼센트는 쓰레기
    • 차에 트럭 짐칸을 달아달라는 의견 무시하기
    • 하지 않을 일에 대해서 솔직하게 말하라
    • 의견을 곧이 곧대로 반영하면 안됨
    • 의견을 경청하고 필요한 응답을 내놓아라
  • 사용자의 말만 듣지 말고, 사용자의 행동 데이터를 의미있는 방식으로 수집하라.
  • 게임화: 문제를 해결하고 청중들에게 의욕을 불어넣기 위해 게임 디자인 기법과 메커니즘을 활용하는 것임

11장, 12장은 딱히 와닿는 내용이 없어서 생략.


 



To do:
  • 영상보기: 에드 캐트뮬, 위기를 조그맣게 만들어라
  • 영상보기: 파워포인트 2007을 이용한 와이어프레임 프로토타이핑 Manuel Clement)


+ Recent posts