레이아웃은 네비게이션을 해도 상태를 유지하고 렌더링을 하지 않는다라고 이해했습니다. 그런데, 오른쪽 레이아웃을 만들면서 패러렐 라우트라던지 template를 쓰지 않고 (비록 컴포넌트를 분리하긴 했으나) 서버에서 데이터를 뿌려주는 미래를 상상하고 쭉 코드를 짜고 계시는 모습을 보면서, 레이아웃이 서버 데이터는 변경사항을 화면에 반영해주는 것처럼 이해가 되었습니다. 뒷부분은 수강하지 않았습니다. 제가 잘못 이해 중인가요?
안녕하세요. 강의 도중 strlen과 sizeof을 비교하는 부분(18분 경)에서 strlen에 대한 질문이 생겨서 글을 작성하게 되었습니다. 직접 3가지 str을 정의하였고, 각 str에 대해 strlen()값을 출력하였더니, 다음과 같았습니다. // 문자열 배열 (NULL 문자 포함 X) char str1[5] = {'H', 'e', 'l', 'l', 'o'}; // 문자열 (NULL 문자 포함 O) char str2[] = "Hello"; // {'H', 'e', 'l', 'l', 'o', '\0'}; char str3[6] = {'H', 'e', 'l', 'l', 'o', '\0'}; printf("strlen(str1) : %d\n", strlen(str1)); printf("strlen(str2) : %d\n", strlen(str2)); printf("strlen(str3) : %d\n", strlen(str3)); 출력되는 결과는 각각 10, 5, 5로 실제 문자형 배열의 크기를 지정한 5를 훨씬 넘어가는 결과가 나왔습니다. 이 결과는 아무래도 마지막 원소로 NULL문자를 넣지 않아서 발생 한 듯 싶은데, 왜 하필 10이 나왔는지 이유가 궁금합니다. 또한, 이럴 경우까지도 고려하여 sizeof를 사용하는 것이 더 바람직한 방법인지 궁금합니다. 마지막으로, 구글링 결과 sizeof의 반환 타입이 size_t이기 때문에 %zu라는 형식 변환자를 사용해야 한다고 하는데, %lu의 경우 보다 자유롭게 대략 long int로 판별될 경우 사용하면 되는 것인지도 궁금합니다. C언어에서 타입을 지정하는 것이 굉장히 중요한 것 같은데, %lu로 퉁쳐도(??) 되는 것인지, 그 판단은 어떻게 하는지 등이 궁금합니다! 긴 글 읽어주셔서 감사합니다.
학습 관련 질문을 최대한 상세히 남겨주세요! 고민 과정도 같이 나열해주셔도 좋습니다. 먼저 유사한 질문이 있었는지 검색해보세요. 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. 안녕하세요 강의 잘 듣고 있는 학생입니다. 다름이 아니라, 강의에서 query DSL 대신 Native Query를 사용하시는 이유가 있으신가요? 현업에서는 query DSL 대신 Native Query를 더 많이 사용하는걸까요??
안녕하세요 쿠케님 강의 잘 듣고있습니다! 제네릭을 사용할 때마다 생기는 고민이 있습니다.. 제네릭을 사용하다보면 컴파일러 경고가 발생하는 경우가 있는데(IDE의 노란 밑줄) 이런 경고들을 모두 해결해서 제거해야할 까요?? 아니면 어느정도 무시를 해도 되는 걸까요?? 이펙티브 자바에는 런타임에 캐스팅 관련 예외가 발생할 수 있으니 이런 경고를 최선을 다해 제거하라. 라는 내용이 있기도 하고, 노란 밑줄이 보이면 눈에 거슬리기도 해서 처음에는 어느정도 제거하면서 개발을 했었는데, 시간이 지날 수록 이게 맞나 싶기도하고 책에 있는 내용이 절대적인 것도 아니기도해서 그리고 강의에서도 어느정도 무시를 하는 것 같아 질문 남깁니다! 팀에서 결정한 컨벤션으로 개발하면 될 것 같은데, 다른 팀에서는 어떻게 진행하는지 궁금합니다! 최대한 제거하는지.. 어느정도는 무시( @SuppressWarnings )해도 되는지
8:42에서 종자의 p밸류값은 7.254117e-10 비료의 p밸류값은 1.835039e-03으로 나오는데요. 둘다 귀무가설을 기각하여 '토마토수'에 영향을 준다는 사실은 이해를 했습니다. 궁금한 점은 p밸류값이 종자가 비료보다 훨씬 수치가 작은데 그렇다면 '종자'가 '비료'보다 토마토수에 더 영향을 끼친다고 해석해도 괜찮은가요?
11:35 strcat는 함수 이름으로 안변하는 건가요? cat이 연결시키는 느낌이고 문자 변수 이름이 str이어서 strcat인건지, 변수이름에 상관없이 strcat이 되는건지 궁금합니다. a="hello"; acat(a, "world")라고는 쓸 수 없는거겠죠...?
안녕하세요. 관리자 테이블에 이메일이 유저의 이메일과 다르지 않다고 생각이 들어서 합치는 게 낫다고 생각이 들었습니다. 처음에는 유저에 그냥 합쳐서 새로운 컬럼 role로 관리하려고 했는데, 중복이 있어서 관리자 테이블엔, role 컬럼을 넣어서 user, admin 2개로 추가해서 이제 유저 테이블에서 FK로 사용하려고 하는데 이 방법은 어떨까요? (강의 너무 잘 듣고 있습니다, 제 멘토이십니다ㅎㅎ)
안녕하세요. 강의 끝까지 다 들었는데 갑자기 외래 키 부분에서 궁금한 점이 생겼습니다. DB 설계할 때 테이블끼리 관계를 맺기 위해 외래 키를 지정하잖아요? 그런데 외래 키로 지정을 안 하는 경우도 있나요? 조인 등에 사용될 속성은 있지만, 외래 키 지정은 안 해서 외래 키 제약 조건이 없도록 하는 경우도 있나요?
안녕하세요 nest로 개발을 진행하다가 fast API로 전향하려는 개발자 입니다. 저와 같은 경우는, TypeORM을 사용하고 있었습니다. TypeORM은 아래 코드와 같이 DB와 연결해 놓고 @Entity 어노테이션을 사용하면 테이블이 자동 생성됩니다. 강의를 보면 테이블을 생성하는 쿼리를 console로 만들어서 DB SQL에 직접 작성하는 것으로 확인됩니다. FAST API는 NEST처럼 테이블이 자동 생성되는 기능이 없는 걸까요?? 또한 @ManyToMany @ManyToOne과 같은 어노테이션을 사용하면 연관관계가 쉽게 맵핑되어 별도의 join 쿼리 없이도 조회,수정,삭제가 가능합니다. 이러한 부분 또한 FAST API는 지원하는 기능이 없는 걸까요?? import { Column, Entity, PrimaryGeneratedColumn } from 'typeorm'; @Entity() export class PostsModel { @PrimaryGeneratedColumn() //알아서 값을 1씩 증가하는 것을 만들어 준다. id: number; @Column() author: string; @Column() title: string; @Column() content: string; @Column() likeCount: number; @Column() commentCount: number; } import { Module } from '@nestjs/common'; import { AppController } from './app.controller'; import { AppService } from './app.service'; import { PostsModule } from './posts/posts.module'; import { TypeOrmModule } from '@nestjs/typeorm'; @Module({ imports: [ PostsModule, TypeOrmModule.forRoot({ //forRoot -> typeOrm과 nestJs을 연결할 수 있는 연결고리를 만드는 것 type: 'postgres', host: '127.0.0.1', port: 5432, username: 'postgres', password: 'postgres', database: 'postgres', entities: [], //데이터베이스와 연동될 모델들 synchronize: true, //nestJS에서 작성하는 typeOrm 코드와 데이터베이스싱크를 자동으로 맞출 것이냐(개발에서는 true, 프로덕션에서는 false) }), ], controllers: [AppController], providers: [AppService], }) export class AppModule {}
안녕하세요. 3분 40초대에 나오는 switch - case에 관련된 예제를 푸는 과정에서 질문이 생겨서 글을 작성하게 되었습니다. 제가 기존에 알던 switch - case는 if - else를 조금 더 편리하게 사용하기 위해 도입된 조건문이었습니다. 그런데, 해당 강의에서 배운 내용은 조금 달랐습니다. 여기 나온 예제를 들어 설명한다면, 변수 len에 저장된 값은 5이다. switch문의 기준은 len(=5)가 된다. 각 case에 대하여 len과 값을 비교했을 때의 결과를 기준으로 다음과 같이 실행한다. 3-1. case의 값이 참일 경우, (case의 값 == len) 해당 case를 기준으로 하여 break를 만날 때 까지 하위에 위치한 case들에 있는 statement들을 모두 실핸한다. 3-2. case의 값이 거짓일 경우, 다음 case로 넘어간다(처음으로 case의 값이 참일 경우를 만날 때 까지) 실행하는 statement에 break가 포함될 경우, 해당 switch문을 종료하고 빠져나온다. 끝까지 break를 만나지 못했을 경우, default의 statement를 실행 후 해당 switch문을 종료하고 빠져나온다. 이러한 논리 구조에 따라 case 3, 4는 건너뛰고 case 5에서 true이기 때문에 statement를 실행(len -= 1 -> len = 4) 처음으로 true인 case를 만났기 때문에, 해당 case 기준 아래에 위치한 모든 case를 실행 --> case 6 실행(len에 저장된 값은 6이 아님에도 불구하고) (len += 3 -> len = 7) --> case 6에서 break를 만남 -> 종료 결과 : len = 7 이런 식으로 진행 되는 것 맞는 건가요? 그렇다면, case 5의 statement가 len+=2;일 경우에도 case 7을 찾아가는 것이 아닌, case 6을 찾아가서 실행 후 break가 되는 것인가요?? 마지막으로, default 키워드는 switch에서 모든 case가 false가 나왔을 때 실행되는 것이 아닌, break를 한 번도 만나지 못했을 경우 가장 마지막에 실행되는 것인가요?? 긴 질문 읽어주셔서 감사합니다!
안녕하세요 ! 강의를 듣기전부터 궁금했던 내용인데 강의를 듣고나서도 답을 찾지 못해서 질문을 남깁니다..! 개발자도구 > Network 탭 > 문서 > 응답 이나 소스보기 에 서버사이드에서 불러온 데이터가 HTML 로 만들어져있으면 SEO 에 영향을 주는 데이터라고 알고 있어요 제가 혼자 테스트해보려고 만든 스트리밍에서는 <script /> 내부에만 서버 사이드에서 패치한 데이터가 들어가있고 HTML 로 만들어지지는 않았더라고요 ( 아마 <script /> 에 있는 정보가 RSC Payload 겠죠..? ) 그래서 이게 SEO 에 영향이 가는 데이터일지 궁금해서 여기저기 찾다가 발견한 Next Playground 에서는 HTML 로도 만들어지고 <script /> 에도 들어가있더라고요 최종적으로 궁금한것은 <script /> 에만 들어있는 스트리밍된 데이터도 SEO 에 영향을 주는지 가 궁금해요 그리고 영향을 주든 안주든 이런 정보는 어디서 찾아봐야하는지 어떻게 검증하는지 알고 싶습니다..! ( 참고로 Playground 에서 패치하는 첫번째 리스트의 이름인 Fusce commodo porta 로 확인해봤습니다! )
해당 강의와 직접적으로 연관있지는 않으나, Lock 관련하여 공부하던 중 성욱님의 MySQL GAP Lock (두번째 이야기) 글을 보게 되었습니다. 우선 정말 많은 도움이 되었음에 감사드리며, 해당 글 관련하여 질문을 드리고 싶습니다. (SELECT FOR UPDATE와도 관련있는 내용이라, 이곳 게시판을 통해 질문 드립니다.) 위 글의 '왜 supremum 레코드를 잠그나요 ?' 단락에서, 8, 9 번째 과정을 보면 다음과 같습니다. 8. 다음 페이지에서 id=137 보다 큰 (첫번째) 레코드인 id=138 읽기 9. WHERE 조건에 일치하지 않으므로 잠금 걸지 않음 그런데 그 아래에서 다음과 같은 내용을 말씀해 주십니다. 'REPEATABLE-READ 격리 수준을 사용하는 MySQL 서버에서는 검색하고 스캔했던 인덱스 레코드를 잠근다는 아주 기본적인 규칙 때문에 잠금이 발생하고 있었던 것이죠. 사용자 데이터가 아닌 시스템 레코드(supremum) 까지도 말이죠.' 그러나 이 설명에 따르면, '왜 supremum 레코드를 잠그나요 ?' 에서 언급한 동작에 모순 이 발생하는 것 같습니다. 5,6,7 번 과정에서는 supremum record를 읽었기 에 잠갔음 에도 불구하고, 8, 9번의 과정에서는 id=138 읽었지 만 잠그지 않고 종료 했기 때문입니다. 위 내용이 모순된 것이라 가정하고, 왜 supremum record에 Lock이 걸리도록 동작했는지에 대한 이유를 개인적으로 찾아보고 공부한 내용들에 기반하여 추측해 보았습니다. (아직 내용을 완벽히 공부하지 못해 틀린 내용이 있을 수 있습니다. 혹시 틀린 부분이 있다면 지적해주시면 감사하겠습니다!) MySQL 의 공식 문서의 내용에 따르면, Gap Lock은 Gap Lock 의 기준이 되는 index record 이전 의 간격을 잠급니다. A next-key lock on an index record also affects the “ gap ” before that index record - MySQL 공식문서 - Next Key Lock 그러나 Gap락이 특정 index record 이전 의 간격을 잠근다는 위 설명에 따르면, 어떤 index의 가장 마지막 record 이후의 간격을 잠글 수 있는 방법이 없어집니다. (Gap Lock 은 이전 간격을 잠그는 것이므로) 따라서, 마지막 record 이후의 값을 잠글 수 있기 위해 supremum pseudo record 를 두었을 것이라 예상합니다. supremum pseudo record(인덱스가 가질 수 있는 가상의 가장 큰 값) 에 대한 GAP Lock은 supremum pseudo record 이전의 간격들을 잠그기 때문입니다. 이는 공식 문서의 다음과 같은 내용을 통해 뒷받침할 수 있을 것 같습니다. 'Suppose that an index contains the values 10, 11, 13, and 20. The possible next-key locks for this index cover the following intervals, where a round bracket denotes exclusion of the interval endpoint and a square bracket denotes inclusion of the endpoint:' (negative infinity, 10] (10, 11] (11, 13] (13, 20] (20, positive infinity) For the last interval, the next-key lock locks the gap above the largest value in the index and the “supremum” pseudo-record having a value higher than any value actually in the index . The supremum is not a real index record, so, in effect, this next-key lock locks only the gap following the largest index value. - MySQL 공식문서 - Next Key Lock 이를 바탕으로 '왜 supremum 레코드를 잠그나요 ?' 의 원인을 분석해보면 다음과 같습니다. - 우선 3,4 번 과정에서 id=137 인 index record를 읽습니다. - 이때 id는 PK 이므로 값이 유니크하기에, BETWEEN 136 AND 137 조건을 통해 137이라는 값을 찾았으면, 해당 값이 조건을 만족하는 가장 마지막 값이라는 것을 알 수 있습니다. - 따라서 id=138 을 더 이상 탐색하지 않고 종료하게 되는데, 이때 id=137은 해당 PK 인덱스(리프노드 페이지) 의 가장 마지막 값이므로 , supremum 레코드를 이용하여 추가적인 간격을 잠구는 것이지 않을까 하는 생각이 들었습니다. 위 부분에 대한 성욱님의 의견을 듣고 싶어 질문드렸습니다. --- 이와 별개로, 추가 궁금증이 있습니다. 1. MySQL 공식 문서에서도 언급되었던 InnoDB performs row-level locking in such a way that when it searches or scans a table index, it sets shared or exclusive locks on the index records it encounters. 라는 문장에서 검색되거나 스캔된 의 의미가 잘 이해되지 않습니다. 예를 들어, id를 PK로 갖는 어떤 테이블에서, id = 3 인 row 를 탐색하기 위해서는, B-tree의 root 부터 시작 ~ leaf 노드로 이동 후, leaf node의 페이지의 전체 데이터를 스캔해야 하지 않나요? 예를 들어 id=3 인 record 가 들어있는 leaf 노드의 페이지에 id가 1 ~ 5 까지 있다고 하면, leaf 노드의 페이지로 진입하여 1부터 순차 탐색을 진행할 것 같은데, 그렇게 되면 1~5 까지의 index 값 사이에서 3을 탐색하는 데 1과 2를 먼저 찾을 것이므로, id가 1, 2, 3인 row가 모두 잠겨야 하지 않나 하는 생각이 들었습니다. 혹시 공식문서에서 언급한 검색 혹은 스캔된의 의미가, 조건에 사용된 인덱스가 걸린 필드 값만 확인하는 것은 포함하지 않는 것일까요? (ex - 위 예시에서 id가 1인 인덱스 확인 조건에 부합되지 않으므로 넘어감. (스캔되었다고 보지 않음) id가 2인 인덱스 확인 조건이 부합되지 않으므로 넘어감 id가 3인 인덱스 확인 조건에 부합되므로 나머지 값 읽어옴.) 위 내용들에서, 제가 어떤 부분을 잘못 생각하고 있는지 알 수 있을까요? 정말 좋은 강의와 글 공유해 주셔서 감사합니다.