오늘 해결한 문제, 새롭게 배운 기술, 문득 떠오른 생각.
당신의 경험이 누군가에게는 다음 한 걸음이 됩니다.
완벽한 글이 아니어도 괜찮아요.
오늘의 작은 배움부터 남겨보세요.
React 채팅 프로젝트를 Electron 데스크톱 앱으로 실행 React와 Vite로 만든 채팅 프로젝트를 Electron으로 감싸 데스크톱 창에서 실행해 봤다. 프론트엔드 폴더에서 Electron을 설치했다. npm install -D electron package.json에는 진입점과 실행 명령을 추가했다. 기존 스크립트는 그대로 유지했다. { "main": "electron/main.cjs", "scripts": { "electron": "electron ." } } main.cjs 파일을 생성했다. co
프로그램 구조 React, Spring, Websocket, LiveKit을 이용해서 HTTP -> Spring : 로그인, 방 생성, 음성에 참여하는 토큰 생성 WebSocket -> Spring : 실시간 메시지 LiveKit : 실시간 음성 ERD WebSocket 로그인 후 웹소켓 연결 Spring Security의 서버 세션 방식으로 로그인을 처리한다. 로그인에 성공하면 서버는 인증 정보를 HttpSession에 보관하고, 브라우저에는 세션을 식별하는 JSESSIONID쿠키를 전달한다. HttpSession에 로그인 정
추가한 기능 날짜별 진료 완료 환자 조회 수납 금액 직접 입력 현금, 카드 결제수단 기록 미수납, 수납완료 표시 추가된 테이블 payments id - 기본키 encounter_id - 진료 ID amount - 금액 method - 결제수단 received_by_id - 수납 처리 직원 paid_at - 수납 처리 시각 결과물 수납 전 Sping의 역할 분리를 통해 admin과 간호사 일 때만 수납 관리가 활성화 되게 만들었다. 수납 후
이번에 추가한 기능 약품 검색 및 처방: 약품 코드 데이터를 불러오고, 약품 검색 후 투여량, 횟수, 일수, 용법을 입력해 처방 저장 검사, 처치 요청: 진료 중 검사나 처치 항목과 요청 사항 등록 수행 상태 및 결과 관리: 요청 -> 수행 중 -> 완료 상태 관리, 결과 입력과 요청 의사의 확인 환자 과거 기록 조회: 이전 진료의 SOAP, 진단, 처방과 검사, 처치 기록 확인 추가된 테이블 medications : 약품 기준 정보 encounter_prescriptions : 진료별 처방 내역(투여량, 단위, 횟수 등
이번에 추가한 기능 기존에는 진료기록을 하나의 note 필드에 자유롭게 작성했다. 이번에는 기록을 목적에 따라 구분할 수 있도록 SOAP 형식으로 변경했다. 접수할 때 입력한 방문 사유인 reason은 별도로 유지하고, 필요하면 S 항목으로 가져올 수 있도록 했다. 상병코드를 검색해 해당 진료의 진단으로 등록할 수 있도록 했다. 병원의 당일 운영 현황을 한눈에 확인할 수 있도록 대시보드를 구현했다. 대기 환자는 접수 순서대로 최대 6명까지 보여주고, 대기 시간이 30분 이상이면 강조했다. 오늘 미접수 예약도 시간순으로 최대
ERD EMR 프로젝트의 기본 흐름인 환자 등록 -> 예약 또는 당일 접수 -> 진료 대기 -> 진료 완료를 구현했다. 데이터 처리 동시 요청으로 중복 접수가 발생하지 않도록 트랜잭션과 잠금 처리를 적용했다. 예약과 진료기록 수정에는 버전 검사를 사용해 다른 사용자의 변경 내용을 덮어쓰지 않도록 했다. @Lock(LockModeType.PESSIMISTIC_WRITE) @Query("select p from Patient p where p.id = :id") Optional<Patient> findLockedById(@P
JPA N+1 문제 해결 내 예매 내역을 조회하는 단순한 API에서 콘솔창에 SQL 쿼리가 20개 이상 쏟아지는 현상을 발견했다. Fetch Join을 사용해 해결했으며, 혹시 몰라 배치 사이즈도 추가했다. 발생한 이후는 단일 테이블만 조회 -> Lazy로 설정되어 있기 때문에 비어있는 객체를 불러옴 -> JPA가 DB에 필요한 데이터들을 SELECT로 계속 조회 적용한 코드 @Query("select distinct r from Reservation r " + "join fetch r.schedule s "
토스 모의결제 API에 연결, 좌석 선정에 대해 여러가지 방법을 사용해서 테스트를 해보았다. 성능 테스트는 k6을 사용했다. 토스 연결 서버에서 좌석을 5분간 HOLD 상태로 변경하고, 주문 번호와 결제 금액을 포함한 예약을 생성한다. 결제창 진행 후에는 프론트엔드에서 전달받은 paymentKey, orderId, amount를 이용해 백엔드가 토스 결제 승인 API를 호출한다. 승인에 성공하면 별도 DB 트랜잭션에서 예약 상태를 CONFIRMED, 좌석 상태를 RESERVED로 변경한다. 이때 저장된 예약 금액과 전달받은 금액
WPF 클라이언트와 Spring Boot 서버 연결 로그인에 사용할 회원 정보를 JPA 엔티티로 정의했다. 이메일은 로그인 식별자로 사용하기 때문에 중복되지 않도록 설정했고, 역할은 문자열로 저장하도록 구성했고, 역할은 DOCTOR, NURSE, ADMIN으로 구분했다. 만들고 있는 티켓 사이트와 비슷한 스프링 시큐리티 구조를 가지고 있다. WPF에서 로그인 요청과 세션 쿠키 관리 WPF의 서버 통신은 AuthService에서 처리하도록 구성했다. 로그인 상태를 유지하기 위해 HttpClientHandler에 CookieConta
토스 결제 인증부터 Spring Boot 예매 확정 가예약 생성 토스 결제창 호출 사용자 결제 인증 백엔드에 결제 승인 요청 토스 승인 성공 DB 예약·좌석 확정 프론트에 성공 응답 결제 전에 가예약을 생성한다 POST /api/schedules/{scheduleId}/reservations/simple { "seatNumbers": ["A1", "A2"] } 백엔드는 선택한 좌석을 확인하고 DB에 저장된 공연 가격으로 총금액을 계산한다. 주문 번호와 주문명도 이 단계에서 만든다. String orderI
켓 예매에 필요한 공연 정보를 조회할 수 있도록 API를 구현했다. 이번 구현 범위는 공연 목록, 공연 상세, 회차별 좌석 조회다. ERD API 구현 - 공연 목록: 전체 공연과 각 공연의 회차 정보를 반환한다. - 공연 상세: slug로 공연을 조회하고, 없는 공연은 404를 반환한다. - 좌석 조회: 회차 ID에 해당하는 좌석을 좌석 번호순으로 조회하고, 선택 가능 여부를 반환한다. 구현할 것 다음에는 사용자가 선택한 좌석을 바탕으로 예매 정보를 DB에 저장하는 기능을 구현할 예정이다. 예매 생성과 좌석 상태 변경을
병원 관리 프로그램을 만들면서 WPF로 기본 화면을 구성하고, MVVM 패턴을 적용해 메뉴에 따라 화면이 전환되도록 구현했다. 이번에는 대시보드와 환자 관리 화면을 연결하면서 XAML, 데이터 바인딩, Command가 어떻게 함께 동작하는지 배웠다. XAML로 기본 화면 구성하기 화면은 왼쪽 사이드바, 상단 제목, 본문 영역으로 나눴다. - Grid: 행과 열로 전체 레이아웃 구성 - StackPanel: 메뉴와 텍스트를 순서대로 배치 - Border: 배경색, 테두리, 여백 설정 - UserControl: 대시보드
대용량 DB처리를 해보기 위해서 간략하게 티켓사이트를 만드려고 한다. 티켓 예매 사이트의 프로젝트 구조를 정리하고 로그인과 회원가입을 구현했다. 프론트엔드는 Next.js, 백엔드는 Spring Boot로 구성했고, 개발용 데이터베이스는 Docker Compose로 MariaDB와 Adminer를 띄우도록 설정했다. 회원가입 요청을 받고 검증하기 회원가입 요청은 MemberController에서 받는다. @RestController @RequiredArgsConstructor @RequestMapping("/api/mem
최근 7일 조회수순
최근 7일 동안 읽힌 공개 글이 아직 없습니다.