21:09 지금 까지 이해한 포인터의 방법은 주소 사용할때는 & 또는 생략, 값을 사용할때는 *로 이해하고 있습니다. 해당 printf("%s\n", arr[0][0]); 라는 구문에 질문이 있습니다. 포인터 변수로 해당 문자열의 주소를 각 맵핑하였고 배열에 맞게 출력하는걸로 해석이 되는데 이때 왜 값을 안 가져오고 주소를 가져오는지 궁금합니다. 또한 %s로 출력하고 해서 주소대신에 값으로 가져오는지 궁금합니다.
유형 9번에서 처음에 Child obj = new Child(); 의 뜻이 Child 타입의 새로운 생성자를 생성하는 것이고, 이 생성자의 자식 class로 갔는데, 생성자가 없고, 부모에도 생성자가 없어서 출력되는 값은 없는 것이고, 그 뒤의 obj.display()코드를 실행해 display의 메서드에서 부모로부터 상속받아 Parent display, Child display가 답이 되는것이 맞을까요?
안녕하세요. 궁금한게 있어서 질문 드립니다. domain 패키지에 entity를 위치 한다고 했을때 주석이라고 말씀하신 어노테이션 JPA @Entity를 만들어서 Member로 정의 그리고 mongo DB도 필요해서 @Document를 정의해서 domain 패키지에 위치 시켜 Member로 정의 이처럼 같은 도메인이 서로 다른 DB로 사용 될때 어떻게 도메인으로 정의해야할지 궁금합니다. 그리고 이름이 중복되는 현상도 발생하기도 합니다. 그렇다고 OracleMember, MongoMember로 지을수도 없는것같습니다. 제 생각은 Member라는 도메인이 Domain 패지키에 별도로 나와서 adapter 안에 JPA Persistent의@Entity로 정의된 클래스와 Mongo Persistent의 @Document로 정의된 클래스가 위치 되어야한다고 생각하는데 어떤 의견이신지 궁금합니다.
안녕하세요! 18강 전체적으로 cache 에 값을 세팅하기 전후로 lock 이나 semaphore 등을 이용해서 GCD 에서 thread safe 를 구현하는 방법에 대한 예시를 들어준것 확인했습니다 이때 removeAll() 의 앞뒤로는 따로 처리가 되어있지않아서, 정말 필요가 없어서 작성되어있지 않은건지, 아니면 단순 예시라서 여기까지는 적용하지 않은건지 궁금합니다 func clearAll() { cache.removeAll() } 두번째로, 이건 주제와 좀 동떨어진 질문이긴한데요..! (혹시 강의 성격과 너무 벗어났다 싶으면 무시해주세요!) 예시를 NSCache 로 들어주셨는데, NSCache 문서에 보면 캐시를 직접 잠그지 않고도 다양한 스레드에서 캐시에 항목을 추가, 제거 및 쿼리할 수 있다고 나와있는걸 확인했습니다. You can add, remove, and query items in the cache from different threads without having to lock the cache yourself 즉, 문서를 통해 자체적으로 thread safe 하게 뭔가를 하고 있구나..를 유추할 수 있기 때문에 (내부적으로는 NSLock 을 사용하고 있긴하지만요) 이럴때는 저희쪽에서 @unchecked Sendable 만 사용해도 무방할까요? 하지만 이런 문서 등을 확인하지 않는 이상 정확히 NSCache 가 thread safe 하게 뭔가를 처리한다는걸 확인할 수 없기 때문에, 예시처럼 @uncheked Sendable 명시와 동시에 자체적으로 semaphore 나 lock 을 걸어줘야하는건지..? 앨런님은 어떻게 생각하시는지 궁금합니다! 감사합니다~
12강 16분 즘에, Task 의 클로저에 value type 의 프로퍼티를 캡처 리스트로 명시하면 아래와 같은 코드에서는 에러가 나지 않는다고 되어있습니다. struct ValueCounter { var value = 0 mutating func increment() -> Int { value = value + 1 return value } } func test() { var valueCounter = ValueCounter() Task { print(valueCounter.increment()) print(valueCounter.value) } Task { [valueCounter] in var newValueCounter = valueCounter print(newValueCounter.increment()) print(newValueCounter.value) } } 하지만 제가 Xcode 26.0.1 에서 확인했을때는 해당 코드의 첫번째 Task 에서 다음과 같은 컴파일 에러가 발생했습니다 Sending value of non-Sendable type '() async -> ()' risks causing data races 이에 추가로 이것 저것 확인해보다가, 아래와 같이 캡처 리스트를 사용하는 Task 를 먼저 작성하면, 에러가 발생하지 않는것을 확인했습니다. // 캡처 리스트 사용하는 Task 순서 변경하니 정상 func test2() { var valueCounter = ValueCounter() Task { [valueCounter] in var newValueCounter = valueCounter print(newValueCounter.increment()) print(newValueCounter.value) } Task { print(valueCounter.increment()) print(valueCounter.value) } } 이와 같은 현상을 어떻게 설명할 수 있을지 궁금합니다. 첫번째 예시의 두번째 Task 에서는 [valueCounter] in 으로 현재 값을 캡처하려고해도, 이미 첫번째로 정의된 Task 에서 valueCounter.increment() 를 호출하면서 다른 스레드 (편의상) 에서 값을 변경하고 있기 때문에, 동일 시점에 딱 한개의 쓰레드에서의 접근이 깨져서 이런 에러가 발생하는 걸까요? (그렇다기엔 에러 위치는 첫번째 Task 정의에서 떠서... 아닌가 싶기도하고요..) 두번째 예시의 첫번째 Task 에서는 캡처 리스트로 값을 캡처해서 valueCounter.increment() 를 호출하고, 두번째 Task 는 valueCounter.increment() 를 하려고해도 이 시점에서 valueCounter 를 참조하고 있는건 이곳 뿐이기 때문에 (첫번째 Task 에서는 캡처해서 사용), 동일 시점에 딱 한개의 쓰레드에서의 접근이 보장되어서 에러가 발생하지 않는걸까요? 결과를 기준으로 나름대로 고민을 해봤는데, 어쨌든 다 추측이라서.. 혹시 이와 같은 현상을 어떻게 이해하면 될지 궁금합니다 감사합니다.
강의에 보면 확인버튼의 폰트 색상을 화이트로 줄 때 .background() 부분의 상단 또는 하단 측에 스타일을 줘도 된다고 하셨는데요. 하단 측에 .foregroundStyle(Color.white)를 주게 되면 확인 글자가 나타나지 않더라구요. 상단에만 줘야하는 것 아닌지 여쭤 봅니다.
안녕하신가 미스터 KILL-9 항상 빠르고 친절한 답변 고맙다 이번에 회사 로직 작성중에 조금 막막한 부분이 있어 질문 하러 왔다 reader 엑셀 파일 읽어오고 processor 에서 해당 엑셀 데이터 값을 가지고 dao 호출해서 검증하고, 깍고 (가공) 마지막으로 쓰기 처형하는데 작업을 하는데 문제는 가공 단계에서 dao 를 직접 호출하면 ExecutorType 이 simple 로 호출되고 쓰기 단계에서 batch 로 ExecutorType 실행되어 에러가 발생한다 Cannot change the ExecutorType… 이렇게 말이다.. 그래서 일단 아래 코드 처럼 해결은 했어 우선 기존 코드는 PoiItemReader -> ItemProcessor<> (여기서 mybatis dao 호출 해서 검증작업도 함) -> MyBatisBatchItemWriter -> 에러 Cannot change the ExecutorType… 해결한 코드 PoiItemReader -> ItemProcessor<> (여기서 mybatis dao 호출 해서 검증작업도 함) -> JdbcBatchItemWriter-> (해결) 그런데 이렇게 작성해도 되려나 싶네.. 그리고 String 문으로 쿼리 짜는것도 맘에 안들고..ㅠㅠ
- 명백한 한계점 (단점): - 네트워크 대역폭 소모: 실제 데이터를 전송하므로 네트워크 부하가 극심하다. 데이터 건수가 많거나 크기가 크면 통신 자체가 병목이 될 수 있다. ( "핵탄두 데이터 전송에 따른 통신망 과부하 주의!" ) - Manager 읽기 병목: Manager 혼자 모든 데이터를 읽어야 하므로, 읽기 자체가 느리다면 원격 청킹은 효과가 없다. ( "중앙 정찰 위성의 스캔 속도 한계!" ) - 복잡성(감시와 디버깅의 지옥문): 역시 미들웨어(Kafka 등)와 프링 인티그레이션 설정이 필수적이다. 프링 인티그레이션 ->스프링 인티그레이션