TIL

Firebase의 FireStore의 함수들에 대하여 학습을 진행하였다.위 케이스로 알 수 있는 것은 doc 함수의 반환 값은, 얻고자 하는 데이터의 위치를 가지고 있는 데이터인것 같다. (편지 봉투를 떠올리면 이해하기 편하다 생각된다.)이후 함께 사용하는 get 또는

코드 작성을 시작함과 동시에 아름다운 에러가 날 반겨주었다.구글링을 해보아도 마땅한 해결법이 나오지 않았다.cdn으로 할 때는 javascript module로 가져오는 형식이 안되는 건가..? 하는 의문을 가지고 html file에 firestore에서 제공해주는 설

개발을 하던 도중 문득 Vanilla Javascript에서는 QueryString을 어떻게 가져오는지가 궁금했다.찾아보니 javascript에서는 location이라는 객체가 있고, 그 객채의 attribute인 search에 query string이 담겨져 있었다.

국비 과정을 들으며 미니 프로젝트를 하던 도중 일어난 일이다.만들어 두었던 페이지를 다른 용도로 사용하기위하여 refactoring이 필요한 상황이었다.firestore의 crud 기능을 전부 module화 시켜 js파일로 따로 빼놓았고, 그 페이지에서만 동작하는 코드

미니 프로젝트가 끝이 났다.프로젝트를 완성시키고 발표를 하는 과정에서 여러 에러를 겪게 되었다.가장 먼저, 디자인 관련하여 slide bar를 제작하기위하여 flickity library를 사용하였는데 slide bar의 drag 기능으로 인하여 내부 Item의 inp

Kotlin으로 Programmers의 알고리즘을 풀다 생긴 일이다.문제이번에 kotlin을 사용하며 문제를 푸는 도중 삼항연산자를 사용하려 하니 곧바로 세상에서 제일 보기 싫은 빨간줄이 생기기에 도대체 왜? 라는 생각이 들어 곧바로 kotlin 삼항연산자 라고 구글링

알고리즘 문제를 kotlin으로 풀다 2차원 배열이 필요해져서 kotlin의 2차원 배열 선언법에 대해서 알아보았다.그런데... 어라...? 기존 사용하던 언어와는 색달랐다.내가 사용해 본 언어중에 이런 식으로 선언하는 언어가 있을까? 하고 찾아보니 dart정도가 가장

과제 회고겸 설명

Kotlin + Spring Boot를 시작하며 발생한 에러들에 대해서 적어보려 한다. Spring Initializr를 통하여 일단 프로젝트를 생성하였다. 가장 처음 보고 놀란 것은 위와 같은 형태였다. > SpringBootApplicatioin > cla

오늘은 java의 static과 kotlin의 companion object, object class에 대해서 이야기 하려고 한다.오랜만에 어셈블리어를 보다가 문뜩 jvm으로 돌아가는 것은 어떻게 돌아갈까 알아보던 중 static에 대해서 큰 오해를 하고 있었다는 사실

우아한 형제 기술 블로그오늘 저번 과제에 대한 피드백을 받게 되었는데, Git연습이 전반적으로 필요하다는 평을 받아 오늘은 Git을 나눠 작업하는 것을 해보았다.사실 이전까지는 git을 사용할때 main에서 작업하고 전부 작업이 끝나거나, 아니면 도중에 다른 pc에서

오늘은이 놈에 대해서 말해보려 한다.개인과제를 끝내고 pull을 하는 순간 또 에러가 발생하였었다.같은 에러가 아닌 이번에는 또 다른 에러였는데 위와 같은 에러가 발생하였다.사실 완전히 같은 에러는 아니고 의도적으로 발생시킨 에러여서 세부 사항은 다를 수 있다.검색을

오늘은 Sparta 국비 교육을 들으며 튜터님과 방향성에 대한 이야기를 하던 도중 아키텍처와 Multi Module에 관한 이야기와 미션을 받게 되었다.모르고 넘어갔다가 나중에 알게 되었으면 정말 눈물을 흘릴 정도로 재밌어 보였다.사실 튜터님이 없었다면 관련 KeyWo

일단 Multi Module을 만들어 보기로 하였다. 그 전에 잠깐 Intellij 이야기를 해보려 한다. 우선 프로젝트를 만들고 아무 모듈이나 바로 생성해보았고, 이후 그 모듈을 삭제하려고 하니 Intellij에서는 모듈을 제거 하시겠습니까? 파일은 삭제되지 않습

이번 주차부터 Kotlin과 Spring Boot에 대하여 학습을 진행하게 되었다.우선 이번 주차 과제의 목표는 Todo App 만들기이다.spring:datasource:url, username, password의 경우 gitignore + 관리의 편이성을 원하여 s

Spring Boot ResponseDto를 만들던 중, data class를 사용하게 되었는데 값이 제대로 전달되지 않아 잠시 생각해봤더니 getter를 기반으로 전송된다는 것을 전에 겪어봐서 바로 떠올릴 수 있었는데, kotlin에서는 어떤 방식으로 사용이 가능한가

Swagger를 작성하던 도중 RequestBody 부분의 property를 직접 지정해줘야 하는 일이 생겼다.새로운 Schema를 정의해 줄 때 어떤식으로 검색을 해야할지 몰라 무지성으로 시도해서 성공했다.덕분에 시간은 날렸지만 오랜만에 이런 저런 뻘짓을 많이 한것

|name|usage| |:---:|:---:| |prefix|Property의 접두사| |name|Property의 이름| |havingValue|Property의 값이 이것과 일치 하였을 때 통과 시키기| |matchIfMissing|값을 찾지 못하였을 때 Co

Sprata에서 개인과제를 진행하던 도중 튜터님과 이야기를 나누게 되었는데, 그 때 코드에 대한 이야기와 더 줄일 방법에 대한 이야기를 하게 되었다.그리고 찾게 된것이 trailing Lambda를 사용하는 방식이었다.일단 Body안에서 Service를 부르는 것부터

dto를 그냥 class를 사용하다 data class로 변경하면서 생긴 일이다.data class로 바꾼 이후 동작을 확인하던 도중 validation Exception이 제대로 작동하지 않아 무슨 일인가 살펴보니위와 같은 형태일 때 Null값이 아닌 대체 값으로 0

Project Git Hub이번 Spring Boot 과제를 받고서 진행하면서 느낀점에 대하여 적어보려 한다.객체 지향에 대한 이론, 개념, 지향점에 대하여 모른 채로 코딩을 해왔는데, 이번 과제를 통하여 튜터분들과의 대화와 강의를 통하여 조금 알게 된 것 같다.위 사

오늘은 kotlin 테스트 코드를 보다가 every와 coEvery에 대한 이야기를 접하게 되어 알아보았다.suspense 함수에 대한 mock 하여 작업할 때 쓰는 것이 coEvery라는 사실을 알게 되었고, 저것을 보자마자 webFlux인지 webMvc인지 궁금해지

국비에서 과제를 진행하던 도중 발생한 일에 대하여 이야기 해보려한다.스프링의 DI와 IOC에 관한 이야기 세션을 진행하던 도중 마지막에 test코드를 보여주었는데 coEvent라는 함수를 통하여 테스트를 진행하던 것을 보았고, 어? 그러면 Spring Mvc에서 비동기

새벽에 runBlocking과 async가 내가 생각한 형태가 맞는지 궁금해져 코드를 보던 도중 한 가지 떠올라 실험을 해보았다.공식 문서에는 구현부가 없기에 그냥 내가 생각하던 방식이 맞겠거니 하고 넘기기로 하였다.그런데... 어라..?이 부분이 눈에 띄었다.사실 이

이번 주는 팀 프로젝트를 시작하게 되어 협업 과정에서 팀장을 하게 되었고 프로젝트 설계를 먼저 진행하게 되었는데 그 과정에서 있었던 일에 대해 말해보려 한다.우선 DDD 구조를 가지고 가도록 하였는데 왜 이것을 채택하였는가에 대해 말해보려 한다.협업에 좋은 구조라고 판

오늘은 프로젝트를 진행하던 도중 문뜩 든 생각에 대하여 이야기 해보려 한다.kotlin을 보면 불변성을 매우 중요하게 여기고 있다고 생각이 들어, 그렇다면 jpa의 entity도 불변성을 지켜야 되지 않을까? 라는 생각으로 시작이 되었다.지키면 어떤 것이 좋냐를 생각했

오늘은 이번주에 팀 프로젝트를 하며 했던것에 대하여 적어보려 한다. 우선, 우리 팀은 과제 중 기초 사항만 구현하기로 하였고 학습과 경험에 중점을 두는 방향으로 진행을 하였다. 그래서 내가 택한 것은 DDD와 Presentation Layer였다. 이전 글에서도 작

강의를 보고 테스트 코드를 짜며 일어난 일이다.우선 강의를 기반으로 짜게 된다면 이런 형태가 나오는데, 나는 현재 postApiService를 제대로 구현하지 않았다. 어차피 Mocking해서 하는데 구현할 필요또한 느끼지 않았으니까.그런데 흠... 이상하다.mockM

오늘 할 이야기는 이전 글의 연장선에 가까운 이야기이다.우선, 이전글에서는 it에 모든 것을 몰아주는 형태였는데, Describe Spec과는 거리가 멀어보여 다시 refactoring 함과 동시에, 한글이 깨지는 상황과 배열에 대한 처리 방법에 대하여 글을 적어보려

Service를 Test하는 과정에서 생긴 일이다.

Repository 테스트 코드를 작성하는데 마지막에 entityManager.flush를 해줘야지만 Query문이 보인다.beforeTest에 DB에 직접 접근을 하면 Transaction 범위 내에서 사용하라고 말한다.그런데 it이 여러개일 경우, 우선 before