Owen Labs

우리 회사 근처의 구내식당들은 매일 SNS를 통해 오늘의 메뉴를 공지한다. 점심시간마다 여러 계정을 확인하기가 귀찮은 나머지 해당 메뉴 게시글을 크롤링해서 이미지가 포함되어 있다면 텍스트로 변환한 후 메신저에 자동으로 알려주는 크롤러를 만들기도했다. 그 크롤러를 만들 때 사용한 OCR 라이브러리의 인식률이 떨어지는 것을 보며 더 좋은 방법이 없을까 하던 중 paddleocr이라는 라이브러리를 발견해서 적용해보기로했다. PaddleOCR 코드 작성 참고 https://yunwoong.tistory.com/249 https://github.com/yunwoong7/korean_ocr_using_paddleOCR 위 글을 참고해서 PaddleOCR 코드를 작성하고 구동해보았다. 맥북으로 실행하였을 때는 CPU..

JPA에서는 Select 쿼리를 생성하기위해 Specification이라는 것을 사용한다. Dto를 이용해 Specification을 손쉽게 생성할 수 있게 해주는 SpecificationBuilder를 구현해보려고한다. 왜 만들게 되었나? JPA를 이용해 개발하다보면 한가지 의문에 도달하곤 했다. ORM은 개발자로 하여금 SQL을 작성하지 않게 해준다는 것인데. 결국 SQL이 아닐 뿐 JPQL, QueryDSL 등의 형태로 여전히 쿼리를 작성하고 있다. 본질적으로 '쿼리'에 대한 이해가 전혀 없어도 비즈니스 로직을 구현하는 데에 문제가 없어야 정말 쿼리로부터 벗어났다고 할 수 있을 것이다. 그렇게 SpecificationBuilder라는 것을 처음 생각했다. SpecificationBuilder의 이점..

백엔드 1차 개발 범위 중 저번 글에서 다루었던 인증, 비즈니스 로직(Application Layer)에 관한 내용은 제외하고 나머지 아래 항목에 대해 이번 글에 작성하려고 한다. - Presentation Layer - Persistence Layer - 기타 초기 설정 Presentation Layer 1차 범위 내에서 Presentation Layer에 힘을 싣고 싶은 부분은 response body의 통일성이었다. 너구리 소굴 API 내에서는 ErrorResponseDto 형태로 ResponseBody를 제한하려고했다. data class ErrorResponseDto( val timestamp: String, val status: Int, val error: String, val message:..

2022.07.21에 작성한 글에서 너구리소굴 백엔드 프레임워크를 nest.js에서 Spring boot로 변경하기로 결정했었다. 그리고 2022.08.29일 약 39일동안 백엔드 1차 개발을 수행했는데, 1차 범위에서 수행했던 작업들과 감상을 간단하게나마 기록하려고한다. 작업을 요약해보자면 아래 다섯가지로 분류할 수 있다. - 인증 - 비즈니스 로직(Application Layer) - Presentation Layer - Persistence Layer - 기타 초기 설정 이 중 인증과 비즈니스 로직에 대한 회고를 이번 글에서 작성하려고 한다. 인증 WebSecurityConfigurerAdapter is Deprecated 1차 개발 범위 내에서 가장 오랜 시간이 걸렸던 작업 범위는 인증 도메인이었..

이전 게시글에서 백엔드 프레임워크를 Nest.js로 설정한 이유에 대해 기술했다. 두 달이 조금 안되는 기간 동안 프레임워크에 대해 충분히 익히지 못한 상태로 개발에 착수하기도 했고, 업무중에는 Spring Boot를 사용하다 보니 Nest.js의 단점이 더 두드러졌다. 그동안 개발하며 본인이 느낀 Nest.js의 단점은 아래와 같다. 1. DI 대상 객체들을 수동으로 등록해주어야 한다. Spring Boot와 비교했을 때 Nest.js의 가장 큰 단점은 DI 설정에 귀찮은 타이핑이 많이 들어가야 한다는 것이다. Spring Boot에서는 클래스를 정의한 뒤 어노테이션을 DI 대상 구현체에 하나, DI 대상 변수에 하나. 총 두 개의 어노테이션 만으로 별도의 추가 작업 없이 DI가 가능하다. 하지만 Ne..

너구리소굴 개발 스펙 Frontend - Vue.js 또는 React.js 사용 예정 개인적으로는 사용해본 경험이 없는 React.js쪽을 선호한다. 큰 이유는 없고 함께 시작하는 동료가 프로그래밍 경험이 전무하다는 것을 고려하여 프론트-백엔드 언어를 하나로 통일하고자 JavaScript를 선택하였다. 그리고 언어를 통일하면서도 실제 어플리케이션은 구분하였는데, 이는 MSA 형태를 지원하고자 결정한 사항이다. Backend - Node.js (Express or Nest) or Kotlin(Spring boot) 중 고민 MVP까지 타이트한 일정을 소화하기 위해, 그리고 초심자인 동료가 언어의 장벽에 막히는 것을 방지하고자 Nest.JS를 선택했다. 그리고 추후 타 서비스를 개발하면서 인증, 파일처리 등..

사실 이번 포스트에서는 서비스 프로바이더 파일에 대해 다뤄보려했는데, 파일 만으로는 동작이나 구조를 유추하기 힘들다고 느꼈다. 라라벨 공식 문서를 읽어보다 보니, 서비스 프로바이더를 이해하기 위해서는 서비스 컨테이너를 이해해야하고, 이를 이해하기 위해서는 라라벨의 Request Lifecycle에 대해 먼저 파악해야 할 것 같다고 느껴 이번 포스팅을 진행했다. 라라벨의 Request LifeCycle 1. index.php 라라벨 애플리케이션에서 모든 요청은 public/index.php 파일로부터 시작된다고 한다.

이전 게시글 [PHP | Laravel] Laravel Framework를 이용한 MVC 패턴 구현 - 1. 개발환경 구성 이직하는 업체에서 PHP를 익혀오면 좋을 것 같다고 요청해서 간단하게라도 실습을 진행해 보려고 한다. 본인도 알아보면서 진행하고 있어서 본문은 계속 수정될 수 있다. 혹시라도 잘못된 정보 dev-err.tistory.com 이전 포스트에서는 PHP/Laravel 개발환경을 구축하고 프로젝트를 생성하는 부분까지 진행했다. 이번에는 생성된 프로젝트의 구조를 파악하고 라라벨 앱을 실행해보려고 한다. 라라벨을 처음부터 공부하는 사람이 작성하는 포스트입니다. 잘못된 내용은 댓글로 남겨주시면 수정하도록 하겠습니다. 1. 프로젝트 구조 먼저 터미널을 이용해 생성된 라라벨 프로젝트 디렉토리에 접근..