172만명의 커뮤니티!! 함께 토론해봐요.
미해결
김영한의 실전 자바 - 고급 2편, I/O, 네트워크, 리플렉션
이유는 모르겠습니다만 제 컴퓨터에서는 DELIMITER 로 지정한 문자 "|" 가 split 메서드에서 작동하지 않더라구요. window를 사용하는데 그 때문인지는 모르겠습니다. 그래서 저는 DELIMITER = "\\|" 로 지정해 동작시켰습니다. 강사님과 split 메서드가 다르게 작동하는 이유는 뭘까요?
미해결
BigQuery(SQL) 활용편(퍼널 분석, 리텐션 분석)
노션에서 작성했습니다! https://salt-baron-5c5.notion.site/3-13aa734e64b880a1a9a1e84a92fa3593
미해결
BigQuery(SQL) 활용편(퍼널 분석, 리텐션 분석)
Notion 링크로 대체합니다. https://colney4844.notion.site/3-13a59b98d5db80438b7fcef0146771f6?pvs=4
미해결
자바와 스프링 부트로 생애 최초 서버 만들기, 누구나 쉽게 개발부터 배포까지! [서버 개발 올인원 패키지]
안녕하세요! 질문이 생겨 질문글 남깁니다 :) 영속성 컨텍스트는 트랜잭션을 사용하면 생겨난다 라고 말씀 해주셨는데요. 이중에 1차 캐시 부분에 대한 내용이 궁금해서 코드를 작성하던중에 의아한점이 생겼습니다. @Transactional public List<UserResponse> getUsers() { User user = userRepository.findById(4L).orElseThrow(); user.updateName("test"); userRepository.findById(4L); userRepository.findById(4L); return userRepository.findAll() .stream() .map(UserResponse::new) .toList(); } 우선은 위 내용인데요, updateName을 호출한 시점에 변경 감지가 되어서 update문이 호출 되었는데, 이후에 로그로 찍히는 select문이 없더라구요. 1차캐시가 진행되면 그 이후에 객체의 값이 변경 되더라도 그 내용까지 다시 반영해서 캐싱 해주는걸까요? public List<UserResponse> getUsers() { userRepository.findById(4L); userRepository.findById(4L); userRepository.findById(4L); return userRepository.findAll() .stream() .map(UserResponse::new) .toList(); } 그리고 두번째 질문은 코드를 이런식으로 트랜잭션 어노테이션 없이 작성했을 때 인데요. 제 추측은 트랜잭션 어노테이션이 없으니 영속성컨텍스트가 생성되지 않을것이고 그에따라 select문이 3번 호출될것이다. 였는데 실행해보니 select문은 한번만 호출되더라구요. 나름대로 왜일까 고민해본 결론은 findById가 구현된 SimpleJpaRepository클래스에 붙어있는 Transactional이 영향을 주는건가? 싶긴 한데 명확한 답은 모르겠습니다 ☹ 1차캐시에 한해서는 트랜잭셔널과는 독립되게 영속성컨텍스트가 동작하는걸까요?
미해결
BigQuery(SQL) 활용편(퍼널 분석, 리텐션 분석)
1. Weekly Retention WITH base AS ( SELECT DISTINCT DATETIME(TIMESTAMP_MICROS(event_timestamp), 'Asia/Seoul') AS event_datetime, DATE(DATETIME(TIMESTAMP_MICROS(event_timestamp), 'Asia/Seoul')) AS event_date, DATE_TRUNC(DATETIME(TIMESTAMP_MICROS(event_timestamp), 'Asia/Seoul'), WEEK(MONDAY)) AS event_week, DATE_TRUNC(DATETIME(TIMESTAMP_MICROS(event_timestamp), 'Asia/Seoul'), MONTH) AS event_month, user_id, user_pseudo_id, event_name, platform, event_params FROM advanced.app_logs ), user_visit_base AS ( SELECT user_pseudo_id, MIN(event_week) OVER (PARTITION BY user_pseudo_id) AS first_visit_week, event_week AS visit_week FROM base ), user_visit_weekdiff AS ( SELECT first_visit_week, DATE_DIFF(visit_week, first_visit_week, week) AS week_diff, COUNT(DISTINCT user_pseudo_id) AS visit_users FROM user_visit_base GROUP BY ALL ) SELECT first_visit_week, week_diff, visit_users, SAFE_DIVIDE(visit_users, FIRST_VALUE(visit_users) OVER (PARTITION BY first_visit_week ORDER BY week_diff ASC ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING)) AS retention FROM user_visit_weekdiff 2. Retain User → New User, Current User, Resurrected User, Dormant User -- 한 달(30일)을 기준으로 구분하였다. -- 신규 유저: 최근 한 달 이내 새로 방문 -- 기존 유저: 최근 한 달 이내 재방문, 그 이전 한달에도 방문 -- 복귀 유저: 최근 한 달 이내 재방문, 그 이전 한달에는 방문 X -- 휴먼 유저: 최근 한 달 이내 재방문 X WITH base AS ( SELECT DISTINCT DATE(DATETIME(TIMESTAMP_MICROS(event_timestamp), 'Asia/Seoul')) AS event_date, user_pseudo_id FROM advanced.app_logs ), user_first_last AS ( SELECT user_pseudo_id, MIN(event_date) AS first_date, MAX(event_date) AS last_date FROM base GROUP BY user_pseudo_id ), last_event_date AS ( SELECT MAX(event_date) AS current_date FROM base ), user_activity AS ( SELECT user_pseudo_id, event_date, LEAD(event_date) OVER (PARTITION BY user_pseudo_id ORDER BY event_date) AS next_event_date, CASE WHEN DATE_DIFF(LEAD(event_date) OVER (PARTITION BY user_pseudo_id ORDER BY event_date), event_date, DAY) > 30 THEN 1 ELSE 0 END AS dormant_history FROM base ), user_types AS ( SELECT u.user_pseudo_id, u.first_date, u.last_date, led.current_date, MAX(us.dormant_history) AS dormant_history, CASE WHEN DATE_DIFF(led.current_date, u.last_date, DAY) > 30 THEN 'dormant_user' WHEN DATE_DIFF(u.last_date, u.first_date, DAY) <= 30 THEN 'new_user' WHEN MAX(us.dormant_history) = 1 THEN 'resurrected_user' ELSE 'current_user' END AS user_type FROM user_first_last AS u CROSS JOIN last_event_date AS led LEFT JOIN user_activity AS us ON u.user_pseudo_id = us.user_pseudo_id GROUP BY u.user_pseudo_id, u.first_date, u.last_date, led.current_date ), first_week_and_diff AS ( SELECT ut.user_type, fw.user_pseudo_id, fw.event_date, DATE_DIFF(DATE_TRUNC(fw.event_date, WEEK(MONDAY)), DATE_TRUNC(ut.first_date, WEEK(MONDAY)), WEEK) AS diff_of_week FROM base AS fw JOIN user_types AS ut ON fw.user_pseudo_id = ut.user_pseudo_id ), user_cnt_by_type_and_week AS ( SELECT user_type, diff_of_week, COUNT(DISTINCT user_pseudo_id) AS user_cnt FROM first_week_and_diff GROUP BY user_type, diff_of_week ), retention_base AS ( SELECT user_type, diff_of_week, user_cnt, FIRST_VALUE(user_cnt) OVER (PARTITION BY user_type ORDER BY diff_of_week) AS first_user_cnt FROM user_cnt_by_type_and_week ) SELECT user_type, diff_of_week, ROUND(SAFE_DIVIDE(user_cnt, first_user_cnt), 2) AS retention_rate FROM retention_base ORDER BY user_type, diff_of_week 3. retention이 높은 그룹? current user: 최고 0.41 (4~5주차) new user: 최고 0.11 (1,3주차) resurrected user: 최고 0.14 (9~12주차) dormant user: 최고 0.09 (3주차) 리텐션이 그나마 높은 그룹: current user current user, resurrected user 리텐션 분포의 경우 상승세 → 하강세 경향성을 보여 피크를 찍을 때 즈음 어떤 이벤트가 있었다고도 추측할 수 있다. 4. click_payment 이벤트를 중점으로 본 Weekly Retention? WITH base AS ( SELECT DISTINCT DATE(DATETIME(TIMESTAMP_MICROS(event_timestamp), 'Asia/Seoul')) AS event_date, DATETIME(TIMESTAMP_MICROS(event_timestamp), 'Asia/Seoul') AS event_datetime, event_name, user_id, user_pseudo_id FROM advanced.app_logs WHERE 1=1 AND event_name = "click_payment" ), event_week_and_first_week AS ( SELECT DISTINCT DATE_TRUNC(event_date, WEEK(MONDAY)) AS event_week, user_pseudo_id, DATE_TRUNC(MIN(event_date) OVER(PARTITION BY user_pseudo_id ORDER BY event_date), WEEK(MONDAY)) AS first_week FROM base ), retention_base AS ( SELECT *, FIRST_VALUE(user_cnt) OVER(ORDER BY day_of_week) AS total_user FROM ( SELECT DATE_DIFF(event_week, first_week, WEEK) AS day_of_week, COUNT(DISTINCT user_pseudo_id) AS user_cnt FROM event_week_and_first_week GROUP BY day_of_week ) ) SELECT day_of_week, ROUND(SAFE_DIVIDE(user_cnt, total_user), 2) AS retention FROM retention_base ORDER BY day_of_week
미해결
자바와 스프링 부트로 생애 최초 서버 만들기, 누구나 쉽게 개발부터 배포까지! [서버 개발 올인원 패키지]
안녕하세요, 24강 수강중에 궁금한점이 생겨 문의 남깁니다. 야믈파일에 설정한 ddl-auto옵션 관련해서 validate로 값을 바꾼 뒤 몇가지 테스트를 해보았습니다. age필드를 완전히 제거 name필드를 named 명칭으로 변경. name필드의 column()안에 들어가는 속성값들을 변경. 이렇게 3가지를 해보았는데 실질적으로 테이블과 일치하지 않는다 라며 서버를 실행하지 않는 경우는 2번 name필드가 다른 명칭으로 변경되었을 때 한가지 경우더라구요. age는 nullable이라 아에 필드가 명시되지 않아도 일치한다고 판단하는걸까요? column 어노테이션 안에 들어가는 값들은 감지하지 못하는게 맞나요?
미해결
BigQuery(SQL) 활용편(퍼널 분석, 리텐션 분석)
Notion으로 작성하여 링크를 첨부합니다. https://polite-vinyl-a61.notion.site/3-13a4994b207d804f969dc98e5bce9794
해결됨
[풀스택 완성] Supabase로 웹사이트 3개 클론하기 (Next.js 14)
Error: async/await is not yet supported in Client Components, only Server Components. This error is often caused by accidentally adding 'use client' to a module that was originally written for the server. 이라는 에러가 뜨고 유저리스트가 빈배열 리턴되는데 이런 경우 어떻게 처리해야하나요?
미해결
BigQuery(SQL) 활용편(퍼널 분석, 리텐션 분석)
과제. 직접 retention 구해보기(주별 weekly) 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(MIN(event_date) OVER(PARTITION BY user_pseudo_id), WEEK(MONDAY)) AS first_week, event_date, DATE_TRUNC(event_date, WEEK(MONDAY)) AS event_week FROM base ) ), user_cnt_and_diff AS( SELECT diff_of_week, COUNT(DISTINCT user_pseudo_id) AS user_cnt FROM first_week_and_diff GROUP BY ALL ORDER BY diff_of_week ), retain_base AS ( SELECT *, FIRST_VALUE(user_cnt) OVER (ORDER BY diff_of_week) AS first_user_cnt FROM user_cnt_and_diff ) SELECT diff_of_week, ROUND(SAFE_DIVIDE(user_cnt, first_user_cnt), 2) AS retention FROM retain_base 과제. 월별 리텐션 쿼리 작성해보기 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_month_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 DATE_DIFF(event_month, first_month, MONTH) AS diff_of_month FROM ( SELECT DISTINCT user_pseudo_id, DATE_TRUNC(MIN(event_date) OVER(PARTITION BY user_pseudo_id), MONTH) AS first_month, event_date, DATE_TRUNC(event_date, MONTH) AS event_month FROM base ) ), user_cnt_and_diff AS( SELECT diff_of_month, COUNT(DISTINCT user_pseudo_id) AS user_cnt FROM first_month_and_diff GROUP BY ALL ORDER BY diff_of_month ), retain_base AS ( SELECT *, FIRST_VALUE(user_cnt) OVER (ORDER BY diff_of_month) AS first_user_cnt FROM user_cnt_and_diff ) SELECT diff_of_month, user_cnt SAFE_DIVIDE(user_cnt, first_user_cnt) AS retention FROM retain_base 리텐션 연습문제 Weekly Retention을 구하는 쿼리를 바닥부터 스스로 작성해보세요. # 답 -- Weekly Retention을 구하자! (Retention이란, 시간이 흐르면서 다시 제품을 사용하는지 측정하는 지표) -- 첫 방문 후 매주 재방문 비율(weekly retention)을 계산하자! WITH base AS ( SELECT DISTINCT ###### DATE(DATETIME(TIMESTAMP_MICROS(event_timestamp), 'Asia/Seoul')) AS event_date, DATETIME(TIMESTAMP_MICROS(event_timestamp), 'Asia/Seoul') AS event_datetime, event_name, user_id, ###### user_pseudo_id FROM advanced.app_logs WHERE event_date BETWEEN "2022-08-01" AND "2023-08-31" ), event_week_and_first_week AS ( SELECT DISTINCT DATE_TRUNC(event_date, WEEK(MONDAY)) AS event_week, user_pseudo_id, DATE_TRUNC(MIN(event_date) OVER(PARTITION BY user_pseudo_id ORDER BY event_date), WEEK(MONDAY)) AS first_week FROM base ), retention_base AS ( SELECT *, FIRST_VALUE(user_cnt) OVER(ORDER BY day_of_week) AS total_user FROM( SELECT DATE_DIFF(event_week, first_week, WEEK) AS day_of_week, COUNT(DISTINCT user_pseudo_id) AS user_cnt FROM event_week_and_first_week GROUP BY ALL ) -- ORDER BY day_of_week ) SELECT day_of_week, SAFE_DIVIDE(user_cnt, total_user) AS retention FROM retention_base Retain User를 New + Current + Resurrected + Dormant User로 나누는 쿼리를 작성해보세요 # 답 -- 신규 유저: 첫 활동일 기준 7일 이내 -- 기존 유저: 첫 활동일 기준 7일 이후, 마지막 활동으로부터 90일 이내 -- 휴면 유저: 마지막 활동일 이후 90일 이상 경과 -- 복귀 유저: 90일 이상 비활성화 이후 다시 돌아온 유저 WITH base AS ( SELECT DISTINCT DATE(DATETIME(TIMESTAMP_MICROS(event_timestamp), 'Asia/Seoul')) AS event_date, user_pseudo_id FROM advanced.app_logs --WHERE event_date BETWEEN "2022-08-01" AND "2023-08-31" ),user_first_last AS ( SELECT user_pseudo_id, MIN(event_date) AS first_date, #OVER(PARTITION BY user_pseudo_id)를 넣으면 윈도우함수사용과 GROUPBY졸 사용 비교했을 때처럼 중복행이 생긴다 MAX(event_date) AS last_date FROM base GROUP BY user_pseudo_id ), last_event_date AS ( -- 원래라면 CURRENT_DATE()로 해야하지만, 앱로그 데이터의 마지막 날로 설정. SELECT MAX(event_date) AS current_date FROM base ), user_activity AS ( -- 90일 이상 제품을 사용하지 않았다면 1, 아니면 0 SELECT user_pseudo_id, event_date, LEAD(event_date) OVER (PARTITION BY user_pseudo_id ORDER BY event_date) AS next_event_date, CASE WHEN DATE_DIFF(LEAD(event_date) OVER (PARTITION BY user_pseudo_id ORDER BY event_date), event_date, DAY) > 90 THEN 1 ELSE 0 END AS dormant_history FROM base ) -- user_types AS ( SELECT DISTINCT u.user_pseudo_id, u.first_date, u.last_date, led.current_date, us.dormant_history, CASE WHEN DATE_DIFF(led.current_date, u.last_date, DAY) > 90 THEN 'dormant_user' WHEN DATE_DIFF(u.last_date, u.first_date, DAY) <= 7 THEN 'new_user' WHEN dormant_history = 1 THEN 'resurrected_user' ELSE 'current_user' END AS user_type FROM user_first_last AS u CROSS JOIN last_event_date AS led LEFT JOIN user_activity AS us ON u.user_pseudo_id = us.user_pseudo_id 주어진 데이터에서 어떤 사람들이 리텐션이 그나마 높을까요? 찾아보세요 WITH base AS ( SELECT DISTINCT DATE(DATETIME(TIMESTAMP_MICROS(event_timestamp), 'Asia/Seoul')) AS event_date, user_pseudo_id FROM advanced.app_logs ), user_first_last AS ( SELECT user_pseudo_id, MIN(event_date) AS first_date, MAX(event_date) AS last_date FROM base GROUP BY user_pseudo_id ), last_event_date AS ( SELECT MAX(event_date) AS current_date FROM base ), user_activity AS ( SELECT user_pseudo_id, event_date, LEAD(event_date) OVER (PARTITION BY user_pseudo_id ORDER BY event_date) AS next_event_date, CASE WHEN DATE_DIFF(LEAD(event_date) OVER (PARTITION BY user_pseudo_id ORDER BY event_date), event_date, DAY) > 90 THEN 1 ELSE 0 END AS dormant_history FROM base ), user_types AS ( SELECT u.user_pseudo_id, u.first_date, u.last_date, led.current_date, MAX(us.dormant_history) AS dormant_history, CASE WHEN DATE_DIFF(led.current_date, u.last_date, DAY) > 90 THEN 'dormant_user' WHEN DATE_DIFF(u.last_date, u.first_date, DAY) <= 7 THEN 'new_user' WHEN MAX(us.dormant_history) = 1 THEN 'resurrected_user' ELSE 'current_user' END AS user_type FROM user_first_last AS u CROSS JOIN last_event_date AS led LEFT JOIN user_activity AS us ON u.user_pseudo_id = us.user_pseudo_id GROUP BY u.user_pseudo_id, u.first_date, u.last_date, led.current_date ), first_week_and_diff AS ( SELECT ut.user_type, fw.user_pseudo_id, fw.event_date, DATE_DIFF(DATE_TRUNC(fw.event_date, WEEK(MONDAY)), DATE_TRUNC(ut.first_date, WEEK(MONDAY)), WEEK) AS diff_of_week FROM base AS fw JOIN user_types AS ut ON fw.user_pseudo_id = ut.user_pseudo_id ), user_cnt_by_type_and_week AS ( SELECT user_type, diff_of_week, COUNT(DISTINCT user_pseudo_id) AS user_cnt FROM first_week_and_diff GROUP BY user_type, diff_of_week ), retention_base AS ( SELECT user_type, diff_of_week, user_cnt, FIRST_VALUE(user_cnt) OVER (PARTITION BY user_type ORDER BY diff_of_week) AS first_user_cnt FROM user_cnt_by_type_and_week ) SELECT user_type, diff_of_week, ROUND(SAFE_DIVIDE(user_cnt, first_user_cnt), 2) AS retention_rate FROM retention_base ORDER BY user_type, diff_of_week current user의 1주차 리텐션은 0.11부터 시작해서 5~6주차에는 0.15까지 오릅니다. new user의 경우 1주차까지 밖에 리텐션을 구하지 못하고, 0.06입니다. resurrected user의 경우 1주차 리텐션은 0.04부터 시작해서 7주차에는 0으로 빠르게 감소합니다. dormant user의 경우 휴면고객의 리텐션을 구하는 것이 의미가 있는지 잘 모르겠지만, 1주차 리텐션은 0.05부터 시작해서 11주차까지 0으로 감소합니다. 리텐션이 그나마 높은 유저는 current user이고, 리텐션이 주마다 서서히 증가하거나 감소하는데 2주차에 오른 것으로 보아 기능 배포나 이벤트가 있지 않았을까 예상해봅니다. Core Event를 “click_payment”라고 설정하고 Weekly Retention을 구해주세요 WITH base AS ( SELECT DISTINCT DATE(DATETIME(TIMESTAMP_MICROS(event_timestamp), 'Asia/Seoul')) AS event_date, DATETIME(TIMESTAMP_MICROS(event_timestamp), 'Asia/Seoul') AS event_datetime, event_name, user_id, user_pseudo_id FROM advanced.app_logs WHERE event_name = "click_payment" ), event_week_and_first_week AS ( SELECT DISTINCT DATE_TRUNC(event_date, WEEK(MONDAY)) AS event_week, user_pseudo_id, DATE_TRUNC(MIN(event_date) OVER(PARTITION BY user_pseudo_id ORDER BY event_date), WEEK(MONDAY)) AS first_week FROM base ), retention_base AS ( SELECT *, FIRST_VALUE(user_cnt) OVER(ORDER BY day_of_week) AS total_user FROM ( SELECT DATE_DIFF(event_week, first_week, WEEK) AS day_of_week, COUNT(DISTINCT user_pseudo_id) AS user_cnt FROM event_week_and_first_week GROUP BY day_of_week ) ) SELECT day_of_week, ROUND(SAFE_DIVIDE(user_cnt, total_user), 2) AS retention FROM retention_base ORDER BY day_of_week app_logs 테이블에서 event_name이 click_payment인 것만 필터 걸어서 리텐션 구하기를 진행했는데 이렇게 푸는 것이 맞을까요..?
미해결
실습으로 배우는 선착순 이벤트 시스템
안녕하세요 강사님 강의 잘 봤습니다. 덕분에 kafka와 redis를 어떤식으로 사용할 수 있는지 많은 걸 엿볼 수 있는 느낌이었습니다. 강의가 다 진행되고 난 후 궁금한 점이 하나 있습니다. 쿠폰 생성 에러 처리 관련되어서 질문이 있는데, 만약 메시지를 수신하는 쪽이 아니라 발송하는 쪽에서 문제가 생겼다면 어떻게 해야하나요? 예를들어 redis에서 increment로 수량에 대해서 가져왔지만, 만약 kafka에 메시지를 보내는 것이 실패 될 경우 reids에 있는 값을 다시 하나 줄여야할 것 같습니다. 이런 경우 try catch 블럭으로 처리를 하는 지? 아니면 다른 방식으로 예외처리 하는지 궁금합니다.
해결됨
김영한의 실전 자바 - 중급 1편
[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예) [질문 내용] 안녕하세요. String 선언시 리터럴 방식으로하면 String Pool에 해당 문자열이 있는지 확인하고, 있다면 해당 문자열의 참조값을 사용하는 것으로 알고 있는데요. 반면 new 연산자를 이용하는 방식은 String Pool 을 거치지 않고 항상 새로운 String 객체를 생성하는걸로 알고있습니다. PDF 파일 2페이지에 이런 내용이 있는데요. 편의상 쌍따옴표로 문자열을 감싸면 자바 언어에서 new Stirng("hello") 와 같이 변경해준다. 리터럴 방식도 new 연산자를 이용하는 방식으로 자바가 변경해주는거라면 Heap 영역에 항상 새로운 String 객체를 생성하게 되는게 아닌지 궁금합니다. 감사합니다. 😃
해결됨
자바와 스프링 부트로 생애 최초 서버 만들기, 누구나 쉽게 개발부터 배포까지! [서버 개발 올인원 패키지]
인텔리제이 내에서 데이터베이스를 실행하려고 하면 [28000][1045] Access denied for user 'root'@' localhost ' (using password: YES) 이와 같은 경고문이 뜹니다. 해결방안을 알고 싶습니다!
미해결
김영한의 실전 자바 - 기본편
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요. 1. 강의 내용과 관련된 질문을 남겨주세요. 2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요. (자주 하는 질문 링크: https://bit.ly/3fX6ygx) 3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요. (질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG) 질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] 여기에 질문 내용을 남겨주세요. 처음에 제가 풀 땐 이렇게 해서 풀었는데 nullPointException 에러가 터졌습니다. 이런 에러가 터진 이유와 그리고 제 생각이 왜 틀린건지 설명해주시면 감사하겠습니다.
해결됨
김영한의 실전 자바 - 중급 2편
제네릭 타입 이레이저 PDF 기준 30p 부분인데 컴파일 이후에는 제네릭 타입 정보가 존재하지 않기 때문에 instanceof나 new를 허용하지 않는다는건 잘 이해를 했습니다. 근데 밑에 코드를 보면 public void create() 부분이 일단은 public void create() {return new T();} 이 부분이 public T create() {return new T();}로 되어야하는거 아닌가요?
미해결
실습으로 손에 잡히는 SQLD(2과목)
2판 기준으로 COL1에는 1,1,1,1이 들어있습니다
해결됨
[코드캠프] 부트캠프에서 만든 고농축 프론트엔드 코스
결론부터 말하면 검색할 때 페이지네이션 현재 페이지가 1로 안 바뀌어서 바꿔봤습니다. 예를 들어 ‘철’이라는 검색어를 입력했더니 페이지가 2페이지까지 있음. 2페이지를 클릭해 2페이지가 보이는 상태에서 검색어를 ‘철수’로 바꾸니 게시글 수가 1페이지까지밖에 없었는데, 1페이지가 현재 activedPage가 아니게 됨(없어진 2페이지 그대로). 검색한 게시글 목록 refetch는 제대로 이루어지기에 1페이지의 내용이 보이는 것은 맞지만 현재 페이지 숫자가 제대로 표시되지 않음. 또한 ‘안녕하세요’의 12페이지를 보고 있었는데 ‘안녕’으로 검색어를 바꾸니 당연히 refetch를 통해 1페이지 게시글 목록을 보여주지만, 페이지네이션은 그대로 11, 12 , ..., 20임 검색어가 바뀌면 페이지네이션의 activedPage와 startPage를 1로 변경해주도록 Paginations01.container에서 useEffect 실행시켜 해결 useEffect(() => { setStartPage(1); setActivedPage(1); }, [props.count]); 검색어를 바꾸면 검색된 총 게시글 수도 보통 달라질 거라는 생각에 props.count를 의존성으로 써본건데 검색어를 바꿔도 우연히 검색된 총 게시글 수가 똑같을 경우 useEffect 실행 안 되니 정말로 검색어가 달라질 때를 기준으로 하려고 BoardList에 있는 keyword를 pagination 컴포넌트에 props로 넘겨줘서 사용 // BoardList.presenter.tsx <Paginations01 refetch={props.refetch} count={props.count} keyword={props.keyword} /> // keyword 전달 // Paginations01.container.tsx useEffect(() => { setStartPage(1); setActivedPage(1); }, [props.keyword]); // Paginations01.types.ts export interface IPaginations01Props { ... keyword?: string; ... } 고쳐지긴 했는데 일단 useEffect에서 setState를 하고 있다는 점(여기선 크게 상관이 없는건지?)과 페이지네이션 컴포넌트인데 keyword라는 걸 받아온다는 것 자체가 검색 컴포넌트의 영향을 받는다는 뜻 아닌가 싶어서(keyword는 검색 기능이 있을 때만 존재하니까) 제대로 된 컴포넌트 분리에 대한 고민(keyword?로 하면 페이지네이션 컴포넌트 쓸 때 keyword 써도 되고 안 써도 되니까 이대로 해도 괜찮을지...?) 다른 방법은 있는지? 의견 있으시면 알려주시면 감사하겠습니다. 그외 궁금한 점 저는 이거 하는 과정에서 yarn dev 해놓은 상태에서 코드들을 저장 계속 하면서 고쳤는데 그럼 원래 바로바로 반영이 되잖아요. 코드에는 문제가 없어서 제대로 작동해야 했는데 페이지네이션 컴포넌트에서 props.keyword가 자꾸 undefined인 바람에 useEffect도 작동 안해서 코드가 문젠줄 알고 한참 삽질 후 그냥 vscode와 크롬 등등 다 끄고 좀 나중에 그대로 다시 켜보니까 잘 작동하게 됐는데 (yarn dev를 끊었다 다시 하는 거로는 아마 해결 안됐음) 이게 처음이 아니고 저번에도 한 번 포기하고 결국 다음날 켜보니까 코드는 그대로인데 갑자기 잘 되었는데 정확히 무엇때문에 이런 문제가 생기는건지 모르겠네요!!! (캐시? .next? 뭐 그런 거 때문인가요?)
해결됨
초보자를 위한 BigQuery(SQL) 입문
포켓몬의 수를 타입 별 집계, 수가 10 이상인 타입만 남기는 쿼리 작성 연습문제에 대하여 질문 드려요. 작성 전에 고민했던 부분은 포켓몬 타입은 type 1, 2로 나뉘어 있다. type 2는 null 인 경우가 있다. => where 로 제외할 수 있을까? type 1, 2 을 포함해서 세야 할 것 같다. (총 포켓몬 수보다 합산 값이 클 수 있다) 였거든요. Group by 에서 type2를 빼면 통합되지 않았다는 오류가 발생해서 어쩔 수 없이 넣긴 했는데, 제가 원한 형태로 구현되지는 않았습니다. 어떻게 해야 null 을 제외한 type2 의 값까지 전부 셀 수 있을까요? WHERE TYPE2 IS NOT NULL 을 넣게 되면 1개 타입만 가진 개체의 경우 아예 집계를 하지 않는 것 같아서 그 부분도 뺄 수 밖에 없었어요. 최종적으로는 1열에 타입, 2열에 해당하는 개체 수가 나오게 구현하고 싶습니다. (바위, 불인 포켓몬의 경우 바위에 1개, 불에 1개 계산되도록이요. 바위, 불 포켓몬 + 바위 포켓몬 + 불 포켓몬 = 바위 2개체 불 2개체) SELECT type1, type2, COUNT(id) as cnt FROM `basic.pokemon` GROUP BY type1, type2
미해결
초보자를 위한 BigQuery(SQL) 입문
Battel 데이터 문제로 보이는데, 설정을 잘못한걸까요?
미해결
나도코딩의 자바 기본편 - 풀코스 (20시간)
13강 상수를 배우고 있는데요. final String KR_COUNTRY_CODE = "+82"; system.out.println(KR_COUNTRY_CODE); 에서 상수를 쓸건데 int가 아닌 final String 을 사용하는 이유는 + 82 때문에그러는걸까요? 숫자만 쓰는게 아니라 + 기호를 사용하기 때문에 문자열 String에 final을 붙여서 final String을 사용하는걸까요?
해결됨
자바 ORM 표준 JPA 프로그래밍 - 기본편
영한님 강의로 많은 도움 얻은 학습자입니다. 최근 커뮤니티나 기술 블로그에 종종 보이는 내용 중 하나가 "연관관계를 맺지 않고 그냥 쓰는 것" 에 대해 어떻게 생각하시는지 궁금합니다. @Entity class Member { .... // @ManyToOne @JoinColumn("team_id") // private Team team; private Long teamId; // 이런식으로 연관관계 없이 그냥 id 값 넣어 사용 } 위와 같은 형태로 Team 객체를 연관관계로 갖고있는게 아닌 id 값 타입 그대로를 가진 형태입니다. 토스 개발자로 계신 제미니님도 연관관계를 잘 맺지 않으신다는 의견을 갖고 계시고, (이유는 id 로만 맺었을 땐 그 다음 전략을 선택하기 쉽다 && 관계를 잘못되게 많이맺어놓으면 다음이 없다라고 하시더군요.) 신빙성 없는 블로그발 출처이긴 하지만 네이버, 카카오에서도 연관관계를 안맺고 쓴다라는 얘기가 있긴하더군요. ( https://velog.io/@ssuh0o0/BE-STUDY-%EC%97%B0%EA%B4%80%EB%A7%A4%ED%95%91%EC%9D%84-%EC%A7%80%EC%96%91%ED%95%98%EB%9D%BC ) 당연히 답이 없는 문제이지만, 개인적인 생각으로는 현업에서 JPA 를 써본 결과 JPA 의 러닝커브 자체도 너무 높고, 이것저것 고려해야 될 것이 너무 많아진다 << 가 제 결론이긴 하거든요. 그 예로 n+1 문제부터 시작해서 양방향 연관관계일 경우 명시적으로 set, add 등을 해줘야하는 문제, 오래 전이라 정확히 기억은 나지 않지만 OneToOne 관계일때 발생했던 문제, A 테이블과 B 테이블 간 조인을 2개 컬럼으로 해야할 때 발생했던 문제, ddl-auto 실수할 여지 ... 등등 연관관계를 통해 객체 그래프를 쉽게 가져올 수 있다는 장점, sql 종속적이지 않은 장점 여러가지 제약사항이 많아 실수할 여지가 많다라는 단점 개인프로젝트라면 1번을 선택하겠지만 현업에서는 1 < 2 인것 같아 고민입니다. 강의 내에서도 그 뛰어난 배민 개발자들도 종종 실수 하신다고 하시기도 했구요. 배민에서는 적극적으로 활용 중인 것으로 알고 있는데, 배민을 제외한 다른 회사에서는 현업에서 어떻게 활용 중인지 또, 위 내용에 대한 의견이 어떠신지 궁금합니다.
