172만명의 커뮤니티!! 함께 토론해봐요.
해결됨
(2026 최신!) 일주일만에 합격하는 정보처리기사 실기
선생님.... 제가 질문이 좀 많습니다.... main 바로 다음에 A b = new B(); 라고 되어있는데, A b가 왜 class B로 되는거죠?? 대소문자도 구분 해야하는거 아닌가요>>>? B를 b로 지정하거나 뭘 하겠다고 한건 없는거 같은데 이해가 안됩니다. 그냥 A라는 부모가 가진 것을 new B라는 자식이라고 A b로 새롭게 정의해서 new B = b라고 보면 되나요?
미해결
김영한의 실전 데이터베이스 - 설계 2편, 실무에서 반드시 마주치는 9가지 설계 패턴
안녕하세요. 주문, 상품과 같은 비즈니스에 중요한 데이터를 전체 행 스냅샷 이력 테이블 로 관리 하는 상황일 때, 대상 테이블(주문, 상품 등)의 칼럼이 추가/삭제되는 상황에 이력 테이블에 어떻게 반영해야할지 질문 드리고 싶습니다. - 추가: 신규 기능으로 인해 새로운 칼럼 추가 - 삭제: 기획 변경으로 오랜 기간 미사용 칼럼으로 낭비되어 삭제로 결정된 경우 등
해결됨
(2026 최신!) 일주일만에 합격하는 정보처리기사 실기
섹션 3. 17강. 23:00 질문 있습니다. printf("입력된 문자열: %s\n", str); 이 아니라 printf("입력된 문자열: %c\n", str)라면 어떤식으로 출력이 될까요? myString[]에서 this is string은 알파벳 하나하나 주소를 갖는건가요? 아니면 통째로 주소를 갖는 건가요?ㅜ 갑자기 헷갈려서 남깁니다.
해결됨
(2026 최신!) 일주일만에 합격하는 정보처리기사 실기
선생님 제가 정말 완전 노베이스에서 하는데, 왜 모든 값들을 출력할 때 출력문 구조가 System.out.println("d1 == d2: " + (d1 == d2)); 이렇게 되어있는데 출력은 +를 뺀 내용만 출력을 하는건가요? d1 == d2: false +의 경우는 " "에 있는 내용도 아니고 단지 두개의 식을 이어주는 역할이라고 생각하면 될까요?
해결됨
(2026 최신!) 일주일만에 합격하는 정보처리기사 실기
선생님 super(); //자동으로 추가되는 부모 클래스 생성자 호출 코드: 여기서 오류 발생이라고 하셨는데, 그렇다면 class Parent() 이렇게 기본 생성자를 호출하고 이후에 매개변수가 있다고 하면 super()은 오류가 없어지나요?
해결됨
(2026 최신!) 일주일만에 합격하는 정보처리기사 실기
super()가 없어지면 기본 생성자를 호출 해야한다는건 이해 했습니다. ElectricCartesla-new ElectricCar("Tesla",2021,75); 라는 변수가 있기때문에 자식 기본생성자인 부분은 건너뛰고 2번쨰인 ElectricCar로 바로 넘어가는건가요? 이후에 부모기본생성자 출력하고 남은 Capacity를 출력하는 순서... 이렇게 이해하면 되는건가요?
해결됨
(2026 최신!) 일주일만에 합격하는 정보처리기사 실기
super에 파라미터가 들어갈경우에는 부모, 자식 기본 생성자는 호출을 아예 안하는거라고 생각하면 되나요? super() 이렇게 되어있다면 기본 부모의 기본생성자와 자식 기본 생성자만 출력하면 되나요?
미해결
자바와 스프링 부트로 생애 최초 서버 만들기, 누구나 쉽게 개발부터 배포까지! [서버 개발 올인원 패키지]
알려주신대로 java jdk 11버전으로 다운받고 Gradle 11버전이 없어서 17로 받았는데, 버전 오류가 발생한 것 같습니다. 17버전을 다시 다운받으려고 하는데, 어떤걸 해야하는지 확인 부탁드립니다!
해결됨
기초 탄탄! 독하게 시작하는 Java Part 3(하) : 소켓과 파일 I/O
08_chatServerSelector 소스코드의 마지막 부분인 브로드캐스팅하는 함수 sendMessageAll에서 오류를 발견했습니다. 제공하여주신 소스 코드를 작성하고, 여러 클라이언트를 실행시켜보았습니다. 연결은 문제가 없었지만, 쓰기 부분에서 문제가 발생했습니다. private static void sendMessageAll(Selector selector, SocketChannel sender, String msg) throws IOException { ByteBuffer msgBuffer = ByteBuffer.wrap((msg + "\n").getBytes()); for (SelectionKey key : selector.keys()) { Channel channel = key.channel(); if (channel instanceof SocketChannel) { SocketChannel target = (SocketChannel) channel; target.write(msgBuffer); // <- 문제 지점 } } } msgBuffer를 반복문을 통하여 타겟 클라이언트 채널에 쓰기를 할 때에, 첫 클라이언트에게만 메시지가 보내지는 것 을 발견하였습니다. 이유는 write호출시 msgBuffer의 position이 마지막으로 이동이 되어서, 다른 클라이언트 소켓 채널에게는 빈 msgBuffer가 쓰기가 되어서 메시지가 보내지지가 않았습니다. 해결방법) msgBuffer의 값을 할당받는 부분을 반복문 안쪽으로 이동시켜 매 이터레이션 마다 값을 받게 코드를 수정하였습니다. // 브로드캐스팅 함수 private static void sendMessageAll(Selector selector, SocketChannel sender, String msg) throws IOException { for (SelectionKey key : selector.keys()) { Channel channel = key.channel(); if (channel instanceof SocketChannel) { SocketChannel target = (SocketChannel) channel; ByteBuffer msgBuffer = ByteBuffer.wrap((msg + "\n").getBytes()); target.write(msgBuffer); } } }
해결됨
6주 완성! 백엔드 이력서 차별화 전략 4가지 - 똑같은 이력서 속에서 돋보이는 법
1. 현재 학습 진도 몇 챕터/몇 강을 수강 중이신가요? 여기까지 이해하신 내용은 무엇인가요? 2. 어려움을 겪는 부분 어느 부분에서 막히셨나요? 코드의 어떤 로직이 이해가 안 되시나요? 어떤 개념이 헷갈리시나요? 3. 시도해보신 내용 문제 해결을 위해 어떤 시도를 해보셨나요? 에러가 발생했다면 어떤 에러인가요? 현재 작성하신 코드를 공유해주세요 안녕하세요 항상 강의 잘 보고 있습니다 ! 딩코딩코님 혹시, 로컬에서 테스트 한 결과를 이력서에 써도 괜찮을까요? 서비스를 배포를 할 생각이긴한데, 똑같은 환경을 2개 만들어서 배포를 하고 테스트를 하려니 비용이 많이 나올 것 같아서 어떻게 해야될지 고민하고 있습니다 ㅜㅜ 이렇게 구체적으로 알려주시면, 더 정확하고 도움이 되는 답변을 드릴 수 있습니다!
해결됨
6주 완성! 백엔드 이력서 차별화 전략 4가지 - 똑같은 이력서 속에서 돋보이는 법
1. 현재 학습 진도 몇 챕터/몇 강을 수강 중이신가요? 4-8 여기까지 이해하신 내용은 무엇인가요? 외래키 제약조건으로 인해 발생한 데드락 문제를 해결하기 위해 INSERT 하려는 테이블에 외래 키를 제거한다. 2. 어려움을 겪는 부분 외래키를 만약에 제거한다면, 어플리케이션 레벨에서 직접 관리한다고 했는데, 구체적으로 어떻게 관리를 하는 건지 궁금합니다! INSERT 하려는 테이블과 연관된 테이블들을 먼저 조회( findXXX() )를 하고, 만약에 없다면 예외를 발생시켜서 트랜잭션을 롤백시키는 방식으로 처리하나요? 실무에서 주로 어떻게 해결하는지 궁금합니다. 그리고 외래키를 사용하지 않는 첫 번째 방법은 이미 테이블이 생성된 시점( INSERT 하려는 테이블에 외래키가 추가되어 있는 상황)에서도 적용할 수 있는건가요? 예를 들어, 이미 테이블에 데이터가 추가되어 있는 상황에서 첫 번째 방법을 적용하려면, 테이블 구조를 아예 바꿔야 할텐데 이 경우에는 두 번째 방법인 쿼리 순서를 바꾸는 걸 대안으로 사용하는 건가요?
미해결
옆집 개발자와 같이 진짜 이해하며 만들어보는 첫 Spring Boot 프로젝트
강의에선 되게 단순하게 큰 틀 위주로 알려주시는 것 같아서 개인적으로 더 자세한 의미나 추가적인 개념이 궁금할 때 검색해보는 편인데, DI라는 것이 클래스 간의 결합도를 낮추고 객체의 유연성을 높이기 위해 빈 객체를 만들어 주입하는 것을 의미한다고 정리했습니다. 이게 맞게 정리한건지 궁금합니다. 또 추상 클래스와 인터페이스 간의 차이점은 찾아봐도 이해가 어렵길래 선생님의 친절한 설명이 필요할 것 같아서 추가로 여쭤봅니다!
미해결
김영한의 실전 데이터베이스 - 설계 2편, 실무에서 반드시 마주치는 9가지 설계 패턴
안녕하세요 영한님. 강의 정말 잘 듣고 있습니다. common_code_detail 은 pk로 natural key(group_code, code) 를 사용하는 것이 정형화되어 있다고 하신 부분을 이해했습니다. 서비스를 운영하다 보면 code의 값을 수정할 경우가 생길 가능성이 있을 거 같은데요. 예를 들면, 다음과 같은 요구사항이 있을 거 같습니다. group_code가 ORDER_STATUS 인 code에 대한 변경 요청. SHIPPING 을 두가지 상태로 확장(SHIPPING_START, SHIPPING_COMPLETED) 변경 전의 SHIPPING은 SHIPPING_COMPLETED로 취급한다. 설계 1편의 "pk는 immutable해야한다" 라는 3번째 규칙이 있었는데요. 공통 코드 테이블의 경우에는 3번째 규칙을 유연하게 적용해야하나? 하는 생각이 들었습니다. 공통 테이블은 natural key를 사용하니 어느정도 허용을 한다고 보면 될까요? 아니면, 기존 키는 삭제하지 않은 채로 그대로 두고 새로 만들어서 규칙을 지키는 방향으로 하시는지 궁금하네요. 실무에서 이런 케이스들은 어떻게 다루시는지 궁금합니다. 감사합니다.
해결됨
김영한의 실전 데이터베이스 - 설계 1편, 현대적 데이터 모델링 완전 정복
이번 강의의 수업자료 pdf 보니, 제목 클릭 시 링크위치가 각 챕터가 아닌, 마지막 페이지 정리 내 제목들로 이동합니다. 9. 논리적 모델링 - 실습.pdf 파일 제외하곤 모든 파일의 목차들이 다 마지막 정리로 이동하더라고요. 그동안 영한님 강의들 자료에는 각 챕터로 쉽게 이동 하기 좋았거든요. 이부분이 개선 가능할까요? 이 상태여도 학습은 가능한데, 건의드립니다. 감사합니다.
해결됨
BigQuery(SQL) 활용편(퍼널 분석, 리텐션 분석)
-- Weekly 리텐션 -- 핵심 : event_date => event_week으로 변경하면 됨 -- 2024-06-30(일) => 2024년 26주차. 2024-06-24(월)도 같은 26주차 -- 데이터를 전처리(가공)하기 위해서 WEEK 함수를 사용할 수도 있고, DATE_TRUNC(일자, 자를 기준) -- DATE_TRUNC : 2024-06-30 => 2024-06-24 -- WEEK : 26. 2024년 26주차! 주차 별 date를 직관적으로 알기 어렵다고 생각하는 편(개인 생각) -- (깨알 지식) WEEK vs ISO_WEEK -- 주 번호를 계산할 때 사용할 수 있는 함수 -- WEEK : 일요일이 주의 첫 날로 간주. 1월 1일이 속한 주가 1주차 -- ISO_WEEK : 월요일이 주의 첫 날로 간주. ISO 8601 국제 표준에 따라 정의. 목요일이 속한 주를 기준으로 주 번호를 지정 -- 목요일이 속하면 그 주의 4일 이상이 포함되기 때문 -- 연도의 첫 목요일이 있는 주부터 1주차 -- 2022년 1월 1일(토요일) WEEK : 2022년 1주차. ISO_WEEK 2021년 52주차. -- 첫 목요일은 2022-01-06. 2022-01-03~2022-01-09가 2022년 1주차 WITH base AS ( SELECT DISTINCT user_id, user_pseudo_id, event_name, DATE(DATETIME(TIMESTAMP_MICROS(event_timestamp), 'Asia/Seoul')) AS event_date, DATETIME(TIMESTAMP_MICROS(event_timestamp), 'Asia/Seoul') AS event_datetime FROM advanced.app_logs WHERE event_date BETWEEN "2022-08-01" AND "2022-11-03" ), first_week_and_diff AS ( SELECT *, -- DATE_DIFF(event_date, first_date, DAY) AS diff_of_day DATE_DIFF(event_week, first_week, WEEK) AS diff_of_week FROM ( SELECT # 일자별로 중복 제거 DISTINCT user_pseudo_id, -- DATE_TRUNC DATE_TRUNC(MIN(event_date) OVER(PARTITION BY user_pseudo_id), WEEK(MONDAY)) AS first_week, DATE_TRUNC(event_date, WEEK(MONDAY)) AS event_week FROM base ) ), user_counts AS ( SELECT diff_of_week, COUNT(DISTINCT user_pseudo_id) AS user_cnt FROM first_week_and_diff GROUP BY diff_of_week ) SELECT *, ROUND(SAFE_DIVIDE(user_cnt, first_week_user_cnt), 2) AS retention_rate FROM ( SELECT diff_of_week, user_cnt, FIRST_VALUE(user_cnt) OVER(ORDER BY diff_of_week ASC) AS first_week_user_cnt FROM user_counts ) -- SELECT -- diff_of_week, -- COUNT(DISTINCT user_pseudo_id) AS user_cnt -- FROM first_week_and_diff -- GROUP BY diff_of_week -- ORDER BY diff_of_week # Monthly 리텐션 쿼리 작성해보기! 지금 코드가 각 diff_week마다 남은 유저들을 전체 유저로 나눠서 아 몇주차쯤 되면 얼마나 남아있는지를 계산한 거 같은데 생각해보니까 예를들어 지금 기간이 11월 3일까진데 한 10월 중순에 들어온 유저 같은 경우엔 diff_week가 한 3 이상인 부분부턴 아예 데이터가 없는거 아닌가요? 데이터가 11월 3일까지 밖에 없으니까요 분모로 사용하는 diff_week=0인 지점에서의 값은 그런 경우들까지 전부 포함된거고 그걸 그대로 모든 retention week마다 분모로 사용하면 위 예시 같은 경우 10월 중순 user들은 한 3주차쯤엔 전부 이탈하는 것 처럼 집계되는거 아닌가요? 그 경우 diff_week가 커질수록 실제 리텐션 보다 과소평가 되는게 아닌가 하는 의문점이 들어 문의 남깁니다
미해결
김영한의 실전 데이터베이스 - 설계 2편, 실무에서 반드시 마주치는 9가지 설계 패턴
안녕하세요 첨부된 sql 파일 [-- ### 해결책 - 코드값 분리] 에서 orders 테이블 order_status의 타입이 common_code의 code 타입과 동일하게 VARCHAR(50)으로 변경되어야 할 거 같습니다. -- ### 해결책 - 코드값 분리 CREATE TABLE orders ( order_id BIGINT PRIMARY KEY AUTO_INCREMENT, member_id BIGINT NOT NULL, order_status VARCHAR(20) NOT NULL, total_amount INT NOT NULL, created_at DATETIME NOT NULL ); CREATE TABLE common_code ( code VARCHAR(50) PRIMARY KEY, name VARCHAR(100) NOT NULL );
해결됨
김영한의 자바 입문 - 코드로 시작하는 자바 첫걸음
[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] Array 연습 문제 5번을 제가 스스로 풀어보았을 때 이런 식으로 코드가 나왔고, 실행시켜봤을 때 답은 똑같이 나오는 것 같습니다. 다만 풀이와는 코드가 조금 다른 부분이 있는데 혹시 제가 풀어 본 코드도 맞는 코드인가요? 아니면 틀린 걸까요?
미해결
토비의 클린 스프링 - 도메인 모델 패턴과 헥사고날 아키텍처 Part 1
안녕하세요, 토비님. 강의 초반에 말씀해 주신 것처럼, 리팩토링 과정에서 “제가 했다면 어떻게 했을까”를 계속 생각해 보며 토비님의 의사결정 과정을 따라가고 있습니다. MemberService.register() 메소드에서 emailSender.send(...) 를 sendWelcomeEmail() 로 분리하시는 과정을 보며 두 가지 고민이 생겼습니다. 첫째, 환영 이메일의 내용이나 정책이 변경될 때마다 MemberService 의 코드가 함께 변경되어야 한다면, 이는 SRP 위반에 해당하지 않는지에 대한 고민입니다. 이 경우 환영 이메일 전송에 대한 책임을 EmailSender 인터페이스 쪽으로 옮기는 것이 더 적절한지 궁금해졌습니다. 둘째, 만약 EmailSender 인터페이스에 해당 메소드를 추가한다면, 구현체가 늘어날수록 인터페이스가 비대해지거나 향후 구현 복잡도가 증가할 수 있다고 느꼈습니다. 이런 경우 default method 로 제공하는 방식에 대해서는 어떻게 생각하시는지도 궁금합니다.
해결됨
(2026 최신!) 일주일만에 합격하는 정보처리기사 실기
double 비교 (6:10) double num1 = 128.0; Double num2 = 128.0; 이 두개를 ==로 비교하면 Double는 다른 ㅇ애들이기 때문에 무조건 false라고 하신거 아닌가요?? 아니면 대문자와 소문자로 인해서 달라지나요?
해결됨
BigQuery(SQL) 활용편(퍼널 분석, 리텐션 분석)
WITH base AS ( SELECT DISTINCT user_id, user_pseudo_id, event_name, DATE(DATETIME(TIMESTAMP_MICROS(event_timestamp), 'Asia/Seoul')) AS event_date, DATETIME(TIMESTAMP_MICROS(event_timestamp), 'Asia/Seoul') AS event_datetime FROM advanced.app_logs WHERE event_date BETWEEN "2022-08-01" AND "2023-08-03" ), first_week_and_diff AS ( SELECT *, DATE_DIFF(event_week, first_week, WEEK) AS weeks_after_first_week FROM ( SELECT DISTINCT user_pseudo_id, DATE_TRUNC(MIN(event_date) OVER(PARTITION BY user_pseudo_id), WEEK(MONDAY)) AS first_week, DATE_TRUNC(event_date, WEEK(MONDAY)) AS event_week FROM base ) ), user_counts AS ( SELECT first_week, weeks_after_first_week, COUNT(DISTINCT user_pseudo_id) AS active_users FROM first_week_and_diff GROUP BY first_week, weeks_after_first_week ) SELECT *, ROUND(SAFE_DIVIDE(active_users, cohort_users), 2) AS retention_rate FROM ( SELECT first_week, weeks_after_first_week, active_users, FIRST_VALUE(active_users) OVER(PARTITION BY first_week ORDER BY weeks_after_first_week ASC) AS cohort_users FROM user_counts ) ORDER BY first_week, weeks_after_first_week 수업때 사용했던 코드인데 제가 처음엔 지금 하고 있는 코호트 분석은 first_week(가입주) 마다 각자 시간이 흐르면서(기준은 week) 리텐션이 어떻게 바뀌는지를 보는 것 이라고 이해했었습니다 그래서 예를들어 첫 달 부터 확 떨어지면 이거 온보딩에 문제가 있는거 아닌가? 라는 문제정의를 하는 식의 생각을 할 수있다... 라고 이해하고 있었는데 다시 보니까 지금처럼 base에 날짜 조건을 필터링 하고 시작하면 min(event_date)를 걸어도 그게 실제 첫 가입일이 아닐 수 있는거 아닌가요? 예를들어 필터링 조건 이전인 2022년 7월에 가입을 한 사람이 2022년 10월에 다시 돌아왔다고 치면 이 경우 2022년 10월 가입 user로 집계되는거지 않나요? 그럼 본래 보려던 거랑 결이 달라지는게 아닌가 싶어서요
