2009년 5월 31일 일요일

티라미수

티라미수 by Grace

티라미수 by Grace

티라미수 by Grace

티라미수 by Grace

티라미수가 갑자기 먹고 싶었다. ㅎㅎ;

그래서 만들게 되었징;;ㅋ

코코아 가루 뿌리기 전에, 슈가파우더를 뿌렸더니 흰색이 살짝 보이네;; ㅋ

음~~~~~ 듬뿍 떠진 치즈무스... ㅠㅠ;;; 맛났었다. ㅎㅎㅎ

새로 알게된 레시피를 이용해서 스폰지케익을 구웠는데 버터가 안들어가다보니, 좀 퍽퍽하기도 하다;; ㅋ

담엔 더 잘해서 좀더 맛있는 티라미수를 만들어야지..ㅎ

이건 선물용..ㅎㅎ

잘 갖구 가라고 미니컵에다가 포장을 했다. ㅎ

맛난 티라미스.. i love it. ㅋㅋ

2009년 5월 30일 토요일

우리집 만두

 

강남역 7번출구에서 대략 500미터 쯤 가면 있나..?

한국자산관리공사와 우리은행 사이 골목으로 들어가다 보면 왼쪽에 있는..

우리집 만두..

 

인테리어나. 위생상태, 서비스는.. 2% 부족한데;

맛은 참 좋더라구요..ㅎㅎ;;;;;

 

김치만두전골 2인분 18,000원

반공기 밥과 채소반찬과 함께 나온다. 만두 6개, 라면사리 1개, 버섯,김치, 등등이 들어간 전골이다.

 

처음엔 썩 그리 맛이없을 줄 알았는데;; 먹다보니..ㅋㅋㅋ 맛나더군요 ㅎㅎㅎ

 

s1000fd 무보정

2009년 5월 29일 금요일

차승원

요새 시티홀의 차승원씨..

완전.. 멋지게 나온다.

전에는 잘 몰랐는데..

왜 이 분은... 나이가 먹을수록.. 멋있지..?? ㅎㅎ;;;

40이라는데.. 40!!!! 사아십..!!;;

근데 이렇게 멋지면;; 어떡하노;;;ㅋㅋㅋㅋ

연기도 잘 하시고..ㅋㅋ

 

캡쳐한 사진인데.. 이상하게.. 조인성이랑 비슷한 느낌이나네..

근데 조인성씨보단.. 차승원씨가..좀더..중후한 멋까지 나는듯..ㅎㅎㅎ

 

하이튼...ㅋㅋ 씨티홀, 차승원씨. 대박..ㅋㅋ;;;;

2009년 5월 28일 목요일

치즈머핀

치즈머핀 by Grace


<치즈머핀>

필라델피아 크림치즈를 넣어서 만드는 건데요..

음..치즈 맛이.. 아주 살면서;;; ㅋㅋ 올라와서..좋아요.^-^

냉장고에 크림치즈 한개가 있는데 이걸로 뭘 할찌 아직 고민중이예요..ㅋㅋㅋ

이것의 레시피도 집에가서 올릴게요 ㅎㅎㅎ;;

 

s1000fd 무보정

2009년 5월 26일 화요일

고구마 팥 양갱

양갱 by Grace

양갱 by Grace

작년 추석 때, june이 시골에 갈 때 였지요..

시골 어머니께.. 선물로 양갱을 만들어서 드렸습니다.

까서 드시기 편하시라고 조그맣게 썰어서, 랩으로 감싸서, 예쁜 상자에 담아서 보내드렸는데..맛나게 드셨다고 ㅎㅎ 했지요..ㅋ

 

애기들도, 어른들도 먹기 딱 좋은 양갱..ㅎ

파는 것은.. 좀.. 깨림칙하자나요..

 

시골에서 농사지은 팥으로다가. 만든거라서, 더욱 맛나더라구요..

팥앙금을 만드는게 쉽지는 않더라구요 ㅎㅎ;;

 

s1000fd 무보정

홈메이드 와플

와플 by Grace

와플틀을 예전에 선물로 받았다. ㅎ

와플을 집에서 해먹고 싶다고 했더니 사주더군..ㅎ

와플틀을 사면 거기에 레시피도 써있다. ㅎㅎㅎ

와플 믹서를 사서 해도 되긴 하더라구요.. ㅎ

 

음.. 해먹어본 결과.. 맛있었습니다.

 

아 전.. 11번가에서 17,xxx 이던가. 2만원 근처가격으로 샀던거 같아요..

쉽고 간단하게 집에서 와플을 즐길 수 있습니다. ㅎ

길거리에서 파는 와플하고는 격이 다릅니다. ㅎ

 

생크림 휘핑해서 아슈크림 얹어서 먹으면 카페 부럽지 않습니다. ㅎㅎ

 

s1000fd 무보정

씨티홀

요새 아주 재미나게 보는 드라마 중 하나.ㅋㅋ

이런 날 보고 june 이 그런다. ㅋㅋ

 

"아주 드라마를 죄다 보는군"ㅋㅋ 라이브로 보는 것은 몇개 안된다.

거의 다운해서 보는 듯..^^;;

 

조국(차승원 분)이 신미래(김선아 분)에게, 여행을 가자고 권한다.

여차저차 하여 가서 잘 보내고,

잠자리에서, 미래가 초긴장해서 누워있는 뒷모습을 보더니..

조국은 눈뜨고서는 코고는 소리를 낸다..

나도 진짜로 '아.. 눈뜨고 자는 구나.' 했다.

알고보니.. 미래를 안심시키려고 했더군.. ㅋㅋ

안심하며 잠에 드는 미래를 보면서, 참.. 의미심장하게 달콤한 미소를 날리는 조국..

결국, 시장출마를 해보라는 조국의 말에.

일부러 이말하려고.. 여행가자고 했죠.? 라며 따지는.. 신미래에게..

조국이 이렇게 말을 했다. 정확한게 대사는 기억나지 않지만..

 

"감당할 수 있겠어요?

그말(시장출마 권유)하려고 여행가자고 한거 아니예요.

실은, 같이 여행가고 싶어서, 그 핑계 댄거예요."

 

라고 하더군.. 순간.. 짠~했다. ㅎㅎ

차간지라고 별명이 붙을 만하네..ㅎㅎ그래서 요새..차승원 칭찬하는 중..ㅋㅋ

멋있는데 연기도 잘한다구..ㅋㅋ 애기 2딸린 유부남 같이 않다고 ㅎㅎ

 

역시.. 솔직한 고백은... 무엇보다.. 최고의 선물인거 같다.^-^

애플 시나몬 크럼블 케이크

애플시나몬 크럼블 케이크 by Grace

사과와, 계피가루, 소보로가 들어간 케이크 입니다.

저도 처음 만들었는데..

약간 저에게 맞게금 수정해서 레시피를 올려야겠어요 ㅎ

그래서 우선 오늘은 레시피 없이 올려요.

 

애플파이는 파이지가 좀 바삭(굽기 차이에 따라 안그럴수도)거리는 방면, 이건, 케이크라서, 부드럽고, 사과가 씹히고, 소보로가 씹혀서 좋더라구요 ㅎ

 

급하게 june에게 주느라고 찍지도 못하고, 남은거 포장할 때나 찍게 되었습니다. ㅎㅎ

 

s1000fd 무보정

2009년 5월 22일 금요일

딸기 무스 케익

재료 :

스폰지 케익 시트 1장,

무스( 우유 220 그램, 노른자 3개, 설탕 51그램, 박력분 24그램, 생크림1 315그램, 젤라틴 4그램, 바닐라 오일 1~2방울), 필링(생크림 150그램, 데코할 딸기), 시럽(1/2Ts, 슈가파우더 25그램), 데코스노우

원형 2호 링틀, 투명무스띠

 

준비작업

1. 시트가 없다면 스폰지 케익을 미리 만들어서 1장만 준비해둡니다.

2. 딸기를 흐르는 물에 충분히 씻은 후, 꼭지를 떼고(씻을 때 꼭지를 떼면 비타민이 녹습니다. 딸기는, 딸기 꼭지가 위로 확 젖혀진게 잘 익은거랍니다 ^^ ) 물기를 뺀 후, 남은 물기를 키친 타올로 닦아줍니다.

그리고, 무스링에서 보이는 면에 닿게 할 딸기를 반으로 쪼개 놓고, 위에 데코할 딸기도 준비해놓고, 나머지는 적당히 잘라둡니다.

3. 생크림1을 미리 60%정도 휘핑해 둡니다.

4. 투명 무스띠는 미리 펴둡니다.(보통 돌돌 말아있자나요)

 

무스 만들기

1. 우유를 바글바글 끓입니다.

2. 노른자, 설탕, 전분을 거품기로 섞은 뒤, 끓인 우유를 넣어가며(2회에 걸쳐) 섞습니다.

3. 2를 불에 올려 밑이 눌러붙지 않게 저어줍니다. (반죽이 물에 섞은 반죽같던 것이, 이젠 죽과 같이 반죽이 익은 느낌이 나더군요..그때까지 바닥이 타지 않게금 저어주며 저어줍니다. 약~중불 정도에서)

4. 불린젤라틴(가루 젤라틴일 경우, 물10그램을 섞어 전자렌지로 미리 녹여줍니다)을 전자렌지에 녹여 위의 반죽에 넣고 섞은 뒤, 생크림1을 넣고 섞어요.

5. 바닐라 오일을 1,2방울만 넣어요.

 

필링 만들기

1. 링틀(안쪽면에 투명무스띠를 덧대서 입혀놓습니다) 에 스폰지를 깔고, 시럽을 발라둡니다.(전 레몬시럽을 주로 쓰는데요 새콤달콤 맛나대요 ㅎ)

2. 딸기의 잘린 단면이 틀벽에 닿게 배열합니다.

3. 무스를 틀의 절반정도 붓고, 딸기를 넣고 채웁니다.

4. 무스틀까지 무스를 넣고 채운 뒤, 스패츌려로 깍아 평평하게 합니다. 그런 후, 냉장실에서 2시간 정도 굳힙니다.

5. 그 후, 생크림2를 휘팽해서 짤주머니를 이용해서 원하는 모양으로 데코해주고, 딸기로 데코해줍니다.

6. 마지막으로 데코스노우 적당량을 체를 이용해서 뿌려줍니다.

 

s1000fd 무보정

오삼덮밥

오삼덮밥 by Grace

오삼덮밥.(샷이 좀 어둡게 찍혔네요;;)

 

오징어와 삼겹살 덮밥.. 굳이 삼겹살 아니여도 될 거 같아요

 

돼지고기의 어느 부위를 해도 상관없을 거 같아요 ㅎ

 

어느 날 저녁으로 먹은, 처음 해본 ㅎㅎㅎ 그렇다고 레시피를 펴놓고 한거 아니구요 ㅎ

 

그냥 감으로다가.ㅎㅎㅎㅎ;;; 해봤는데 맛나다고 하네요 ㅎ

 

재료 : 오징어 1/2마리, 돼지고기 200그램 정도, 양파 1개, 파, 마늘, 고추장, 요리당(없으면 그냥 설탕), 고추장, 깨, 갖은 야채, 식용유 살짝, 간장 조금, 청주(혹은 럼주) 1큰술

 

돼지고기와 오징어를 식용유 살짝 부린 후 볶다가, 양념을 넣고 볶다가, 청주를 넣어요(비린내 제거용). 그러다가, 야채를 넣고 볶았습니다..ㅎ

 

근데 전,, 양념을요..

미리 만들어놓은 소스를 이용했어요 ㅎ

 

각종 과일 고추장 및 등등을 넣고 고추장 소스를 만들어 두었는데요

그것으로 두루두루 쓰게 되더라고요.

찌개나 , 볶음이나 등등..ㅎㅎ 저것도 그랬어요.

그래서 딱히 재료에 더 적을게 없네요^^;;

소스를 미리 만들어두면, 화학조미료 없이 맛을 내게 되서 좋더라고요.

아직 소스의 황금비율을 찾지 못해 알려드릴순 없네요 ㅠㅠ;;;

 

s1000fd 무보정

계란찜

계란찜 by Grace

계란찜, 어려운줄 알았다. ㅎㅎㅎ

그런데 언니한테 배운 후로 아주 쉽게 한다. ㅎ

 

계란 1개랑, 물1/2컵 정도 넣고, 보통 계란 후라이 해먹을 때 만큼의 소금보다 조금 더 넣으면 된다.

그리고는 충분히 풀어줍니다.

충분히 풀으실 수록, 숨구멍도 없이 밀도가 높은 계란찜이 된답니다. ㅎ

전 그냥 대충 휘휘젓어서 저래요 ㅎㅎㅎ;;

혹 원하는 야채가 있다면..? 송송 썰어서 넣으면 된다. ㅎㅎ

 

그리고는 제일 약불에 올려서, 대략 10분~15분정도 끓이면 됩니다.

주의하실게 오래 하시면 밑이 탑니다. ㅎㅎㅎ

회사 자리 이동

그냥 자리만 서로 바꾸는게 아니였다.

지난해 처럼, 전체 자리 배치까지 다시하는 완전 들었다 놨다하는.. 이사를 또 했다.

 

거의 1년에 한번은 하는 듯;; 재미 붙으셨나.;;;

 

이번엔 아예 파티션을 제거하라는 부장님의 말씀 따라. 연구소안의 파티션은 모두 제거되었다.

이젠..눈만 돌리면 남들이 뭐하는지 다 보인다.

이 부담감..ㅋㅋㅋ

 

lcd 화면 보호 필름이라도 사야하는건가...?

 

먼지속에서 들었다 놨다. 짐 날르다 보니 머리도 아프고 힘도 없군..

감기 기운이 아니길..ㅠㅠ;;;

2009년 5월 21일 목요일

마토이스시(회전초밥)

마토이스시

 

참 맛있는 초밥집.

집에서 가깝기 때문에 종종 갑니다.

매장은 그리 크지 않아요.

음.. 테이블이, 15개 정도 있었던 거 같은데..

그렇다고 너무 붐벼서 기다리고 그런적은 없었어요.

아무래도, 1인당 14,800원에 1시간 사용이기 때문에 원활하게 이용이 가능한거 같아요.ㅎ

초밥의 상태는 양호합니다. 그리고 회전식이니깐, 딱 보고 바로 만들어 놓은 것을 골라먹으면 되지요 ㅎ

어느 분은 별로라고도 하실 수 있는데 그건 뭐 개인의 편차이니 어느 정도 감안하시구요 ㅎ

회전초밥 뷔페이니깐,  원하는 만큼 1시간 안에만 사용하시면 되요.

4인 이상일 경우는, 회전레일 가까운 곳으로 자리 예약을 해주더라고요.

적지 않은 샐러드바(야채,과일,튀김,롤, 온면,메밀면 등등)도 있고요.

값비싼 더 좋은 곳의 초밥과는 뭐..ㅋㅋ 당근 비교가 안되겠지만,

나름 괜찮고 이용의 가치는 있다고 봅니다. ㅎㅎ

 

위치는, 구로디지털단지역에서 간다면..?

구로디지털단지역 근처의 이마트 맞은편에 대륭포스트타워1차, 지하 B118호 에 있어요.

남구로역에서 간다면..?

남구로역 2번 출구로 나와서, 만민중앙교회 방면으로 직진하다 보면,

삼거리가 나옵니다. 오른쪽은 마리오 가는길, 왼쪽은 구로디지털단지 가는길,

왼쪽으로 꺽어서 100미터 걸어가면, 대륭포스트타워1차 건물이 나오고 지하 B118호 입니다.

 

생과일 생크림 케익(레시피 無)

생크림 케익 by Grace

생크림 케익 by Grace

생크림 케익 by Grace

생크림 케익 by Grace

생크림 케익 by Grace

생크림 케익 by Grace

생크림 케익 by Grace

생크림 케익 by Grace

생크림 케익 by Grace

 

아직 초보라서, 제가 몇번 만들지는 않았지만,

동물성 생크림을 이용해서,

생과일들로만 만들어서 선물하고 먹기도 하고 그랬어요.

더 예쁘고 화려하게 할려면 가능은 하지만, 과일이 금값인지라..ㅎㅎ

적당선에 절제하고 있지요 ㅎㅎㅎ

 

위의 케익들은

동일한 스폰지케익에 데코들만 달리했을 뿐 만드는 방법은 똑같다는것!!

ㅋㅋㅋㅋ;;

맛은 기가 막히게 좋았습니다.

 

레시피는 간단하게 조만간 올릴게요..ㅎㅎ;;;

달손님이 올때는..

여자로써,,,

달손님이 오는 것이..

참 감사한 일이지만,

사춘기를 지나면서부터 수십년을 함께 해야 하는.. 손님..쿠쿠;;;;;

 

오늘같이 비가 오는 날,,

달손님이 오시면, 참..;;;; 대략난감이지요;;

 

생리통을 겪는 여자분들에게.. 간단하고도 기초적인 상식하나. 알려드려요..ㅎㅎ

 

저도 아주 심하지는 않은데요.. 그렇다고 아예 없는 것도 아니고 해서, 저도 은근 도움을 받은..ㅎㅎ

 

바로..

 

치즈! 를 먹는 것입니다. ㅎ

예전에 kbs 비타민에서 봤는데, 생리통에는, 칼슘(치즈에 많다고 하더군요)을 많이 섭취해줌으로,

통증을 완화 시킬 수가 있다고 하더라고요..

 

그래서 저도, 달손님이 올때 쯤 되면,

치즈를 사다가, 시작 전 부터, 하루 세끼마다 1개씩 먹었어요 ㅎㅎ

아예 싹 가져주시는 않지만, 좀 완화된거 같더라고요..

 

굳이 그것이 아니래도, 칼슘섭취는 여자로써, 아주 중요한 일부분이니깐요..

 

골다공증이나 기타 등등을 생각해도 여자로썬, 칼슘섭취가 아주 중요한것 같아요 ^-^

2009년 5월 20일 수요일

google test

xUnit 아키텍처에 기반하고 있고, 다양한 플랫폼을 지원한다. (test vs9.0)

google code 에 있으며 현재 1.3.0이 최신 버전이다. unittest++, boost test ... 등등 많은 것들이 있지만, Junit 같이 쓰기 편한 것은 c++에서(reflection 이 없어서..ㅠㅠ) 찾기는 힘든거 같고, 그나마 그중에 google test(New BSD License)가 좋았다. 문서화도 잘 되어 있는 편이며, 예제도 많다. 특히 google mock 와 같이 사용하면 정말 좋다.(요건 다음에...)

 

간단하게 사용법을 알아보자.

TEST(ExampleCase, TestVector)

{

........

ASSERT_EQ(x.size(), y.size()) << "Vectors x and y are of unequal length";


for (int i = 0; i < x.size(); ++i)

{

EXPECT_EQ(x[i], y[i]) << "Vectors x and y differ at index " << i;

}

}


TEST 매크로를 이용하면 하나의 TestCase를 쉽게 만들수 있다.

첫번째 인자(ExampleCase)는 TestCase 이름이고, 두번째 인자(TestVector)는 TestMethod 이름이 된다.

나중에 --gtest_filter를 사용해서 TestCase별로 모을때 편리하고, 다음에 나오지만 TestCase, TestMethod 별로 SetUp, TearDown을 설정 할 수도 있다.

 

단정문은 prefix로 ASSERT_*, EXPECT_* 가 있다.

ASSERT_* : 단정문이 실패하면 이후의 test method는 무시하고 마친다.

EXPECT_* : 단정문이 실패하더라도 error를 출력하고 이후의 test method를 모두 수행한다.

*_EQ 이외에도 *_TRUE, *_FALSE, *_NE, *_LT, *_GT .... 이 있다. ( google test wiki )

단정문 뒤에  << 은 단정문의 조건이 실패시 사용자가 원하는 문자열을 출력하도록 설정할 수 있다.

 

 

 

TestCase를 사용하는 법을 배워보자.

#include "gtest/gtest.h"

#include "gmock/gmock.h"

#include <iostream>

#include <ctime>


template<unsigned int limit>

class TimeTest : public testing::Test

{

protected:

virtual void SetUp()

{

start_time_ = time(NULL);

}

virtual void TearDown()

{

EXPECT_TRUE( time(NULL) - start_time_ <= limit );

}

private:

time_t start_time_;

};


class TestCalc : public TimeTest<1>

{

private:

typedef TimeTest<1> base;

protected:

void static SetUpTestCase()

{

std::cout << "TestCalc TestCase SetUp" << std::endl;

}


void static TearDownTestCase()

{

std::cout << "TestCalc TestCase TearDown" << std::endl;

}


protected:

virtual void SetUp()

{

base::SetUp();

std::cout << "SetUp" << std::endl;

}

virtual void TearDown()

{

base::TearDown();

std::cout << "TearDown" << std::endl;

}

protected:

int add(int lhs, int rhs)

{

return lhs + rhs;

}

int sub(int lhs, int rhs)

{

return lhs - rhs;

}

};


TEST_F(TestCalc, Test1)

{

ASSERT_EQ(add(1, 1), 1);

EXPECT_EQ(add(1, 1), 2);

}


TEST_F(TestCalc, Test2)

{

EXPECT_EQ(add(1, 1), 1);

EXPECT_EQ(sub(2, 1), 1);

}


TEST_F(TestCalc, Test3)

{

ASSERT_EQ(add(1, 1), 2);

EXPECT_EQ(sub(2, 1), 1);

}


int _tmain(int argc, _TCHAR* argv[])

{

testing::InitGoogleTest(&argc, argv);

return RUN_ALL_TESTS();

}

 

 

TestCase 는 testing::Test 상속 받아서 만들어야 한다.

SetUp, TearDown은 TestMethod 마다 실행될 코드를 넣는다.

SetUpTestCase, TearDownTestCase는 TestCase 초기화, 마무리 코드를 넣는다.

TestCase 매크로는 TEST_F() 를 사용하여 만들면 된다. (TEST FIXTURE)

또 이곳에는 없지만 프로그램 전체 초기화, 마무리 코드도 넣어줄수 있다.

testing::Environment 를 상속받아 SetUp, TearDown 재정의 해주고,

testing::AddGoogleTestEnvironment() 함수를 사용하여 셋팅해 주면 된다.

 

출력창에 보이는 것과 같이 어떤 TestCase가 실행이 되었고,  Method 별로 성공|실패를 알려주며, 실패시는 소스 코드 파일과 행을 출력하며 예상값과 실제값이 어떻게 틀린것인지 출력해준다.

 

 

 

google test 실행 인자

--gtest_output=xml:path - path 경로로 test 결과를 xml로 출력해 준다.

--gtest_break_on_failure (난 안되더라;; ㅡㅡ;) - 실패시 디버그 가능하도록 브레이크가 걸린단다.. -_-;

--gtest_filter=ExampleSuite.* - <- ExampleSuite 안에 있는 TestCase만 테스트 한다.

--gtest_filter=*Suite* <- Suite라는 이름이 들어간 TestSuite 모두를 테스트 한다.

–gtest_repeat=3 - 입력 횟수만큼 테스트 한다.

 

더 많은 옵션은 구글 코드에 가서 google test wiki를 참고 하기 바란다.

자세한 정보는 이곳(http://code.google.com/p/googletest/wiki/GoogleTestPrimer)을 참조 하기 바란다.

문서뿐 아니라 자세한 예제(http://code.google.com/p/googletest/wiki/GoogleTestSamples)도 많다.

 

이 글은 스프링노트에서 작성되었습니다.

마늘빵 만들어 먹기

마늘빵 by Grace

식빵을 이용해서, 쉽게 또 저렴하게 마늘빵을 만들어 먹어보았습니다.

아주 맛은 굿입니다. ㅎ

1줄을 몽땅 만들어서, 친구들과 나눠 먹으면 너무나도 좋아라 합니다.

이의 레시피는 집에가서 올리도록 할게요 ^^

 

<재료 및 만들기>

1. 재료

식빵 15~20장

마늘소스( 버터 60그램, 마요네즈 15그램, 연유 15그램, 마늘분말 8그램(분말없으면 다진마늘 동량), 설탕 6그램, 파슬리 1ts )

 

2. 만들기

  1. 쿠키 커터를 이용해서, 식빵에 모양을 내도 되고 아니면 저와 같이 그냥 적당히 잘라서 해도 되요.
  2. 오븐을 미리 예열해둡니다. 180도.
  3. 마늘소스 만들기
    1. 버터를 마요네즈보다 더 질은 상태로 풀어놓는다. (전자렌지로 살짝 녹여도 되요)
    2. 여기에, 마요네즈, 연유, 마늘, 설탕, 파슬리를 넣고 섞기.
    3. 준비 된 식빵에 이 소스를 앞뒤에 바른다. (솔이나, 숟가락으로 )
    4. 180도 온도로 5~7분 정도를 굽는다.(딱 보면 노릇노릇해지는 정도만 하면 되요, 다 굽고 꺼낼때, 마늘빵이 딱딱해져야.. 나중에 식혀놔도 눅눅해지지 않고 오래도록 바삭하더라구요. 더 바삭하게 구우려면 좀더 구우면 되고요.)

발렌타인 데이에 딱 맞는 초코브라우니 와 초콜릿

초코브라우니 by Grace

초코브라우니 by Grace

발렌타인 선물 by Grace

저와 june이 너무 좋아라 하는 초코브라우니..ㅎ

카카오함량 60% 정되는 되는 놈으로다가, 초코브라우니를 만들면,

달콤쌉쌀하니..너무나도 맛납니다. ㅎㅎ

처음 만들어서 선물해줬을 때, 동그랗게 눈을 뜨며,, 너무 맛나다고 찬사를 아끼지 않는 june의 모습이 아직도 생생하네요 ㅎㅎ

이 레시피도 집에가서 올릴게요.. ㅎㅎ

 

<초코브라우니 재료 및 만들기>

  1. 재료
    1. 다크초콜릿 170그램, 버터 80그램, 흑설탕 70그램, 달걀 3개, 박력분 60그램, 코코아가루 2Ts, 베이킹파우더 1/2ts
  2. 만들기
    1. 초콜릿과 버터를 볼에 넣고선 중탕으로 녹여준다.
    2. 다 녹으면, 흑설탕을 넣고 손거품기로 저어준다.
    3. 오븐을 미리 예열해둡니다. 170도.
    4. 흑설탕까지 다 녹으면, 중탕볼에서 내려서, 달걀을 한개씩 넣어가며 재빨리 휘핑해준다.
    5. 체친가루(박력분, 베이킹파우더)를 넣고 잘 섞어줍니다.
    6. (원하면, 여분의 견과류를 넣고 섞어줘도 되요)
    7. 유산지를 깐 원형틀(원형2호)에 반죽을 붓고, 평평하게 만들어 준 뒤, 견과류를 반죽윗면에 장식해준다.
    8. 170도 오븐에서 30~40분 정도 굽는다.
    9. 이쑤시개나 얇은 젓가락으로 빵의 옆구리를 쿡..질러보아..ㅋㅋㅋ 반죽이 묻어나지 않으면 익은 거예요.
    10. 꺼내서, 식힌망 위에 올려놓고 식히기.

 

<초콜릿 재료 및 만들기>

  1. 재료 : 유산지(28mm 여러장), 견과류(호두, 아몬드, 코코넛 슬라이스 등등 다른 견과류), 생크림 80그램, 버터 10그램, 다크초콜릿 180그램,
  2. 만들기
    1. 견과류는 오븐170도(예열없이) 5분 정도 넣어서 구워놓으면 좋아요(코코넛 슬이스는 굽지 않아요 구으면 약간
    2. 다크초콜릿을 중탕으로 녹입니다.
    3. 생크림을 끓여요.
    4. 바글바글 끓으면 불에서 내려, 1의 다크초콜릿에 부어서 섞습니다.
    5. 버터를 넣습니다.(3 이 따뜻할 때 버터가 잘 녹아요)
    6. 버터가 녹았으면, 유산지 적당히 나눠 담습니다.
    7. 초콜릿이 더 굳기 전에, 준비된 견과류를 토핑처럼 예쁘게 올려주세요..^-^
    8. 생초콜릿이기 때문에 굳고 나서도 딱딱하진 않습니다. 견과류가 씹히고, 초콜릿은 아주 부드럽게 사르르 녹는 초콜릿 입니다. ㅎㅎ

달콤한 초코칩

초코칩 쿠키 by Grace

 

<재료>

버터 75그램,

흑설탕 75 그램,

박력분 110 그램,

달걀 1개,

소금 3그램(1ts 조금 안되게),

베이킹파우더 3그램(1ts 조금 안되게),

바닐라 오일 3그램(청주, 럼주등으로 대체 가능, 없으면 그냥 생략),

초코칩 50그램(저는 다크초콜칩을 썼어요),

건포도 30그램(뜨거운 물에 살짝 헹궈 둡니다. 몸에 안좋은 기름등을 제거하기 위해서요 ^^;) ,

호두(혹은 기타 견과류) 30그램

- 쿠키 지름 3cm 10~12개 분량

 

<만들기>

  1. 말랑 버터(실온에 녹인것, 혹은 전자렌지에 30초 정도 녹인것) 를 휘핑한다.
  2. 설탕을 나눠 넣으며, 설탕입자가 녹지 않게금 까지 젓는다. 설탕 입자가 퍼지면 케익처럼 퍼짐.
  3. 여기에 노른자를 넣고, 젓다가, 흰자를 넣고 젓는다(저는 그냥 전란을 넣고 섞어요 ㅎ)
  4. 체친 박력분, 베이킹파우더를 11 자로 발끼 살살 섞기.
  5. 이쯤 되면 오븐을 170도로 켜둔다(예열, 대략 10분 정도, 이때에, 사용할 견과르를 넣어두면 살짝 구워집니다. 그것을 초코칩에 넣을 때 사용하면 더 맛나고 고소한거 같아요)
  6. 초코칩을 넣고 젓기
  7. 바닐라 오일 혹은 럼주 등을 넣기
  8. 숫가락 두개로 이용하여 동그랗게 떠서 쿠키팬에 놓는다. (좀 띄엄띄엄 놓는다, 익으면서 커진다), 반죽이 되게 되었다면, 동그랗게 떠서 쿠키팬에 올리고 살짝 납작하게금 눌러준다. 질게 되었다면 굳이 눌러주지 않아도 적당하게 가라앉는다.
  9. 170 도에서, 15~20분 정도 굽는다.
  10. 가운데를 갈라보고 가루없이 잘 익었나 본다.
  11. 꺼내서 실온에서 20분간 식히면 딱 맞는 쿠키의 단단함이 되찾아진다.

정말..ㅎㅎ 맛있게 먹는 레시피입니다.

저는 위의 레시피에서 설탕이나 버터의 양을 10%~20% 정도는 더 적게 넣습니다. ㅎ

그렇게 줄여도 맛나더라구요 ㅎㅎ

 

만들어서 저렇게 예쁜 포장지에 싸서 선물하면 멋스럽고 폼나고 ㅎㅎ 맛나다고 칭찬 듣는.. 쿠키가 됩니다..^-^

2009년 5월 19일 화요일

실용주의 프로그래머

  • 실용주의 프로그래머 팁
  • 내 기술에 애정과 관심을 갖어라.
  • 자신의 일에 대해서 생각하면서 일하라.
    • 절대 기계적으로 일하지 말라. 언제나 생각하고, 언제나 일하면서 동시에 자신의 일을 비평하고 분석하라.
  • 어설픈 변명을 만들지 말고 대안을 제시하라.
    • 실수를 저지르거나 잘못된 판단을 내렸다면, 정직하게 인정하고 다른 방안을 제안하도록 노력하라.

"가장 큰 약점은 약점을 보일 것에 대한 두려움이다." - 보쉬에(J.B.Bossuet), Politics from Holy Writ, 1709

  • 깨진 창문을 내버려두지 말라.
    • "깨진 창문"(나쁜 설계, 잘못된 결정, 형편없는 코드...)는 발견하자마자 바로 고쳐라.
    • 무엇이든지, 판자로라도 덮어두어서, 관리하고 있다는 것을 보여라.
  • 변화의 촉매가 되라.
    • 촉매제가  되어 다른 성공요인을 끌어낼수있다.
  • 큰 그림을 기억하라.
    • 내가 무엇을 하는 지에만 정신을 쏟지말고, 주변에서 무엇이 일어나는지 주의있게 봐라. 안그러다가, 처음 큰 그림을 망칠수가 있다.
  • 품질을 요구사항으로 만들어라.
    • 타협과정에 사용자를 참여시켜라.
    • 완벽하게 훌륭한 프로그램을 과도하게 장식하거나 지나칠 정도로 다듬느라 망치지 말라. 완벽해지기란 불가능하다.
  • 지식 포트 폴리오에 주기적으로 투자하라.
    • 매년 새로운 언어를 최소 하나는 배워라.(머리 터져;)
    • 기술서적을 분기마다 한 권씩 읽어라.(아;; 독서;;)
    • 비기술서적도 읽어라.
    • 수업을 들어라.
    • 지역사용자 모임에 참여하라.
    • 다른(개발)환경에서 실험해보라
    • 요즘 흐름을 놓치지 마라.
    • 인터넷을 이용하라 - 뉴스그룹 등 기술 정보를 습득하라.
  • 읽고 듣는 것을 비판적으로 분석하라.
  • 무엇을 말하는가와 어떻게 말하는 가 모두 중요하다.
    • 말하고 싶은게 무엇인지 알아라 - 요점을 미리 적어놓거나 생각해놓는다
    • 청중을 알아라 - 이 말을 들어야 할 다양한 종사자들을 생각해서 그들 구미에 맞게금 말하라.
    • 때를 골라라 - 잘 받아들여질 때에 말하라.
    • 스타일을 골라라 - 상대방이 원하는 의견 전달의 스타일(간단 메모?, 긴 브리핑?, 요점 브리핑?) + 내가 할 수 있는 전달 스타일.
    • 멋져보이게 하라 - 문서 작성한다면 꾸며서 멋있게.
    • 청중을 참여시켜라 - 피드백
    • 청자가 되어라. - 잘 들어야 내 말에도 경청해준다. 대화형 회의로 만들어라.
    • 응답하라 - 질문에 대한 답을 지금 못 준다고 해도, "조금 후에 주겠다" 라든가. 뭔가 응답을 하라.
    •  email 도 대화만큼이나 중요하다.
  • 무엇을 말하는가와 어떻게 말하는가 모두 중요하다.
  • Dry(Don't Repeat Yourself) - 반복하지 마라. 즉 중복을 피하도록 하라.
    •  강요된 중복
      • 필터, 코드생성기를 작성한다. 전처리기 사용
      • 최소한의 주석만 단다.
      • 문서화 하고 개발을 하라?? 요구사항 명세에 따라, 테스트를 거치고 완료를 하라는?
      • 문서와 코드를 항상 동일하게 유지하라는?? June
    • 부주의한 중복을 피하라. EX) 선을 표현하는 변수 startp, endp 가 있는데, 굳이 length를 둘 필요가 없다. endp-startp를 빼면 length 다.
    • 참을성이 없어서 만들어 내는 중복을 피하라. 동일한 함수를 copy and paste 남발하는 일은 하지 않도록 하라.
    • 개발자간의 코드 중복이 있을 수 있다. 이것은 리더나 설계가 책임 분배를 갖도록 해야 한다. 서로 대화하고, 소스를 공개하면서, 중복을 피해야한다.
  •  재사용하기 쉽게 만들라. 재사용이 안되면 중복을 피해가기 힘들다.
  • 관련 없는 것들 간에 서로 영향이 없도록 하라.
    • 직교성을 높여야 함(독립성 높이고, 결합도 낮추고), 생산성 향상, 리스크 감소.
    • 코드의 결합도를 줄이고, 전역 데이터 사용을 피하고, 유사함수를 피하라. 항상 리팩토링에 힘쓰라.
  • 최종 결정이란 없다. 즉, a 요구 사항만 존재할 것이라고 여기지 말라. a가 갑자기 b요구사항으로 변모해도, 금방 변경이 가능해야 한다. 가역성을 높여라. 그것들에 대해서, 유연하게 능동적으로 대처할 수 있게 코딩을 해라.
  •  목표물을 찾기 위해 예광탄을 써라. 예광탄 코드도 사용가능한 코드이다.  점진적으로 전체 기능을 확인 할 수 있다. <--대비--> 모듈 조립을 통한 거대 공학적 접근 방식.
    • 장점 : 뭔가 작동되는 것을 (점진적으로) 일찍 부터 보게 된다.  통합작업을 수행할 기반이 생긴다. use case를 한 번에 하나씩 다룬다.
    • 예광탄을 써서 맞춘 것이 목표가 아닐 수도 있지만, 조준이 가능하다.
    • 프로토타입과의 차이점 : 프로토타입은 목적에 맞는 것을 구현하기 위해 테스트용으로 만들어서 원하는 결과를 얻어낸 후 버리고 진짜 코드를 적용해서 완성해낸다., 예광탄 코드는, 점진적으로 맞춰가면서 재사용가능한 코드가 된다.
  • 프로토타입을 통해 학습하라. 프로토타이핑을 통해, 배우게 되는 교휸, 이것으로 목적에 가까이 간다.
    • dummy 데이터를 쓸 수 있다. 제한된 기능만을 제공하기도 한다. 정해진 방법 외에는 실행이 안될 수도 있다. 많은 문서화가 필요하지도 않고 간단하게도 된다., 실제 개발에 사용되는 언어로 프로토타입을 작서할 수도 있지만, 대부분 고수준 언어(스크립트)를 사용한다.
    • 세부사항은 무시하고, 전체적으로 시스템 동작에 대한 감을 잡는 것이다.
    • 프로토타입 코드는 폐기 될 것이라는 것. 개발초기에, 잠재적  문제 발견 수정에 대해 비용이 적게 들기 때문에 쓴다.
  • 문제 도메인에 가깝게 프로그래밍 하라.
    • 도메인의 문제만을 푸는 일에만 정신을 집중할 수 있게 하라.
    • 소형 언어를 만들어 사용하는것도 하나의 방법이다.
  • 추정을 통해 놀람을 피하라.
    • 무엇을 묻고 있는지 이해하자. 질문에서 도메인의 범위에 대해 감을 잡을 필요가 있다.
    • 시스템의 모델을 만들어 보라.
    • 모델을 컴포넌트로 나누어라. 각 컴포넌트가 전체 모델에 영향을 미치는 매개변수를 찾아라.
    • 각 매개변수에 값을 주어라.
    • 답을 계산하라. 이상해 보이는 답이 나올 경우 문제를 잘못 이해했거나 모델을 잘못 만들었을 가능성도 있다.
  • 코드와 함께 일정도 반복하며 조정하라.
    • 비슷한 어플리케이션을 만들어본 경험이 없다면 단순한 추측에 불과하다.
    • 점증적 개발이 도움이 될것이다.
      • 요구사항 체크하기
      • 위험 분석하기
      • 설계, 구현, 통합
      • 사용자와 함께 검증하기
  • 지식을 일반 텍스트로 저장하라.(메타데이터도 일반텍스트로, 공개우려가 있다면, 암호화를 해라, 유닉스 철학)
    • 구식이 되는 것에 대한 보험
    • 호환성
    • 더 쉬운 테스트
  • 명령어 셸의 힘을 사용하라.
  • 하나의 에디터를 잘 사용하라.
    • 호환성, 확장성, 생산성
  • 언제나 소스코드 관리 시스템을 사용하라.
  • 비난 대신 문제를 해결하라.
  • 디버깅을 할 때 당황하지 마라.
    • 항상 문제의 근본적인 원인을 발견하려고 노력하고, 그 문제의 특정한 증상만 고치려고 하지 마라.

      "가장 속이기 쉬운 사람은 자기 자신이다." - 에드워드 불워-리톤(Edward Bulwer-Lytton) The Disowned

  • 'select'는 망가지지 않았다.
  • 가정하지 마라. 증명하라.
  • 텍스트 처리 언어를 하나 익혀라.
  • 코드를 작성한는 코드를 작성하라.
  • 완벽한 소프트웨어는 만들 수 없다.
  • 계약에 따른 설계를 하라
  • 일찍 작동을 멈추게 하라.
  • 단정문을 사용해서 불가능한 상황을 예방하라.
  • 예외는 예외적인 문제에 사용하라.
  • 시작한 것은 끝내라.
  • 모듈간의 결합도를 최소화하라.
  • 통합하지 말고 설정하라.
  • 코드에는 추상화를, 메타데이터에는 세부 내용을.
  • 작업흐름 분석을 통해 동시성을 개선하라.
  • 서비스를 사용해서 설계하라.
  • 언제나 동시서을 고려해 설계하라.
  • 모델에서 뷰를 분리하라.
  • 칠판을 사용해 작업흐름을 조율하라.
  • 우연에 맡기는 프로그래밍을 하지 말라.
  • 여러분의 알고리즘의 차수를 추정하라.
  • 여러분의 추정을 테스트하라.
  • 일찍 리펙터링하고, 자주 리팩터링하라.
  • 테스트를 염두에 두고 설계하라.
  • 소프트웨어를 테스트하라. 그렇지 않으면 사용자가 테스트하게 될 것이다.
  • 자신이 이해하지 못하는, 마법사가 만들어준 코드는 사용하지 말라.
  • 요구사항을 수집하지 말고 채굴하라.
  • 사용자처럼 생각하기 위해 사용자와 함께 일하라.
  • 구체적인 것보다 추상적인 것이 더 오래간다.
  • 프로젝트 용어사전을 사용하라.
  • 생각의 틀을 벗어나지 말고, 틀을 찾아라.
  • 준비가 되었을 때 시작하라.
  • 어떤 일들은 설명하기보다 실제로 하는 것이 더 쉽다.
  • 형식적 방법의 노예가 되지 마라.
  • 비싼 도구가 더 좋은 설계를 낳지는 않는다.
  • 팀을 기능 중심으로 조직하라.
  • 수작업 절차를 사용하지 말라.
  • 일찍 테스트하고, 자주 테스트하라. 자동으로 테스트하라.
  • 모든 테스트가 통과하기 전엔 코딩이 다 된게 아니다.
  • 파괴자를 써서 테스트를 테스트하라.
  • 코드 커버리지보다 상태 커버리지를 테스트 하라.
  • 버그는 한 번만 잡아라.
  • 한국어도 하나의 프로그래밍 언어인 것처럼 다루라.
  • 문서가 애초부터 전체의 일부가 되게 하고, 나중에 집어넣으려고 하지 말라.
  • 사용자의 기대를 부드럽게 넘어서라.
  • 자신의 작품에 서명하라.

 

 

 


entropy : 시스템 내의 '무질서'한 정도를 가리키는 물리학 용어.

이 글은 스프링노트에서 작성되었습니다.

야근..

야근은 절망이지.. 싫다..

해야 할일이 많아서,

정규 시간에 소화해 내지 못해서,,

하는 것이 야근 아닌가.

 

것도 코딩의 삽질 연속이다 보니 더욱 그렇다..

 

누구는 농구하러 신나게 고고싱하러 갔드만..쩝.. -_-

애플파이


애플파이 by Grace

 

저희의 블로그 이름이.. apple-pie 아니겠어요..? ㅎㅎㅎ

이름과 걸맞게 애플파이의 레시피도 올리겠어요 ㅎㅎ

지금은 회사이니깐, 우선 샷만 올려놓고요 집에가서,, 올릴게요 ㅎㅎ

제가 만들어서 먹은건데요.. 특히나 울 June이 좋아합니다. ㅎㅎ

아주 맛나다고 하더라고요 ㅎㅎㅎ

 

<재료 및 만들기>

  1. 타르트지 만들기
    1. 재료 : 버터 60 그램, 소금 1/8ts, 슈가파우더 60그램, 계란노른자 1개, 박력분 110 그램, 럼주(혹은 청주) 1ts( 혹은 바닐라 오일 1방울)
    2. 실온의 버터를 젓다가, 소금, 슈가파우더를 넣고 젓는다.
    3. 여기에 계란 노른자를 넣고 저어준 후, 체친 박력분을 넣고 섞는다.
    4. 위의 반죽을 비닐에 넣고 넓게 펴서 냉장실에 넣고 1시간 휴지를 시킨다.
  2. 사과필링 만들기
    1. 재료 : 사과 1개(잘게 썰어놓는다), 설탕 20그램, 버터 10그램, 밀가루 1/2Ts, 원하면 계피가루 1/8ts
    2. 냄비에 설탕을 녹인 후, 버터를 넣고 잘 섞는다.
    3. 버터 녹으면, 사과 넣고 중불 10분 졸인다.
    4. 사과가 졸이면, 밀가루, 계피가루를 넣고 2분 정도 졸이고 충분히 식힌다.
  3. 아몬드 크림 만들기
    1. 재료 : 버터 25그램, 설탕 20그램, 계란 흰자, 아몬드 분말 25그램, 럼주 1Ts
    2. 실온버터에 설탕을 3회 나눠 넣으면서 젓고, 계란흰자도 넣고 젓는다.
    3. 체친 아몬드 분말 넣고, 주걱으로 살살 저은 후, 럼주를 넣는다.
  4. 오븐 예열해두기(180도)
  5. 1시간이 지났다면? 휴지 시키던 반죽을 꺼내서, 밀대를 이용해서 얇게 민다.(대략 3mm 정도) 얇게 민 반죽을 타르트 지에 붙히고 밀대를 반죽을 붙힌 타르트 틀 위에서 밀면, 깔끔하게 나머지 반죽이 떨어져 나간다. ㅋ
  6. 붙힌 타르트 지에, 포크로 송송송 구멍을 찍어놓는다(들림 현상 방지)
  7. 타르트 지에 붙어있는 그 위에, 아몬드 크림을 담고 그 위에 사과 필링을 담는다(혹원 사과 필링을 담고 아몬드 크림을 위에 담는다, 혹은 섞어서 담는다)
  8. 남은 타르트 반죽이 있다면 얇게 밀어서, 사진과 같이 위에다가 붙혀주면, 모양이 더 근사하고 멋있다. ㅎ
  9. 예열 된 오븐에 넣고 20~30분간 굽는다.

 

크림 스파게티

크림 스파게티 by Grace

◆재료(2인분 기준):새우 10마리, 오징어 1/2마리, 관자 4개(원하는 해물로 교체가능), 바질 1팩, 화이트와인 2 스푼(청주 대체 가능), 올리브 오일 약간, 스파게티 면 160g. 브로컬리, 양송이, 양파, 베이컨, 마늘

◆크림소스=우유 500ml, 버터 20g, 밀가루 20g, 소금, 후추 약간, 월계수 잎 2장

 

  1. 새우는 머리와 꼬리는 떼고 손질해 먹기 좋게 살만 발라 준비해 두고,
  2. 관자는 반으로 잘라 준비한다.(계절을 고려하여 홍합, 가리비조개 등 기호에 맞는 해산물을 추가해도 좋다)
  3. 오징어는 껍질을 벗겨 적당히 얇게 썰어 둔다.
  4. 홍합이 있을 경우,  위의 해산물을 같이 뜨거운 물에 데쳐놓는다.
  5. 바질은 굵직하게 썰어 둔다. 바질은 최근 대형 마트에서 구할 수 있다.
  6. 브로컬리는 살짝 삶고, 양송이와 양파는 채썬다.
  7. 스파게티면은 소금을 넣은 끓는 물에 10분 정도 삶아서 건진 후 식힌다. 식힐 때, 올리브 유를 조금 발라 두면 서로 달라 붙지 않는다. 스파게티면은 간이 전혀 되어 있지 않기 때문에 소금을 넣고 삶으면 약간 간이 배여 우리 입맛에 더욱 잘 맞다.
  8. 크림소스를 만들 때 명기된 분량의 밀가루와 버터를 넣고 낮은 불에 은근히, 천천히 볶아 '루(roux)'를 만든 뒤 우유를 천천히 부으면서 덩어리 지지 않게 풀어준다. 밀가루와 버터를 볶을 때는 갈색의 색깔이 날 때까지 볶으면 안되니 주의해야 한다.
  9. 여기에 월계수 잎과 소금·후추를 넣고 충분히 끓인 뒤 월계수 잎은 건져 낸다.
  10. 팬에 올리브 오일을 두르고 마늘을 넣고 살짝 볶다가, 해산물을 넣고 볶다가, 베이컨을 넣고 볶다가 거의 익었을 때,  야채를 넣고 볶다가, 화이트 와인을 부어 완전히 익힌다.
  11. 만들어 놓은 크림소스를 부어 끓이면서 기호에 맞게 다시 소금, 후추로 간을 한다.
  12. 삶은 스파게티와 바질을 넣어 끓여서 접시에 먹기 좋게 담는다.

========================================================================================

제가 여기 저기서 정보를 얻어다가 완성한 레시피 인데요..

여러번 해먹어보았는데.음 아직은 약간 2% 부족한듯한 느낌인데 ㅎㅎ 다른 사람들은

맛있다고 또 먹고 싶다고 그르네요 ㅎㅎㅎ

 

이 글은 스프링노트에서 작성되었습니다.

 

치킨샐러드

치킨샐러드 by Grace

  • 드레싱(전날 미리 준비해놓기)
  1. 참깨드레싱 : 플레인 요구르트1개, 마요네즈 1큰술, 참깨5큰술, 식초 1큰술, 꿀1큰술, 레몬즙 1큰술
  2. 들깨드레싱 : 양파,레몬,들깨가루6큰술,식용유4큰술,설탕2큰술,식초2큰술, 소금1/2큰술
  3. 허니머스터드 : 허니머스터드 2큰술, 레몬즙2큰술,설탕2큰술,소금약간,청주2큰술,다진마늘1큰술

 

  • 샐러드(전날 미리 준비해놓기)
  1. 양상추, 샐러리, 삶은 계란, 방울토마토,브로컬리 살짝 데친것,

 

  • 치킨텐더 만들기
  1. 물반죽에 담궜다가 -> 튀김옷을 입히고 -> 튀기기
  2. 닭고기를 포크로 찍어서 간이 베이게 한다;;
  3. 닭가슴살(혹은 닭안심살)을 우유에 30분간 재워둔다.
  4. 닭고기 밑간은 소금, 후추, 맛술(없으니 청주로 대체)를 뿌려서 둔다.(10분)
  5. 물반죽 만들기 : 계란1개,  밀가루 80g, 물 40g, 케이준 가루 없으니 고춧가루 조금
  6. 튀김옷 : 옥수수전분(3), 감자전분(3), 튀김가루(6), 파슬리가루(1) 을 봉투에 담아놓기 ( 간단하게 튀김가루만 해도 됨 )
  7. 튀길 때, 물반죽을 살짝 떨어뜨려봐서 올라오면 튀긴다. 2번 튀긴다. 1번째 굽고 2번째는 다 넣고 튀겨서 건진다. 키친 타올에 두고 기름을 밴다.

==========================================================================================

소풍갈때 마다 만들어 먹었던 치킨샐러드와 참치김밥..

정말.. 너무너무 맛있습니다..ㅎㅎ

단 튀기실 때, 기름이 많이 소비 된다는게 흠인데요..

키친 타올을 이용해서 충분히 기름을 빼주세용..^-^

이 글은 스프링노트에서 작성되었습니다.

 

참치김밥

참치김밥 by Grace

4인분

밥 : 고슬밥 4공기, 참기름 1큰술, 깨소금 1큰술, 소금 약간, 식초 약간

재료 : 참치캔 작은거 1개(기름 쫙 빼놓기), 마요네즈, 햄 작은거, 김, 달걀 지단( 2개로 만들기), 깻잎 8장, 단무지(흰색),

당근 작은 거 1개, 맛살 작은거 1개, 시금치, 우엉 작은 거 1개(생략가능)

준비물 : 김말이 발

 

  • 전날 준비할 것
  1. 참치 캔 기름 빼놓기
  2. 햄, 맛살 길게 찟어놓기, 뜨거운 물로 데친 후, 살짝 볶기
  3. 당근 채 썰어서, 식초에 담궜다가 건져서, 살짝 볶기
  4. 달걀 지단 만들기
  5. 시금치 녹여놓기
  6. 단무지 찬물에 담궈놓기
  • 당일날 준비할 것
  1. 밥 고슬하게 짓기(몇시간 전에 미리 해놓기)
  2. 밥 양념하기(참기름 1큰술, 깨소금 1큰술, 소금 약간, 식초 약간)
  3. 참치에 마요네즈 섞기
  4. 김발 말기
    1. 김의 반양큼 밥을 깔고, 깻잎을 올려놓고, 참치를 올려놓기
    2. 햄, 달걀, 단무지,당근,맛살,시금치 등을 올려놓기
    3. 말기, 끝부분에 물로 살짝 찍어서 감아놓기
    4. 다 말고 난 다음에 썰기

==========================================================================================

소풍갈때 마다 만들어 먹었던 치킨샐러드와 참치김밥..

정말.. 너무너무 맛있습니다..ㅎㅎ

밥을 맨처음 펴주실 때, 손을 이용해서 적당히 펴시는거 아시죠?

밥이 김의 2/3 는 덮어주어야 나중에 말고 나서 예쁘게 모양이 나온답니다. ㅎㅎㅎ

밥의 간을 맞추는게 핵심인데요 ㅎㅎ

야채를 볶을 때 소금을 넣으시면 밥에는 좀 싱겁게 하시고,

소금의 양을 잘 조절하세요 ㅎ

이 글은 스프링노트에서 작성되었습니다.

매운해물잡채

 

1. 양파, 당근, 부추, 풋고추, 목이버섯은 채썰어 각각 기름 두른 팬에서 볶아준다.

2. 찬물에서 불린 당면은 끓는물에 삶은 뒤 간장, 설탕, 참기름으로 버무려놓는다.

3. 오징어, 새우, 홍합은 데쳐놓는다.

4. 달군팬에 고추기름을 두르고 다진 마늘, 마른 고추를 볶다가
  데친 해물, 고추가루, 맛술 등을 넣고 볶아준다.

5. 모든 재료를 함께 버무려주면 완성.

이 글은 스프링노트에서 작성되었습니다.

맛간장 만들기

간장 2컵, 사과나배 1/2 벗겨놓기, 양파 , 레몬1쪽,

파인애플1쪽, 감초 3~4개(설탕대신 진맛), 흑설탕 1큰술, 마늘, 월계수잎, 통후추,

물(다시마육수넣어도됨)넣고 끓여 졸였다가 냉장고 넣어놓고 조림이나 무침할때 이것만 넣으면 됨.

 

 

이 글은 스프링노트에서 작성되었습니다.

2009년 5월 18일 월요일

07장. 템플릿과 일반화 프로그래밍

항목 41. 템플릿 프로그래밍의 천릿길도 암시적 인터페이스와 컴파일 타임 다형성부터

  • 객체 지향 프로그래밍의 축
    • 명시적 인터페이스
    • 런타임 다형성
  • 템플릿 일반화 프로그래밍의 축
    • 암시적 인터페이스 - 표현식(expression)이 유효 해야한다.
    • 컴파일 타임 다형성
  • 클래스 및 템플릿은 모두 인터페이스와 다형성을 지원한다.
  • 클래스의 경우, 인터페이스는 명시적이며 함수의 시그니처를 중심으로 구성되어 있습니다. 다형성은 프로그램 실행 중에 가상 함수를 통해 나타납니다.
  • 템플릿 매개변수의 경우, 인터페이스는 암시적이며 유효 표현식에 기반을 두어 구성됩니다. 다형성은 컴파일 중에 템플릿 인스턴스화와 함수 오버로딩 모호성 해결을 통해 나타납니다.

 

항목 42.typename의 두가지 의미를 제대로 파악하자.

  • template<class(typename) T> 는 같은 의미이다.
  • 템플릿 매개변수에 종속된 것
    • 의존 이름(dependent name)
    • 중첩 의존 이름(nested dependent name)
    • 중첩 의존 타입 이름(nested dependent type name)
  • 의존 이름에 typename을 붙여서 type 이란것을 알려줘야 한다.
    • 예외
    • 상속되는 기본 클래스 리스트
    • 멤버 초기화 리스트에 있는 기본 클래스 식별자
  • 특성 정보(traits) 클래스를 이용하여 타입을 생성할 수 있다.
  • 템플릿 매개변수를 선언할 때, class 및 typename은 서로 바꾸어 써도 무방합니다.
  • 중첩 의존 타입 이름을 식별하는 용도에는 반드시 typename을 사용합니다. 단, 중첩 의존 이름이 기본 클래스 리스트에 있거나 멤버 초기화 리스트 내의 기본 클래스 식별자로 있는 경우에는 예외입니다.

 

항목 43. 템플릿으로 만들어진 기본 클래스 안의 이름에 접근하는 방법을 알아 두자.

  • c++의 하위 언어들 중 한 부분인 객체지향 c++에서 템플릿 c++로 옮겨 갈 때 상속 메커니즘이 끊김.
    • 기본 클래스 함수에 대한 호출문 앞에 "this->"를 붙인다.
    • using 키워드를 사용하여 유효범위를 알려준다.
    • 함수 앞에 명시적으로 기본 클래스를 알려준다.
      • 되도록 쓰지 말라( 가상 함수일 경우 동적 바인딩이 무시된다.)
  • 기본 클래스의 멤버에 대한 참조가 무효한지를 컴파일러가 진단하는 과정에서 미리 들어가는냐, 나중에 들어가느냐가 핵심이다.
  • 파생 클래스 템플릿에서 기본 클래스 템플릿의 이름을 참조할 때는, "this->"를 접두사로 붙이거나 기본 클래스 한정문을 명시적으로 써 주는 것으로 해결합시다.

 

항목 44. 매개변수에 독립적인 코드는 템플릿으로부터 분리시키자.

  • 템플릿은 코딩 시간 절약, 코드 중복 회피 두마리 토끼를 잡도록 해준다.
    • 생각없이 하면 코드 비대화를 초래할 수 있다.
  • 공통성 및 가변성 분석 을 통해 코드 중복을 막자.
  • 예제 코드 꼭 볼껏
    • template base 접근 this-> 안됨;; -_-;
  • 크기별 고정 버전
    • 컴파일 시점에 투입되는 상수 - 상수 전파(constant propagation) 최적화
  • 타입별 크기 가변 버전
    • 프로세스의 메모리 로드량 감소 - 명령어 캐쉬내 참조 지역성 향상
      • 시간적 지역성(temporal locality), 공간적 지역성(spatial locality) 향상.
  • 이진 표현 구조가 똑같을 경우 코어 부분을 한벌만 만들고, 타입별로 랩핑 하는 형태로 만들수도 있다.
  • 템플릿을 사용하면 비슷비슷한 클래스와 함수가 여러 벌 만들어집니다. 따라서 템플릿 매개변수에 종속되지 않는 템플릿 코드는 비대화의 원인이 됩니다.
  • 비타입 템플릿 매개변수로 생기는 코드 비대화의 경우, 템플릿 매개변수를 함수 매개변수 혹은 클래스 데이터 멤버로 대체함으로써 비대화를 종종 없앨 수 있습니다.
  • 타입 매개변수로 생기는 코드 비대화의 경우, 동일한 이진 표현구조를 가지고 인스턴스화되는 타입들이 한 가지 함수 구현을 공유하게 만듦으로써 비대화를 감소시킬 수 있습니다.

이 글은 스프링노트에서 작성되었습니다.

06장. 상속, 그리고 객체 지향 설계

항목 32. public 상속 모형은 반드시 "is-a(...는...의 일종이다.)"를 따르도록 만들자.

  • public 상속의 의미는  "is-a(...는 ...의 일종)"입니다. 기본 클래스에 적용되는 모든 것들이 파생 클래스에 그대로 적용되어야 합니다. 왜냐하면 모든 파생 클래스 객체는 기본 클래스 객체의 일종이기 때문입니다.

 

항목 33. 상속된 이름을 숨기는 일은 피하자

  • 유효 범위 검색 방법
    • 지역 유효 범위 (local scope)
    • 객체 유효 범위
    • base 클래스 유효 범위
    • 네이스페이스 유효 범위
    • 전역 유효 범위
  • 기본 클래스로 부터 오버로드 버전을 상속 받으려면 '상속된 이름 가리기'를 무시하자.
  • '상속된 이름 가리기'를 무시할려면, using 선언을 써서 보이도록 할 수 있다.
  • 파생 클래스의 이름은 기본 클래스의 이름을 가립니다. public 상속에서는 이런 이름 가림 현상은 바람직하지 않습니다.
  • 가려진 이름을 다시 볼 수 있게 하는 방법으로, using 선언 혹은 전달 함수를 쓸 수 있습니다.

 

항목 34. 인터페이스 상속과 구현 상속의 차이를 제대로 파악하고 구별하자.

  • 멤버 함수 인터페이스는 항상 상속되게 되어 있기 때문에 추상 클래스는 파생된 클래스에 절대적인 영향을 미친다.
  • 순수 가상 함수를 선언하는 목적은 파생 클래스에게 함수의 인터페이스만을 물려주려는 것이다.
    • 순수 가상함수도 정의를 제공할 수 있다.
    • 사용할때는 static 함수처럼 ::로 사용가능 하다.
  • 단순 가상 함수를 선언하는 목적은 파생 클래스로 하여금 함수의 인터페이스만 아니라 그 함수의 기본 구현도 물려받게 하는 것이다.
  • 비가상 함수를 선언하는 목적은 파생 클래스가 함수 인터페이스와 더불어 그 함수의 필수적인 구현(mandatory implementation)을 물려받게 하는 것이다.
  • 인터페이스 상속은 구현 상속과 다릅니다. public 상속에서, 파생 클래스는 항상 기본 클래스의 인터페이스를 모두 물려받습니다.
  • 순수 가상 함수는 인터페이스 상속만을 허용합니다.
  • 단순(비순수) 가상 함수는 인터페이스 상속과 더불어 기본 구현의 상속도 가능하도록 지정합니다.
  • 비가상 함수는 인터페이스 상속과 더불어 필수 구현의 상속도 가하도록 지정합니다.

 

항목 35. 가상 함수 대신 쓸 것들도 생각해 두는 자세를 시시때때로 길러 두자.

  • 비가상 함수 인터페이스(non-virtual interface : NVI ) 관용구 - 템플릿 메서드(template method) 패턴.
    • 가상 함수 은폐론
    • 함수 기능은 파생 클래스에게 위임하고, 함수를 호출하는 시점은 기본 클래스만의 고유 권한으로 만든다.
  • 함수 포인터로 구현한 전략 패턴
    • 전략(strategy pattern) 패턴의 단순한 응용
  • tr1::function으로 구현한 전략 패턴
    • 호환되는 시그니처를 가진 함수 호출성 개체를 사용할 수 있도록 만든 전략 패턴의 한 형태.
  • 고전적인 전략 패턴
    • 한쪽 클래스 계통에 있는 가상 함수를 다른 쪽 계통에 속해 있는 가상 함수로 대체하는 전통적인 전략 패턴.
  • 가상 함수 대신에 쓸 수 있는 다른 방법으로 NVI 관용구 및 전략 패턴을 들 수 있습니다. 이 중 NVI 관용구는 그 자체가 템플릿 메서드 패턴의 한 예 입니다.
  • 객체에 필요한 기능을 멤버 함수로부터 클래스 외부의 비멤버 함수로 옮기면, 그 비멤버 함수는 그 클래스의 public 멤버가 아닌 것들을 접근할 수 없다는 단점이 생깁니다.
  • tr1::function 객체는 일반화된 함수 포인터처럼 동작합니다. 이 객체는 주어진 대상 시그니처 호환되는 모든 함수호출성 개체를 지원합니다.

 

항목 36. 상속받은 비가상 함수를 파생 클래스에서 재정의하는 것은 절대 금물!

  • 비가상 함수는 정적 바인딩(static binding)으로 묶인다.
  • 가상 함수는 동적 바인딩(dynamically binding)으로 묶인다.
  • 비가상 멤버 함수는 클래스 파생에 관계없는 불변동작을 정해 두는 것이다.
  • 상속받은 비가상 함수를 재정의하는 일은 절대로 하지 맙시다.

 

항목 37. 어떤 함수에 대해서도 상속받은 기본 매개변수 값은 절대로 재정의하지 말자.

  • 가상함수는 동적으로 바인딩(late binding) 되지만, 기본 매개변수는 정적으로 바인딩(early binding)된다.
  • 기본 매개변수 값을 부모 클래스와 똑같이 제공하기도 힘들다.
    • 코드 중복
    • 의존성 (부모 클래스의 기본 매개변수를 바꾸면 파생 클래스도 다 같이 바꿔줘야 한다.)
  • 비가상 인터페이스 관용구(non-virtual interface : NVI)를 쓴다.
  • 상속받은 기본 매개변수 값은 절대로 재정의해서는 안 됩니다. 왜냐하면 기본 매개변수 값은 정적으로 바인딩되는 반면, 가상 함수(여러분이 오버라이드할 수 있는 유일한 함수이죠)는 동적으로 바인딩되기 때문이다.

 

항목 38. "has-a(...는...를 가짐)" 혹은 "is-implemented-in-terms-of(...는...를 써서 구현됨)"를 모형화할 때는 객체 합성을 사용하자.

  • 합성(composition)
    • 레이어링(layering), 포함(containment), 통합(aggregation), 내장(embedding)
  • 응용 영역(application domain)
    • 우리 일상을 본뜬 객체(사람, 이동수단...)
  • 구현 영역(implementation domain)
    • 순수하게 시스템 구현을 위한 인공물(버퍼, 뮤텍스..)
  • 객체 합성이 응용 영역에서 일어나면 has-a 관계
  • 개체 합성이 구현 영역에서 일어나면 is-implemented-in-terms-of 관계
  • set 을 list를 가지고 구현할 경우 is-a 관계는 부적합하고, 대신 is-implemented-is-terms-of 관계를 이용하여 구현 하면 간단하다.
  • 객체 합성(complsition)의 의미는 public 상속이 가진 의미와 완전히 다릅니다.
  • 응용 영역에서  객체 합성의 의미는 has-a입니다. 구현 영역에서는 is-implemeted-in-terms-of의 의미를 갖습니다.

 

항목 39. private 상속은 심사숙고해서 구사하자.

  • private 상속은 is-a 관계가 아니다. is-implemented-is-terms-of 관계이다.
  • 구현만 물려받고 인터페이스는 전혀 물려받지 않는다.
  • 객체 합성보다 private 상속을 쓸경우는 대개 비공개 멤버를 접근할때, 혹은 가상 함수를 재정의할 경우가 주로 사용된다.
    • 공간상의 이득을 얻을수 있다.
    • 공백 기본 클래스 최적화(empty base optimization: EBO) : 단일 상속하에서만 적용됨
  • public 상속과 객체 합성으로 똑같이 구현할수 있다. 그리고 더 자주 쓰인다.
    • 클래스를 설계하는데 있어 파생은 가능하게 하되, 파생 클래스에서 가상함수를 재정의 할수 없게 설계 차원에서 막고싶을때
    • 컴파일 의존성을 최소화 하고 싶을때
  • private 상속의 의미는 is-implemented-in-terms-of 입니다. 대개 객체 합성과 비교해서 쓰이는 분야가 많지는 않지만, 파생 클래스 쪽에서 기본 클래스의 protected 멤버에 접근해야 할 경우 혹은 상속받은 가상 함수를 재정의해야 할 경우에는 private 상속이 나름대로 의미가 있습니다.
  • 객체 합성과 달리, private 상속은 공백 기본 클래스 최적화를 활성화 시킬 수 있습니다. 이 점은 객체 크기를 가지고 고민하는 라이브러리 개발자에게 꽤 매력적인 특징이 되기도 합니다.

 

항목 40. 다중 상속은 심사숙고해서 사용하자.

  • 가상 상속(virtual inheritance)을 사용할수 있다.
    • 가상 상속을 안쓴거 보다 크기가 크다.
    • 속도도 느리다.
  • 다중 상속은 단일 상속보다 확실히 복잡합니다. 새로운 모호성 문제를 일으킬 뿐만 아니라 가상 상속이 필요해질 수도 있습니다.
  • 가상 상속을 쓰면 크기 비용, 속도 비용이 늘어나며, 초기화 및 대입 연산자의 복잡도가 커집니다. 따라사 가상 기본 클래스에는 데이터를 두지 않는 것이 현실적으로 가장 실용적입니다.
  • 다중 상속을 적법하게 쓸 수 있는 경우가 있습니다. 여러 시나리오 중 하나는, 인터페이스 클래스로부터 public 상속을 시킴과 동시에 구현을 돕는 클래스로부터 private 상속을 시키는 것입니다.

이 글은 스프링노트에서 작성되었습니다.

05장. 구현

항목 26. 변수 정의는 늦출 수 있는 데까지 늦추는 근성을 발휘하자.

  • 루프 안에서의 변수 정의
    • 대입이 생성자-소멸자 쌍보다 비용이 덜 들고, 전체 코드에서 수행 성능에 민감한 부분을 건드리는 중이 아니라면 루프안에서 변수를 정의 하고 쓰자.
  • 변수 정의는 늦출 수 있을 때까지 늦춥시다. 프로그램이 더 깔끔해지며 효율도 좋아집니다.

 

항목 27. 캐스팅은 절약, 또 절약! 잊지 말자.

  • "어떤 일이 있어도 타입 에러가 생기지 않도록 보장한다." C++ 동작 규칙.
  • 구형 스타일 캐스트
    • (T)표현식
    • T(표현식)
  • C++ 스타일 캐스트
    • const_cast
    • dynamic_cast
    • reinterpret_cast
    • static_cast
  • 신형 스타일 캐스트가 좋은 이유
    • 알아보기 쉽다.
    • 캐스트 사용 목적이 좁혀져서, 사용 에러 진단에 용이하다.
  • 객체 하나가 가질수 있는 주소가 오직 한 개가 아니라 그 이상이 될 수 있음.
  • 가상 함수에서 베이스 클래스 함수를 호출할 경우 캐스팅 하지 말고 base::function() 을 호출하도록 하자.
  • dynamic_cast 은 정말 느리다.. -_-; (일부 컴파일러는  strcmp 사용해서 vtable 검사)
  • 폭포식 dynamic_cast ;;; 과연 쓰는 사람이 있을까? -_-;; (절대 쓰지 말자.)
  • 다른 방법이 가능하다면 캐스팅은 피하십시오. 특히 수행 성능에 민감한 코드에서 dynamic_cast는 몇번이고 다시 생각하십시오. 설계 중에 캐스팅이 필요해졌다면, 캐스팅을 쓰지 않는 다른 방법을 시도해 보십시오.
  • 캐스팅이 어쩔 수 없이 필요하다면, 함수 안에 숨길 수 있도록 해 보십시오. 이렇게 하면 최소한 사용자는 자신의 코드에 캐스팅을 넣지 않고 이 함수를 호출할 수 있게 됩니다.
  • 구형 스타일의 캐스트를 쓰려거든 C++ 스타일의 캐스트를 선호하십시오. 발견하기도 쉽고, 설계자가 어떤 역활을 의도했는지가 더 자세히 들러납니다.

 

 

항목 28. 내부에서 사용하는 객체에 대한 '핸들'을 반환하는 코드는 되도록 피하자.

  • 클래스 데이터 멤버는 아무리 숨겨봤자 그 멤버의 참조자를 반환하는 함수들의 최대 접근도에 따라 캡슐화 정도가 정해진다.
  • 무효참조 핸들이 가장 큰 문제이다. ( 핸들을 따라 갔는데 실제 객체의 데이터가 없는 경우 )
  • 어떤 객체의 내부요소에 대한 핸들(참조자, 포인터, 반복자)을 반환하는 것은 되도록 피하세요. 캡슐화 정도를 높이고, 상수 멤버 함수가 객체의 상수성을 유지한 채로 동작할 수 있도록 하며, 무효참조 핸들이 생기는 경우를 최소화할 수 있습니다.

 

항목 29. 예외 안전성이 확보되는 그날 위해 싸우고 또 싸우자!

  • 예외 안전성을 확보하려면 두 가지의 요구사항을 맞추어야 한다.
    • 자원이 새도록 만들지 않는다.
      • 자원 관리 전담 객체를 만들어 해결하자.
    • 자료구조가 더렵혀지는 것을 허용하지 않는다.
      • 예외 안전성 세 가지 보장중에 하나를 제공하자.
  • 기본적인 보장(basic guarantee)
    • 함수 동작중 예외가 발생하면, 실행중인 모든 것들을 유효한 상태로 유지하겠다는 보장.
    • 자료구조를 더럽히지 않으며, 모든 객체의 상태는 내부적으로 일관성을 유지한다.
    • 하지만 프로그램 상태가 정확히 어떠한지 예측이 안 될 수도 있다. 함수를 만든 사람만이 알수있다.
  • 강력한 보장(strong guarantee)
    • 함수 동작중 예외가 발생하면, 프로그램 상태를 절대로 변경하지 않겠다는 보장.
    • 원자적인 동작을 수행한다.
    • 함수가 성공적으로 실행을 마친 후의 상태, 함수가 호출 되기전의 상태 두 가지만 존재.
  • 예외불가 보장(nothrow guarantee)
    • 예외를 절대로 던지지 않겠다는 보장.
    • 기본 제공 타입의 모든 연산은 예외불가 보장.
    • 예외 지정
      • void something() throw(int)   -   int 예외 발생
      • void something() throw()   -   예외를 발생하지 않음.
      • void something()   -   임의의 예외를 발생
    • uncaught excetion, unexpected exception 발생 가능.
    • set_terminate, set_unexpected 함수로 handler를 등록 가능. (vc9.0 미구현, gcc 3.4.5 구현)
  • 함수 부수 효과(side effect) 때문에 강력한 보장을 하기 힘들다.
  • 효율 문제도 있기때문에 실용성이 확보되는 경우에만 강력한 보장을 제공하는데 힘쓰자.
  • 예외 안전성이 없는 함수를 한개라도 쓰면 그 시스템은 전부 예외에 안전하지 않은 시스템이 된다.
  • 예외 안전성을 갖춘 함수는 실행 중 예외가 발생되더라도 자원을 누출시키지 않으며 자료구조를 더럽힌 채로 내버려 두지 않습니다. 이런 함수들이 제공할 수 있는 예외 안전성 보장은 기본적인 보장, 강력한 보장, 예외 금지 보장이 있습니다.
  • 강력한 예외 안전성 보장은 '복사-후-맞바꾸기' 방법을 써서 구현할 수 있지만, 모든 함수에 대해 강력한 보장이 실용적인 것은 아닙니다.
  • 어떤 함수가 제공하는 예외 안전성 보장의 강도는, 그 함수가 내부적으로 호출하는 함수들이 제공하는 가장 약한 보장을 넘지 않습니다.

 

항목 30. 인라인 함수는 미주알고주알 따져서 이해해 두자.

  • 함수의 길이가 길면 페이징 횟수가 늘어나고, 명령어 캐시 적중률이 떨어질 가능성이 높다. 코드 비대화.
  • 반대로 굉장히 짧으면 함수 본문이 함수 호출문보다 작아질 수도 있다. 명령어 캐시 적중률도 높아진다.
  • 암시적 인라인 요청(정의 부분에 본문 추가), 명시적 인라인 요청(inline 키워드 사용)
  • 보통 함수에 루프문, 재귀 호출, virtual 함수가 있으면 인라인 시키지 않는다.
  • 함수 포인터를 이용하면 인라인 시키기 않는다.
  • 라이브러리 설계할때는 바이너리 업그레이드를 제공할 수 없다.
  • 함수 인라인은 작고, 자주 호출되는 함수에 대해서만 하는 것으로 묶어둡시다. 이렇게 하면 디버깅 및 라이브러리의 바이너리 업그레이드가 용이해지고, 자칫 생길 수 있는 코드 부풀림 현상이 최소화되며, 프로그램의 속력이 더 빨라질 수 있는 여지가 최고로 많아집니다.
  • 함수 템플릿이 대개 헤더 파일에 들어간다는 일반적인 부분만 생각해서 이들을 inline으로 선언하면 안 됩니다.

 

항목 31. 파일 사이의 컴파일 의존성을 최대로 줄이자.

  • 표준 라이브러리 구성요소는 전방 선언을 하면 안된다.
  • 정의부에 대한 의존성(dependencies on definitions)을 선언부에 대한 의존성(dependencies on declarations)으로 바꾸는게 컴파일 의존성을 최소화 하는 핵심이다.
    • 객체 참조자 및 포인터로 충분한 경우에는 객체를 직접 쓰지 않습니다.
    • 할 수 있으면 클래스 정의 대신 클래스 선언에 최대한 의존하도록 만듭니다.
    • 선언부와 정의부에 대해 별도의 헤더 파일을 제공합니다.
  • pimpl 관용구("pointer to implementation") 사용. (핸들 클래스 - 구현 클래스)
  • 인터페이스 클래스 사용. 객체 생성 수단이 있어야 한다.( 보통 팩토리 함수 사용(가상 생성자) )
  • 인라인 함수를 쓰지 못한다.
  • 구현부가 바뀌었을때 사용자에게 미칠 파급 효과를 최소로 만들수 있다.
  • 컴파일 의존성을 최소화하는 작업의 배경이 되는 가장 기본적인 아이디어는 '정의' 대신에 '선언'에 의존하게 만들자는 것입니다. 이 아이디어에 기반한 두 가지 접근 방법은 핸들 클래스와 인터페이스 클래스입니다.
  • 라이브러리 헤더는 그 자체로 모든 것을 갖추어야 하며 선언부만 갖고 있는 형태여야 합니다. 이 규칙은 템플릿이 쓰이거나 쓰이지 않거나 동일하게 적용합니다.

 

 

이 글은 스프링노트에서 작성되었습니다.

04장. 설계 및 선언

항목 18. 인터페이스 설계는 제대로 쓰기엔 쉽게, 엉터리로 쓰기엔 어렵게 하자

  • 인터페이스를 설계할 때 최소한의 제약 ( 타입, ... )을 갖자. (?)
  • 좋은 인터페이스는 제대로 쓰기에 쉬우며 엉터리로 쓰기에 어렵습니다. 인터페이스를 만들때는 이 특성을 지닐 수 있도록 고민하고 또 고민합시다.
  • 인터페이스의 올바른 사용을 이끄는  방법으로는 인터페이스 사이의 일관성 잡아주기, 그리고 기본 제공 타입과의 동작 호환성을 유지하기가 있습니다.
  • 사용자의 실수를 방지하는 방법으로는 새로운 타입 만들기, 타입에 대한 연산자 제한하기, 객체의 값에 대한 제약 걸기, 자원 관리 작업을 사용자 책임으로 놓지 않기가 있습니다.
  • tr1::shared_ptr은 사용자 정의 삭제자를 지원합니다. 이 특징 때문에 tr1::shared_ptr은 교차 DLL문제를 막아주며, 뮤텍스 등을 자동으로 잠금 해제하는데 쓸수 있습니다.

 

항목 19. 클래스 설계는 타입 설계와 똑같이 취급하자.

  • 좋은 타입은 문법이 자연스럽고, 의미구조(semantics)가 직관적이며, 효율적인 구현이 한가지 이상 가능해야 한다.
  • 타입 설계시 고려할 사항
    • 새로 정의한 타입의 객체 생성 및 소멸은 어떻게 이루어져야 하는가?
    • 객체 초기화는 객체 대입과 어떻게 달라야 하는가?
    • 새로운 타입으로 만든 객체가 값에 의해 전달되는 경우에 어떤 의미를 줄 것인가?
    • 새로운 타입이 가질 수 있는 적법한 값에 대한 제약은 무엇으로 잡을 것인가?
    • 기존의 클래스 상속 계통망(inheritance graph)에 맞출 것인가?
    • 어떤 종류의 타입 변환을 허용할 것인가?
    • 어떤 연산자와 함수를 두어야 의미가 있을까?
    • 표준 함수들 중 어떤 것을 허용하지 말 것인가?
    • 새로운 타입의 멤버에 대한 접근권한을 어느 쪽에 줄 것인가?
    • '선언되지 않은 인터페이스'로 무엇을 둘 것인가?
    • 새로 만드는 타입이 얼마나 일반적인가? ( 일반화  template )
    • 정말로 꼭 필요한 타입인가?
  • 클래스 설계는 타입 설계입니다. 새로운 타입을 정의하기 전에, 이번 항목에 나온 모든 고려사항을 빠짐없이 점검해 보십시오.

 

항목 20. '값에 의한 전달'보다는 '상수객체 참조자에 의한 전달'방식을 택하는 편이 대개 낫다.

  • 기본적으로 함수에 객체를 전달할 때 '값에 의한 전달' 방식을 사용한다. (C에서 물려받은 특성)
  • 값에 의한 전달인 경우 복사 생성자, 소멸자 를 호출하기 때문에 효율이 떨어진다.
  • 참조에 의한 전달방식은 복사손실 문제가  없어지는 장점도 있다.
  • 참조자는 내부적으로 포인터 사용.
  • 반복자, 함수 객체 만들때 규칙
    • 복사 효율을 높일것
    • 복사손실 문제에 노출되지 않도록 만드는 것
  • 사용자 정의 타입은 참조 전달을 사용하자.
    • 기본 타입과 사용자 정의 타입은 아예 다른게 취급 되는 경우도 있다 ( 이럴경우 4byte 객체라고 하더라도 참조로 전달하자. )
    • 사용자 정의 타입은 언제든 변화에 노출되어 있다.
  • 기본 제공 타입, STL 반복자, 함수 객체 타입 이외에는 참조 전달 방식을 사용하라.
  • '값에 의한 전달'보다는 '상수 객체 참조자에 의한 전달'을 선호합시다. 대체적으로 효율적일뿐만 아니라 복사손실 문제까지 막아 줍니다.
  • 이번 항목에서 다룬 법칙은 기본제공 타입 및 STL 반복자, 그리고 함수 객체 타입에는 맞지 않습니다. 이들에 대해서는 '값에 의한 전달'이 더 적절합니다.

 

 

항목 21. 함수에서 객체를 반환해야 할 경우에 참조자를 반환하려고 들지 말자.

  • 참조자는 객체(인스턴스)에 또 다른 이름일 뿐이다.
  • 지역 객체의 포인터나 레퍼런스를 반환 하지 마라. ( 리턴할 때 객체가 사라진다. 쓰레기 주소 반환 )
  • 새로운 객체를 반환하게 만들자. (반환값 최적화[return value optimization] RVO)
  • 지역 스택 객체에 대한 포인터나 참조자를 반환하는 일, 혹은 힙에 할당된 객체에 대한 참조자를 반환하는 일, 또는 지역 정적 객체에 대한 포인터나 참조자를 반환하는 일은 그런 객체가 두 개 이상 필요해질 가능성이 있다면 절대로 하지 마세요.

 

항목 22. 데이터 멤버가 선언될 곳은 private 영역임을 명심하자.

  • 문법적 일관성. 어떤 객체에 접근 할 수 있는 유일한 수단은 멤버 함수이다.
  • 세밀한 접근 제어. 캡슐화.
  • 클래스의 불변성 및 사전조건, 사후조건을 검증할 수 있다. [무결성]  ( delphi, C# - property )
  • protected 도 public 과 다르지 않다. 캐슐화 되지 않았다.
  • 데이터 멤버는 private 멤버로 선언합시다. 이를 통해 클래스 제작자는 문법적으로 일관성 있는 데이터 접근 통로를 제공할 수 있고, 필요에 따라서는 세밀한 접근 제어도 가능하며, 클래스의 불변속성을 강화할 수 있을 뿐 아니라, 내부 구현의 융통성도 발휘할 수 있습니다.
  • protected는 public보다 더 많이 '보호'받고 있는 것이 절대로 아닙니다.

 

항목 23. 멤버 함수보다는 비멤버 비프렌드 함수와 더 가까워지자.

  • 비멤버 함수를 사용하면 패키징 유연성이 높아지는 장점이 있으며, 추가적으로 컴파일 의존도도 낮추고 확장성을 높일 수 있습니다.
  • 캡슐화하면 유연성(융통성)이 증가한다. ( 당연 -_-; )
  • 꼭 비멤버 비프렌드이여야 한는것 아니고, 그 클래스의 private 멤버의 캡슐화에 영향을 주지 않는다는 점이 중요하다.
  • 이런한 편의 함수들을 같은 네이스페이스의 함수로 만들면 더 자연스럽다.
  • 네임스페이스로 할 경우, 여러개의 소스 파일로 나누어 만들수 있는 장점도 있다. ( C++ standard library )
  • 클래스 하나를 나누어 구현 할수 없다. ( C# 가능 )
  • 멤버 함수보다는 비멤버 비프렌드 함수를 자주 쓰도록 합시다. 캡슐화 정도가 높아지고, 패키징 유연성도 커지며, 기능적인 확장성도 늘어납니다.

 

항목 24. 타입 변환이 모든 매개변수에 대해 적용되어야 한다면 비멤버 함수를 선언하자.

  • 암시적 타입변환은 꼭 필요한 곳에 사용하자.
  • 멤버 함수의 반대는 프렌드 함수가 아니라 비멤버 함수이다.
  • 어떤 함수에 들어가는 모든 매개변수(this 포인터가 가리키는 객체도 포함해서)에 대해 타입 변환을 해 줄 필요가 있다면, 그 함수는 비멤버이어야 합니다.

 

항목 25. 예외를 던지지 않는 swap에 대한 지원도 생각해 보자.

  • 표준 라이브러리 swap 알고리즘.
  • pimpl (pointer to implementation) 기법을 사용하면 설계, 비용 모두 좋다.
  • 완전 템플릿 특수화(total template specialization)를 이용하라.
  • C++은 클래스 템플릿에 대해서는 부분 특수화(partial specialization)는 허용하지만 함수 템플릿에 대해서는 허용하지 않는다.
  • 인자 기반 탐색(argument-dependent lookup) 혹은 쾨니그 탐색(koenig lookup).
  • namespace를 사용하라.
  • 특수화 버전을 만들었을 수도 있기때문에 호출문에 한정자를 쓰지 말자.
  • 강력한 예외 안전성 보장(strong exception-safety guarantee)을 제공하자.
  • std::swap이 여러분의 타입에 대해 느리게 동작할 여지가 있다면 swap 멤버 함수를 제공합시다. 이 멤버 swap은 예외를 던지지 않도록 만듭시다.
  • 멤버 swap을 제공했다면, 이 멤버를 호출하는 비멤버 swap도 제공합시다. 클래스(템플릿이 아닌)에 대해서는 std::swap도 특수화해 둡시다.
  • 사용자 입장에서 swap을 호출할때는, std::swap에 대한 using 선언을 넣어 준후에 네이스페이스 한정 없이 swap을 호출합시다.
  • 사용자 정의 타입에 대한 std 템플릿을 완전 특수화하는 것은 가능합니다. 그러나 std에 어떤 것이라도 새로 '추가'하려고 들지는 마십시오.

이 글은 스프링노트에서 작성되었습니다.

03장. 자원 관리

항목 13. 자원 관리에는 객체가 그만!

펼쳐두기..


 

항목 14. 자원 관리 클래스의 복사 동작에 대해 진지하게 고찰하자.

펼쳐두기..

 

항목 15. 자원 관리 클래스에서 관리되는 자원은 외부에서 접근할 수 있도록 하자.

펼쳐두기..


항목 16. new 및 delete를 사용할 때는 형태를 반드시 맞추자.

펼쳐두기..


 

항목 17. new로 생성한 객체를 스마트 포인터에 저장하는 코드는 별도의 한 문장으로 만들자.

  • new 로 생성한 객체를 스마트 포인터로 넣는 코드는 별도의 한 문장으로 만듭시다. 이것이 안 되어 있으면, 예외가 발생될 때 디버깅하기 힘든 자원 누출이 초래될 수 있습니다.

 

 

이 글은 스프링노트에서 작성되었습니다.

02장. 생성자, 소멸자 및 대입 연산자

항목 5. C++가 은근슬쩍 만들어 호출해 버리는 함수들에 촉각을 세우자.

  • 컴파일러는 경우에 따라 기본 생성자, 복사 생성자, 복사 대입 연산자, 소멸자를 암시적으로 만들수 있다.

 

항목 6. 컴파일러가 만들어낸 함수가 필요 없으면 확실히 이들의 사용을 금해 버리자.

  • private : 복사 생성자와 대입 연산자를 명시적으로 선언하자. ( 구현은 빼자. friend 객체, 함수에서 호출이 가능해진다. )
  • boost::noncopyable 같이 기본 클래스로 만들어 놓을수도 있다. ( 이러면 컴파일 타임에 에러가 난다  )
  • 사용하지 않는 멤버 함수는 private으로 선언하고 구현 하지 말자.

 

  • 카피 하지 말아야 할껏?? 자원관리 객체(복사 처리 되도록 참조 카운트를 사용할 경우는 상관 없음), singleton 객체

 

항목 7. 다형성을 가진 기본 클래스에서는 소멸자를 반드시 가상 소멸자로 선언하자.

  • 파생 객체를 기본 클래스의 포인터를 통하여 삭제될 때 그 기본 클래스가 비가상 소멸자를 가지면 부분 소멸(partially destroyed)가 발생한다.
  • 다형성을 지원하는 기본 클래스로 쓸려는 의도가 아니면 소멸자를 virtual로 하지 말라. ( 다른 언어 호환성 X, 메모리 낭비 )
  • 순수 가상 소멸자는 정의도 해줘야한다.?? ( -_-;; 링크 에러 발생 )

 

항목 8. 예외가 소멸자를 떠나지 못하도록 붙들어 놓자.

  • 소멸자에서 예외 처리
    • 프로그램 종료
    • 예외 삼키기
  • 예외는 "소멸자가 아닌 다른 함수에서 비롯된 것이어야 한다." 가 포인트.
  • assert 를 활용하면 예외를 초기에 잡을수 있다 (적극 활용하자)

 

항목 9. 객체 생성 및 소멸 과정 중에는 절대로 가상 함수를 호출하지 말자.

  • 생성자 혹은 소멸자 안에서 가상 함수를 호출하지 마세요. 가상 함수라고 해도, 지금은 실행중인 생성자나 소멸자에 해당되는 클래스의 파생 클래스 쪽으로는 내려가지 않으니까요.

 

항목 10. 대입 연산자는 *this의 참조자를 반환하게 하자.

  • 대입 연산자는 *this 참조자를 반환하도록 하자.

 

항목 11. operator=에서는 자기대입에 대한 처리가 빠지지 않도록 하자.

  • operator = 을 구현할 때, 어떤 객체가 그 자신에 대입되는 경우는 제대로 처리하도록 만듭시다. 원본 객체와 복사 대상 객체의 주소를 비교해도 되고, 문장의 순서를 적절히 조절할 수도 있으면, 복사 후 맞바꾸기 기법을 써도 됩니다.
  • 두 개 이상의 객체에 대해 동작하는 함수가 있다면, 이 함수에 넘겨지는 객체들이 사실 같은 객체인 경우에 정확하게 동작하는지 확인 하세요.

 

항목 12. 객체의 모든 부분을 빠짐없이 복사하자.

  • 복사한는 함수는  복사 생성자복사 대입 연산자 두개.
  • 객체 멤버 변수(field)가 추가 될때 마다 위의 두 함수를 같이 업데이트 해줘야한다.
  • 파생된 객체일 경우에 기본 클래스의 함수들도 호출해 줘야한다.
  • 객체 복사 함수는 주어진 객체의 모든 데이터 멤버 및 모든 기본 클래스 부분을 빠뜨리지 말고 복사해야 합니다.
  • 클래스의 복사 함수 두 개를 구현할 때, 한쪽을 이용해서 다른 쪽을 구현하려는 시도는 절대로 하지 마세요. 그 대신, 공통된 동작을 제3의 함수에다 분리해 놓고 양쪽에서 이것을 호출하게 만들어서 해결합시다.

 

 

이 글은 스프링노트에서 작성되었습니다.

01장. C++에 왔으면 C++의 법을 따릅시다.

항목 1. C++을 언어들의 연합체로 바라보는 안목은 필수

  • C
  • 객체 지향 개념의 C++
  •  템플릿 C++
  • STL
  • C++을 사용한 효과적인 프로그래밍 규칙은 경우에 따라 달라집니다. 그 경우란, 바로 C++의 어떤 부분을 사용하느냐입니다.

항목 2. #define을 쓰려거든 const, enum, inline을 떠올리자.

  • #define은 기호테이블에 안들어간다. (디버깅시 헷갈릴수 있다.)
  • #define은 유효범위가 없다. ( 상수 데이터(const, enum) 멤버는 캡슐화가 된다. )
  • enum은 #define처럼 쓸데없는 메모리 할당도 절대 저지르지 않는다.
  • #define 매크로는 간혹 골치 아픈 괴현상을 일으킨다.
  1. #define CALL_WITH_MAX(a, b) f((a) > (b) ? (a) : (b))
  2. CALL_WITH_MAX(++a, b);
  • inline은 매크로의 효율을 유지하면서 정규 함수의 모든 동작방식 및 타입안정성을 갖추었다.
  • 단순한 상수를 쓸 때는, #define 보다 const, enum을 우선 생각하자.
  • 함수처럼 쓰이는 매크로를 만들려면, inline 함수를 우선 생각하자.
  •  

항목 3. 낌새만 보이면 const를 들이대 보자!

  • 의미적인 제약을 줄 수 있다.
  • 상수 멤버 함수
    • 상수 객체가 호출 할 함수
    • 클래스의 인터페이스를 이해하기 좋게 해준다. (작성자의 의도 파악)
    • C++에서는 "상수 객체에 대한 참조자"가 실행 성능을 높여준다.
    • 비트수준 상수성(bitwise constness) [물리적 상수성(physical constness)]
      • 객체를 구성하는 비트들 중 어떤 것도 바꾸면 안된다는 것.
    • 논리적 상수성(logical constness)
      • 비트수준 상수성 대체 개념으로 일부 몇 비트 정도는 바꿀수 있다. 그것을 사용자 측면에서 알아채지 못하게만 하면 상수 멤버 자격이 있다.
  • mutable 키워드
    • 어떠한 순간에도 수정 가능하다. (상수 멤버 함수에서도 사용가능)
  • 비상수 멤버 함수가 상수 멤버 함수를 호출하고 const를 떼어내어 코드 중복을 피하자.
  • const를 붙여 선언하면 컴파일러가 사용자의 에러를 잡아내는데 도움을 줍니다.
  • 컴파일러 쪽에서 보면 비트수준 상수성을 지켜야 하지만, 여러분은 개념적인(논리적인) 상수성을 사용해서 프로그래밍해야 합니다.
  • 상수 멤버 및 비상수 멤버 함수가 기능적으로 서로 똑같게 구현되어 있을 경우에는 코드 중복을 피하는 것이 좋은데, 이때 비상수 버전이 상수 버전을 호출하라.

 

항목 4. 객체를 사용하기 전에 반드시 그 객체를 초기화하자.

  • 그 객체의 모든 것을 초기화하자!
  • 대입(assignment)와 초기화(initialization)를 헷갈리지 말자. (더 효율적)
  • 상수이거나 참조자 데이터 멤버의 경우엔 반드시 초기화되어야 한다.
  • 객체를 구성하는 데이터 초기화 순서
    • 기본 클래스 -> 파생 클래스
    • 클래스 데이터 멤버는 선언된 순서대로 초기화
  • 정적 객체의 초기화 순서는 개별 번역 단위에서 이루어진다.
    • 전역 객체, 네임스페이스 유효 범위에 정의된 객체, static 멤버 객체,  static 지역 객체(지역 정적 객체), static 파일 유효 범위 객체
    • 번역 단위 : 소스의 언어를 기계어로 옮긴다는 의미. 그 파일이 #include한 파일까지 합쳐서 하나의 단위
    • 비지역 정적 객체들 사이의 상대적인 초기화 순서는 정해져 있지 않다.
    • 단일체 패턴(Singleton pattern)으로 대신하자.
    • 지역 정적 객체는 함수 호출중 그 객체의 정의에 최초로 닿았을때 초기화되도록 C++보장한다.
    • 다중 쓰레드 프로그램에서는 다중 쓰레드로 돌입하기 전에 정적 객체를 초기화 하자. (초기화 경쟁 상태 문제 방지)
  • 기본제공 타입의 객체는 직접 손으로 초기화합니다. 경우에 따라 저절로 되기도 하고 안 되기도 하기 때문이다.
  • 생성자에서는 초기화 리스트를 즐겨 사용하자. 그리고 초기화 리스트의 순서는 멤버가 선언된 순서와 똑같이 나열하자.
  • 여러 번역 단위에 있는 비지역 정적 객체들의 초기화 순서 문제는 피해서 설계해야 한다. 지역 정적 객체로 바꾸어라.

 

  • 암시적 템플릿 인스턴스화???

이 글은 스프링노트에서 작성되었습니다.

2009년 5월 16일 토요일

편하게 전기밥솥으로 플레인 요구르트 만들기

전기밥솥으로 편하게 플레인 요구르트를 만드는 법을 알려드릴게요..^^

제가 해본 결과 맛나서 알려드려요..ㅎ

기존에 갖고 있는 요구르터가 플라스틱이라서, 아무래도 몸에 안좋을 거 같아서,

유리케이스로 만들고 싶었는데요.. 새로 사자니 돈이 들자나요..

그래서 나름 찾아보고 테스트 해본 결과 입니다.

준비물 : 우유 1리터(혹은 900밀리리터, 보통 일반 우유를 쓰라고 하더라고요 저도 그랬고요.), 불가리스(캡슐 등등은 안됨) 1개, 나무숟가락 혹은 젓가락
주의 사항 : 쇠 제품은 사용하지 않습니다. 유산균 파괴 가능성이 있으니깐요, 보온 중에는 전기밥솥을 열거나, 이동 및 충격을 주지 않습니다. 보온 중에는 전기밥솥을 열어보지 않습니다.
예상 비용 : 우유 1리터( 저렴한 1,590원) , 불가리스(마트에서는 묶음판매라서 편의점에서 이통사 멤버쉽 카드로 할인해서, 1,020원)  

=======================================================
1. 우유와 불가리스를 잘 섞는다.

2. 적당량의 그릇에 나눠 담는다.( 저는 머그잔이나, 글라스락 같은 것에 나눠 담습니다)

3. 전기밥솥 안에 2를 넣습니다.( 머그잔이나 글라스락은 뚜껑덮지 않고 넣어줍니다. 혹은 랩을 씌우고 구멍 몇개 뚫기)

4. 보온, 휴지(보온 취소 후 그대로 두기) 를 반복합니다.
4-1. 1시간 보온, 3시간 휴지, 50분 보온 후 바로 꺼내서 냉장고에 보관합니다.  이와 같이 할 경우, 만들어지는 플레인 요구르트는 신맛이 덜하고, 고소한 상태가 됩니다.
4-2. 1시간 보온, 7시간 휴지, 1시간 보온 후 바로 꺼내서, 냉장고에 보관합니다. 이와 같이 할 경우, 만들어지는 플레인 요구르트는 신맛이 좀더 강하게 됩니다.
4-3. 위의 과정이 끝나고 나서 보면, 아직은 연두부 마냥 흔들면 흔들릴 정도입니다. 이 상태에
에서, 바로 냉장고에 넣어두고 5시간 정도 지나면, 이젠 찰진 요구르트가 됩니다.
4-4. 위의 4-1 혹은 4-2 중 맘에 드는 방법대로 하시면 됩니다. 보온 시, 주의 하실 것은, 유산균
은 40도 정도에서 활성화 되지만 넘어서면 죽는다고 합니다. 그러니 전기밥솥은 60~70
도 정도 된다고 하니 너무 오랫동안 보온을 하시면, 유산균이 죽어서 찰지게 안될수도 있어
요. 주의하세요 ㅎ

만들어진 요구르트에 유청(맑은 물)이 생기는데, 그것은 영양소가 많다고 하니 버리시 마시고 드시든, 맛사지 등으로 사용하시면 될 거 같아요

=======================================================

원래는 저도 4-1로 하려고 했습니다. 그런데 ㅎㅎ 잠드는 바람에 휴지를 7시간이나 시켰지뭐예요
그래두 마지막까지 해본 결과 너무나도 제 스타일에 딱 맞았습니다.ㅎㅎ

4-1도 해봤었지만, 쨈이나 그런것 추가 안하고 그냥 드실 분은 4-1이 좋을거 같고요.
약간 추가해서 신맛도 즐기시려면 4-2가 좋을거 같아요 ㅎㅎ

너무 쉬운거라서, 과정 샷은 없고요..
만들어서, 먹던 샷을 올리도록 할게요

4-2로 했을경우, 너무나도 찰지고 ㅎㅎ 새콤달콤하니 좋더라구요 ^-^

처음에 4-1로 했을 때, 의외로 지켜봐야 하는 시간이 길어서 나름 걱정이였거든요..
근데 4-2가 좋은 이유가.ㅎㅎ 저녁에 자기 전에 씻을 때, 1시간 보온 후에 보온 취소해놓고,
그냥 자면 7시간이 그냥 지나가자나요 ㅎㅎ
그러고 아침에 일어나자마 1시간 보온을 시켜놓고 출근전에, 냉장고에 딱 두고 나가면 ㅎ
귀가 후에 바로 먹을 수 있어서 좋더라구요..^-^

즐겁고 저렴하며 편한 플레인 요구르트로 함께해요 ㅎㅎㅎ

플레인 요구르트 by Grace

2009년 5월 14일 목요일

iphone 관련 사이트 모음