또 뜯어고쳤다.num1과, num2, operator 입력값을 사용자로부터 받아온다.result라는 상수를 통해 Calculator클래스의 operate함수에 num1, num2, operator를 보내준다.//calculator.ktclass Calculator {
html과 css 기초이전에 다 해봤던 것들이라 크게 어려움은 없었다.오랜만에 해보니 조금 어색하긴 했음
구글 firebase 활용아래 태그로 사용하였을 때 사진과 같이 내가 원하는 순서에 들어가지 않음브라우저 > db > 브라우저 순서로 불러오며 순서 개념이 사라지나 ??실제로 firebase에는 순서가 상관없이 데이터가 저장되고 있었음firebase에서 읽어오는 순서대
나는 가입하기 클릭 시 표시되는 팝업창을 만들었다.db는 팀원의 firebase를 사용하였는데, 어딘가 문제가 있는 것 같다.찾아보니 firebase는 문서의 필드값에 undefined를 허용하지 않았다.adddoc() 함수를 호출할 때 어떠한 값이 undefined
메인 화면에서 팝업창을 사용하지 않고, 현제 페이지 내에서 정보들을 받아 db로 보내기로 했다.검색하니 html, css, javascript를 사용한 modal을 확인하여 사용해 보기로 했다.처음에는 한 줄에 여러 항목이 들어간다거나,생년월일을 표시하는 데에 있어서
어제 창모드와 작은 화면에서 modal의 윗 부분이 짤려서 보이지 않는 현상을margin 조정과 scroll 효과 추가를 통해 해결했다.이제 작은 화면에서도 아래와 같이 표시되며 모달 팝업 내에서의 스크롤을 할 수 있게 됐다.삭제 버튼을 추가할 때에는 등록하기 버튼에서
3일간 제작한 페이지를 배포했다.https://doojoo9999.github.io/projectB01/CSS를 통해 눈내리는 효과도 추가했다 !처음 기획했던 디자인과는 많이 차이가 난다."일단 해보자"는 마음 가짐으로 시작한 프로젝트인 만큼각자가 원하는 사항
다른건 그래도 한 눈에 이해했는데 역시나 반복문은 어느 언어를 봐도막 쉽게 와닿지가 않는다.for문 for (요소 in 리스트) {로직}for (index in start untill(.. 대체가능) last)로직}while문while (if \~~) {로직i++ (증
3주차 강의까지 듣다가 문득 내가 2주차를 완벽하게 이해했나? 라는 생각이 들어다시 2주차를 켰다.연산자와 반복문을 배웠으니 계산기를 만들려고 한다.유저가 원하는 연산자를 입력하여, 그에 맞는 결과값을 보여주고이를 반복하기 위해 var programContinue 라는
하루 종일 열심히 만들어 보긴 했는데. 잘 한건지 모르겠다.class Calculator { val addOperation = AddOperation() val subtractOperation = SubtractOperation() val multipl
마션의 첫 문장밖에 내 상황을 설명할 길이 없다.나는 꺾여버렸다.중요한 것은 꺾이지 않는 마음이지만매우 중요함에도 이미 꺾여버린 마음이다.class Calculator { var multiplyOperation = MultiplyOperation() //: Abs
예외처리는 매우 중요하다.프로그램을 실행하기 전 알 수 있는 컴파일 에러를 오류,실행 중 발생하는 런타임 에러인 예외가 발생할 수 있다.예외 사항에 대한 처리가 필요하다.fun test() { try { 예외가 발생할 수 있는 코드 } catch(예외종류)
먼저, Android Studio를 사용하다가 IntelliJ를 설치했다.프로그램 로딩 속도가 빨라지고, 편의성 부분이 좋아진 것 같다.구현 사항을 확인하고 메인부터 만들었다.메인 메뉴 1~4와 0번을 입력받아, 각 메뉴로 이동하게 설계했다.호출된 메뉴 클래스는 세부
하루종일 ArrayList와 싸웠다.처음 내가 의도한 바는 추상 클래스에서 불러오는 상속 클래스들의 정보를추상클래스에서 받아올 때 list에 넣고 싶었다.추천도, 이름, 가격, 세부 정보를 불러온다.몇 시간동안 애먹었는데, 추상 클래스에서는 리스트를 사용할 수 없다고
큰 문제가 있다내 메인 중 일부인데, 원하는 버거를 선택해서 장바구니로 옮기는 과정이다.버거의 종류가 10만개라고 가정하면when문으로 10만줄을 쓸 수는 없다.일단 이걸 대체할 수 있는 방법이 있는가? 가 첫 번째 문제다.두 번째 문제는, 유저가 음식 메뉴를 선택해서
인터페이스를 사용하는 이유.추상화는 강의를 통해 배웠고 실제로 써먹고 있었는데인터페이스는 전혀 감이 안왔었다.예제를 통해 인터페이스와 추상클래스의 차이점을 확인할 수 있었는데,인터페이스는 말그대로 틀밖에 없고, 틀과 일부 기능을 구현하는 추상클래스와는어느정도의 차이가
>DI (의존성 주입) > >DI(Dependency Injection)는 의존성 주입이라는 뜻으로, 객체 지향 프로그래밍에서 발생하는 객체 간 의존 관게를 효과적으로 관리하기 위한 방법 중 하나이다. 간단한 예시를 통해 DI가 필요한 사유를 확인해 보았다. F
APIREST (Representational State Transfer)상태의 전이 (State Transfer)를 표현(Representational)하기 위한 HTTP 아키텍쳐 스타일.URI(Resource) - 먼저 URI를 통해 Resource 이름을 표현 (
뭔가 본격적인 시작에 앞서 이제 안오면 섭섭할 '위기'가 다시 찾아왔다.코드를 구석구석 해석해 보려고 한다.어노테이션이란?먼저, @로 시작하는 어노테이션은 컴파일러나 프레임워크 등에게 특정한 의미나,기능을 전달하는 역할을 한다.@RequestMapping 어노테이션은
오늘 인터페이스를 처음 사용해 보았다.추상 클래스와 비슷한 역할을 한다는 점은 알고있었는데,정확히 어떤 차이가 있는지 알아보았다.인터페이스인터페이스는 구현 부분이 없는 클래스이다.인터페이스의 생성자를 만들 수 없고, 인터페이스의 객체 역시 직접 만들 수 없다.어떻게 인
내가 알고있던 DB에 대한 데이터를 풀어보고, 기억하고 있던 내용에 대한 상세 자료를 찾아보았다.Database는 '데이터의 집합'이다.기본적으로 매우 많은 데이터를 처리한다.나는 간단하게 1~10까지의 수를 예시로 썼는데 1~10억개의 수라고 생각해보자.나는 1~10
JPA는 객체와 Database를 매핑한다 (연결한다)JPA가 객체 지향적으로 데이터베이스를 다루는데,그 때 테이블과 맵핑되는 객체가 바로 Entity다.@Entity라는 어노테이션을 지정함으로써JPA에서 관리하는 객체로 작동한다.@Entity@Table(name =
웹 API에서 요청을 하는 방식으로 주로 사용되는 param, query, body는 각각 데이터를 전송하는 방식과 목적에 차이가 있다.Param(Path Parameter)용도 : 주로 특정 리소스나 객체를 식별하는 데 사용된다.예시 : /users/{userId}
새로 시작할 프로젝트인 gogoCard Application의 API를 설계했다.가이드라인을 참고하여 작성했는데, 제대로 된 API 설계인지는 잘 모르겠다.이 기능에서 어떠한 값을 요청하고 회신받는지에 대해 고민할 수 있었고,고민한 내용을 스프레드시트에 간단하게 풀어냈
JPA에서 deleteById와, delete의 차이점을 알아보려 한다.deleteById와 delete는 Spring Data의 API 중 CRUDRepository interface에 정리되어 있다.어떤 차이가 있을까?데이터를 삭제할 때 두 가지 방식 모두 동일한
@OneToMany, @ManyToOne 어노테이션은 1:n과 n:1 관계를 설정하는 어노테이션이다.오늘 comment 기능을 구현하며 cardId를 불러와야 했는데,이 어노테이션을 잊고 있다가 어떻게 구현하지... 라며 한참의 시간을 소비했다.연관관계는 아래와 같다1
API에서 요청에 따른 응답 중 comments를 답해야 할 상황이 있어 위 코드를 추가했다.cardResponse에서 List CommentResponse를 불러오는 이유는CommentEntity와 CommentResponse가 서로 다른 클래스이기 때문이다.나도 처
1단계. 프로젝트 아이디어 구상하기2단계. API 명세 작성하기3단계. ERD 작성하기4단계. 와이어프레임 작성하기게시물 CRUD 기능 \- 게시물 작성, 조회, 수정, 삭제 기능뉴스피드 기능(메인 페이지/전체 조회 페이지)\*\* \- 뉴스피드 페이지
오늘 팀원 전체가 DB 연결이 안되는 이슈가 있었다.
https://obsidian.md마크다운 문법2.1. 헤더Headers큰제목: 문서 제목This is an H1This is an H1작은제목: 문서 부제목This is an H2This is an H2글머리: 1~6까지만 지원This is a H1This
이번 주는 팀원들과 팀 프로젝트를 진행했다.팀 REVIEWERS일상 중 모든 내용을 리뷰할 수 있는 페이지를 만들고자 했다.나의 일상을 리뷰할 수도, 듣고 있는 노래를 리뷰할 수도, 어제 본 영화를 리뷰할 수도,지금 쓰고 있는 전자 기기를 리뷰할 수도 있는 페이지를 만
최근 진행했던 프로젝트를 결국 마침표를 찍지 못하고 끝이났다."나름 잘 했다" 라는 기준에는 들어갈 수 있을지언정"만족했나?" 라는 질문에는 답하기 어려울 것 같다.Spring Security 사용 중 발생했던 문제를 해결해 보려고 몇 번이나 찾아봤지만결국 해결하지 못
Principal : User의 식별자로, userId, Email과 같은 정보를 담고 있는 객체Credentials : Password와 같이 중요한 정보로, 유출 방지를 위해 인증된 이후 삭제함Authorities : 권한 정보로, 보통 Role 혹은 Scope로
비영속 (new/transient)\-> 영속성 컨텍스트와 전혀 관계가 없는 새로운 상태영속 (managed)\-> 영속성 컨텍스트에 관리되는 상태준영속 (detached)\-> 영속성 컨텍스트에 저장되었다가 분리된 상태삭제 (removed)\-> 삭제된 상태1차 캐시
QueryDSL을 의존성에 추가하였다면,JPAQueryFactory를 빈으로 사용할 수 있도록 설정해 주어야 한다.기존에는 UserRepository가 JpaRepository를 상속하고 끝이었는데제법 특이한 구조로 바뀐다.위 코드를 보면 CardRepository가
SELECT 문의 기본 형식 SELECT - 조회할 데이터 지정 WHERE 조건 적용 서브 쿼리 서브 쿼리는 2개의 SQL 문을 하나로 만든다.
백오피스를 지난 5년간 가장 많이 사용한 사람 중 한 명이 아닐까.근데 막상 만들어 보려니 감이 잡히지 않는다.운영툴을 사용해 유저의 데이터를 직접 조작하거나, 보관함을 통한 아이템 추가, 삭제 등의 작업과 웹사이트의 백오피스에는 다소 큰 차이가 있었다.먼저, 작성했던
아마존 S3를 이용해 보려고 하다가 실패했다.실패 원인은 다양했는데 포기한 가장 큰 이유는 많은 예제들 중에 내가 써먹을 수 있을 만한 예제를 찾지 못했다.그래서 Supabase DB를 사용하고 있으니, Supabas Storage도 사용해 보자! 라고 생각했다.일단,
인증된 유저만 진행할 수 있는 게시글 작성, 삭제, 파일 업로드 등에서userId를 반드시 따로 request에서 받아와야 하는가?라는 생각에 어차피 토큰에 저장되어 있을 텐데 받아오자. 라고 생각했다.SecurityContextHolder에 저장되어 있는 유저id를
1
이전 비밀번호를 관리할 수 있는 기능을 추가했다.검증 과정을 모두 마치면, UserEntity의 oldPasswords 리스트에 변경한 비밀번호를 추가한다.UserEntity에는 아래와 같이 추가했다.@ElementCollection해당 필드가 '컬렉션'이라는 것을
소셜로그인과, 사이트 회원가입을 통해 저장되는 데이터가 달라,각자의 테이블에 데이터를 보관했다.처음에는 userId를 가지고, requestParam으로 플랫폼을 받아야 해당 플랫폼의 userId를 조회했다.이 방식이 너무 비효율 적이라고 생각했고, userId를 입력
Docker의 image는 그림 파일을 말하는 것이 아니라, 컨테이너를 생성할 때 필요한 요소이며, iso 파일과 비슷한 개념이다.도커에서 사용하는 이미지 이름은 아래의 형태로 구성된다.저장소 이름: 이미지가 저장된 장소. 이름이 명시되지 않으면 도커 허브의 공식 이미
QueryDSL은 쿼리 생성에 특화된 프레임워크로, JPA 프레임워크와 분리되어 있다.QueryDSL은 Entity 정보를 담은 Q타입 클래스를 사용한다.QType class는 QueryDSL 설정이 성공적으로 진행되면, @Entity가 붙은 클래스를 찾아서 자동으로
이메일 회원 가입시 사용 할 메일 인증을 추가했다.개발 과정에서 여러 에러들이 표시됐었는데,다행히 빠르게 문제를 해결할 수 있었다.내가 기존에 입력했던건 아래와 같다.properties 위쪽은 다 똑같았는데, 메일 발송이 안돼서 다시 찾아보았다.반드시 설정해 줘야하는
1편 보러 가기 Utillity Class 만들기 개선점 1. @Transactional 1에서 업로드한 내용 중 메일 발송이 안되던 점은 트랜잭션 어노테이션을 삭제한 뒤 문제가 해결되었다. 아마 같은 요청이 반복되었을 때, 하나의 요청으로 처리한 것이 아닐까
JPA를 사용하여 도메인을 관계형 데이터베이스 테이블에 매핑할 때,공통적으로 도메인들이 가지고 있는 필드나 컬럼들이 존재한다.대표적으로 생성일자, 수정일자, 식별자 같은 필드와 컬럼이 있다.도메인마다 공통으로 존재한다는 의미는, 결국 코드가 중복된다는 것이다.Creat
람다식 (Lambda Expression) ? 람다식은 함수를 하나의 식으로 표현한 것이다. 함수를 람다식으로 표현하면 메소드의 이름이 필요 없기 때문에 익명 함수의 한 종류라고 볼 수 있다. 기존에는 함수를 선언할 때 아래와 같이 선언하였다. 람다 방식에서는 메
coalesce (합체하다)COALESCE (A, B) 는 A와 B를 병합하는 것이다.왼쪽의 Null값에 B가 들어간다즉, FREEZER_YN 의 Null값에 N을 삽입하여 문제를 해결했다.SELECT COALESCE(A, '---') FROM test;위와 같은 방식
메일 인증 시간을 정해주었다.Service단에서 15분이 넘은 인증 코드는 유효하지 않도록 처리했다.1) Request에 포함된 이메일을 사용하여 mails 테이블에서 이메일이 같은 데이터를 DB에서 찾는다.2) 현재 시각을 now에 저장한다.3) DB에서 찾은 aut
@RestControllerAdvice 를 사용해서 모든 RestController 의 예외를 공통화해서 처리해주세요!이 어노테이션은 Spring MVC에서 제공하는 어노테이션이고전역적인 예외 처리를 담당하고 있다.클래스에 적용시키면 해당 클래스는 전역 예외 핸들러로
JPA에 대해 심화 내용을 학습하던 중, RDBMS를 사용하면서도 FK를 가지지 않는 회사들이 많다는 내용을 확인했다.나도 겪었던 문제지만, post_id를 fk로 가지는 comment 를 작성할 때post가 없을 때에는 comment가 작성되지 않는다.이게 단순히 1
학습 동기 발송하고 인증되지 않은 이메일을 삭제하기 위해 스프링 스케쥴러를 사용했다. 사용 방법 1. 스케쥴러 활성화 먼저, 메인 어플리케이션 클래스에 @EnableScheduling을 통해 스케쥴러를 활성화 시켜준다. 2. 시간 설정 이메일이 자동으로 삭제될
테스트 코드를 작성하고 있다.Controller에 대해 테스트를 진행해 보고 싶은데, 어떻게 테스트 코드를 작성해야 되는지 전혀 감이 안온다.테스트가 완료될 때 까지 계속 변경된 내용을 해당 포스트에 수정할 예정이다.
사실 CRUD는 이제 뭐 할 게 없다.요청하는 수 만큼의 쿠폰을 생성한다.쿠폰 발급시에는 아래와 같은 정보가 필요하다content : 쿠폰 내용 (런칭 기념 쿠폰, 전사 임직원 쿠폰 등)couponNumber : 쿠폰 번호 (16자리의 개별 난수 쿠폰 번호, 중복 불가
coupon을 입력했을 때 request로 불러온 내용과 일치 여부를 확인한다.만약, 쿠폰 번호가 같고, avilable이 true라서 사용이 가능할 경우쿠폰 번호에 대해 사용 불가 처리와 함께 등록된 유저 정보를 쿠폰 데이터에 담는다.개별 쿠폰이기 때문에 위와 같이
현재 쿠폰을 등록하는 API의 TPS가 12로 매우 낮은 수치이다.TPS는 Transaction Per Second로, 초당 처리할 수 있는 트랜잭션을 의미한다.평균 테스트 시간도 요청부터 응답까지 약 58초가 걸리는 상황이라정상적인 서비스가 가능하다 라고 보기 어려운
학습 동기 마지막 접속일로부터 6개월간 서비스 이용이 없는 유저의 정보를 분리하여 보관한다. 먼저, 분리할 대상을 선별하기 위해 Spring Scheduler를 이용하여 MemberStatus를 SLEEPER 로 변경하기로 했다. (관리자나, 스트리머 모두 동일) 내