뻔뻔한블로그

매개변수

• Center: The center location of the sphere in the game world.
• Radius: The radius of the sphere.
• Segments: The number of segments used to approximate the sphere’s surface.
• Color: The color of the sphere.
• PersistentLines: Whether the sphere’s lines should persist between frames.
• LifeTime: The amount of time the sphere should remain visible, in seconds.
• DepthPriority: The priority of the sphere’s depth in the rendering pipeline.
• Thickness: The thickness of the lines used to draw the sphere.

	DrawDebugSphere(GetWorld(), GetActorLocation() + FVector(0, 0, 200),
		100.f,12, FColor::Red, true,30.f);

GetHitResultUnderCursor

Trace Hit

void ATank::Tick(float DeltaTime)
{
	Super::Tick(DeltaTime);

	if(PlayerControllerRef)
	{
		FHitResult HitResult;
		PlayerControllerRef->GetHitResultUnderCursor(ECC_Visibility, false, HitResult);
		DrawDebugSphere(GetWorld(), HitResult.ImpactPoint,
	25.f,12, FColor::Red, false,-1.f);
	
	}
}

참고
https://agrawalsuneet.github.io/blogs/drawdebugsphere-in-unreal/

CreateDefaultSubobject :

생성자에서만 실행가능

템플릿으로 <>안에 사용할 컴포넌트를 넣어줌

TEXT()

각각의 컴포넌트를 구분하기 위한 값이 들어간다.

해쉬 값을 생성하기 때문에, 다른 TEXT와 겹치면 안된다.

하위 클래스 셋팅하기

EditDefaultsOnly

default 편집에서만 수정가능

EditInstanceOnly

인스턴스에서만 편집가능

BlueprintReadWrite

블루프린트에서 접근 가능

AllowPrivateAccess = "true"

BlueprintReadWrite 키워드를 썼기 때문에 접근제한자 private에서도 사용 불가능하지만.

AllowPrivateAccess  = "true"로 사용 가능하도록 할 수 있다.

Category = "Super Duper ~~"

설정한 카테고리 이름으로 블루프린트에서 검색이 가능하다.

단순히 솔루션 탐색기에서  delete를 해도 완전히 삭제되지 않는다.

1. 언리얼 에디터 종료

2. 솔루션탐색기 에서 제거

3. 프로젝트 폴더에에서 클래스 삭제

4.솔루션 재빌드

VisibleAnywhere

블루프린트에서 보이지만 수정 불가능

EditAnywhere

블루프린트에서 수정가능한 필드

VisibleInstanceOnly

블루프린트에 detail창에는 보이지 않지만 Main 배치한 인스턴스에서만 보인다.

기억할 내용

- "이 애플리케이션을 외국에서 사용하는 일은 절대 없을 텐데 뭐하러 국제화하지?, "count는 음수가 될 수 없어," 로깅은 실패할 리 없어" 이런 식으로 자신을 기만하지 말자, 특히 코딩할때는

- 단정문으로 불가능한 상황을 예방하라

- 물론 그런 일은 절대일어나지 않을 거야' 라는 생각이 든다면 그런 일을 확인하는 코드를 추가하라

- 하지만 오류 처리를 해야 하는곳에 단정을 대신 사용하지는 말라

- 첫 번째 방어선은 가능한 오류를 검사하는 것이고, 그 다음은 그러고 놓친 것을 잡아내기 위해 단정을 사용하는 것이다.

- 프로그램을 출시할 때 단정기능을 꺼 버리는 것은 줄타기 곡예를 하면서 연습으로 한 번 건너 봤다고 그물 없이 건너는 것과 비슷하다.

느낀 점

 실제 서비스를 할때는 예상치 못한 여러가지 이슈가 발생하게된다. 게임은 특히 여러사람들이 동시에 접속하고 상호작용하는 부분들이 많기 때문이다. 그래서 크래시리포트등 발생시점에 기록을 남기는 편이다. 마찬가지로 이러한 부분을 잡아내는데 필요한 방법인것 같다. 절대로 일어날리 없다고 생각했지만 일어난다. 이 단정은 디버깅요소로 활용할 수 있다.

Topic 24 죽은 프로그램은 거짓말을 하지 않는다.

기억할 내용

- '있을 수 없는 일'이 발생했을 때 우리는 그 사실을 알아야 한다. '그런 일은 절대 일어날 리 없어'라는 사고에 빠지기 쉽다.

- 망치지 말고 멈춰라 : 가능한 한 빨리 문제를 발견하면 좀 더 일찍 시스템을 멈출 수 있으니 더 낫다. 

- 어떤 환경에서는 실행 중인 프로그램을 그냥 종료해 버리는 것이 적절하지 못할 수도 있다.(해제되지 않은 리소스, 로그메시지 기록, 트랜잭션 정리, 등)

- 이상 발생하면 이 시점 이후로 하는 일은 모두 수상쩍은 게 된다. 되도록 빨리 종료시키자.

느낀 점

 여기서 말하고자 하는 것은 이슈가 발생하면 그 상황에서 이상하게 통과시키지 말고 그 즉시 종료시키라고 한다. 한번 이슈가 발생된 이후에는 원인 모를 이슈가 계속해서 발생할 수 있기 때문이다. 그렇다고 무조건적으로 종료만 시키는 것은 능사가 아니다. 실제 서비스하고 있는 코드라면 로그를 잡고 프로그램이 죽지 않도록 하게 할 때도 있다. 

Topic 23 계약에 의한 설계

기억할 내용

- 수천 년간 우리가 얻은 해법 중 몇 가지는 소프트웨어를 만드는 데에도 적용할 수 있다. 정직한 거래를 보장하는 최선의 해법 중 하나는

'계약'이다.

- DBC : 계약에 의한 설계(Design By Contrac)

- 정확한 프로그램이란 ...많지도 적지도 않게 딱 그만큼만 하는 프로그램

- 예상이 되는 프로그램

- 선행조건 : 루틴의 선행 조건이 위반된 경우에는 루틴이 호출되어서는 안 된다.

- 후행조건 : 루틴이 자기가 할 것이라고 보장하는 것

- 클래스 불변의 법칙 : 호출자의 입장에서 볼 때는 이 조건이 언제나 참인 것을 클래스가 보장한다.

- tip37 계약으로 설계하라

- '게으름뱅이코드' 수용할 것은 엄격하게 확인하고, 내어 줄 것에 대해서는 최소한도를 약속하는 것이다.

- DBC 구현 : 코드를 작성하기 전에 유요한 입력범위가 무엇인지, 경계 조건이 무엇인지, 루틴이 뭘 전달한다고 약속하는지, 혹은 더 중요하게는 생각하는 무엇을 약속하지 않는지 등을 나열하는 것만으로도 더 나은 소프트웨어를 작성하는데 큰 도움이 된다.

느낀 점

 이번주제는 소프트웨어를 설계할 때 조건을 걸면서 좀 더 안정된 설계가 가능하다는 말인 것 같다. 프로젝트가 길어지면서 다양한 함수와 복잡해지는 코드가 많아지게 되는데 이러한 계약의 의한 설계를 함으로써 안정된 설계가 필요하다. 요즘에 느끼는 것도 항상 코드를 작성할 때는 규칙이 있어야 한다. 일관성이 있어야 흐름이 예상이 되기 때문이다.

GetOverlappingActors : 액터가져오기

AActor* UTriggerComponent::GetAcceptableActor() const
{
	TArray<AActor*> Actors;
	GetOverlappingActors(Actors);

	for (AActor* Actor : Actors)
	{
		bool HasAcceptableTag = Actor->ActorHasTag(AcceptableActorTag);
		bool IsGarbbed = Actor->ActorHasTag("Grabbed");
		if (HasAcceptableTag && !IsGarbbed)
		{
			return Actor;
		}
	}

	return nullptr;
}

셋팅해놓은 태그가 붙어있고 Grabbed가아니면 액터를 반환.

UPrimitiveComponent : "기본적인 렌더링 기능 컴포넌트 클래스"

void UGrabber::Grab()
{
	UE_LOG(LogTemp, Display, TEXT("Grab"));

	UPhysicsHandleComponent* PhysicsHandle = GetPhysicsHandle();
	if (PhysicsHandle == nullptr)
	{
		return;
	}

	FHitResult HitResult;
	if (GetGrabberableInReach(HitResult))
	{
		UPrimitiveComponent* HitComponent = HitResult.GetComponent();
		HitComponent->SetSimulatePhysics(true);
		HitComponent->WakeAllRigidBodies();
		AActor* HitActor = HitResult.GetActor();
		HitActor->Tags.Add("Grabbed");
		HitActor->DetachFromActor(FDetachmentTransformRules::KeepWorldTransform);
		PhysicsHandle->GrabComponentAtLocationWithRotation(
			HitResult.GetComponent(),
			NAME_None,
			HitResult.ImpactPoint,
			GetComponentRotation()
		);
	}
}

HitActor->Tags.Add("Grabbed"); : 동적으로 Tag추가

HitActor->DetachFromActor(FDetachmentTransformRules::KeepWorldTransform); : Actor의 RootComponent를 현재 연결되어 있는 모든 SceneComponent에서 분리

석상이 놓여있으면 트리거로 인해 철장이 열리고 잡는 순간 다시 철장이 내려옴

같은 속성의 액터오브젝트로 바꿔치기

Topic 22 엔지니어링 일지

기억할 내용

- 일지를 쓰면 좋은 점 3가지

기억보다 더 믿을 만하다

지금 하는 일에 계속해서 집중할 수 있다.

무언가를 쓰기 위해 하던 일을 멈추면 여러분의 뇌도 기어를 바꾼다.

- 수년 전에 여러분이 무엇을 하고 있었는지 돌이켜 볼 수 있다.

-  때때로 수년 전에 여러분이 무엇을 하고 있었는지 돌이켜 볼 수 있다.

- 종이를 사용해라 키보드를 두드리는 것과 다른 무언가 특별한 것이 있다. 

느낀 점

 메모하는 습관이 중요하다는 것은 이미 알고 있지만, 무언가를 쓸 때 뇌는 기어를 바꾸며, 내가 지금 무엇을 하고 있는지 되돌아볼 수 있는 시간이 될 수 있다는 등, 뭔가 머릿속에 추상적으로만 (메모하니까 좋겠지~) 생각했던 것들이 구체적으로 어떤 효과가 있는지 알게 되었다. 

Topic 21 텍스트 처리

기억할 내용

- 프로그래밍에서 텍스트 처리 언어는 목공에서'루터'와 같다. (루터 절단 기계) => 적절히 사용하면 놀라운 효과를 낸다.

- 유틸리티를 뚝딱 만들어 낼 수도있고, 아이디어를 프로토타입해 볼 수도 있다.

- 전통적인 언어를 사용하다보면 다섯 배에서 열 배 가까이 더 오래 걸릴 것이다.

- tip35 텍스트 처리 언어를 익혀라

느낀 점

 이번 주제는 주로 프로그래밍에 사용하는 언어 외에 텍스트 처리 언어를 사용해 업무의 생산성을 높이자 라는 의미가 있다. 여기서 제시한 연습문제에서는 소스파일에서 반복적으로 작업을 하는 기능을 처리하는 스크립트를 만들라 하는데 유용할 것같다. awk, sed에 대해서도 알아봐야겠다.

가고일 석상으로 인해 문이 내려가다가 멈춘다.

이 가고일에 컴포넌트에 접근하여서 물리적용 해제 하기

if (Actor != nullptr)
{
	UPrimitiveComponent* Component = Cast<UPrimitiveComponent>(Actor->GetRootComponent());
	if (Component != nullptr)
	{
		Component->SetSimulatePhysics(false);
	}
    
	Actor->AttachToComponent(this, FAttachmentTransformRules::KeepWorldTransform);
	Mover->SetShouldMove(true);
}

- UPrimitiveComponent`는 Unreal Engine에서 사용되는 주요 컴포넌트 중 하나로, 모든 "기본적인" 렌더링 가능 컴포넌트의 기본 클래스

 - SetSimulatePhysics(bool) 물리 시뮬레이션 on/off

- AttachToComponent : RootComponent를 제공된 구성 요소에 연결

결과

Topic 20 디버깅

기억할 내용

- 디버깅의 심리 : 단지 문제 풀이일 뿐이라는 사실을 받아들이고, 그런 마음으로 공략하라.

- 다른 사람의 버그를 발견 후, 그 버그를 만들어 낸 부정한 범죄자를 비난하는 데에 시간과 노력을 쏟지말고 ... 기술의 전당에서는 남을 비난하기보다 문제를 고치는 데에 집중해야 한다.

- Tip29 비난 대신 문제를 해결하라.

- 버그가 여러분의 잘못인지 다른 사람의 잘못인지는 중요치 않다. 어쨌거나 그 버그를 해결해야 하는 사람은 여러분이다.

- 디버깅 사고 방식 : 가장 속이기 쉬운 사람은 자기 자신이다. - 애드워드 불워 -리턴

- 버그를 목격하거나 버그 신고를 보는 순간의 첫 반응이 '그건 불가능해'라면 여러분은 두말할 필요 없이 틀렸다.'정말 그럴 리가 없는데'로 시작하는 생각의 흐름에 신경 세포 하나도 낭비하지 말라.

- 특정한 증상만 고치지 말고 항상 문제의 근본 원이을 찾으려고 노력 하라

- 실마리 찾기 : 우연에 의해 오도되기 쉽다. 우리는 우연한 사건을 디버깅하느라 시간을 낭비할 여유가 없다. 일단 정확하게 관찰해야 한다. 

디버깅 전략 

- 버그 재현하기 : 재현할 수 없다면 어떻게 그 버그를 고쳤다는 것을 확인할 수 있겠는가?

- Tip31 고치기 전에 실패하는 테스트부터

- Tip32 그놈의 오류메시지 좀 읽어라

- 이상한 결과 : 실패하는 테스트를 이용하여 문제를 재현하라 

- 메모를 하면 도움이 될 때가 많다. 추적을 시작할 때 우리가 어디에 있었는데 메모를 남겨 두지 않았다면 원래 자리로 돌아오느라 시간을 많이 소모했을 것이다.

- 로깅과 트레이싱 : 트레이싱 구문은 '여기까지 도달'이나 'x값 = 2'와 같이 화면 혹은 파일에 출력하는 작은 진단용 메시지를 일컫는다.

- 트레이싱은 여러 프로세스가 동시에 작동하는 경우, 실시간 시스템, 이벤트 기반 애플리케이션 등, 시간 자체가 중요한 요소가 되는 시스템에서 이루 말할 수 없이 소중하다.

- 고무오리 : 문제의 원인을 찾는 방법에는 그냥 누군가에게 설명하는 방법이 있다.

- 문제를 설명하게 되면 혼자 코드를 살펴볼 때는 당연히 여기고 지나갈 것을 명시적으로 이야기해야 한다.

- 소거법 : 사람들이 작성한 애플리케이션 코드, 외부 제품(데이터베이스나 네티워크, 웹 프레임워크, 특화된 통신 방식, 알고리즘 등) 플랫폼 환경(운영체제, 시스템 라이브러리, 컴파일러)이 뒤섞여 있을 것이다. 하지만 처음부터 그런 생각을 하지는 말라

- 발굽 모양을 보면 말을 떠올려야지 얼룩말부터 떠올리지 말라

- 가정하지 말라, 증명하라

느낀 점

 이번 주제는 내용도 많고, 개발할 때 중요하게 생각했던 것들이라 생각된다. 공감이 되는 부분이 꽤나 많았다.  발하다 보면 버그가 발생하는데 이 버그가 누가 만들어 냈는지 궁금할 때가 많은데, 그럴 시간에 문제를 해결하려고 노력하는 것이 맞다. 그리고 다른 사람의 의해 나의 작업물에 버그가 보고 되면 그 부분에서는 그럴 리가 없는 데를 얘기한 내가 부끄러웠다.(그럴 리가 없는데, 발생했잖아). 

버그를 추적할 때 메모장을 사용하기, 누군가에게 설명하기, 로깅과 트레이싱(은 몰랐던 용어라 찾아봄)등 디버깅에 필요한 방법들을 제시해주고 있어 실제로 버그 발생 시 적용해 볼만 것들이 많았다.

Topic 19 버전 관리

기억할 내용

- 버전 관리 시스템은 일종의 거대한 '실행 취소'키와 같다.

- 버그 추적이나, 감사, 성능관리, 품질 관리를 해야 할 때 매우 귀중하다.

- 언제나 버전 관리 시스템을 사용하라

- 혼자서 한 주짜리 프로젝트를 진행하는 경우일지라도, 나중에 '버리기로 한' 프로토타입일지라도, 심지어 열분이 작업하는 것이 소스코드가 아닐지라도, 모든 것을 버전 관리 아래에 둬라. 각종 문서, 전화번호 목록, 외부 업체에 보내는 메모, makefile, 빌드와 릴리스 절차, 로그 파일을 정리하는 작은 셸 스크립트까지 모두 다.

- 브랜치 사용하기

- 

느낀 점

 프로젝트에서 버전관리 시스템은 필수라고 생각한다. 이번 주제에서 '특정 브랜치에서 푸시를 하면 시스템을 빌드하고 테스트를 수행한 다음, 테스트가 성공하면 새로운 코드를 서비스에 배포한다.'라는 내용이 있는데, 현재 회사에서도 이렇게 당연히 진행되어야 하는 반복적인 작업을 자동화 하는 방법을 진행하고 있다. 내가 직접 만들어 본적은 없어서 이런 작업이 어떤식으로 진행되는지 알아 볼 필요가 있어 보였다.

Topic 17셸 가지고 놀기 , Topic 18 파워 에디팅

Topic 17셸 가지고 놀기

기억할 내용

- GUI는~ 자신에게 꼭 맞는 '매크로 도구'를 만들 수 없다.

- GUI에 장점은 WYSIWYG(What You See Is What You Get)보는 것이 여러분이 얻는 것이라면, 단점은 WYSIAYG(Waht You See Is All You Get, 보는 것이 전부다. 111p

- 자신 만의 셸 만들기

- GUI에서 수동으로 하는 작업있으면 자동화할 수 있는 법 알아보기

느낀 점

 수동적인 작업을 할때 자동화를 하고 싶거나, 커스텀한 동작을 단축키 하나로 할 수 있는 방법이 있을까 이런 생각을 한 적이 있었는데, 이 방법이 아닐까 생각이 들었다. 

Topic 18 파워 에디팅

기억할 내용

- 에디터를 유창하게 쓸 쑤 있게 해라

- 유창해지는 것의 가장~ 생각이 자유롭게 흐를 것이고 프로그래밍에 큰 도움이 될 것이다.

- 어떤 것이 '유창'한 것인가.

- 텍스트를 편집할때 문자, 단어, 줄 문단 단위로 커서를 이동하거나 내용을 선택하라

- 코드를 편집할 때 반대쪽 괄호로 이동하거나, 함수, 모듈 등 다양한 문법 단위로 커서로 이동하라

- 변경한 코드의 들여쓰기를 자동으로 맞춰라

- 무엇가 같은 일을 반복하는 것을 발견할 때마다 이렇게 생각하는 습관을 들여라, '분명 더 나은 방법이 있을 텐데.' 그리고 더 나은 방법이 있는지 찾아보라.

- 에디터 성장시키기

- 명백한 한계에 봉착한다면 필요한 기능을 추가하는 확장 기능을 찾아보라

- 사용하는 에디터의 확장 기능 언어를 파헤쳐라 보라. 여러분이 늘 하는 반복적인 일을 자동화할 방법을 연구해 보라

느낀 점

 작업을 할 때 마우스가 아닌 키보드로 화면을 자유재자로 이동하거나 커서를 쉽게 이동하는 사람들이 있다. 키보드와 마우스를 왔다 갔다 하는 시간을 단축시키고, 수동으로 반복적인 일들을 자동화하는 방법으로 작업 능률이 늘어난다고 생각이 들었다. 여기서 제시한 도전 과제를 연습해야겠다는 생각이 들었다.

Topic 16 일반텍스트의 힘 

기억할 내용

- HTML,JSON,YAML,HTTP, SMTP, IMAP 등이 일반텍스트이다. 106p

- 지원 중단에 대한 보험 (형태의 데이터와 그 자체만으로 의미가 드러나는 데이터는 다른 어떤 형태의 데이터보다, 심지어 그 데이터를 생성한 애플리케이션보다 더 오래 살아남을 것이다.) 107p

- 기존 도구의 활용 (버전 관리 시스템에서 에디터, 명령 줄 도구에 이르기까지 컴퓨터 세계의 거의 모든 도구는 일반 텍스트를 다룰 수 있다. 108p

- 더 쉬운 테스트 (시스템 테스트에 합성 데이터를 일반 텍스트로 표현하면 특별한 도구를 만들 필요 없이 간단하게 테스트 데이터를 추가하거나 수정할 수 있다.) 109p

- 최소 공통분모 (널리 퍼져있고, 미래에도 살아 남을 것이다.)
 

느낀 점

 일반 텍스트가 무엇인가 했지만, 사람이 직접 읽고 이해할 수 있는 형태의 인쇄가능한 문자로 이루어진 텍스트를 말하는 것이다. 더 나은 테스트를 하고, 더 쉬운 테스트 환경을 만들기 위해서는 이번 주제와 Topic 17(셀 가지고 놀기)을 잘 다룰 줄 알아야겠다는 생각이 들었다. 하지만 이런 부분도 단점은 존재한다. 보통 포맷형태가 공간을 많이 차지한다. 바로 읽기가 쉬워 보안에는 약할 수 있다. 

Topic 15 추정

기억할 내용

- 추정하는 법을 배우고 측정 능력을 계발하여 ~ 직관적으로 이것이 가능한지 판단할 수 있게 된다. 94p
- 얼마나 정확해야 충분히 정확한가? ~ 무언가를 끝내는 데 근무일 기준으로 약 130일 동안 일해야 한다고 말하면 드는 사람은 실제 소요 기간이 추정과 상당히 비슷하리라 기대할 것이다. 하지만 "아, 대략 6달 정도 걸리겠군요"라고 말하면 지금부터 5~7달 사이 언젠가쯤 끝날 것 이라 여길 것이다. 두 숫자는 같은 기간을 이야기하지만 '130일'은 실제 여러분의 느낌보다 더 정확도가 높으이라는 인상을 풍길 수 있다. 95p
- 추정치는 어디에서 나오는가?
1. 그 일을 해본 사람에게 물어보라
2. 무엇을 묻고 있는지 이해하라
3. 시스템의 모델을 만들어라 ( 기본적인 것만 갖춘 개략적인 모델을 만들어 보라, 조직이 개발하는 동안 사용할 발판, 밑그림이 될것이다.) 97p
4.모델을 컴포넌트로 나눠라
5. 각 매개 변수에 값을 할당하라 (결과에 가장 큰 영향을 미치는 매개 변수를 찾아서 이 매개 변수의 값을 최대한 정확하게 산출해 내는 것이다.) 98p
6. 여러분의 추정 실력을 기록하라 (나중에 이 값이 실제 결과에 얼마나 가까웠는지를 평가해 보면 정말 좋을 것 이다.)
- 프로젝트 일 추정하기
1. 미사일에 페인트 칠하기(숫자 하나로 대답해야만 하는 상황이 아니라면 숫자 하나가 아니라 여러가지 시나리오로 추정한다.)
2. 코끼리 먹기(단계를 작은 단위로 나누어 점증적으로 )
- 계산한 추정치를 기록으로 남겨라. 그리고 각 추정치가 얼마나 정확했는지 기록으로 남겨라. 오차가 50%이상이라면 잘못된 추정치를 내게 된 원인이 무엇인지 찾아보라
 

느낀 점

 실제로 작업을 할때는 일정을 추정하기가 쉽지 않았다. 작업을 진행하다가 예상치못한 요인 코드뿐만 아니라 외부 요인까지..내기 해보진 않은 일이라면 더더욱 어려웠다. 여기서 제시한 방법을 활용하며 일정산정 방법을 가다듬고 결과에 따라 정확도가 얼마나 떨어지는지 점검해보는 연습을 해야겠다. (뭐든지 사실 생각만 하는 것보다는 실제로 적용해보아야 안다.)

Topic 13 프로토타입과 포스트잇

기억할 내용

-  프로토타입 ~ 위험 요소를 노출시킨 후, 이를 매우 저렴한 비용으로 바로잡을 기회를 얻는 것이다. 80p

-  프로토타입은 빠르게 개발할 수 있다.  ~ 여러분에게 당장 중요하지 않은 세부사항이라면 추후에 사용자에게 매우 중요해질지도 모르지만 일단 무시하면서 코딩할 수 있다.

- 세부 사항을 포기할 수 없는 환경에 처해 있다면 진짜로 프로토 타입을 만들고 있는 게 맞는지 자문해 보라.

- 프로토 타입 대상은 ~ 증명되지 않았거나, 실험정이거나, 의심이 가는것, 마음이 편하지 않은 것 모두가 프로토타이핑의 대상이 될 수 있다. 81p

- 프로토타이핑의 가치는 생산한 코드에 있는것이 아니라 이를 통해 배우는 교훈에 있다.

- 아키텍처를 프로토타이핑할 때는 코드를 작성하지 않고 화이트보드, 포스트잇, 인덱스카드 등을 사용해도 된다. 83p

- 프로토타팁임을 모르는 사람에게는 오해를 살 정도로 매력적일 수도 있기 때문에 ~ 이 코드는 폐기할 것이고, 불완전하며, 완성할 수 없다는 사실을 분명히 주지시켜야 한다.

느낀 점

- 이책에서 말하는 예광탄, 프로토타입 각각 장단점이 있고, 요구되는 목적, 특성에 따라 선택이 필요하다. 나는 평소에 프로토타입이라고 생각했지만 예광탄에 가까운 작업을 선 작업을 했던 것 같다. 프로토타입은 없어질 코드이며, 코드는 남지 않고 작업하면서 이를 통해 배우는 교훈에 있다는 말이 포인트라고 생각했다. 

Topic 12 예광탄

기억할 내용

- 프로젝트를 개발할때는 ... 수 많은 미지의 것과 맞닥트리게 된다. 72p

- 어둠 속에서 빛을 내는 코드 : 탄환이 순식간에 목표물에 도달하기 때문에 기관총 사수는 즉각적인 피드백을 얻을 수 있다. 73p

- 요구 사항으로 부터 최종 시스템의 일부 측면까지 빨리, 눈에 보이게, 반복적으로 도달하게 해 줄 무엇인가를 찾아야한다. 

- 예광탄은 한번 쓰고 버리는 코드를 만드는것이 아니다. 75p

- 모든 기능이 들어있지 않을 뿐 / 시스템을 구성하는 요소를 모두 연결해 놓은 후 목표물에 얼마나 근접했는지 확인할 수 있으며. 조정도 가능하다

- 변경 요청과 기능 추가 요청은 언제나 게속 들어오기 마련이다. 76p

- 예광탄 장점 : 1. 사용자가  뭔가 작동하는지 일찍 볼 수 있다. 2. 개발자가 들어가서 일할 수 있는 구조를 얻는다. 3. 통합 작업을 수행할 기반이 생긴다. 4.보여줄 것이 생긴다. 5.진행 상황에 대해 더 정확하게 감을 잡을 수 있다.

- 예광탄 vs 프로토타입 : 예광탄은 기능은 없지만, 완결된 코드이며, 골격이다. 프로토타입은 예광탄을 발사전에 수행하는 정찰이나 정보 수집과 같다. 79p

느낀 점

이번 내용으로 예광탄은 프로젝트 작업을 시작할때 골격을 만드는 시스템구조와 같다고 느꼈다. 프로토타입과 혼동될 수 있지만. 이 둘은 다르며, 장단점을 가지고 있다. 나는 예광탄은 작업을 시작하면 꼭 필요한 작업이라고 생각이들었다. 먼저 골격을 만든 후 살을 (기능) 붙이는 방법이 여러모로 큰 장점을 가지고 있다고 생각했다.

Topic 11 가역성

기억할 내용

- 당신이 가진 생각이 딱 하나밖에 없다면, 그것만큼 위험한 것은 없다. 66p

- DRY원칙, 결합도 줄이기, 외부 설정 사용하기를 따른다면 중요하면서도 되돌릴 수 결정의 수를 가능한 줄일 수 있을 것이다.

- 되돌릴 수 없는 결정을 줄여야 하는 까닭은 우리가 프로젝트 초기에 늘 최선의 결정을 내리지 못하기 때문이다. 68p (많은 외부요인)

- 바닷가의 모래 위에 쓰인 글씨라 생각하라. 언제든지 큰 파도가 글씨를 지워버릴 수 있다.

- Tip18 최종 결정이란 없다. 69p

- 유연한 아키텍처 : 아키텍처, 배포, 외부 제품과의 통합 영역을 유지하는 데에도 관심을 기울일 필요가 있다.

- 누구도 어떤 미래가 펼쳐질지 알 수없다. 70p

느낀 점

프로젝트를 진행하다 보면 예상치 못하는 이슈가 생기기 마련이다. 단순히 코드설계에서만 생기는 것이 아닌, 외부요인들 언제 어디서나 나타나게 된다. 이번 주제에서는 이런 예상치 못한 일들이 생긴다면 그때 어떻게 효율적으로 복귀할 수 있을까, 그리고 왜 그렇게 해야만 하는가를 설명해 주는 내용이었다. 지금까지 거의 반복된 내용이라면 ETC, DRY원칙을 다시 한번 중요하다고 느꼈다. 

• 기억할 내용
  • '직교성' 하나가 바뀌어도 나머지에 어떤 영향도 주지 않으면 서로 직교한다.
  • 비직교적 예시 => 헬리콥터 조종
  • TIP.17 관련 없는 것들 간에 서로 영향이 없도록 하라
  • 직교성의 장점
    생산성 향상 => 자족적인 컴포넌트들을 작성하는 것이 하나의 커다란 코드 덩어리를 만드는 것보다 쉽다.
    리스크 감소 => 위험의 크기를 감소시켜준다. (코드 격리, 테스트 용이 등)
    계층 구조적 설계는 모듈 간에 의존성이 폭증할 위험을 줄인다.
    '특정 기능에 대한 요구 사항을 대폭 변경하는 경우 몇 개의 모듈이 영향을 받는가?'
    코딩 => 코드의 결합도를 줄여라, 전역 데이터를 피하라, 유사한 함수를 피하라
  •  자신이 작성하는 코드를 항상 비판적으로 바라보는 습관을 길러라. 기회가 있을 때마다 코드의 구조와 직교성을 개선하기 위해 노력하라(리팩터링)
  • 단위 테스트를 빌드하고 실행하기 위해 어떤 작업이 필요한가? 나머지 시스템 중 상당 부분을 불러와야 하지는 않는가? 만약 그렇다면 모듈과 나머지 시스템 사이의 결합도를 충분히 줄이지 못했다는 뜻이다.
• 느낀 점
  • 이번 파트에서는 많은 부분에 공감이 됐다. 이미 작업이 끝난 코드에 새로운 기능이 추가될 때나 변경이 될 때 많은 부분을 고려하며 작업을 해야 했었던 경험, 특정 부분을 바꿨을 때 예상치 못한 다른 곳에서 문제가 발생했던 경험, 모듈, 컴포넌트화를 통해 직교성의 장점을 살리며 작업하도록 해야겠다.

문제

변수에 데이터를 추가 후 라이브 코딩을 통해 업데이트 과정을 거친 후 에디어틀 재시작하면 변수가 사라지는 이슈가 있다.

ex) MyInt3이라는 변수에 '500'을 셋팅

에디터 재시작

MyInt3가 사라짐

언리얼 에디터에서 라이브코딩을 하면 MyInt3변수는 복구되나 셋팅한 값이 사라짐.

해결방법

에디터를 닫고 빌드 후 다시 에디터 실행

Solution Explorer에서 Build로 처리

AutoPossessPlayer 설정을 Player0으로 셋팅

AutoPossessPlayer : 레벨이 시작될 때나 폰이 생성될 때, 자동으로 폰을 소유해야하는 플레이어 컨트롤러를 결정

갑자기 블루프린트 창에 아무것도 안뜨는 경우가 있었다. 당황스러운...

해결방법 : window -> class default -> 블루프린트 에디터열기!

안녕하세요.

불판코팅업체 이핌코팅을 소개해드립니다.

삼겹살 고깃집을 운영하는 삼촌에게도 추천해 드렸는데요

이전에 이용하던 재코팅 업체보다 이 핌코팅이 더 꼼꼼하게

코팅되고 더 오래 쓸 수 있다고 하시네요. 고기 굽는 품질도 더 좋아졌다고 합니다. 

고깃집, 또는 그릴석쇠, 타코야끼, 빵팬등 사용하며 가게를 운영하시는 사장님이라면 주목해 주세요!

불판은 맛있는 고기를 굽기 위한 중요한 장비입니다.

그러나 시간이 지남에 따라 불판 표면이 마모되고 부식될 수 있습니다.

이럴 때 이 핌 재코팅 서비스를 이용하면 불판을 새로 구입하지 않고 고기불판을 다시 새롭게 만들 수 있습니다.

이핌 코팅은 입고가 되면 많은 공정 작업이 들어가는데요

제품 입고 -> 열처리 1차 -> 쇼트 -> 열처리 2차 -> 코팅 1차 -> 열처리 3차 -> 코팅 2차 -> 코팅 3차 ->

열처리 4차 -> 코팅 4차 -> 열처리 5차 -> 마블코팅 5차 -> 열처리 6차 -> 포장+출고

저도 재코팅이 엄청 공수가 많이 들어가고 번거로운 작업인지 처음 알았습니다.!!

그리고 이핌 코팅은 서울,경기,인천 지역은 정규직원이 직접수거 및 무료 배송하고 있다고 합니다.

학교오븐팬 재코팅, 식판 연마도 이미 많은 학교에서 이 핌코팅을 이용하고 있다고 합니다!

현재 이핌코팅 첫 주문 10퍼센트 할인 및 무료코팅 이벤트

진행하고 있다고 하니 필요하신 사장님들은 이 핌 코팅 이용해 보세요!

https://smartstore.naver.com/coating_epim

불판, 그리드, 오븐팬, 그리들, 솥뚜껑 등 코팅 입히는 건 모두 가능하다고 합니다. 

• 기억할 내용
  • 효과적인 소통 없이는 아무리 훌륭한 아이디어라도 고립되고 만다. 28p
  • 개발자로서 우리는 여러 입장에서 소통해야 한다.
  • 코드를 작성하는 것은 우리의 의도를 기계에게 전달하는 것이지만, 생각을 기록하여 다음 세대의 개발자들에게 전달하는 것이기도 하다.
  • 청중을 알라. 29p
    • 청중의 요구와 관심, 능력을 이해해야 한다. (어떤 난해한 기술의 장점에 대해 긴 독백을 읊조리는... 단 지껄임 일뿐. 짜증 나는 일이다)
    • 변경 사항을 청중에 따라 각각 다른 방법으로 제시할 수 있다.(ex 영업부, 마케팅, 유지보수팀)
  • 말하고 싶은 게 무언지 알라 30p
    • 말하고자 하는 것이 정확히 무엇인지 생각해 내는 것은 어려운 일이다.
    • 무엇을 말할지 미리 계획하라
  • 때를 골라라
    • 청중이 무엇을 듣기 원하는지 이해하려면 그들의 우선순위를 알아야 한다.
  • 스타일을 골라라
  • 멋져 보이게 하라
  • 청중을 참여시켜라 ( 독자가 문서 초안에 참여하도록 하라) 32p
  • 경청하라
  • 응답하라 33p
  • 문서화 (노력을 중복으로 들이거나 시간을 낭비하지 말고 문서를 늘 손에 닿는 가까운 곳에 두면 된다.)
    • 기계적인 주석은 오히려 코드 유지 보수를 어렵게 만든다(모든 함수, 자료 구조, 타입 정의)
    • 어떻게 동작하는지는 코드가 이미 보여주고 있기 때문에 이런 주석은 사족이다.
    • 코드 주석은 프로젝트에서 쉽게 누락되는 다른 곳에서 문서화할 수 없는 부분을 문서화하기에 최적의 기회다.
• 느낀 점
  • 게임 클라이언트 개발자로서 여러 사람들과 소통하는 경우가 많다. 기획자, 아트, 서버 등등 다양한 사람들과 대화할 때 어떤 식으로 소통해야 하며, 또, 소통에는 문서화를 통해 어떻게 소통하는지도 알게 되었다. 어떻게 보면 뭐든 적극적으로 참여하는 마음이 중요해 보인다. 또 이 책에서는 이번 주제 마지막에서 온라인 의사소통에 예절도 가르쳐 준다.ㅎㅎ

• 기억할 내용
  • 지식에 대한 투자가 언제나 최고의 이윤을 낸다. -벤저민 플랭클린 19p
  • 지식과 경험이야말로 가장 중요하고 날마다 쓰이는 전문가 자산이다.
  • 하지만 불행히도 이 자산은 '기한이 있는 자산' 이다. (빠르게 변화하는 기술 시장) 20p
  • 새로운 것을 배우는 능력은 가장 중요한 전략 자산이다.
  • 지식의 포트폴리오
    • 주기적인 투자 : 정기적으로 이용할 계획을 마련하라
    • 다각화 : 오늘 인기 있는 기술이 내일이면 거의 쓸모없어지거나 그 정도는 아니어도 수요가 없어지기도 한다.
    • 리스크 관리 : 달걀을 한 바구니에 담지 말라
    • 싸게사서 비싸게 팔기
    • 검토 및 재 조정
  • 목표
    • 매년 새로운 언어를 최소 하나는 배워라
    • 기술 서적을 한 달에 한 권씩 읽어라
    • 기술 서적이 아닌 책도 읽어라
    • 수업을 들어라
    • 다른 환경에서 실험해 보라 : 윈도우,리눅스.
    • 요즘 흐름을 놓치지 말라 : 다른 기술을 다루는 뉴스와 온라인 게시물을 읽어라
• 학습의 기회 : 답이 뭔지 전혀 알지 못할 땐 인정하고 거기서 멈추지 말라 24p
• 비판적 사고 : 읽거나 듣는 것에 대해 비판적으로 생각하는 것이다. 25p
  • 왜냐고 다섯 번 묻기
  • 누구에게 이익이 되나?
  • 어떤 맥락인가? (전제 조건은 무엇이고 그 결과의 장기, 단기적 여파는 무엇인가?)
  • 언제 혹은 어디서 효과가 있을까?
  • 왜 이것이 문제인가?

• 느낀 점
  • 지식의 포트폴리오를 쌓아야 한다. 언제 어떤 기술이 트렌드가 될지 모르고 당장 필요가 없어지는 기술이 있을 수 있다. 이것은 아무도 모르기에 항상 준비를 해야 한다. 이번 주제에서는 그것을 준비하는 과정, 방법들이 소개됐다. 당장 없어지고 유망하지 않다고, 가만히 있는 것보다는 그것들을 배우는 과정에서 성장한다는 것이다.