테스형

친구들과 SNS에서 심리 테스트 결과를 신나게 공유하고 있을 때, 나도 하나 만들어서 친구들의 의견을 다양하게 넣고 즐기고(기회가 된다면 수익창출도 해보고)싶다는 생각을 했다. 결국은 아이디어 싸움이겠지만, 나는 꽤 그런 쪽으로 탁월한 재치가 있기에 걱정은 되지

서비스 플로우는홈화면 → 테스트 선택 → 질문 진행 → 선택 기록 → 결과 산출 → 결과 화면(이미지로 제공) → 공유이렇게 진행된다.테스트 선택 → 질문 진행 → 선택 기록 부분에 대해서 말하고 싶다.!피그마 덕에 간단히 금방 만들 수 있었다.와이어프레임아니고실제로이

과거의 나는 API 명세서의 개념을 API 서버의 기능 자체에 포커싱을 두고 명시하는 '기능정의서' 에 조금 더 치우져 생각했었다 .. 하지만 API 명세서라 함은 FE-BE간의 소통을 위한 혹은 API 서버 이용자에게 "무엇을 어떻게 요청하면 무엇이 어떻게 나옵니다

https://start.spring.io/Maven은 자바 프로젝트의 빌드 및 의존성 관리를 수행한다. XML 기반의 pom.xml을 사용한다.Gradle(Groovy/Kotlin)은 더 간결한 DSL을 사용하여 빌드를 관리한다. build.gradle 또는

안정적이고 효율적인 코드를 위해 Test 코드를 작성하려 하는데 2가지 문제가 생겼었다.Test 환경에서 Log4j2 가 활성화 되지 않는 것 이다 ..문제는 간단했다.현재 Gradle 설정 상에서 Lombok 의존성은 main 소스에만 적용되고, test 소스에는 자

메모리를 기반으로 한 DB로서 키값(Key-Value) 구조의 데이터 저장이 가능하며, 빠른 조회 및 쓰기를 지원해 주는 기능을 지니고 있다. 또한 다양한 데이터 구조를 지원하고, 비동기 처리 및 분산처리를 위한 기능을 제공하기 때문에 고성능 시스템에서 널리 쓰이고 있

프론트 서버를 따로 둘 예정이라Cors 설정을 위해 Spring Security를 추가한다.후에 로그인 기능 추가 혹은 사용자에게 여러 권한을 줄 때도 사용할 예정이다.우선 의존성 추가부터SecurityConfig 클래스로 설정을 해줘야겠다.application.pro

프론트 엔드는 Next.js 와 typeScript를 사용할 예정이다.프로젝트가 잘 만들어졌음을 볼 수 있다.localhost:3000 으로 접속하면업로드중..야호 !

궁극적으로 내 서비스는 자신의 테스트 결과 이미지를 SNS에 공유하는 2차 홍보의 롤도 가지고 있으니 이미지가 아주 필수적인 요소이다.(물론 모든 서비스에서 중요한 요소이겠지만 말이다.) AWS S3서버를 이용하여 이미지 서버를 독립적으로 운용할 예정이다. 한 기술

웹 서비스를 다 제작하였으니 이제 배포를 하면 된다. 내게는 FE, API, DB 이렇게 3가지의 서버가 필요하다. 이번 서비스는 FE/API+DB 로 구성하여 2개의 EC2로 배포 할 예정이다. EC2 검색인스턴스 시작이름 설정ubuntu로 설정프리티어를 제

이전 AWS 인스턴스 구축에서 만든 EC2 서버에 Docker를 설치해보자EC2 인스턴스에 Docker를 설치한 뒤, Git Action을 통해 Docker Hub에 올려둔 이미지를 docker pull하여 컨테이너로 실행하면 복잡한 서버 설정 없이도 쉽게 웹 서비스를

AWS EC2 인스턴스 구축 후 EC2 Docker 설치까지 마쳤다면, 이제 배포를 할 때가 왔다.GitHub Action 을 이용하여 Push 시 Master brach에 있는 프로젝트를 Docker 컨테이너를 이용해 AWS EC2 인스턴스에서 구동하게끔하는 자동화

AWS EC2 인스턴스 구축 후 EC2 Docker 설치까지 마치고, Github Action을 통한 AWS EC2 Docker 자동화 파이프라인 구축을 통해 배포까지 마쳤다.를 통해서 접속할 수 있다. 하지만 이는 Http 요청이며 보안되지 않은 형태이다.나는 원하는

AWS EC2 인스턴스 구축 후 EC2 Docker 설치까지 마치고, Github Action을 통한 AWS EC2 Docker 자동화 파이프라인 구축을 통해 배포까지 마쳤다. 도메인까지 구한 상태이다. 이를 Route 53을 통해 내 tst-FE EC2 서버와 연결

여러 과정들을 거친 결과 ..일주일 정도 시간을 써서 제작 할 수 있었다.https://tessbro.site콘텐츠는 2개정도 만들었다.이미지와 콘텐츠들은 GPT 를 통해서 만들었다.

테스트 플랫폼 : 테스형 서비스 구축 과정 시 Github Action을 통한 AWS EC2 Docker 자동화 파이프라인 구축에서 일어난 트러블 슈팅 모음 문서아무래도 .pem 키를 입력하는데에 문제가 생긴 것 같다..github/workflows/deploy.yml

테스트 플랫폼 : 테스형 서비스 구축 과정 시 Github Action을 통한 AWS EC2 Docker 자동화 파이프라인 구축에서 일어난 트러블 슈팅배포를 완료하고 프론트 주소에 접속하였더니 ..텅 -..API 서버와 연동이 잘 안된건지 DB서버에 연결이 잘 안된건지

테스트 플랫폼 : 테스형 서비스 구축 과정 시 Github Action을 통한 AWS EC2 Docker 자동화 파이프라인 구축에서 일어난 트러블 슈팅 모음 문서이 다음 진행은 레디스에 일부 정보를 저장하여 캐싱하는 프로세스이다.테스트 시작하기 ! 버튼을 누르면이런 흐

취준 활동 중 이지만,프로젝트를 개선하고 기술적 도전을 하여 개발자로서의 깊이를 늘리고자 리팩토링을 진행합니다.기존에 Notion으로 작성하였던 약식 산출물부터 갈아엎기로 했다.교육기간중 Google Sheet를 사용한 산출물이 더 체계적이기 때문이다.추가된 부분은로그

테스형 산출물비록 혼자서 프로젝트를 리팩토링 하지만, 체계적인 과정을 거치는게 후에 관리하기에도 편하고 회고할 때 유용할 것 같다.추가로 작성한 산출물은WBS기능 정의서커뮤니티는 너무 뻔하기에 우선 반려화면 설계서API 명세서 (진행 중)DB 설계서 (업로드 예정)데이

Figma를 활용하여 UI를 설계했다.생각보다 화면이 많이 나와서 당혹스러웠지만, 최대한 효율적이고 알차게 쳐냈다.개선된 약식 화면 설계서늘 느끼지만 개발보다 설계 단계가 더 머리아픈 것 같다. . . ㅎㅎ코테 준비와 프로젝트를 같이 하니까 조금 벅차지만, 시간을 효율

은 크게 2가지 방법이 있다.1\. Soft Delete (논리 삭제) : DB에서 데이터를 완전히 삭제하는 것이 아닌 특정 칼럼에 조치를 취해 사용자 입장에서는 데이터에 접근할 수 없도록 하는 방식2\. Hard Delete (물리 삭제) : 실제로 DB에서 데이터를

기존 서비스에서 자체 로그인 및 회원가입 기능은 충분히 구현한 경험이 있으며, 이번에는 사용자 편의성과 빠른 접근성을 높이기 위해 Google과 Naver 기반의 소셜 로그인만을 제공하고자 한다.사용자가 Google 또는 Naver(이하 GN) 로그인 버튼을 클릭하면

JPA 설계를 마친 후 서버를 구동시켰더니.tessbro 라는 계정이 CREATE가 권한이 없어 거절되었다고 한다.확인하여보니, tessbro 계정이 없는 것을 알 수 있었다.DB에 root 계정으로 접속해생성과 권한을 부여하였다.

아르바이트, 새로 잡힌 면접, 개인 일정, 예비군 훈련으로 개발 기간을 조율해야한다.아 ~ 맘 놓고 공부만 할 수 있던 대학생 때가 너무 그립다 ! !