나는 요새 wechat api를 개발중이다 javascript도 xml도 css도 모르지만 여튼 하고 있닿ㅎㅎㅎㅎㅎ 기존 코드에 유지보수를 하고 있는데, 내부의 base libary 버전이 이제 버전 리스트에서도 안보이게 되었다.. 그 말은 즉슨 베이스 라이브러리를 교

위챗 미니 프로그램에 개발을 하는데, 위챗은 https가 아니면 접속이 불가능하다.디버깅 모드 내에 설정을 하면 https 접속이 가능하다고 하지만, 그거는 ide 내부의 시뮬레이터에 한정된다.카메라로 촬영을 하는 로직을 추가하는데, 시뮬레이터로는 도저히 실행이 불가능

회사 내 서비스의 어드민 프로젝트가 있는데, 어드민도 서비스 단위로 생성되있지 않고 2개 서비스를 한개의 프로젝트로 개발해놓았다.그래서 추가 개발이 있을 때, 사이드 이펙트도 터지고 불필요한 검수도 하게 되고여러모로 번거로움이 있어 프로젝트를 분리하게 되었다.정말 간단

개발을 하다보면, 프로젝트에 대한 문서가 필요한 경우가 있다. 프론트, 앱 개발자와 소통하는 목적일 수도 있고, 어떤 API가 구현되있는지 확인하는 목적일 수도 있다.Spring Boot에서 가장 흔하게 사용하는 DOCS는 Spring Docs와 Swagger가 있다.

vue.js 환경에서 다국어 작업 (typescript)vue도 typescript도 써본 적이 없어(사실 프론트 자체를 거의 안해본,,,) chatGPT의 도움을 많이 받아서 다국어 작업을 진행했다.다국어 작업으로 화면에서 처리가 추가적으로 필요하지만세팅하고 어떻게

특정 Entity의 컬럼을 확인하고, 검증하는 일은 해당 Entity 내부에서 해야할 일이다.쉽게 표현하면, Entity 내부에 구현된 메소드를 호출하는 것은 Entity에게 물어보는 느낌이라면Service단에서 Entity가 해야할 일을 직접 구현하는 느낌은, Ent

5. 형식 맞추기 프로그래머라면 형식을 깔끔하게 맞춰 코드를 짜야 한다. 코드 형식을 맞추기 위한 간단한 규칙을 정하고 그 규칙을 착실히 따라야 한다. 팀으로 일한다면 팀이 합의해 규칙을 정하고 모두가 그 규칙을 따라야 한다. 필요하다면 규칙을 자동으로 적용하는 도구를

date range picker를 사용해서, 날짜를 검색하는 기능에 대해서 만족하고해당 기능을 응용해서 하루 날짜에 대한 매출 검색, 월별/년별 매출 검색을 구현하려고 했다.우선 하루 매출 검색을 구현하는데, 내가 사용한 코드의 경우 dateRange 타입으로 attr

기간별 검색 기능와 하루종일 걸려서 너무 뿌듯해서 영상까지 업로드!ㅋㅋㅋㅋㅋㅋㅋㅋ날짜나 월별 검색은 input으로 바로 받아서 가능한데, 기간별은 어떻게 해야하나 구글링하던 중에date range picker라는 오픈소스를 찾았다!!!설명은 frontbackend라는

오랜만에 또 블로그 업로드다!백엔드를 마무리하고, 프론트를 시작하고 나니 결국 백엔드도 리턴을 바꾸면서 같이 수정을 하면서 작업중이다.이제 수정 form과 수정만 연결하면, 환자와 매입의 기능적인 부분은 마무리가 되는데 완성이 되면 메뉴바를 만들고 그리드 모양도 좀 잡

기능 개발에 박차를 가하던 중에 코로나에 걸렸당ㅎㅎㅎㅎㅎ일주일 동안 아무것도 못하고 푹 쉬다가, 겨우겨우 매입 기능을 추가했다.추가하면서, 문제가 발생한 부분은 거래처와 매입의 관계가 ManyToOne인데, 매입과 재고의 관계도 ManyToOne이라서 조회할 때, 각

빈이 많아지고 복잡해지면 ApplicationContext 생성에 적지 않은 시간이 걸릴 수 있다. ApplicationContext가 만들어질 때 모든 싱글톤 빈 오브젝트를 초기화하는데, 이 작업이 많은 시간이 소요된다.이 문제를 해결하기 위해서 Application

어제 순항중이다가, sum 함수에서 난관을 맞이했다.....매출 단건 조회의 경우, dto로 받아서 뿌려주면 그만인데여러 건의 매출 조회는 몇 건인지, 총 얼마의 매출이 발생했는지 약환자와 침환자의 경우에 대해서도 각각 건수와 매출액 집계가 필요했다.그러면 단 건 조회

patient와 income을 매핑해놓고, income에 name 컬럼을 두는 것은 좋은 설계가 아니라는 생각이 들었다.그러면 복합키로 설정하면, 이 문제가 해결될 것으로 생각하고 우선 income 테이블의 name 컬럼을 삭제하고 복합키 설정을 했다.일대다 관계인 환

환자 정보에 대해서, 매출에서 pathvariable로 받는 환자와 매출의 환자가 동일한지 비교하기 위해서2가지 정보 이상을 매칭 시켜서 unique 제약조건 설정이 필요했다.봉프가 일반적으로 병원에 갔을 때, 생일과 이름으로 대조해보지 않느냐며 아이디어를 제공해줘서이

오랜만에 블로그를 작성하는 것 같다. querydsl 강의를 듣고, 쿼리를 짜고 이제 얼추 로직도 구현이 되었다. JpaRepository로 기본적인 find메소드나 자동완성으로 select 기능을 사용하다가, 디테일한 select가 필요해서 작업 중간에 queryds

p.145 ~ 183테스트란 결국 내가 예상하고 의도했던 대로 코드가 정확히 동작하는지를 확인해서, 만든 코드를 확신할 수 있게 해주는 작업이다. 또한 테스트의 결과가 원하는 대로 나오지 않는 경우에는 코드나 설계에 결함이 있음을 알 수 있다. 이를 통해 코드의 결함을

p.111 ~ 128스프링의 기본적인 동작 원리가 모두 IoC 방식이라고 할 수 있지만, 스프링이 다른 프레임워크와 차별화돼서 제공해주는 기능은 의존관계 주입이라는 새로운 용어를 사용할 때 분명하게 드러난다.그래서 초기에는 IoC컨테이너라고 불리던 스프링이 지금은 의존

querydsl의 강의를 보니, EntityManager가 나온다. Spring Boot를 사용하면, 내가 직접 EntityManager를 사용하지 않더라도 Application이 시작될 때, 자동으로 EntityManager가 bean을 등록한다고 한다.EntityM

로직을 작성하다보니, 생각보다 복잡하다!income이 추가될 때마다, patient의 lastVisit 날짜가 업데이트되어야 하고마찬가지로 수정, 삭제 시에도 날짜가 반영되어야 한다.날짜는 income중에서도 해당 환자의 가장 최근 방문일을 찾아서, 그 날짜로 반영되어