JHB의 삽질 이야기

말인 즉슨 선 Project, 후 Github인 케이스. 아무 것도 없는 Blank Github인 경우는 고민 할게 없다. 먼저 작업 하던 프로젝트를 A, 후에 Github에 생성한 Repository를 B라고 하면 그냥 B에 A를 push 하면 끝난다. 하지만, B를 생성 할 때, License, Readme, gitignore 등을 생성했다면? 당연히 해당 commit이 B에 생성 됐을 것이고, A와 B를 합치는 것이 단순한 작업이 아니다. 내가 선택한 방법은 A프로젝트에 작업하던 Commit History를 잃지 않기 위해 B의 Initial Commit 위로 A 프로젝트를 Rebase 하는 것이다. 상황은 이렇다. aws_boto3_helper 라는 프로젝트를 이미 Git을 통해 작업 중이었고, ..

차라리 AWS 전용 블로그, Windows 개발 전용 블로그, Java 언어 전용 블로그.. 였다면 좀 더 쉬웠을까 예를 들어 React Native를 이용한 AWS Amplify용 FCM 푸쉬 메세지 개발 이라는 제목으로 글을 포스팅 한다면... 이 글은 Mobile카테고리? JS카테고리? React Native카테고리? AWS Mobile? AWS? AWS Amplify? AWS 개발 관련 된 것이니까 AWS Development? FCM이니까 Android? 이런게 여러개다. CDK를 이용한 EKS 배포 AWS Pinpoint를 이용한 Custom Event의 Raw Log를 S3에 수집하자 등등.. 뭔가 두서없이 글을 막 쓰다보니 카테고리 구분짓기가 너무 어렵다. 내가 정리를 잘 못하기 때문인 것..

group by 가 포함된 쿼리문에서는 group by가 중요하다. select survived, count(1) from titanic group by survived 쿼리가 위와 같다면.. 앞에 select에 있는 survived가 중요한게 아니라 group by에 있는 survived가 중요하다. SQL문의 select에서 survived를 선택한 건 뒤에 group by 에서 survived가 사용되기 때문이다.